Counterpoint: when every developer is urged to build something with "measurable impact", you end up like Google, where people launch something visible, get promoted, and move on, leaving the service to wither away.
Arguably that means you have bad easy-to-game metrics. I wouldn't call what many (most?) Googlers do "impactful". More like "Let's keep a bunch of smart people busy so they don't get hired by our competition"
If the service you built withers away when you move to a different team, it was a pet project that The Business doesn't care about (because it has zero impact). Literally the definition of a bullshit busywork job :)
How is this a counterpoint? The above is advice to developers seeking to improve their career, not executives at large public companies making hiring policy decisions.
The fact that goog is well known for starting projects then killing them, suggests to me they don't really appreciate the measurable impact of their work.
How do you even know the actual impact you had on revenue/profits? Engineering is often many layers removed from customer interactions, sales and accounting. Some companies have complex and opaque revenue channels. Frankly I take any claims of direct revenue/profit growth/generation with a grain of salt. Typically at best, you're wildly guessing, at worst, you're outright lying.
The PM you worked with should be able to answer this question. If they can’t, your project is likely a waste of time.
The signal from a hiring standpoint is that you asked and cared about this. Engineers who will just do whatever are less useful/impactful than engineers who push back and care about the value they’re delivering. Even if it’s sometimes fuzzy to estimate.
Your original example is very specific, but your follow up clarifies that the reality is that it is vague guesswork. I think you could claim contribution, but very hard to define that line x of code written last Friday resulted directly in y% of profits.
To me it signals you're probably exaggerating. You better be able to back up your reasoning behind your claim. Bold claims require bold explanations.
This goes back to the tying of a SQL query directly to profits. That would be an interesting story if it were true, but such a story is probably an extreme rarity.
We're talking about calculating the impact of your weekly or daily work directly to profit generation. There is a level of granularity and detail to your claim that is likely impossible to realistically calculate, so it would be very hard to accept such claims at face value.
"I made the query for X, an operation that is performed Y times per day, Z% faster resulting in N% increase in Xs performed daily. This meant we could (defer hiring additional headcount|do more <profit-generating/cost-limiting process dependent on X> per day)."
Many teams don't invest in the tooling required to measure this kind of impact, but it's possible to ballpark it.
That’s a good example. The math doesn’t need to be precise, and you don’t need to track it down to lines of code. “Part of team of X developers who delivered product Y that produced $Z in revenue.” is enough for anyone to very roughly ballpark-estimate impact.
This is counter to GPs initial point, where there is a specific claim of direct profit generation. The advice is now just getting watered down into vague ballpark estimates and tossing in a revenue number onto your resume. The advice might as well just be "work on successful projects", which is "thanks captain obvious" advice.
The success of the project as a whole is measured, of course.
But it's 20 people working on it, from design to sales to ops to customers relations to devs. How could you possibly pin 20% of the profit (not even the turnover, but the profit) on one guy?
Even if he improved the SQL queries and that immediately led to more sales, making the choice to work on that over other things was probably not his.
Nobody is asking to pin all that on exactly one person. That’s a silly overly engineery way of looking at it.
It’s a team effort. Being part of the team who did X is enough. You can then talk about your specific individual contribution when appropriate.
Just like everyone in an NBA team “wins the championship” and gets to put “winner” on their resume. Or how hockey players say “I won the Stanley cup”, even though they did it as a team.
This seems to be completely counter to your initial post tying weekly/daily work directly to profit to determine what is worth your effort and what to put on your resume. You even give SQL queries as an example, so I don't see how that's not trying to tie it down to the lines of code.
There's a big difference between:
1. I optimized SQL queries for Nameless Corp to increase profits 20%
2. I optimized SQL queries for Nameless Corp on a multi-million dollar project.
> The PM you worked with should be able to answer this question
Most software devs work on tiny fragments of large projects. Let's say I work in Microsoft on Bluetooth stack in Windows 10 - how do I translate that into increased Microsoft profits?
You are talking about the project/product itself. Does your company sit down each quarter and crunch who specifically was responsible for the revenue and profits that quarter, down to the employee or lines of code? Doubtful.
it’s _very_ easy to calculate your impact, or the one of your team, when you work on meaningful projects. if that’s not the case, you are probably working on non-essential things.
I think that's rather naive. A lot of work engineers do involves either keeping systems afloat or minor alterations that in cohort lead to a new feature but each minor alterations itself not doing anything meaningful. Evaluating individual or even team impact in those cases is _hard_. Yes, product people or in some cases managers do it but most of their numbers come with five asterisks to cover their asses as they are largely bs.
There are definitely people who are impactful enough and deserve to make bold "I" statements but they are in the vast minority.
Down to the lines of code written? Your product may get millions in revenue, but you wrote a single module out of hundreds, how much % do you take credit for?
Also it sounds like a toxic culture if you have to constantly try to tie your day-to-day work directly to how it impacts new revenue and profits or else your work is considered worthless.
If the takeaway is, "never work on internal tools," I've worked at companies where the internal tools were more valuable than anything customer-facing.
If you're great at optimizing SQL, probably just doing that in any place you can get your hands on will make a pretty big impact.
Overall impact is more helpful than resume points, IME, especially when references are involved.
If optimizing an internal tool can raise profits by 20%, I don't understand your disagreement. The comment you're replying to mentioned profits vs. unnoticed efficiency, not internal tools vs. consumer-facing software.
If it makes a big impact, it makes a big impact.
> If you're great at optimizing SQL, probably just doing that in any place you can get your hands on will make a pretty big impact.
This seems like an argument that there are no priorities and no things that are more important than other things. I don't think you believe that.
> This seems like an argument that there are no priorities and no things that are more important than other things. I don't think you believe that.
On the contrary, I'm arguing that making an impact wherever you can is better than avoiding things that don't meet some criteria of "things that are likely to help my resume." The priority I'm advocating is, making an impact by applying your skills (or even better, learning new skills) to solve problems that you can find (or are brought to you).
This is how you'll build a breadth of experience (which will be valuable for employers) and identify a niche that you enjoy (which will be valuable for you).
> If the takeaway is, "never work on internal tools," I've worked at companies where the internal tools were more valuable than anything customer-facing.
Yes, but they're exceptions.
> Overall impact is more helpful than resume points, IME, especially when references are involved.
The vast majority of the best paying jobs out there (FAANG), don't care at all about references.
It's a big world, it depends a lot in which circles you move around, I guess.
Disclaimer: I do work at a FAANG. I'm not sure what circles you're talking about.
"References" in the traditional sense may not be an important thing. But certainly being able to back your resume claims – whether with skills from that experience, or with people who will vouch for you – is important. If it wasn't, we could all just put "Optimized SQL and improved profit 20%" (or anything else) on our resumes, no?
I participate in interviews from time to time. I don't ask a lot of trivia-type algorithm questions, but I do try to size up where a candidate has invested their effort so far. Have they invested it in trying (and learning) to solve problems? Or have they invested in in padding their resume? I'll take the former over the latter every time, even if they don't have a bunch of brag-points on their resume.
If you “improve admin interface load times by 20%” do the calculation on what that is in saved time and possible money over 5 years. Then you have both.
You should of course have someone in management agree to your numbers and approve that you can use it on your CV.
Unfortunately saving time/money is not as sexy as increasing revenue.
I learned this once by creating a tool at a telecommunications company I was working at. It made it significantly faster for Technical Support to initiate a Remote Desktop session with a customer. We ran reports on how many RDP sessions we started per month; and recorded how much time the tool saved. At the time it was estimated to save about $2.1M in time savings every year, at a time when the Tech Support queues had long waits.
Couldn’t get any traction with management. Had some grassroots growth internally until we were asked to shut it down since it was an unofficial tool.
Meanwhile they would chase sales campaigns or marketing stunts that might result in $50-100k in new sign ups.
Nobody cares how much you saved in time because it doesn’t get reported anywhere. It shows up on no important metrics. Sales going up by $100K is sexy. Admins handling an extra ticket per day because the interface is quicker isn’t.
This is the kind of inefficiency that startups can use to get ahead of established competitors. So don't be sad, this is just a reminder to be an entrepreneur.
> Nobody cares how much you saved in time because it doesn’t get reported anywhere. It shows up on no important metrics. Sales going up by $100K is sexy. Admins handling an extra ticket per day because the interface is quicker isn’t.
I don’t get that. Solving an extra ticket per day should somehow correlate with either revenue increase(indirect) or cost saving(direct), right?
Revenue increase; unlikely. Cost savings? Yes. But does it?
Managers want big teams. It makes them look good. Having 15 direct reports looks better than having 10. That means the manager needs his people to be efficient enough to look good on paper, but inefficient enough that he gets to hire more people. Having a bigger budget and higher headcount makes him look good.
yeah, I've read a lot about automation here where this was a common argument, also I noticed this in the company I work for as well. If you are in IT or the user yourself and automate something it doesn't really get recognized by management. I think the only time automation is recognized by management is when it's on the agenda of management itself, e.g. if it's said that 20% of the people have to go and for that to happen there has to happen automation (and outsourcing). However, in this case the idea comes from management so there would not be much recognition for the ones doing the automation (also with the reduction in workforce it wouldn't be appropriate for mere workers to ask for a bonus/raise! Of course that doesn't apply to management..). Automation really is a good example of how dysfunctional (or averse to change) big companies are.
That’s why I said profits not revenue. Specifically to capture that 1 & 2 might be the same work :)
Just talking in terms of business impact puts you miles ahead of other candidates in many eng jobs. Especially for levels above junior. Very important to have engineers who (want to) understand why they do what they do.
What looks better on a resume?
1. I optimized SQL queries for Nameless Corp to improve admin interface load times by 20%
2. I optimized SQL queries for Nameless Corp to increase profits 20%
If possible, always work on some version of option 2.