Things change when you get closer to Principal (two levels higher) but at the staff level, despite what might be on paper, they’re just senior engs that negotiate well
(I’m speaking as someone on that track, so am as guilty as the next)
Looking at my change lists from last year, I made a bunch of new models in our backend and wrote a few pages in React. Added monitoring, alerting and shipped the product pages. You know, your typical “software engineering” work.
What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.
The hard part is self review time where I put my fantasy novel author hat on and spit out some bullshit on how my React components changed the technological direction of the company. Maybe this skill is what makes me a Staff Engineer!
“Typical” work, done well and on time with good production reliability, is often hard to get.
Perhaps it’s a sign of your seniority that you think that’s all typical. I’ve seen people release buggy code with no tests, metrics, or monitoring and think they were finished with it. That gets fixed when the more senior engineers step in and demand higher standards.
It’s sad that the baseline for quality in the software industry is so low, but that’s how it is.
Junior -> needs monitoring ~weekly
Senior -> does eng work reliably and on time, can lead a junior or maybe a few but doesn't have to
Staff -> leads Seniors (plus maybe some juniors directly)
Grandparent is mentioning that in their org there are plenty Staffs that do not lead anyone.
They are written to make a case for not prompting people. They are not guideline
No words for an insight as incisive as this.
Insightful - thank you
This is surprisingly underrated, I know a lot of senior engineers that struggle with it. The best thing I ever did for my career when I started professional software development was realize that my manager and my customers did not care about tech stack choices, or perfect software. All they cared about was that it shipped, and in a reasonable time. They could handle some bugs as long as I fixed them.
I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.
While it certainly helped my ability to look good to PMs and other programmers, it made for un-scalable, un-readable, and un-maintainable code. My company lost tons of developers due to the constant punting of code debt. It might be easy to say push back on clients but the dev team rarely had that ability unless it was a nice client. Ugh, so glad I found a better company.
Nobody cares about high quality code in a corporate environment neither should you. They're going to toss your code out of the window when some MBA from McKinsey & Co. comes and do "cost structuring" for your corporate.
Keep your craft for your open source projects if you _really_ want to do it. It's your code and it really matters to humanity if you make something good in th open.
It really isn't hard to ship perfectly good code relatively fast. I think most times when people have trouble getting code out the door without causing serious tech debt, it's because they've gone down the premature optimization rabbit hole and introduced a lot of unnecessary complications anticipating some future that doesn't yet exist.
This may be an unpopular thing to say, but at most companies, you should have less senior engineers than that doing nearly all of the "get the damn software out the door already" work. The 10-15 years experience people should really be doing work with broader impact than that. And this isn't to downplay the importance of that just-get-things-done role at all! It's critically important. But it's a ratio thing; most companies should have a lot of earlier career folks implementing things and a few later career (or just very high achieving) folks setting technical direction, discovering and advocating for new projects, yada yada yada. I think the truth is that lots of places have this ratio out of whack with respect to the actual availability of impactful projects to work on. If there isn't enough work for folks at Staff level and above beyond just knocking out crud apps, you've got a mismatch.
There's a pretty wide variation in efficacy at doing the mainstream work. It's good to retain and reward the people who are good at it, so that they make up a higher proportion of the ones doing it. Otherwise you're constantly throwing away good people and replacing them with new hires of lower/unknown quality, just because you don't have enough "strategic direction" type work to promote them.
- I had been acting two levels above my paygrade for several years;
- everybody assumed that I was two levels above my paygrade;
- considerable turnover in managers (on average, without changing team often, I changed manager about 1.2 times per year) meant that nobody realized that there was a problem;
- attempting to actually get to the next paygrade brought a reaction of "well, if he's not at the next paygrade, there must be a reason, right?"
Clearly, the ladder was broken. That's one of the many reasons for which I eventually left that job.
All my feedback was along the lines of "you're great, but next time"
When I, and about 15 others left over the same two week period as the results of those promotions were made public it was a BIG shock to the biz. Sadly I hear they are just blaming culture at the lower levels rather than the HR team who do this.
HR is welcome to attend/audit the process, give statistical analysis, check for biases, advise on how to handle underperforming employees, give compensation band advice, and execute the promotion decisions the technology group decides. But if they’re the ones deciding, you need to change your company (or change companies).
I had a three year period where that kept happening. I was already doing the job of my former boss, but their boss kept switching out and the new guy didn't know who I was and I had to prove my worth all over to them. Happened three times during that time period.
After pushing for two review cycles to get a promotion and being told "not yet, maybe next time", I finally left.
I won't waste my time on that again. If my manager gets swapped out on me there's a decent chance I'll start looking to leave too, because as you say, the ladder was broken above me.
If I have to prove myself to someone all over again, I might as well switch jobs an get a raise while I'm at it.
That understanding changed how I thought about my own career development after I moved back to an IC role.
If you get someone promoted, they get bumped into a new salary band, and thus get a larger raise — and this is outside the above pool.
From an ICs perspective, I think the takeaway is that getting promoted is almost never the wrong move and should be done as soon and as aggressively as possible, otherwise you're probably leaving money on the table.
Even in the rare event that you manage to get promoted beyond your level of competence and are now struggling to avoid being fired for performance, you just move to another company with your shiny new title and enjoy a higher total comp there than you would have gotten without promotion anyway. It's pretty hard to go wrong.
Companies that have a lot of money, tend to manage that money by dividing it up into different "pots" that are controlled by individual managers. This is just a straightforward way of managing a business, but what's not obvious at first glance is that moving money from one pot to another is hard. If a higher power has decided that the merit increase budget is 2%/y, that could be hard for an individual manager to budge. On the other hand, if you promote someone, you get the full 2% of your new budget in the next annual cycle, so your salary budget has increased by more than 2% for that year.
Another thing is that if you bump a junior up to senior, and that person leaves, nobody will bat an eye at replacing them with another senior.
What I did as an IC was that I articulated my interests to my boss in fairly plain terms. I asked: What's the process for moving up a level? What do I need to do? What goals can we put on my performance review? A lot of people are timid about this, especially as the answer might be No. One of my friends was told by his boss: "You are topped out at your level." Ouch. What I can't tell anybody is what risk they're taking by adopting any particular approach.
I don't think I engaged in any skullduggery or politics. I am in fact enthusiastic about the business, and committed to improving my own knowledge and work. Something I've told my bosses, which is completely sincere, is that I have a lot of mental flexibility, and am happy to be guided by what they think is the best for their department and the business.
It might be that my experience as a manager gave me some cred, since it was clear that I understood the process from both sides of the table.
It might be hard to hear but this is a very good answer from the boss. Your friend was told to start looking for a new job if they want to move up rather than waste their time grinding away at their current job. Much better than being sold false hope.
It really depends on the company though
1) The CEO was consulted on a particular comp plan for the new year with budgets for promotions/new hires/retention etc.
2) The CEO was almost certainly given a "generic" plan that the investors of the company + whatever data the HR team has indicates is warranted.
3) The CEO has to decide between going to bat for the employees with the investors (his boss), pushing back on HR with no data, or just accepting it.
Unsurprisingly the CEO always takes option 3 - everyone is breathing their own exhaust on what a good raise for the year is and the investors will often present a generic comp plan. You'll usually hear things like "we pay the median" or similar to justify this, but the root cause is always the same, bad data driving bad decisions.
Also note that generally these comp plans are made regardless of role. Engineering being more cyclical tends to have rapidly increasing comp on the up-cycle and struggles to match this model. On the flip side we all may be great full that HR doesn't mark comp to market.
CEOs are facilitators. Maybe this is a case of startup culture seeping in but there is always a firewall between the CEO and the rest of the c suite.