I certainly like that companies are introducing yet another step in the IC ladder. Before it was like: junior1 -> junior2 -> senior1 -> senior2 -> manager. And the money you get by being junior2/junior2/senior1 is not that much. Nowadays I see companies doing: ... -> senior1 -> senior2 -> staff1 -> staff2 -> manager.
So, in the past I have quit a job at level staff1 (decent money), just to go to another company where they label me as senior 2 (more money, but this is not the topic of discussion here). So now, I have yet another opportunity to make more money by being promoted to staff1 (and then staff2) basically doing the same thing I have been doing all these recent years.
The Staff Engineer's Path – Book Review
11–20 of 251 posts
Re: The Staff Engineer's Path – Book Review
#12I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead. Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.
Titles are very much diluted.
I've seen companies hire college sophomores who have never heard of the concept of a database and make them Sr Engineers on a analytics teams. I've seen Sr Engineers hired with one year of relevant experience.
At this point, "Sr Engineer" is just the new "Jr Engineer". There's nothing wrong with this, but indeed, Staff Engineer tends to mean 8+ years of experience.
Re: The Staff Engineer's Path – Book Review
#13This is all thats required of staff engineers? Heck, at the big consulting firms, senior associate engineers had to do all this to get promoted to manager. [context: senior associates were 1 step from the bottom rung]
This is a collection of highlights from a book, so I don’t think it’s “all that is required of staff engineers.”
Re: The Staff Engineer's Path – Book Review
#14[deleted]
Re: The Staff Engineer's Path – Book Review
#15Where do all the hardcore engineering jobs live? I've been bothered by the fact that most advanced engineering roles like "staff" actually mean "manager who does system design as well"
Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Where are the people creating amazing software and do they get a special "advanced developer" title?
I guess, I'm curious if there are actual roles in companies for people who love their craft and create software others can't. Most companies seem to be consumers instead of creators and only offer Jr.-to-Sr. level roles around making a CRUD API micro-service collection.
Re: The Staff Engineer's Path – Book Review
#16I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead. Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.
I've always viewed the levels sort of like this, obviously very dependent on company:
Juniors need hand-holding at every step. They may be new grads who don't even know how to behave in a professional environment or very inexperienced folks 1-2 years out of school taking a role in a completely different language they're unfamiliar with. You're talking to them anywhere from 5+ times a day to every other day as they transition up. They may have lots of meetings, especially during onboarding, but they're mostly listening. Their day-to-day is almost entirely "how" with very little "why."
Mids need hand-holding for the bigger picture stuff. You still need to give a general shape to their work but you can expect them to look up the docs for your validation library if they don't know how to do something, and you can expect to format and structure their code and PRs the right way every time (the junior will likely ping you on Slack asking how to write a custom validation function at least once). But it's unlikely you're going to need to talk to them daily. Hopefully they have large blocks of uninterrupted time to work as these are the folks churning out lots of tickets. They can also start thinking more about "why" than "how."
Seniors shouldn't really need hand holding for much of anything. Give them a feature or an entire product and they should be able to figure out approximately how to do it and what resources it will take. More meetings than mids but still need uninterrupted time. IME my productivity starts to really dip if I don't have at least two half-day blocks in a week. I'm in a new-ish job (first year still but 14 years in industry) so have been lucky so far but have been starting to block off chunks if I see my schedule filling. Seniors are probably running several of the meetings they're in, and maybe directing work for juniors and mids. I've been in companies where the line between Senior and Engineering Manager is very blurry as well with new EMs still spending 1/4-1/2 their time writing and reviewing code. And in most companies this is the "terminal" or "professional" level where you're not expected to move beyond here. Lots of folks will hit senior and be there for 15, 20, 25 years until they retire.
Staff is where the amount of code you write starts to drop off, meetings start to ramp up (you're no longer able to block off half your day), and in my opinion the biggest difference, you don't get assigned anything to work on. You're expected to have intimate knowledge of your business domain, your technical domain, and the challenges in both, and formulate plans to use technology to ease problems in both. I also feel like this is the first level where most companies don't need them, including a lot that have them. We have about 85 software engineers where I am, and two of them are Staff, which seems like about the right amount percentage-wise. There's only so much big work to go around and while there might be a lot of people capable of doing it, you don't want 10% of your engineers to be Staff and fight over the 0.5-1% of Staff work that's available. This is also the level I see it much more important what you're doing outside of work. Not as far as side projects, but going to conferences, speaking, user groups, having content available that works as advertising for your and your company, etc.
And then of course Principal where 99% of companies don't have or need them, where you're basically a VP or Director but on the Individual Contributor track rather than management. These are going to be so company-specific it's not even worth talking about them except in the context of a particular company. You're probably at Google or Microsoft or similar at this point.
Re: The Staff Engineer's Path – Book Review
#17> Put non-meetings on the calendar I'd love to do that. But once you throw in real meetings, no meetings days, PTOs, time zones it becomes difficult to schedule a work meeting because now there's no overlapping block of time when you need to meet. Now all meetings get pushed out even more and the calendar time required for certain tasks increases.
Allow read access to your calendar for teammates and instruct them to override your "Thinking time" slots in situations where the matter is urgent.
That's what I do, and it works very well.
Re: The Staff Engineer's Path – Book Review
#18> Put non-meetings on the calendar I'd love to do that. But once you throw in real meetings, no meetings days, PTOs, time zones it becomes difficult to schedule a work meeting because now there's no overlapping block of time when you need to meet. Now all meetings get pushed out even more and the calendar time required for certain tasks increases.
Allow read access to your calendar for teammates and instruct them to override your "Thinking time" slots in situations where the matter is urgent.
There's several issues with this:
* I work with too many people to reasonably instruct them of this preference and expect them to follow it.
* The definition of urgent is highly subjective. What's urgent to one person isn't to someone else.
* Some will be more aggressive and book over it, while others will be more passive/shy like junior engineers. You're now further rewarding aggressive behavior over passive behavior.
But more importantly non-urgent meetings are still important. If everyone does this then the minimum turn around time for engineering tasks needing help/consensus between 3 engineers goes up from a few hours to a few days. You compensate this by juggling more tasks.
I think in practice the downstream problems are much worse than the original problem you're solving. I prefer to just decline any meetings that aren't a good use of my time.
Re: The Staff Engineer's Path – Book Review
#19I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead. Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.
Staff engineer is the new senior engineer.
Yes, but if you stay where you are and don’t push the managers you work with to take execution responsibility you will damage your career.
Re: The Staff Engineer's Path – Book Review
#20> Put non-meetings on the calendar I'd love to do that. But once you throw in real meetings, no meetings days, PTOs, time zones it becomes difficult to schedule a work meeting because now there's no overlapping block of time when you need to meet. Now all meetings get pushed out even more and the calendar time required for certain tasks increases.
The best time to put such "non-meetings" on your calendar is when you switch teams. You're new and the meeting vultures haven't noticed the new piece of meat yet.
I switched teams a year ago and quickly blocked off 2-3 hour slots every day as "focused work time". It's been a godsend for my sanity.
Edit: typo