> One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.
I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controlled environments. I would be curious to see how many tech companies (or the average engineer's experience) have changed from being tech led where engineers have autonomy to being more product management led. My suspicion without evidence is that the overall engineering autonomy has decreased over the years as the culture of tech has (in my opinion) shifted away from tech focus to more business, management, product focus with engineers just as the widgets who are tasked with fulfilling the goals of business, management, product.
This sounds about right. At least I feel it acutely in my career. And the more experienced I got instead of more autonomy it has decreased. So to me it seems autonomy is decreasing at a rather fast clip.
Even outside projects and general work condition it is worse. 10 years back I could just decide when to work from home, or do a few interesting projects show to managers get approval afterwards. Today I have to explain myself to managers and get proper approvals for same thing. And I have been in same place for quite some time so it is not even the case that I have to prove to my new employers first.
Being not much ambitious I use to think after these many years and multiple successful project my win is to be a kind of made guy in that same mid-level position. Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.
Turns out things I assumed, don't exist. And even if they do they are above my level. Not worked in big tech, no massive RSU based compensation and with AI flattening difference (in employer's view ) between 2 vs 20 years of experience, story is not going to end great for people like me.
You can get to be a staff level engineer doing that. However, beware that to really make it up the corporate ladder, you actually have to reject that. Note that I didn't say reject doing the things assigned. I mean reject it as in you figure out the things that they should be assigning and get those done instead.
There are lots of different routes via staff and above level engineer. However, what they do have in common is working on really hard problems that take a lot of other people to work with. You will typically find your staff and higher level engineers rarely are actually writing code themselves. They are all management, but it's a technical management part.
The thing is, it's really hard to be there because management will constantly assign you various product-focused things and you end up being a widget. And so you have to figure out how to break out of that to say, no, this is the wrong widget and you have to show them that, look, I delivered this widget and when they see it, they should realize, wait, this guy was right. I assigned the wrong widget and he did it and so I need to trust this guy and give him more time to do things that give us the right widget.
Remember, the real goal is to make money for the company. As an engineer, you might say your salary is, say, $200,000 a year. But that is only a small part of it. For every dollar they spend on you, they need to spend $10 on other things to make it work. To pay your salary, you need to make not just enough product to bring enough to pay for your salary. You also have to pay for marketing, sales, product support, other managers, HR, and a bunch of other things I can't even think of off the top of my head. So the real question you should be asking is how do I earn, by actions I do, more than $2 million a year for my company. If you're earning your company $2 million a year as an engineer, they're breaking even on you at best, you should do widgets they trust will work. If they are earning $10 million, that's something that you should be putting on your resume and saying, look, this is why you need to give me a promotion. I am earning this $10 million every year. If you want to do even better than that, make it not $10 million that you're personally doing, but things that, because you're assigning other people to do them, are earning hundreds of millions. If you can earn the company hundreds of millions of dollars a year, you can justify a large salary for yourself, and you keep dozens of other engineers busy doing things.
Or you can take the lazy way out and just be a widget producing what they need you to do. That's good enough.
> You will typically find your staff and higher level engineers rarely are actually writing code themselves.
Many so called staff+ engineers are basically glorified Google Docs engineers, or management who want to call themselves technical. It seems to be fashionable these days to call oneself "technical" without actually knowing anything of the problem domain.
They basically take all the "credit" for any innovation out of the team, and scapegoat other teams when project deliverables are not met.
Funny people should have that problem. I have spent most of my career in the startup space, and my experience has consistently been that the amount of problems to solve is vastly larger than what I can reasonably achieve in my waking hours.
So I don't find problems to solve, I try to assess which problems are most urgent, or which solution solves several of them at once. Learning to get that kind of prioritisation right to keep all teams and customers happy and productive is what I'm very proud of in my career.
There are a lot of known problems... but there are also a lot of unknown, or at least unrecognized problems. Some of those unrecognized problems are going to be more useful and higher-leverage than recognized problems. The same "being a sponge" approach still helps.
I find there's some overlap between being good at Root Cause Analysis and realizing that 3 of your most common problems are really all a 4th problem, some aspects of which have not hit you yet.
I am doing exactly same thing of creating a solution which can be applied to multiple problems at the same time.
Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.
Some people either want to solve a whole problem or none of it.
There's art in knowing what parts of a problem can be solved now without screwing your chances of fixing the rest later when you actually fully understand the problem, and have discovered a proper fix.
Exactly. Everywhere I've worked had at least 3-4X more bugs than we had capacity to fix, and the bug count grew over time, net of any fixing happening. There was never difficulty finding problems to solve. Unfortunately most places don't give engineering the autonomy to solve critical issues. It's just feature cram and redesigns, over and over, and let the bugs pile up.
The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.
This has been my experience until the past 6-9 months, when AI got good enough that I can build rails to prevent more bugs while also hammering through critical issues, redesigns, etc.
It’s never been better to be a staff+ engineer, where you can knock shit out of the park and tee up your team to do the same all at once
I actually really appreciate the mindset this has given me towards life in general, and I consider it a superpower.
I find people get overwhelmed and go deer in the headlights when there is a huge amount of stuff to do.
I actually feel relaxed when I say “it’s not possible to do it all. There will always be more jobs than time. The only thing that matters is that we work on the most important things”
I also enjoy seeing the things that just perpetually sit at the bottom and never even get close to being looked at. Others stress and think it’s a huge problem. I like to look at them and see that in context, there are much bigger fish to fry, and we’re doing the right thing by frying the bigger ones and ignoring the little ones.
Mostly agree, one small caveat. I always had a class of critical problems. They were rarely the important, but they were critical to things running smoothly.
You always are going to have coworkers who don't see half the stuff you see. Sometimes convincing people which problem to let you solve in peace is the hard part.
So many places only fix a problem after they've already reaped the majority of the pain of having the problem. Like they want to experience hitting every step on the way down.
I think almost all of tech is bloated and massive layoffs wouldn’t phase most companies (though it would be harmful to people’s lives so it seems cruel to do this). Fewer people per teams means less context switching and devs own more. They don’t have to look for work, it will be in front of their face. In so many of these big tech companies I’ve worked at I’ve seen too many not having enough work to do. They end up creating meetings and other wasteful things (doc writing) to occupy their time. Managers and directors seem to want big bloated teams, the larger their head count the more they can demand and push for a promo.
Inefficient allocation of work aside (where you end up with people doing nothing, despite I suspect a substantial amount of work in the backlog), I think the mindset of "just reduce devs so there's not so much context switching/they can own more" is short-sighted from a business perspective.
Even in projects that could objectively be owned by 1-2 people but are allocated to a 5-10 person team instead, I've encountered cases where velocity gets absolutely obliterated by a sub-domain "owner" dev being on vacation. Now imagine this is not a fairly small sub-domain but half the project, and instead of a vacation your one-of-two dev gets hit by a bus.
I wish people would create more and better docs. Pour as much time into a meticulously written doc details as they discuss indentation and variable naming style.
But instead, just like with your attitude, it's considered second grade or even useless work, and as a result docs always suck if they even exist. They don't get that code is made for people to consume just as much as for the machine, and docs are just an extension of that. That's one reason LLMs are so popular, they actually tell you what you'd have found in the doc, had it existed. But LLMs are restricted to the what and don't cover the why. I some places that makes good docs even rarer. In others it makes them easier since the machine generates the "fluff" and the human just fills in the rationale.
The part I find challenging in the senior-staff twilight is that having deep technical knowledge means I can solve short term problems, just as requests, fast and effectively.
The author mentions that you should spend time understanding the frustrations from other teams, but that takes up loads of time and I don’t like being the person who talks and talks but doesn’t push code and ship features. I’d love to hear how others have experienced that
Once upon a time my grand-grand-boss explained that he had no problem hiring top-notch engineers - pick up the phone, call recruiters for new candidates, connect the incoming stream to the interview pipeline, two months later you get the requested quantity of engineers. OTOH there is no repeatable process to hire someone who will help identify the right problems and drive them to resolution. So if such person is found they will be pushed towards doing things that have no obvious success recipe and away from the things that do.
> I don’t like being the person who talks and talks but doesn’t push code and ship features
Like you, I dislike the "talker" role for people on IC ladders. I often encourage those people to switch to Director+ roles.
The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.
But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.
Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.
I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!
1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness.
2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.
You can limit chit chat very well this way.
You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.
For technical teams, almost every single thing I ship:
1. cements a new pattern or contributes to a new one that my team can use
2. improves cicd speed or checks
You can usually knock out the non technical team work and pick off 1 from technical team work along the way
Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.
I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle
Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals
The biggest problem of a sTaFF eNGInEeR can be solved right away: stop writing about this crap. All of these titles are so meaningless where one organization's staff is another's junior is another's CEO, it doesn't matter because all of the organizational insanity that lead you to your coveted title means jack anywhere else. I should write a big ol' think piece from my perspective as a Senior Staff Distinguished Principal! I will get lots of clicks.
There’s literally no difference between writing about being a staff engineer versus someone writing about being a janitor. Honestly I’d rather read about the janitor, they actually make a measureable difference.
It's pathetic how hard people hold on to titles. What have you -done-? How much have you added to the bottom line?
The author notes:
> One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.
I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controlled environments. I would be curious to see how many tech companies (or the average engineer's experience) have changed from being tech led where engineers have autonomy to being more product management led. My suspicion without evidence is that the overall engineering autonomy has decreased over the years as the culture of tech has (in my opinion) shifted away from tech focus to more business, management, product focus with engineers just as the widgets who are tasked with fulfilling the goals of business, management, product.
all hypothesis, only anecdata
This sounds about right. At least I feel it acutely in my career. And the more experienced I got instead of more autonomy it has decreased. So to me it seems autonomy is decreasing at a rather fast clip.
Even outside projects and general work condition it is worse. 10 years back I could just decide when to work from home, or do a few interesting projects show to managers get approval afterwards. Today I have to explain myself to managers and get proper approvals for same thing. And I have been in same place for quite some time so it is not even the case that I have to prove to my new employers first.
Being not much ambitious I use to think after these many years and multiple successful project my win is to be a kind of made guy in that same mid-level position. Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.
Turns out things I assumed, don't exist. And even if they do they are above my level. Not worked in big tech, no massive RSU based compensation and with AI flattening difference (in employer's view ) between 2 vs 20 years of experience, story is not going to end great for people like me.
You can get to be a staff level engineer doing that. However, beware that to really make it up the corporate ladder, you actually have to reject that. Note that I didn't say reject doing the things assigned. I mean reject it as in you figure out the things that they should be assigning and get those done instead.
There are lots of different routes via staff and above level engineer. However, what they do have in common is working on really hard problems that take a lot of other people to work with. You will typically find your staff and higher level engineers rarely are actually writing code themselves. They are all management, but it's a technical management part.
The thing is, it's really hard to be there because management will constantly assign you various product-focused things and you end up being a widget. And so you have to figure out how to break out of that to say, no, this is the wrong widget and you have to show them that, look, I delivered this widget and when they see it, they should realize, wait, this guy was right. I assigned the wrong widget and he did it and so I need to trust this guy and give him more time to do things that give us the right widget.
Remember, the real goal is to make money for the company. As an engineer, you might say your salary is, say, $200,000 a year. But that is only a small part of it. For every dollar they spend on you, they need to spend $10 on other things to make it work. To pay your salary, you need to make not just enough product to bring enough to pay for your salary. You also have to pay for marketing, sales, product support, other managers, HR, and a bunch of other things I can't even think of off the top of my head. So the real question you should be asking is how do I earn, by actions I do, more than $2 million a year for my company. If you're earning your company $2 million a year as an engineer, they're breaking even on you at best, you should do widgets they trust will work. If they are earning $10 million, that's something that you should be putting on your resume and saying, look, this is why you need to give me a promotion. I am earning this $10 million every year. If you want to do even better than that, make it not $10 million that you're personally doing, but things that, because you're assigning other people to do them, are earning hundreds of millions. If you can earn the company hundreds of millions of dollars a year, you can justify a large salary for yourself, and you keep dozens of other engineers busy doing things.
Or you can take the lazy way out and just be a widget producing what they need you to do. That's good enough.
> You will typically find your staff and higher level engineers rarely are actually writing code themselves.
Many so called staff+ engineers are basically glorified Google Docs engineers, or management who want to call themselves technical. It seems to be fashionable these days to call oneself "technical" without actually knowing anything of the problem domain.
They basically take all the "credit" for any innovation out of the team, and scapegoat other teams when project deliverables are not met.
Funny people should have that problem. I have spent most of my career in the startup space, and my experience has consistently been that the amount of problems to solve is vastly larger than what I can reasonably achieve in my waking hours.
So I don't find problems to solve, I try to assess which problems are most urgent, or which solution solves several of them at once. Learning to get that kind of prioritisation right to keep all teams and customers happy and productive is what I'm very proud of in my career.
There are a lot of known problems... but there are also a lot of unknown, or at least unrecognized problems. Some of those unrecognized problems are going to be more useful and higher-leverage than recognized problems. The same "being a sponge" approach still helps.
I find there's some overlap between being good at Root Cause Analysis and realizing that 3 of your most common problems are really all a 4th problem, some aspects of which have not hit you yet.
I am doing exactly same thing of creating a solution which can be applied to multiple problems at the same time.
Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.
Some people either want to solve a whole problem or none of it.
There's art in knowing what parts of a problem can be solved now without screwing your chances of fixing the rest later when you actually fully understand the problem, and have discovered a proper fix.
Exactly. Everywhere I've worked had at least 3-4X more bugs than we had capacity to fix, and the bug count grew over time, net of any fixing happening. There was never difficulty finding problems to solve. Unfortunately most places don't give engineering the autonomy to solve critical issues. It's just feature cram and redesigns, over and over, and let the bugs pile up.
The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.
The amount of pushback I get when I do a refactor to make a certain class of bug never happen again is huge...
Fortunately this kind of refactor is a lot easier nowadays with LLMs, but the QA is not improved and often what takes the longest.
This has been my experience until the past 6-9 months, when AI got good enough that I can build rails to prevent more bugs while also hammering through critical issues, redesigns, etc.
It’s never been better to be a staff+ engineer, where you can knock shit out of the park and tee up your team to do the same all at once
I actually really appreciate the mindset this has given me towards life in general, and I consider it a superpower.
I find people get overwhelmed and go deer in the headlights when there is a huge amount of stuff to do.
I actually feel relaxed when I say “it’s not possible to do it all. There will always be more jobs than time. The only thing that matters is that we work on the most important things”
I also enjoy seeing the things that just perpetually sit at the bottom and never even get close to being looked at. Others stress and think it’s a huge problem. I like to look at them and see that in context, there are much bigger fish to fry, and we’re doing the right thing by frying the bigger ones and ignoring the little ones.
Mostly agree, one small caveat. I always had a class of critical problems. They were rarely the important, but they were critical to things running smoothly.
You always are going to have coworkers who don't see half the stuff you see. Sometimes convincing people which problem to let you solve in peace is the hard part.
So many places only fix a problem after they've already reaped the majority of the pain of having the problem. Like they want to experience hitting every step on the way down.
“Over time, some [problems] fade away while connections begin to appear between others that initially seemed unrelated.”
Reminds me of https://youtu.be/DSjbTC-hvqQ?t=1159
I think almost all of tech is bloated and massive layoffs wouldn’t phase most companies (though it would be harmful to people’s lives so it seems cruel to do this). Fewer people per teams means less context switching and devs own more. They don’t have to look for work, it will be in front of their face. In so many of these big tech companies I’ve worked at I’ve seen too many not having enough work to do. They end up creating meetings and other wasteful things (doc writing) to occupy their time. Managers and directors seem to want big bloated teams, the larger their head count the more they can demand and push for a promo.
Isn't this just true for 90% of professional service industries?
Inefficient allocation of work aside (where you end up with people doing nothing, despite I suspect a substantial amount of work in the backlog), I think the mindset of "just reduce devs so there's not so much context switching/they can own more" is short-sighted from a business perspective.
Even in projects that could objectively be owned by 1-2 people but are allocated to a 5-10 person team instead, I've encountered cases where velocity gets absolutely obliterated by a sub-domain "owner" dev being on vacation. Now imagine this is not a fairly small sub-domain but half the project, and instead of a vacation your one-of-two dev gets hit by a bus.
> other wasteful things (doc writing)
I wish people would create more and better docs. Pour as much time into a meticulously written doc details as they discuss indentation and variable naming style.
But instead, just like with your attitude, it's considered second grade or even useless work, and as a result docs always suck if they even exist. They don't get that code is made for people to consume just as much as for the machine, and docs are just an extension of that. That's one reason LLMs are so popular, they actually tell you what you'd have found in the doc, had it existed. But LLMs are restricted to the what and don't cover the why. I some places that makes good docs even rarer. In others it makes them easier since the machine generates the "fluff" and the human just fills in the rationale.
The part I find challenging in the senior-staff twilight is that having deep technical knowledge means I can solve short term problems, just as requests, fast and effectively. The author mentions that you should spend time understanding the frustrations from other teams, but that takes up loads of time and I don’t like being the person who talks and talks but doesn’t push code and ship features. I’d love to hear how others have experienced that
Once upon a time my grand-grand-boss explained that he had no problem hiring top-notch engineers - pick up the phone, call recruiters for new candidates, connect the incoming stream to the interview pipeline, two months later you get the requested quantity of engineers. OTOH there is no repeatable process to hire someone who will help identify the right problems and drive them to resolution. So if such person is found they will be pushed towards doing things that have no obvious success recipe and away from the things that do.
> I don’t like being the person who talks and talks but doesn’t push code and ship features
It was fun while it lasted, wasn’t it?
Like you, I dislike the "talker" role for people on IC ladders. I often encourage those people to switch to Director+ roles.
The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.
But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.
Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.
I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!
For non-engineering teams my playbook is:
1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.
You can limit chit chat very well this way.
You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.
For technical teams, almost every single thing I ship:
1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks
You can usually knock out the non technical team work and pick off 1 from technical team work along the way
Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.
I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle
Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals
The biggest problem of a sTaFF eNGInEeR can be solved right away: stop writing about this crap. All of these titles are so meaningless where one organization's staff is another's junior is another's CEO, it doesn't matter because all of the organizational insanity that lead you to your coveted title means jack anywhere else. I should write a big ol' think piece from my perspective as a Senior Staff Distinguished Principal! I will get lots of clicks.
There’s literally no difference between writing about being a staff engineer versus someone writing about being a janitor. Honestly I’d rather read about the janitor, they actually make a measureable difference.
It's pathetic how hard people hold on to titles. What have you -done-? How much have you added to the bottom line?