Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front.
IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine.
So certainly "can fix bugs and write docs and tests" isn't sufficient for that promotion. A junior engineer and a manager who is at least partially paying attention can get that done.
I also don't really disagree with the evaluation that 6 months of Senior level work isn't enough for a promotion, especially if nothing actually shipped.
I get that constant reorgs are frustrating. That alone is enough of a reason to not work at Google or another BigCo. That's the real problem here.
> Writing documentation and fixing bugs is in fact not the bar for a senior software engineer.
The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
In some cases, the biggest problem is building and launching something shiny and impressive. In other cases, the biggest problem is fixing bugs. Refactoring complex/unstable systems to make them more simple/reliable. Figuring out the things that no one knows, and writing clear documentation for it so that no one will need to be blind again.
The sign of a good leader is correctly identifying the right thing to work on, and then getting it done, regardless of how "menial" it may seem. A culture where people are only recognized for working on shiny things, leads to organizational clusterfucks like Google's hangouts/allo/duo fiasco.
> The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
You're missing the crucial step of advocating for these problems to be solved. Until you know this is actually something important to the organization, you're just scratching your own itch.
In OPs example, did it really matter that the data was occasionally bad? Quite often analytics exist to check a box in a sales pitch, but nobody actually looks at them. OP couldn't quantify this impact for the promotion committee because they likely didn't quantify it for anyone but themselves.
I worked on one such app. It was lost in the cross fire, I was asked to try to fix a bug. I came back and said this wasn't a bug, it was a badly built system. If they wanted me to work on it, I'd need a few sprints dedicated to it. They passed. A month or two later, it was impacting some crucial flows. We revisited it and funded it. I AB tested the rewrite against the original and saw a statistically significant improvement in user behavior. We retired the original, I presented my findings to our product team. They agreed it was impactful.
>>The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
Yeah, right.
People who hold the current power will never let you do it. For one simple reason. No one likes to be promoting their next boss.
In fact in most companies merely talking about 'biggest problems plaguing an organization' can get you fired. No likes to be told that the current bosses aren't up-to their job.
Organizations that wish to be successful are designed so that you can't promote your next boss. Engineers and management are different things. Engineers can be promoted and do impactful work and identify problems and get promoted some more, without ever threatening to become anyone's boss.
Then, your engineers can be rated based on how well they solve engineering problems, and management can be rated based on how well they manage human capital and allocate between the various engineering problems that need to be solved. Certainly there's some politicking based on prioritization, but that's not a bad thing. You don't want to accidently solve problems that no one really needs solved, its a waste of time.
Sure shitty organizations exist. That doesn't mean organizations are always shitty.
At my current position I have been hired to help rewrite an application and I was literally taken aside and talked to for saying, verbatim, that "the application was built for business needs that no longer exist, and we need to update it for our current requirements", because it upset people by implying that the code they wrote 5 years ago was no longer perfect.
It seems like any organization that grows beyond 2 layers of management turns into an organization that spends the majority of it's time posturing rather than attempting to get anything done
The role of a senior software engineer totally is to handle bugs and produce docs. The difference is that seniors should expect to work on more difficult systems, bugs, and documentation tasks.
When we don't value docs and bug fixing, we create undocumented and buggy code. When we don't value it by relegating it to junior developers, we miss opportunities to mentor others by both explaining the system at a high level and also using failures as teachable moments at the line level.
A Senior developer who shows understanding of multiple systems at a high level (making docs) in an organization as well as being able to understand and deconstruct the work of others (fixing bugs) consistently is qualified for a higher level role where they work across multiple teams of developers.
To me a senior software engineer can, with mid and junior engineers at their disposal, design, document, implement, deploy and maintain systems that have a demonstrable ROI for the organization for a long period of time after deployment.
The notion that "a junior engineer and a manager who is at least partially paying attention can get that done" is a horseshit excuse that could be applied to 99% of what any given developer does. Moreover, developers find themselves having to write tests and fix bugs because the priorities of upper management didn't allow it or foster it for the last developer.
> developers find themselves having to write tests and fix bugs because the priorities of upper management didn't allow it
Well there's your problem. If fixing those bugs isn't aligned with the priorities of upper management then you are either working on unimportant bugs or your org is screwed. You going rogue certainly isn't the solution.
I see this a lot. Developers place their priorities and biases over actual business direction. And then feel shocked when they are told their contributions weren't impactful. I've shipped enough dead code that nobody really used but it checked a box on a sales call to know that quality software isn't always what we're selling.
The problem is dishonesty. I've never worked for a company that would at least admit "our primary focus is selling rather than software quality". I know it should be implied, but when work is advertised as "looking for ninja pro engineers dedicated to their craft to help build top notch software", no wonder people get misaligned on values.
Have you ever worked for a company that was faced with running out of money? Things get real pretty quick when you hear you only have X months of runway.
Then upper management needs to be forthright in their priorities. Have you ever worked somewhere that didn't tell their developers something like "we expect clean code and quality software"? I don't think I've heard of somewhere that owned up to the fact that their primary interest was to pump out software despite a lack of code maintainability. I'm sure that the teams that produce hot garbage for Oracle tell themselves that they care about code quality.
In that case, developers are expected to read between the lines, which is quite an antipattern in doing business with any company. If you're essentially being lied to, the deal can only get worse from there.
Developers having a level of autonomy to address problems is what you consider "going rogue"? I guess it looks that way if I squint, but if developers can't decide on their own to address problems, that's not somewhere anyone should want to work. I wouldn't even want to be the slavedriver who sees their developers who are solving legitimate problems as escaping the plantation. A good manager should, rather than see this behavior as rogue, try to work it in to the existing process. A healthy development cycle should allow developers to allot a level of time or effort to address issues, and even junior developers can know better what needs to be addressed than someone who hardly touches the code.
You're right, going rogue isn't the solution; it's a sign that leaving the organization may be the solution.
There is a balance between the developer's priorities and that of the business. A business that doesn't care about a developer's judgment is totally myopic and self-deluded into thinking that it knows best about the nuanced facets of its operation. Concurrently, developers have been paid to do a job, and if they divert too much from what that job is, that can be doing wrong to the hand that's feeding them. Yet, if they are being set up to fail by the company(e.g. insufficient time allotted to maintenance), they are faced with the choice to "go rogue" in an attempt to save themselves and perhaps the company if they can see a rude awakening up ahead. As much as you may see this as transgression, this kind of situation is ultimately set up by the employer and they are solely responsible. We're not talking about employees doing their own side projects on the company time; they may literally be trying to save the company from itself.
Employees are going to going to exert some form of autonomy even when it's not granted to them. Those who are in positions of power can choose to harness that initiative instead of viewing it as a threat.
Yeah, I agree with you that you can't build a system where people get promoted to Senior Software Engineer just for fixing bugs and writing documentation. I do think it should be worth something.
It doesn't take a senior engineer to fix a bug, but I believe that it is a senior-level skill to be able to identify subtle bugs and pick which ones to fix.
The current situation creates perverse incentives because nobody wants to fix bugs, and everyone suffers for it. The team executes slowly because everyone has to wade through dead code, undocumented code, buggy other components. Time you invest in fixing things would probably be a net savings for your team/Google, but are probably not a net savings for you personally.
I adopt the Joel Spolsky measure of a developer as someone who is "smart and gets things done." I think a good reward system should incentivize picking the right tasks and making high-value contributions to the team, regardless of whether a lower-level employee could have theoretically done the work if it was specified and assigned to them.
Certainly it counts for something. And I fully support it leading to great reviews for OP. But being good at your job isn't the same as being able to do the next job up the promotion ladder. OP was likely on if the most impactful engineers at his level, but he failed to demonstrate he could perform the job of a Senior Engineer, which has a much greater scope than bug fixes and documentation.
Everyone calls it out as playing politics, but really it's just metric driven career development. If you can't/don't measure it, how do you know it improved? How do you know there was a gap in company value to start with?
The issue with this is that it leads to people choosing projects based on what they think is promotable and doing the bare minimum on anything else. Which is how you get code with no tests or documentation.
I think there needs to be some recognition for people who saw that there was a real need for some grunt work, and the business was suffering because of it, and went and did the work. The key part about this that I would consider "senior" is being able to look at everything that is going on and figure out what is actually critical.
> Which is how you get code with no tests or documentation.
Without knowing this is actually detrimental to the org, I don't find this to be a problem in and of itself.
> there was a real need for some grunt work, and the business was suffering because of it
I would expect a Senior Engineer to be able to advocate and justify this grunt work.
> The key part about this that I would consider "senior" is being able to look at everything that is going on and figure out what is actually critical.
"Actually" is the operating word here. This requires external validation. If you feel you've saved the company but can't convince anyone of it, then you probably didn't save the company.
I obviously don't work for Google - so an outsider's opinion:
- Expanding on op here, senior software engineer isn't one who is doing more junior work: It is pretty much a different job profile. You are making higher order decisions.
- Promotions come with a lot of timing as well: Honestly talent evens out after a bit and luck/timing/inter-personal skills tend to take over. I have seen excellent code bases that nobody cared about. I have seen a lot of pretty crap code generate billions of dollars (and trickle down to the devs as money/levels).
- Re: Reorgs: life is mostly unfair. I heard this in an ad and it stuck, 'we lose more than we win'. I am surprised you stuck with that manager/team for that long though. Career is a lot about making the right bets in terms of companies / managers / teams as well. I have had reorgs affect me negatively and positively (they shutdown the project and promoted me anyway - a long time ago in ms), so there might be some survivorship bias here. I guess I do try to project every situation into what the protagonist could've done better instead of sympathizing :/.
In an ideal world, we will have people who can grow (and make more money / level etc) in both dimensions: Vertically in terms of responsibilities and horizontally in terms of quantity of same level work / team dynamics etc. In practice we have a system pretty much everywhere where growth is defined solely vertical. This leads to a ton of actual problems too: You get a person really really good at coding / execution but shit in big picture thinking / broad system design choices / cross team work etc. spend a bunch of time in a level. Now you have to either promote him into a spot where s/he will fail OR lose em to attrition. Either choice tends to break.
A quick note since I have seen some people change / grow / learn in these unsuitable positions against odds: All these actions have a probability function in they way they work out. so take my points here about eventualities of various promos with a pinch of salt. Some do end up working out and these anecdotal statements obviously don't apply there. I do know whenever we choose to push / recommend a promo, we definitely are hoping for it to work out though :)
> This leads to a ton of actual problems too: You get a person really really good at coding / execution but shit in big picture thinking / broad system design choices / cross team work etc. spend a bunch of time in a level. Now you have to either promote him into a spot where s/he will fail OR lose em to attrition. Either choice tends to break.
I hate this issue, and see it occur in so many companies. Why are we so opposed to simply paying more/increasing benefits of people at the same level? Why can't an "regular" Engineer just get a large raise for being an amazing Engineer, because that's what you need! Instead, they need to be come a "Senior" Engineer who also has some kind of other management-type job that they suck at.
Yea this is maddening. “We can’t pay you anymore because The Book [1] says we can only pay people at your level from $X to $Y and you’re at Y. We can’t promote you because you are at the highest individual contributor level. And we cant make you a manager because you’re on a 2 person team and there is nobody to manage.”
“OK So I guess I need to leave.”
“Why oh why can’t we retain our talent????”
So ridiculous. You need an IC career track that is rewarding and achievable.
1: yes, they actually pointed to a physical book that described some industry standard of what software engineers must be paid.
Diving into a old undocumented codebase and then deleting code, rewriting code and document it without breaking stuff can be more challenging than designing and writing new code.
"terminal level", in the sense being used by the OP, doesn't mean "end of the IC track". It means a level that you can be at "forever". Often times the junior engineering levels have some expectations around eventually being promoted (ie, "up or out").
IIRC, at Google the levels below Senior Engineer require progress toward a higher level as a job requirement. So that even if you're performing well at that level, if you aren't showing progress it gets counted against you in perf increasingly until eventually you are at risk of being pushed out.
Terminal level and Max mean different things here.
Indeed you can become a senior fellow at Google, but you aren't expected to. You are however expected to hit senior at some point in your career. There's no requirement to grow further, so the bar for senior is high.
I think google itself follows that same path of promotion, ending in a fellow position after distinguished engineer? I wonder how many people at google have the fellow title.
It doesn't sound like they meant that senior was the last possible level, just the last level to which promotion in a career should be expected through "normal" growth and development. It looks like less than 1-2% of engineers at my company (FAANG) are above "Senior".
yeah, but responsibilities (and technical complexity) grows with each step, and many people, for whatever reason, stall out at one level for most of their career.
If you word it that way, it sounds incredibly easy. Actually, what that person did was identify problems in legacy software, reverse engineer them (a hard thing), document them (reduces maintenance/extension costs), and fix problems. A company Google's size will be making most of its revenue on legacy systems that constantly need extension, repair, and refactoring. They'll sometimes do something clean-slate but improving legacy stuff is a high-impact skill.
So, a mix of hard and useful work on numerous legacy systems that can be used to improve revenue-producing systems does sound like it merits some senior, software engineers. Heck, at a lot of companies, there's always senior software engineers guiding people through legacy projects just out of fear of breaking mission-critical systems. Usually a mix of a knowledgeable veteran and some junior coders for grunt work. Whereas, making new features on well-documented, well-tested systems is so easy in comparison that it surprises me that this alone can get people into senior positions if evaluations are done right.
I think you are mostly correct. But the problem with Google's promo/perf process is that there has until very recently been the expectation that all employees eventually get to Level 5 (Senior Software Engineer). When I started it was outrightly stated that if you didn't get to this level within 5 years, you would probably end up getting, ehh... scrutinized.
They have since backpedaled on that, and now it's not an expectation. But you can imagine what kind of frustration this can lead to if you're continually passed up for promo to that level.
There's also the problem of comparing apples and oranges.
The lack of metrics is a problem. But the bigger problem is the interesting non-maintence-mode projects went from 0 to somewhere, or from 7 to 8 and a bit features' and that's a lot 'cooler'/'bottom-line demonstrable' than 'I made the thing break less often and less breakable and more understandable'.
It also says something that Google isn't measuring itself very well, although this is one anecdotal data point, I'm sure it's not the only one with the 'defrag' reference, relocation/churn etc. etc.
I also take issue with your documentation reference. The existing lack of documentation was probably caused by other Senior Software Engineers?
At a certain level promotion is not about just doing something well. Funnily enough, his plans now are to go do other things (presumably well) without a particular sense of direction and hope that it works out.
IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine.
So certainly "can fix bugs and write docs and tests" isn't sufficient for that promotion. A junior engineer and a manager who is at least partially paying attention can get that done.
I also don't really disagree with the evaluation that 6 months of Senior level work isn't enough for a promotion, especially if nothing actually shipped.
I get that constant reorgs are frustrating. That alone is enough of a reason to not work at Google or another BigCo. That's the real problem here.