How I find problems to solve as a staff engineer

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

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.

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.

This 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 a formality since they were already clearly doing the work. Every person I've seen 'rise to their level of incompetence' was striving to get the title/pay bump and looking to 'play the game' to get there.

If your motivation for solving people's problems is that it will get you a promotion, instead of the fact that you like solving problems, then it's probably not the right job for you.

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

Great article and super relevant advice. As building becomes easier and easier in our career those with the agency to find problems worth solving become x10 more productive.

Like other people in this thread are also saying, the more you master this skill the more often you'll have people finding *you* to give them their problems, which only makes this easier.

Not 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.

I 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 late, other teams are territorial and don't really want you to intervene.

“I start to see what’s really slowing people down and what my team or I can do about it.”

I often tell engineers that employees will never go to an “innovation center” in a company to say that their job could be made obsolete. And by definition the workplace is not 100% effective as long as there is employees. Still there is most likely always more that can be done, so think that the existing people can be automated away and be used in new positions.

A good way to find problem from top-down is to look for similar jobs done. Often a department with a lot of employees. 10% more efficient for 100 is better than 100% for two, unless those two indirectly slow the rest of the company down.

And I like to think that when companies expand rapidly it’s easy to spot problems, the contrary is slow growth, then problems is often someone’s job and they will not complain if it’s not stressful. The last part is often solved over time with even more people.

It's interesting how engineer/developer levels are so meaningless across organizations. Where I am, somebody who can only do the work assigned to them isn't senior. That's borderline entry level. Doesn't mean they're a bad programmer or only have 3 hours of experience, just isn't at the higher level. Seems where this person works (Google?) that threshold is at staff

I'm staff+ too. I don't need to find problems, they find me, very quickly and it's mostly a triage operation on problems from then on. I always have a list as long as my arm of problems that are worth my time.

Also a staff engineer. This is pretty much exactly what I do.

Often it is a result of suggesting an improvement to some PR for a program or system that someone is doing some work on, and discovering that for whatever reason it doesn't quite work. This tends to lead to a deep dive of really analyzing and understanding the problem and how the piece of the system fits into the overall picture. This analysis often leads to a more structured approach to a problem, placing it in the context of wider industry or CS theory, thus enabling us to leverage prior art and other people who have grappled with similar problems.

I'm surprised there was no comment here about asking the support team what is actually paper cutting the customer.

Small business, small team, gets shit done.

Large corporation, more meetings about what to do than doing it, power trips, drama, backstabbing, you name it. Keep you head on a swivel at megacorp.

I've learned that twice when both startups I worked for were sold. They made millions, I was shown the door. Any business that talks about being "family" or any of that crap is a cult, stay away.

I stopped working to make shareholders rich, and started working for myself. I don't believe anyone will ever truly get what they want out of life working for someone else.

People ask XY problems and your job is to find what issue they are having, not try to help them with the attempted solution.

Basically a StackOverflow guidance on XY problem applies to the general problem solving as well.

It’s difficult to see the difference between a solution looking for a problem and vice versa.

> “How do you find problems worth working on?”

They usually find me.

> How I find problems to solve as a staff engineer

For me, walking down the hallway where I work is usually sufficient...

Hell, what am I even saying? I have a large list of them to begin with, and it rarely gets shorter

I think the first problem may be fixing the broken mobile experience. I'm getting black text on a very dark gray background.

One thing that isn't often mentioned in these discussions:

Making sure that the work was actually done.

I've been a Staff Engineer and managed engineers and it's pretty shocking what people consider to be "done".

A couple examples:

- Doing a migration to using Tailscale and an engineer claims it's done even though there is just one giant ACL for the whole firm

- Migrating from one monitoring system to another despite only 80% of the alerts have been migrated

- etc

Some of this is business folks creating bad incentives. Some of it is not creating good "success criteria" for projects. Either way, someone has to go through and make sure that both the details and the big picture deliverables landed correctly.

This being HN, I'm sure someone will say something like "just hire better engineers". I've seen phenomenal engineers make bad choices here due to poor incentive design.

A perfect example:

- you reward people for hitting delivery deadlines

- you punish people when there are outages

you might think you're pretty smart until you realize the odds of getting yelled at if you miss a deadline is 100% but the odds of an outage are <100%. The EV+ outcome then becomes to hit the deadline even if you know the code isn't ready.

Again, the job of senior engineers/engineering managers is to make sure these things don't happen by both double checking work and also pushing back on bad incentives.

Listen to your customers but ignore what they say. “Treat your customers like a kindergarten class. If they’re all asking for a snack they’re hungry but perhaps they really need a nutritious lunch instead.”

My 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 employers. I will be in a long standup meeting with company A while I am answering slack messages from company B or company C has a deadline that overlaps with another and I'd have to work on at the same time.

Previously without LLMs this was very difficult but now its manageable, especially with openclaw and hermes doing a lot of lifting. This let me discover a lot of what's discussed in the article naturally.

I have a different problem: I can find all the problems, but I can't solve them, because they aren't within my control. The people whose control they are within aren't interested in solving them (or letting others work on them). The political and psychological games required to get people to just let you solve problems seems like a second job.

If you spent your whole career inside one corporate ecosystem...do not confuse your rank in that hierarchy, with your rank in the profession. By looking at the some comments here, many are doing that.

https://www.youtube.com/shorts/FXPh2_BAZD8

“The shape” — smells like tokens. Each paragraph is too perfect.

Eh, I'm not going to say this is wrong, but pretty much like all advice, it's kinda cheap without data. Like Dale Carnegie may be very famous and have a book and say "Use people's names all the times and your conversations will be great" but who actually knows if that makes a difference without some controlled outside study.

I see a lot of people really eager to tell other people how to staff, but a lot of them sure do seem to disagree, and most people I know get to staff anyways without any particular skill after a certain age (title inflation?) including myself.

My smell test for an engineer is -- are they trying to quantify the size of everything in terms of impact, or are they just reacting to whatever customer knocks on their door?

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?

TL;DR is that its extremely hard to show staff level expertise if you work at a wrong company. And the amount of companies that still need this expertise is ever decreasing (big corpos with a lot of autonomy)

This is the real reason why we dont see natural path for more ppl to progress towards Staff level.

Interestingly noone talks about this. “Be first or bust”