One thing I often find in salary negotiation advice are lines that go like this "At my last company, I increased sales by 3% by $YADDA_YADDA".
The thing is that I can't really think of nice metrics like this, and am surprised that a lot of engineers would find something as significant as sales numbers.
For one thing, the further your metric is from strict revenue, the harder it is to put a price tag on it. A sales number is easy, but if you optimized some part of the code somewhere, it becomes much more fuzzy and longer to explain. Sure, Patrick also pushes people to get jobs were your contribution is more directly correlated to revenues, but not everyone will want a job like that, and until you do get one, you can't use that.
The other thing is that I feel it's easier to consider a sales person as directly responsible for a significant increase in revenue for their market. But engineers work in teams, so saying "I increased sales by x%" is hard to justify: what about the Product Manager that spec'ed it out? What about the rest of the engineering team that worked on that change, reviewed it, pushed it to production? If you're the only one doing all that, sure, but that's rarely the case.
So, what's a good way to come up with relevant, justified metrics like that?
Sales guys very rarely tie their stomachs in knots with "So I suppose technically I might have talked to five million in new accounts last quarter, but most of them required new features, so I'm not sure I can justifiably claim credit for that one without splitting it with the engineering team." One might start learning from that example. Did you lead development on a new product with $5 million in sales? Then I might describe that as leading development on a new product with $5 million in sales. I wouldn't recommend optimizing SQL queries on a screen no one actually uses, but if that is your day to day activity, you were improving performance of the company's flagship product which launched to over $5 million in sales. If you're optimizing page load speed then presumably you tracked the before and after and, if you don't have great data about how that trickled into the business results, you can at least say "I shaved 5 seconds off our dashboard. Research from Google / Amazon / Microsoft / etc has found that page load speed has the following quantifiable impacts and that the sensitivity is on the order of 100 ms, or roughly one fiftieth of the improvement I delivered."
You can also either a) engineer your transfer to the part of the company which makes money or b) engineer your work duties such that they include things which will help career growth. For example, A/B testing both prints money and gives very relevant, justified metrics which are likely to include things motivational to decisionmakers at current and future employers. If you are an engineer in a company which doesn't A/B test but could, you should make that sale internally, and then nominate yourself as the obvious person to implement it.
patio11: just to play devil's advocate here, you have posted in the past that you have never made more than $60k per year[1]. This prompted a much attacked post [2] that is actually sort of structurally similar to this one (how to get more money for engineers), but aimed at you specifically rather than others, which made it strange.
Can I ask you the extent to which your points are field tested? Within the last 488 days, have your salary negotiations actually paid off, and who have you been negotiating with given that you are an entrepreneur with your own company?
This is not meant as ad-hominem and I like much of your writing. But you are like a sports trainer recommending a workout plan, and it is not unreasonable to ask whether you are actually in shape.
A couple points, First of all I am a heat seeking missile for praise. For me, I've never optimized my life or life style for money.
Think of negotiation as levers that can be moved. I've discovered how to move the levers, but I haven't moved them because I'm not optimizing for money.
This is an article about moving the levers, not about optimizing the levers.
I know what you're saying, but sales guys benefits from the perception that they're solely responsible for the close of a sale. That's their job after all. So the $5M in sales? It wouldn't have happened without them! (that's the perception)
if that is your day to day activity, you were improving performance of the company's flagship product which launched to over $5 million in sales
Already there are more steps. You know he didn't sell that himself, a sales person did, and the link between performance and number of sales is unclear without knowing the product. So, to me, the $5 million number is nice ('ok so he was trusted to work on that important product') but feels a bit irrelevant when asking for a specific offer increase.
For whatever reason, it doesn't convince me that this candidate in particular couldn't have been replaced by another candidate for the same result. In the example of a sales person, I'm more easily convinced that s/he was influential in the result. edit: I guess it's because sales is so much more of a "people" job than engineering.
But maybe I'm just pointing at what you've been saying: take a job closer to the money…
"For 9 months I led development on a project that did x, y, an z. I delegated work to 5 other engineers and spent about 30% of my time coding/architecting. The released product took in $15M in revenue the following year."
"For the last 2 years I've been on a team of 5 software engineers who work on one of my company's top portfolio products, which nets a revenue of $200M per year. I was the architect of one particular feature which boosted sales $25M the following year, and coded half of it while leading 2 other engineers to finish it to completion."
It helps not to think of $$ as being a direct tie-in to what value the engineer provides, because again, we aren't _that_ close. It does help to understand that there is some tie-in - ie. as an engineer, that you get that you are essentially building stuff to make money and you are cognizant of the consequences of your work. On another level it demonstrates that you have status to be in positions of that much importance. But you don't want it to come off like bragging, it simply is some metric that could easily be read off from a project post-mortem.
Good managers know that it takes more than the sales guy to close the deal to make that $5MM deal work. The sales people know this, too. Aftermarket support and/or production issues mid-stream are the bane of our existence. When it goes well everyone deserves the credit.
Now that I have that experience if I saw a non sales person place something like the above on their resume I would be very intrigued. Not because they're claiming responsibility (which I don't read into that) but because it says to me that they see their place in the whole system and how they contribute. That is really rare and really valuable. Like you say it's harder to see it when you're not in front of the customer, but if you do see it I think it means you're probably an "A" player.
For example, I used to sell heavy equipment to the concrete industry. In the back shop there was a manager of a unit that did about 25% of the work that needed to be done to build any machine that I would sell. He didn't have any direct contact with the customers. He didn't sit in on any sales meetings, and didn't have a very good idea of the forecast that was coming (unfortunately). He was absolutely critical to making each sale happen and each customer happy and he seemed to understand this. Without him it would have been very difficult to land the deals that we did. He absolutely deserves to place that he was critical to building an $8_figs business area on his resume. And by doing so I think it shows that he has vision beyond his area. I'd work with him again in a second.
He was "far" from the money but it didn't seem that way to me. He could just write on his resume that he was a Tool and Die Maker that managed a small machine shop of about 6 people. And it's true, but it doesn't do him justice.
The other problem is what happens if you ended up on a project that didn't make any money or one that lost money.
You might spent 3 years working on something and produced the most excellent work of your life but for whatever reason the end product sucked.
It might not have been your fault , the marketing might have been terrible , it could have been mismanaged or it might just have been an awful idea from the start.
It probably sucks for the guy who programmed microsoft clippy..
This is why everybody should study science for a while. ;) The tack to take is "we did this experiment, and we built the best thing we could, a thing that accomplished feats X and Y and Z, but the experiment didn't yield the results we hoped for."
Considering that figures floating around say that as many as 90% of software projects fail, there's probably many of us in that group. (I consider myself one of them.)
There's got to be a way to put a positive spin on a project that was late, over-budget, rejected by the customer, poorly specified, technically misdirected, utterly mismanaged, and ultimately written off as a huge waste of time, money, and energy. But just saying "I learned a lot about how not to do things" doesn't really impress anyone.
"We made a number of technical errors. We decided to try using a brand new datastore called NoDB. Unfortunately, it turned out that our learning curve on NoDB v1.234 was steeper than we expected. It's an amazing product, but it's new and not yet well documented so it took us a long time to learn its quirks. I became an expert on NoDB because of all the tuning I had to do to try to improve performance and it's a fantastic product. I think that YesDB would have been much faster to learn but by the time we realized that, the project was cancelled.
However, with what I learned from that experience and what you've told me about your project, I think that NoDB would be a perfect fit. It has yaddayaddayadda features. What do you think?"
Yep. It's seen as bad form to criticize former or current co-workers at a job interview but sometimes the only honest answer is "all my co-workers were either lazy or incompetent but I'm better than them hence why I'm looking for another job".
It also sucks when you do client work in web development and build a good website for somebody who then proceeds to use the CMS to create pages full of spelling errors and nasty images their nephew created in pirate photoshop so you cannot use it as a portfolio piece.
You come into an interview with me and say that, and you've just talked yourself out of a job. I don't care how impressive your resume is; don't care if otherwise you walk on water. If you can't even avoid expressly criticizing your teammates in a job interview, it sends signals that you don't know when to keep your mouth shut; that you have no idea what it means to be tactful. That in turn suggests to me that you're going to be a pain in the ass to work with and are more focused on "who's right" in a discussion than coming to a consensus.
I really, really, really hate the phrase "not a team player" but right or wrong, that's exactly what that statement would advertise.
I'll back that one up. That exact attitude is something I'm personally working on right now, mostly as a result of discovering how much it affects people's perception of my work and abilities.
Talking crap about your previous co-workers is a great way to waste interview time and convince someone you will be difficult to work with. You're in a job interview. This is best-foot-forward, "paint me a picture of how awesome you could be" time. Don't bitch about your last job, we aren't here to talk about that.
If the honest answer truly was "everyone else was incompetent", just talk about your role in the project. If everyone was really that terrible and you were really that good, you should have some awesome stories about how you helped keep things on track. Maybe the whole damn thing was a sinking ship, but you have to have done something to help keep it afloat. Tell those stories.
Anyone with half a brain will catch on that you're talking around a bad work environment. They'll appreciate your tact and file away a note that letting you talk to customers/sales/management/whoever may not be as horrible as it would with most engineers. That's a very good mark in your favor.
Oh, don't get my wrong I'd be way way more tactful than that in an actual interview.
It just sucks when you feel like you might have to defend a lot of bad decisions that were made by others and all your good ideas were overruled, I don't want to sound like "Mr Hindsight".
Curiosity: Have you actually been in the position of interviewing people who said things like that and being unimpressed, or do you just feel like they're not impressive things to say about yourself?
> So the $5M in sales? It wouldn't have happened without them! (that's the perception)
Maybe there was a either a strict deadline or a challenging technical issue to overcome such that that sale couldn't have happened without your contribution.
Maybe that software was sold for $5M because it was way more stable, responsive and easy to deploy and use than its competition.
Maybe, thanks to good engineering and best practices, bugs and requests for improvement were quickly answered.
Maybe, again thanks to good engineering, that software was easily tailored to each customer's need, and customers were willing to pay (way) more.
Maybe... Start to look at your job and at your product with sales goggles and find other selling points.
Many companies I think will intentionally keep employees in the dark as much as possible about how much they are really worth to the company.
I worked in support once for an outsourcing company where I was paid only a little over minimum wage and given a number of SLAs to keep (which I usually exceeded).
When I found out years later about the actual costs to the customer of the work I was doing (management flatout refused to give us any of these numbers) I realized that I could have worked about 4 days a week on the same monthly salary and they would still have made a substantial profit on me.
Coming from academia, where we don't make money, we spend money, I wondered this too. I can come up with a badass Monte Carlo algorithm that does our computation in half the time, but there's absolutely no way to connect this to any monetary value because the end product isn't about money.
I meant coming from an academic job to a non-academic one. I'm doing well on the grant front, but I don't think that'll help me in getting a "normal" job.
There are three main ways for people to show their business value:
1. Absolute ability to add $ to the bottom line
2. Relative ability compared to others
3. Absolute technical skills
Academics transitioning to business do well focusing on 2 and 3, especially 2. If you show me that you were the top 1% of the top 1%, I'm going to be impressed.
One quick concrete example: a friend of mine got the top scholarship for graduate students at her school. This was worth maybe $7,000-not a huge amount in business terms. But it marked her as one of the two best out of 10,000 graduate students.
Most people would just put the name of the grant, but what's impressive is the fact that only .05% of applicants got the grant. Once she put that as the first line on her resume, she got significantly more call-backs.
Sounds like you've made some interesing Monte Carlo based research. Why not write about that/promote that? Get other insitutions talking about how great lutorm from $YOUR_INSTITUTION is. Will academia pay for that?
-His main role was working on a software process that generated XYZ benefit for the free users
-He increased the efficiency of that process, allowing the company to increase the XYZ's they created by 100%
-Free users who had XYZ were n% more likely to buy
-Sales were worth an average of ABC dollars
-Multiplying it all out, he was responsible for increasing the bottom line by a lot
Now, he had to make a lot of estimates, and ask people he knew at his company for estimates on some of the information. But by amassing all this information he can make a much stronger case for his value than if he could only talk about the technical work he did.
I don't think most engineers or engineering managers really give a flip... At least IME they don't.
They want to see that you can produce code. So if you can point to features/apps that you developed, or how you optimized some feature somewhere, that's what they want.
I understand that and that's kind of my point. As an engineer, you can definitely talk about what you've done to convince the other party that you're capable, but it's (IMO) more difficult to tie it to a specific increase in the offer when negotiation starts, which is what Patrick discusses.
Specifically, he puts the asked salary increase head-to-head with the potential revenue increase: "Getting me that extra $4,000 would make this a much easier decision. Considering that this is conceivably worth millions to you, we’d be silly not to do business with each other." Which indeed makes it sound like a bargain. :)
And I know it's exactly the goal of what Patrick preaches: speak in terms of value created, not technical competence. It's just, y'know, hard :)
The thing is that I can't really think of nice metrics like this, and am surprised that a lot of engineers would find something as significant as sales numbers.
One way: Did you work on a feature that was then used to sign up a client that is now worth €X?
>So, what's a good way to come up with relevant, justified metrics like that?
Make shit up.
I'm dead serious. Not in terms of "This product never existed and I'm going to lie to you", but in terms of "Everyone loved that feature I did, it probably helped retain 3-5% of our clients alone, and we were able to hire another two people the following year, so that probably works out to about 10% growth."
Seriously, if you're working on $YADDA_YADDA, then obviously there should be some justification for it, either to yourself or your manager. That's what you need to get down, stuff like: improved response times by x%, killed y open bugs, removed z lines of code, whatever your project's current major issues are.
And if you can't come up with an easy justification like that, why are you doing it? :)
The thing is that I can't really think of nice metrics like this, and am surprised that a lot of engineers would find something as significant as sales numbers.
For one thing, the further your metric is from strict revenue, the harder it is to put a price tag on it. A sales number is easy, but if you optimized some part of the code somewhere, it becomes much more fuzzy and longer to explain. Sure, Patrick also pushes people to get jobs were your contribution is more directly correlated to revenues, but not everyone will want a job like that, and until you do get one, you can't use that.
The other thing is that I feel it's easier to consider a sales person as directly responsible for a significant increase in revenue for their market. But engineers work in teams, so saying "I increased sales by x%" is hard to justify: what about the Product Manager that spec'ed it out? What about the rest of the engineering team that worked on that change, reviewed it, pushed it to production? If you're the only one doing all that, sure, but that's rarely the case.
So, what's a good way to come up with relevant, justified metrics like that?