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 controll…
How I find problems to solve as a staff engineer
81–90 of 188 posts
Re: How I find problems to solve as a staff engineer
#82Not a staff engineer, but this sounds very much like what I do and then am not allowed to follow up on. One particular company where I've been several times as senior or lead developer, I just keep stumbling over problems I would love to take on. I'd love to be a staff engineer there with the freedom to take on these sort of problems, but that's apparently just not how they work.
Re: How I find problems to solve as a staff engineer
#83I worked at the Staff level for a while, I think the key is to report to a director who manages managers. Every time I did I had a good time, projects were easy to define and people were easy to convince. I had the same level with a few managers who were managing other ICs, and that never worked. Other ICs try to compete on tasks, people don't come to you with their needs, you learn about different projects often too…
Re: How I find problems to solve as a staff engineer
#84My advice as someone working at staff engineer role for 3 different employers remotely and the "let problems accumulate" resonates but different context: - don't be too proactive in solving issues that signals you are not busy to your employers. - you are not hired to sit around 9-5, what you ship and how it impacts the business bottom line is far more important. Especially true when I have to juggle 3 different empl…
Re: How I find problems to solve as a staff engineer
#85The 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 controll…
These days tech is indispensable to most businesses so top down control has been asserted.
Re: How I find problems to solve as a staff engineer
#86Earlier quoted context omitted.
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.
Re: How I find problems to solve as a staff engineer
#87This is all very good advice, but I would caution anyone asking the question at the start of the essay that they probably shouldn't be a Staff Eng. Unless you're at a company where that title is simply a rung on the ladder that doesn't have differentiated responsibilities (there are lots of those out there). Every person I've worked with who's been successful as a Staff+ Engineer, promoting them was normally more of…
Re: How I find problems to solve as a staff engineer
#88The 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 controll…
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.
Re: How I find problems to solve as a staff engineer
#89Earlier quoted context omitted.
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.
If a bugfix has big impact, even if it’s a one-liner fix, it’s still a staff problem
I get your point. Staff levl engineers should be working on really hard problems that will make a long-term impact, but they often aren't very visible at any one moment. It's only when you look over long-term and you realize that things have slowly gotten better that you realize the impact. At least I hope they've gotten better. I've made some decisions over the years that I wonder if they really made things better or not. And it's really hard to say since there's no control where you can say, well this is what it would have been a different way.