How I find problems to solve as a staff engineer

8/23/2026 at 7:57:42 PM

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

by wpasc

8/23/2026 at 9:01:27 PM

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.

by geodel

8/23/2026 at 9:36:56 PM

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

Any individual company is likely to atrophy because continual success breeds fear of change, fear of breaking what's already working. Especially if management rotates and new management didn't actually create the success in the first place.

by majormajor

8/24/2026 at 1:49:29 AM

> Especially if management rotates and new management didn't actually create the success in the first place.

Critical point, and absolutely true in my case. With change in management all past successful projects are "failures" now. Instead of using x, y, z projects uses a, b, c so leadership is kind to dismiss me with prejudice.

by geodel

8/24/2026 at 4:21:38 AM

How will you get bonus if you don't do anything different?

How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things?

How will you replace them without funding i.e. more budget, more power?

How will you keep moving up if you don't repeat this cycle?

by noisy_boy

8/24/2026 at 3:56:35 PM

I don't know if you're being facetious our not. I agree that that's the current landscape, but it doesn't make any sense! Imagine a great big ship sailing the oceans in ancient times. The crew made the ship sail straight. Now imagine (for argument's sake) the crew could be replaced at will. Preventing any deviation in the course is it's own success. The ship is working as intended and producing value. So to use your questions:

How will you get bonus if you don't do anything different? You won't crash the money-maker.

How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things? You won't. That discipline is it's own value.

How will you replace them without funding i.e. more budget, more power? Your maintenance budget pales in comparison to the R&D budget, so funding should be a non-issue. You're not asking to recreate the boat, only replace discrete known quantities.

How will you keep moving up if you don't repeat this cycle? Because the momentum was set at ship launch, not at ship improvement.

I honestly don't understand how this all breaks down in modern times once you introduce shareholders. Is it that shareholders literally get spooked by stagnation?

by butlike

8/24/2026 at 5:03:48 PM

>Is it that shareholders literally get spooked by stagnation?

Yes, 100% they do. Look at what happened to Instant Pot.

by entropicdrifter

8/24/2026 at 7:05:39 PM

All items true. I dug my own grave by telling management look, we can already do all new features by reusing same system at much less expense.

by geodel

8/23/2026 at 9:16:37 PM

>Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.

My experience has been you'll be regularly moved around to mitigate the "bus factor"

If you're seen as highy capable you'll be moved on to firefighting duty.

by cube00

8/24/2026 at 9:43:17 AM

One should distinguish between high-stakes vs low-stakes firefighting duties. The former could fast-track one's career, but the latter is a guarantee for stagnation.

by laserlight

8/23/2026 at 9:58:26 PM

Yep, and if this happens you need to get promoted quickly out of that or you’ll get stuck at it. It’s great fun, and you’ll learn about every project your company has going on by doing it.

by maccard

8/23/2026 at 10:20:42 PM

>It’s great fun

If you don't set hard boundaries it's also the fast track to great burn out.

by cube00

8/24/2026 at 7:07:05 AM

As a European that’s a great way to get paid for a two year holiday.

by artisinal

8/24/2026 at 3:47:52 AM

The higher the position the less leeway you have because you are working on bigger problems with more experienced people who want to do things their way.

It makes sense the higher up you go the more demanding the boss because their boss is more demanding.

by ipaddr

8/23/2026 at 8:30:09 PM

Without providing too much detail, at my current place of employment I find that to be the case.

In most of my career, especially when in a Staff role, it has been up to me to propose the direction and priority of work within my scope. Usually, this is based on my estimation of the impact to the business (possible new features, security) or operations (devx, efficiency $$$). Obviously I still have to work with product to get things scheduled as they have needs that must be met, but it was as an equal partner. As a very creative person thats usually the space I enjoy the most.

by hankbond

8/23/2026 at 8:04:41 PM

I agree with this and think that when your company isn't profitable and is running out of runway (due to the end of the zirp) and can't get more, moving toward features that more directly could land sales is a natural top-down move (and totally correct in the abstract).

However I still see a lot of "work theater" where directors couldn't care at all about changing the bottom line but just care that work that sounds plausible enough is executed in a predictable way that makes them look good (in fact they get pretty disappointed if something happens TOO fast [like half the estimate] as it illustrates they are out of touch the work they are claiming to represent). What I'm saying is that "do more top-down-product" in theory makes sense as a direction, but in practice I usually see it as wasted energy.

by zug_zug

8/24/2026 at 2:38:39 AM

I'm sort of in this area, and I'm fighting the same struggles because I desire "productivity", not autonomy.

I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care.

IMO, it's a 180 degree shift to go from trying to accomplish assigned work to creating new work and accomplishing (or delegating) it / adding it to roadmaps / etc. To me, it wasn't at all obvious that this was what I should be doing, so it was strange to sort of stumble upon it when asking an adjacent question.

It would have been very useful to get an explicit instruction such as "hey, only spend 1/4 of your time on planned work" or similar.

I'm sure there are plenty of people out there who spent their entire career trying to avoid doing assigned work so it's an easier transition, but for rule followers it's a weird change.

by rconti

8/24/2026 at 4:44:55 AM

I always include sprint points or at least some metrics to track, because even in areas that don't care about it, there is some chance a new CTO/manager/buyout or whatever jumps in. Day 1 asks for metrics and then retroactively judges people's output on it.

I've annoyed my team previously in demanding jiras and sprint points (and helping build it out as much as I could to not take too much of their time) because I could feel the turn happening to metrics.

Sure enough the only person in my team let go was because he outright refused to fill in his JIRAs and I could not get through to him the difference in what is logical and what plays well to management when they lose their minds.

Bit of a tangent, but even in the work you're describing, I treat sprint points and JIRAs as future CYA, not necessarily a work sheet.

by JauntyHatAngle

8/24/2026 at 7:56:11 AM

Doesn't that just effectively make you that person? The alternative is surely simply saying we haven't historically tracked that, should someone join and want it.

by OJFord

8/24/2026 at 8:52:30 AM

Not quite sure what you mean by that, I'm not the one making decisions of who to cut. That's one to many levels above me.

Your stated argument would make sense if you're dealing with reasonable people. Which is sometimes.

But I'm talking specifically when shit hits the fan and people levels above me put down a mandate across many divisions.

As it is if they're making cuts they'll grasp whatever metrics they can and cut. If they don't have metrics that gives less protection, not more.

Take "as you can see I have X number of staff fully allocated and up to their eyeballs in work" vs "I don't have that metrics but trust me". That's part of my job or responsibility depending on my seniority to justify my team and keep them employed and not stressed by cuts and workload.

by JauntyHatAngle

8/24/2026 at 8:03:28 PM

Sorry, I was referring to your first paragraph, about someone new coming along and caring about metrics retroactively not previously cared about.

My point being that by proposing the solution 'so we should care about them, in case that happens' you effectively are (or are equivalent to) that person, you're making it happen sooner (and for sure).

by OJFord

8/23/2026 at 9:20:15 PM

I've certainly seen that shift in some places. 8 years ago I started on a project as a freelance software engineer, to build something they couldn't really envision yet. I had a ton of freedom, built a prototype, chose my own tech stack, designed every part of it. A team was built around it, and I migrated to a leadership role where I decided the direction, addressed issues I saw, redesigned parts that needed improvement. We had an enormous amount of freedom, and used it to build great things fast.

A bit over a year ago, I joined that same company again, as lead of what's technically the same team, this time as an employee, but everything had changed. It was very hierarchical, very top-down, very little freedom, lots of red tape and office politics, and a tedious, slow pace.

by mcv

8/24/2026 at 11:13:08 AM

Your employer has much of its goodwill burnt in the past, and has learnt much from it to be able to dictate what you should and shouldn’t do.

by vachina

8/23/2026 at 11:00:40 PM

In my experience (35+ years), it is the opposite now. It used to be massively top down, and now it is more and more bottom up, at least with the companies I have experience with.

by gilbetron

8/24/2026 at 6:13:25 AM

Do you mean this applies to other engineers who are less experienced than yourself or only to you?

by wreath

8/24/2026 at 3:13:14 AM

[dead]

by nullsanity

8/24/2026 at 11:56:54 AM

I think this is very true. I've seen it. It's the same in the design field too.

And it's because the tech industry has matured. Best practices are clearer, and there is proportionally less work happening "at the forefront", so to speak.

Most tech work is, at its core, stuff like building CRUD wrappers around a database. But we know a lot more about how to do those things now than we did 25 years ago. Our tech stacks are mature. There are extraordinarily well established patterns, and so much prior art.

This means that business folks have a stronger intuition of what's possible than before -- and that makes top-down direction much more likely. The innovation is commonly in the business strategy, not the tech itself.

(I'm not saying there aren't hard problems to solve, or there isn't exciting greenfield stuff happening -- there absolutely is, especially with LLMs -- it's just that the majority of tech work today exists to unblock a business goal)

by iamcalledrob

8/23/2026 at 11:30:40 PM

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.

by bluGill

8/24/2026 at 3:22:05 PM

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

by gajjanag

8/23/2026 at 11:43:54 PM

(author here) I really like your framing here! I think it captures the essence of my thinking in a really concise and coherent way.

by lalitmaganti

8/24/2026 at 1:04:05 AM

Hard to feel motivated either way when both roads seem to ultimately lead to layoffs, regardless of performance. If you can even get to staff/principal level to begin with. That's more a matter of when you were born these days instead of what you know.

by johnnyanmac

8/23/2026 at 9:57:54 PM

I've had about the same level over the years. Early on, before I had a nest egg, I had little real autonomy, despite outward protestations top-down asking for risks and ideas. Afterward, maximizing average outcomes rather than worst-case risk, I've had a ton of career success either proposing and executing good ideas or else just ignoring the product roadmap when necessary to make the company better. I encourage my team to do the same (ideally they have to resort to subterfuge less than I did since I highly value bottom-up input, but either way is fine). It's, again, risky, but if you consistently deliver above expectations then in many environments you'll get more promotions and raises than you know what to do with, despite the lack of predictability.

Lately, product and my boss have been on board, so it's been fantastic to actually have partners to discuss these "risky" ideas with and better fit them into the roadmap rather than guarantee things which would get us all promoted will be shot down instead. I personally have more bottom-up autonomy than I think I've ever had at $WORK.

That's only anecdata. Another aspect of that tech microcosm is that at various points I explicitly did not have permission to do the right thing and had to be careful with the politics. It only worked out because I was right and because I was okay with the consequences if I had been wrong. Maybe that means I had low autonomy in your definition?

by hansvm

8/24/2026 at 12:23:03 AM

I've spent ~20 years working either as a contract worker and in more recent years, full time work.

Every company I did substantial work for was bottom up from the perspective of my role, which is also related to infrastructure and developer tools / workflows.

Basically I'd work alongside the dev team and report to the CTO, VP of engineering or engineering manager depending on company size. Nothing really needed sign off beyond my manager and even then in most cases I was left to self-regulate 95% of it. That style makes a lot of sense for this type of role, it's much different than writing app code with feature requests coming from a product team.

Every substantial line of work was directly related to reducing friction, pain or instability as well as saving time. These could be workflows or technical implementations. Also a lot of times it is bringing order from chaos. These could be things that directly affected me or the dev team. Internally I treat the dev team as both peers and customers.

by nickjj

8/24/2026 at 6:17:53 AM

I think this is largely true. Theoretically it follows that mature industries would become this way more and more.

In my software engineering jobs there was always strong top down product direction. In my AI research jobs people are often staring at me blankly waiting for me to tell them what we can do.

A young industry the only people who really understand the potential of what the technology can do are the experts and practioners.

Overtime all the best ideas get picked off, and the general population who are non practitioners gain enough knowledge that they can understand what the technology can do better than the experts how can impliment it.

by nbardy

8/23/2026 at 8:10:57 PM

Most of my career has been spent in JavaScript and then MuleSoft. I have only ever seen top-down authority in about 20 years of doing this, except for when I was at Travelocity early in my career.

The general perception is that JavaScript work in the corporate world is for young people who have no idea what they are doing and lack the maturity to write original solutions. This perception is common from developers who do other work, management, and developers who primarily perform JavaScript work. If I want to be creative or have autonomy to do anything more ambitious than putting text to screen I have to save it for personal side projects or do unrelated work.

MuleSoft work was just more of the same with all decisions funneled to strict silos of a select few and everybody else was just a keyboard pressing stooge.

Yes, that does sound dreadful, but what's worse is that it amplifies the personalities of people who will throw others under the bus for attention and potential rock stars who perform their most diligent work at hiding from that attention.

by austin-cheney

8/23/2026 at 9:20:59 PM

> more ambitious than putting text to screen

And you will be ordered exactly where to put that text down to the pixel.

However your design system will be built around a twelve column bootstrap layout which your designer won't follow because "an experience can't be constrained by columns"

by cube00

8/24/2026 at 9:00:10 AM

> I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controlled environments

I've thought a little about this. First: I don't believe that you can have bottom-up autonomy, without taking clear responsibility over outcomes.

Previously the main bottleneck in engineering orgs has been figuring out scaling and reliability. So you could own the outcome of "99.99%" and everyone was happy. But I think the bottlenecks in the orgs have changed. Partly due to increased productivity, and lower barriers to solve previously hard problems (thanks to good old AI), and partly due to shift in focus from maintenance of a product, to feeling forced to think about "which AI-native company/product will eat us next quarter". Some of this shift is towards product. Like... what does a great product in market x look like given the condition that we now have cheap and good AI models? Should it be different? These aren't engineering questions... unless you want to dip your toes in the business/management/product side of things (which I 100% think engineers should do!). But it requires you to go from owning the 99.99% outcome to owning "how do we create a product with y user retention curve and k number of users".

by prolly97

8/23/2026 at 11:13:36 PM

All anecdata here too but I agree. I’ve been in the industry long enough to remember when companies weren’t _all_ tech and us tech folks were considered specialists with a niche who charted their own course.

These days tech is indispensable to most businesses so top down control has been asserted.

by afavour

8/23/2026 at 8:57:47 PM

Its a good thing that the Author pointed out the caveat cause most companies/teams/people do not operate in this mode. Subtle in the details is a fact hidden that the author is able to manage what he wants to do, most people do not get that kind of luxury. This either means that the author has earned enough political reputation based on past work or they are aligned with their management chain.

tldr; this advice is probably impractical for a bigger chunk of industry.

by sandeepkd

8/23/2026 at 9:10:10 PM

Agree. It is to author's credit that he shows self awareness about this kind of autonomy and privilege.

by geodel

8/23/2026 at 9:20:25 PM

This is my current world, at least. Bit of a shame. But they pay me well enough still and the work is interesting enough that I don’t mind too much.

by girvo

8/24/2026 at 12:05:20 AM

Every step up in my career has, ironically, lead to less autonomy.

by ravenstine

8/24/2026 at 1:13:24 AM

“It is easier for a rich man to pass through the eye of a needle than find the Kingdom of Heaven.”

by alchemism

8/24/2026 at 5:52:17 AM

It's funny you highlighted the 'one caveat' line. I literally came here to post 'One caveat:' (and nothing else), as claude code seems cli to revel in adding an apparently obligatory 'one caveat' blurb at the end of every response. (viz. https://www.reddit.com/r/ClaudeCode/comments/1vbsr2m/one_cav... )

  Struck me that the staff engineer 'finding problems to solve' might be (whether for better or worse) manifesting that same tendency.

By the way, as Maganti's article has both the 'one caveat' structure and the reference to 'shape' , both being very common claude-isms, I treat the article as gen-AI. May still have something interesting/useful to say, may not, but I'd find the prompt series Maganti desired to employ to elicit producing the article prose more informative than anyything about the prose itself.

by ricksunny

8/24/2026 at 1:13:02 AM

I confess that when I work at controlling places, I engage in conspiracies. But I can only pull the subterfuge off for about 3 years and then I have to move on before I get PIPed for making their entire engineering staff more efficient, and then they move the goalposts for 'meets expectations' and don't know exactly what it is I'm doing, but they know they don't like it and now they have some numbers that tell them what they want to hear.

Like a woodworker building his own jigs, I always build my own tools whether the company wants them built or not. When I'm in a supportive environment, I work on and share those tools loudly. When I'm not, it's over lunches, behind closed doors, pulled out during emergencies, or just snuck into the CI pipeline without comment.

Frankly, the fact that not everyone does this has always been a cultural disconnect for me. The whole point of our field is to take repeatable tasks and write code to replace them. The fact that only about one in six of us does this for the tedious or error-prone parts of our own work is just maddeningly bizarre to me.

Nevermind the overly large fraction of people who have to be dragged kicking and screaming into using tools written by others. That number has gotten smaller over the last couple of decades but it started too high and the slope of that line says something awful about the industry. I don't know what, but it's something I'm sure nobody wants to hear, so I haven't poked at that bear too much (I have plenty of other bears to poke.)

by hinkley

8/23/2026 at 8:50:56 PM

I think it was correlated with outsourcing and H1B replacements, because you can’t outsource the leadership required for bottom-up methods.

Further, foreign business culture is significantly more too-down than American business culture.

by zmgsabst

8/23/2026 at 10:29:15 PM

I noticed what you describe 5 years ago.

Since then, not only have we lost autonomy, but there was no top-down direction to begin with. And there is none now.

Nobody knows what the next incentive to chase is, so they're liquidating headcount and engaging in fraud to appear profitable.

(re: fraud, I'm learning the hard way why my own employer's stock price dramatically improved-- ever since they switched to stack ranking, they just make shit up to PIP and deny severance ahead of layoffs.)

by suburban_strike

8/24/2026 at 1:41:27 PM

Lesson learned: Publicly traded or VC-owned companies should be de-prioritized when choosing an engineering job.

by bigfishrunning

8/23/2026 at 8:37:24 PM

I think the autonomy was stripped not that long ago and it's making software products far worse.

It doesnt make sense that this would happen from an economic perspective at first glance - not unless you consider labor (devs), execs and investors to be three competing groups who are vying for power.

by pydry

8/23/2026 at 9:28:37 PM

It depends on company culture, and there's as many of those as there are kinds of people. I've worked at large, medium, and small companies, in many industries, and there's no common pattern. The people in charge set the tone, and the people are all different.

If there's a pattern in the people, it's that more people in charge are less capable of doing the job, because they've grown up in a culture of ignorance. The past 10 years has been dominated by "StackOverflow Engineers" promoted to management, and people who read HN clickbait blog posts and believe it's good advice (it's not). They never had the time, training, or mentorship to learn from decades of experience. And Dunning-Kruger keeps them confident that they don't need to change.

However, on this point:

"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"

That's exactly what engineers are supposed to do: listen to and enable the business. A mechanical engineer does not dictate the shape of the car. The designer tells the mechanical engineer what the car will look like. It's up to the engineer to make it work. However, it's also up to the engineer to tell the business that you can't fit a 600hp engine in a Mazda Miata without seriously affecting handling. It's supposed to be a two-way street. Good management/leadership knows this and enables it.

by 0xbadcafebee

8/24/2026 at 4:00:05 AM

> That's exactly what engineers are supposed to do: listen to and enable the business.

This may be the case if you're a junior engineer just crunching through individual tickets, but with the lower end of software engineering being automated away where even more junior engineers have to take more product/feature ownership, I don't think "churning widgets" is the right way to think about our job anymore.

by supriyo-biswas

8/24/2026 at 6:25:07 PM

And this is why the lack of training/mentorship is having a negative effect: somebody needs to be protecting and guiding the junior engineers. They don't know they're supposed to push back and say "I'm not the person who's supposed to decide how your product works, I'm just supposed to build it". They don't know that they need to interrogate the business and get them to commit to details. They probably don't know how to have the conversation and ask those questions.

That's what mid-level and seniors have always been for, to provide that knowledge on the job. But mid-levels and seniors are increasingly the equivalent of juniors with bigger paychecks, because they didn't have someone to show them. We need apprenticeship. In the trades, an apprentice will train for years with a master tradesman who teaches what you need to qualify for the title of journeyman. We need apprenticeship in software development, and real Professional Engineer qualifications. It helps the end-user, the business, and the engineers.

by 0xbadcafebee

8/23/2026 at 10:06:48 PM

this

by spl757

8/23/2026 at 7:46:46 PM

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.

by 9dev

8/23/2026 at 9:53:13 PM

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.

by ryandrake

8/23/2026 at 10:56:44 PM

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.

by therealdrag0

8/24/2026 at 9:53:42 AM

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.

by DanielHB

8/23/2026 at 11:18:56 PM

If a bugfix has big impact, even if it’s a one-liner fix, it’s still a staff problem

by rckclmbr

8/23/2026 at 11:36:42 PM

Sometimes the biggest impact you can make is just changing the spelling of T-E-H to T-H-E on a very visible page. Hopefully that's not a staff level problem in your company.

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.

by bluGill

8/24/2026 at 12:18:05 AM

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

by dirtbag__dad

8/24/2026 at 1:19:50 AM

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.

by testing22321

8/24/2026 at 4:06:08 PM

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.

by BatFastard

8/23/2026 at 8:10:50 PM

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.

by tikhonj

8/24/2026 at 8:05:16 PM

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.

by hinkley

8/24/2026 at 8:04:17 PM

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.

by hinkley

8/24/2026 at 1:38:41 PM

Working in startups has left me with almost the opposite problem. While there are many theoretical problems to solve, most are not valuable to solve until you have a reasonable degree of confidence that customers care about them.

by SkyPuncher

8/23/2026 at 8:52:18 PM

I think this is more relevant reality. At Staff and Principal you have visibility into a lot of fires going around you. What helps is understanding the relative importance of what fire to douse and be at peace with the ones that you cannot control.

by sandeepkd

8/23/2026 at 7:49:10 PM

You probably pivoted your career towards the startup space so you found it effortless. For others it is basically a castle with a 20m wall.

by markus_zhang

8/24/2026 at 12:20:45 PM

> “… the amount of problems to solve is vastly larger …”

Are those problems in your “assigned“ lane?

I’m curious if you’re saying something else—that your organization somehow permits, encourages, shares its tasks/problems. Or what % of your job is management?

by xtiansimon

8/23/2026 at 8:18:19 PM

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.

by Geof25

8/24/2026 at 8:07:28 PM

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.

by hinkley

8/23/2026 at 7:49:42 PM

He says: That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

by esafak

8/23/2026 at 7:59:39 PM

Yes. He also says: “How do you find problems worth working on?” a senior engineer I mentor asked me recently. My point is that I'm working in a whole different environment, and the challenge - to me - is never finding interesting problems to solve, but identifying the most important problem out of a large pool of known problems.

by 9dev

8/24/2026 at 12:11:15 AM

That still sounds like it chimes with the quote you shared. The question the senior engineer was asking may have been exactly your last sentence. As in, among the “pool of known problems,” how do I find the ones worth working on? “Worth” may not mean “interesting” but “of lasting value”

by alpinisme

8/23/2026 at 8:00:29 PM

“Can be a superpower” is so empty. What does that mean outside of trying to proliferate some cliche?

by hyperhello

8/23/2026 at 8:11:52 PM

Just means it can be powerful or useful technique that can feel “magical” when employed.

I wouldn’t overthink this.

by aleksiy123

8/23/2026 at 8:14:08 PM

Not overthinking can be a superpower, but writing eloquently can be a superpower, and not trailing cliches behind your pen can be a superpower.

by hyperhello

8/23/2026 at 9:41:49 PM

Now everyone is a bloody writing critic and everything is a piece of master literature that needs to be criticised as such.

by xandrius

8/23/2026 at 10:49:32 PM

No, but I’m getting really tired of seeing things that took less effort to write than it does to read. People have to process this AI-influenced LinkedIn-influenced SEO-optimized Reddit-template dung heap of worthless content-style and get past it, because even though expectations may be low, it’s in bad taste to the point that it’s starting to embarrass on a cultural scale.

by hyperhello

8/23/2026 at 8:08:15 PM

This is not distinct.

Even in a big corp there are always problems to solve. The point is to find problems that both:

1) are hard enough that someone junior won't be able to solve them alone, and

2) actually provide value to the company / users

by underdeserver

8/23/2026 at 8:24:48 PM

It’s the same in a large corporate environment. I have a “personal projects” doc of ideas I’ve had to make development experiences better at my current role - it’s a couple hundred lines long.

I managed to get a couple of smaller tools out recently thanks to having copilot available to churn on them while I spend my time on prescribed work, but it would consume all of my time to even make a significant dent in it.

by devmor

8/23/2026 at 8:58:49 PM

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.

by CSMastermind

8/24/2026 at 4:36:38 AM

I suspect this is partly a function of your organisation.

Some places, do not care terribly, about what you _could_ achieve, or they have garbage internal practices which prevent you from doing this work effectively no matter how much you _care_, or maybe they’re just a garbage workplace but you need the job. In these cases, you may as well ruthlessly go-for-the-title, because they’re not going to change, so you may as well get something beneficial while you’re stuck somewhere shitty.

Now, if it’s a decent org, which looks after its people, produces a product it cares about, has actual career progression, sure, you can afford to do the work first and earn it properly, but let’s not pretend that’s amazingly common, and attempting to do this, in some places will just get you exploited and burnt out, with no pay or title bump to show for it.

by FridgeSeal

8/24/2026 at 3:43:33 PM

The issue is stuff like job security and layoffs; it’s easy to not care about what position you have until someone is looking to fire 20% of non staff engineers and suddenly you are afraid of being on the chopping block.

by NewsaHackO

8/24/2026 at 3:58:17 PM

In my org, you’re not allowed to do work like this without the title.

by Drew_

8/23/2026 at 11:26:26 PM

I suspect you might hear a lot of push back on this take, but I for one fully agree. I would go as far as to say that in my workplace, this a nearly inverse relationship between quality of work and how actively that person is thinking about / talking about / acting-as-if-they-are-owed a promotion.

by sebastos

8/24/2026 at 3:12:47 PM

I came here to say exactly this. Thank you.

The people in my workplace that I respect the most and that are the most competent are the ones least interested in career politics and promotions. Heck they even often reject management responsibilities. They just want to do good work and management gets that and gets out of their way. In contrast, there is this guy constantly thinking what he could so to make an impression and talks about compensation and RSUs and cliffs and he is stuck where he already was 6 years ago and nobody would consider him for promotion ever.

by teiferer

8/23/2026 at 8:06:27 PM

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.

by ronnier

8/24/2026 at 3:17:18 PM

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

by teiferer

8/24/2026 at 11:42:19 AM

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.

by HighGoldstein

8/24/2026 at 8:12:29 AM

Isn't this just true for 90% of professional service industries?

by alansaber

8/23/2026 at 8:10:32 PM

yea this was the case even before ai. fighting for scope is 80% of the job now. Ppl like OP dont really need to "Act like a sponge" and figure out "problems to work on" if there is natural demand for stuff they are building work will present itself.

There is also crazy ladder climbing with all these titles and difference in payscale. So ppl like the author are trying to optimize what a role X is supposed to be doing. Everyone is just the same thing everywhere.

Everywhere you go its the same ppl, same ladder , same tools same sucking up to boss blah blah. Cant wait to get out of this shit.

by dominotw

8/24/2026 at 6:10:25 AM

I’m in my 4th dev job of the last 12 years and every one of them has been wildly different in terms of structure, culture, tooling, work style, etc.

by bottle_roket

8/23/2026 at 8:14:18 PM

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

by intoXbox

8/24/2026 at 12:09:39 AM

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!

by boulos

8/23/2026 at 10:42:54 PM

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?

by DenisM

8/23/2026 at 8:33:29 PM

I’ve experienced this. The critical realization for me was that most of those problems which I know I can solve quickly, without even having to write a Jira ticket or groom them into a sprint or whatever, are problems I should let someone else solve.

Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.

At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.

It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.

by zbentley

8/24/2026 at 1:16:36 AM

Yep. Look for the problems that aren't going to get solved without you - either because nobody else sees the problem, nobody else is positioned to be the solution, or because your skills uniquely line up. That can't be all you do, but it's the highlight reel.

by zmj

8/24/2026 at 12:28:45 AM

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

by dirtbag__dad

8/23/2026 at 8:51:53 PM

I think that's a completely natural source of frustration for someone who is used to being able to put hands to keyboard and solve problems quickly, but IMO the higher you climb the ladder, the more you have the opportunity and responsibility to take a longer view and to delegate - which often means that other people are pushing the code.

by jpitz

8/24/2026 at 1:22:57 AM

I find that I often tik-tok between organizational work and deep technical work. (I come close to the "solver" archtype on https://staffeng.com/guides/staff-archetypes/). There are weeks-months when I am not writing a ton of code. I'm still doing technical work, but it's architectural documentation, experimentation, or discussion where my contributions aren't directly visible in commits. Then there are weeks where I ship dozens of PRs.

I'm often thinking about 1-2 immediate term problems (what am I coding on now), 5+ medium term problems (what am I planning to work on next or moving such that someone else can work on it), and then a handful of long-term problems ("this is currently intractable, how do I convince leadership/this other team/etc. to make it possible for someone to actually address the technical problem I care about").

by joshuamorton

8/23/2026 at 8:38:56 PM

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.

by napo

8/23/2026 at 11:08:05 PM

Yes. My sweet spot is reporting to someone in the director levels.

by goalieca

8/25/2026 at 2:16:35 AM

I started as a developer and now run a small company. For the past 5 years I've been spending most of my time on planning and product decisions.

About a year and a half ago I started using AI heavily in that process. What used to be endless searching and asking around is now me debating problems with AI and shaping direction together. It's also great for building quick prototypes to communicate with developers and designers.

Since execution got so much faster, I can focus on the business itself. We even shifted our whole process from long-term planning to short-term cycles. It's been very effective.

But it's hard. There are just so many things I've never done before.

by nicedaylucas

8/23/2026 at 8:50:54 PM

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

by Neywiny

8/24/2026 at 4:26:51 AM

"Do the work assigned to them" has multiple levels of abstraction. You could say it's the task level which would be entry level. You could say it's the project level which would be mid level. You could say it's the a service or domain which would be senior. Staff should be tackling org wide and cross-team issues. The amount of scope and clarity needed for a "problem" changes and gets larger in expectation and more terse in explanation the further you go.

by jb3689

8/23/2026 at 10:46:39 PM

It depends on what you mean. There's lots of ways of looking at this, but I'd think of "entry level" as someone who is assigned individual tasks, and maybe needs help or oversight on completing them. Someone senior is assigned a project, or even a problem (and certainly has input on which projects they work on), and can handle the entire process of investigating, proposing, designing, and implementing the solution to that problem, which may involve oversight or tracking of other people.

Staff+ is additionally directly influencing which projects the org is prioritizing.

by joshuamorton

8/24/2026 at 12:48:24 AM

I wish our most senior staff eng/architects actually worked on stuff that is useful. They love playing around with new technology that has nothing to do with our current platform or where we're going. Sometimes they'll try to fix some thing the last architect started on before they too move on to another job.

by rr808

8/24/2026 at 1:28:27 AM

I advise people to seek out small companies, ideally ones going through product/market fit. Like, they recently came up with something to sell and have begun selling it. Resource-constrained, good growth, not super explosive. You can find one (including mine!). In this environment you will quickly learn how to do more with less, identify the real problems, deliver quickly, work directly with customers, learn the domain (not just tech), and how to build good products. After this, go ahead and work for a big company if you want and you'll be amazed how well you do.

by stevepotter

8/23/2026 at 9:14:05 PM

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.

by mcv

8/23/2026 at 11:04:08 PM

You definitely need a technical leadership or leaders who understand the staff level value. You also need sponsorship. And you need to accept you maybe propose 5 things and only 1 gets funded and then 3 years later a previous proposal fits the zeitgeist and gets funded.

by therealdrag0

8/24/2026 at 9:44:42 PM

“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

by will5421

8/24/2026 at 1:53:33 AM

I understand the approach to wait until the same pattern shows up across multiple different problem domains, to build a good solution for all of them.

But sometimes it's a chicken-and-egg problem.

Teams most often don't have the patience to wait for your proper solution. If you don't have a ready solution to easily address their problem, they just build their own work-arounds, or give up the task if it's too hard. And those teams all have their own priorities to tackle on their plate for the quarter, so even if you eventually build a proper solution later, it's unlikely they'd migrate to your solution or restart their task.

So even if you have accumulated a lot of old use cases, when you build a proper solution you'd need new use cases to justify your effort, the ones where the owner teams are willing to build along with the iterations of your solution. That kind of new use cases may or may not come up when you have the bandwidth and resource to actually do this. And if you miss one opportunity, the constant shifts of organization priorities would likely mean there would not be another chance for you to do it. The end result is, every team either builds their workarounds, or just give up if it's too hard, without a proper solution.

by wwind123

8/24/2026 at 12:23:26 AM

I tend to judge my impact as a staff engineer by the things I stop other engineers from shipping, as much as the things I "fix".

It's one thing to make architecture changes and features that people need, but being in the right conversation to say "don't do X, Y will cover 80% of your requirements for no extra tech debt" is afaic more valuable.

You've just taken a feature from a 3mth chunk to a 6 week chunk and thats a big thing.

by dbetteridge

8/24/2026 at 2:50:30 AM

Question from a "Staff+" engineering/product IC/leader in startup-like companies...

> [...] demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed.

This is framed in big-corporate worker motivation terms: being valued by the company, getting promotions, boosting career.

Is it generally possible to operate in big-corporate environments focused only actual success of the company and customers, and have all your needs (money, status, security, etc.) taken care of, without needing to think about them?

Or is playing to big-corporate reward mechanisms -- such as hitting known metrics, getting on high-profile projects, doing role performances, and getting credit with the right people -- the closest that you'll get to alignment and contributing positively?

by neilv

8/24/2026 at 3:20:57 AM

It’s a cop out, but depends on the company and it’s somewhere in between. Even with success-of-the-company as your compass, other stuff always matters. Good work done invisibly can’t be rewarded. Working on the lowest-profile projects is often interchangeable with working on the least important projects to the company. And if you are building credit with the wrong people, maybe you aren’t working on the right problems.

There’s obviously the dysfunctional form of all this, but it’s also rare that there’s one simple and obvious “do this thing and it’s best for the company and everyone will automatically understand what you did”

by ip26

8/24/2026 at 3:18:30 PM

P7 at Activision. Never had the problem of not enough problems to solve. I always have a priority queue of things to work on!

by ultrahax

8/24/2026 at 2:02:12 PM

In my last role as a senior you were siloed, with little visibility on larger company goals, cross team issues etc. It was nigh impossible to have a holistic view of things like mentioned in the article. I was lucky when the staff engineer handed me a problem to fix.

Have since moved to much smaller company, and I think the advice is valid there.

by wwqrd

8/23/2026 at 9:24:49 PM

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

by punnerud

8/23/2026 at 9:25:02 PM

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

by jofzar

8/24/2026 at 1:47:01 AM

> Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them.

Absolutely applies to product focus and customers too. Giving the customer exactly what they ask for with no analysis will result in crappy software.

Except that sometimes a company giving the customers exactly what they want does optimize for sales in the market (especially in "enterprise sales", government contracts, and anything involving RFPs etc)... it just always also results in crappy software. This is how we get crappy software that sells well.

by jrochkind1

8/24/2026 at 6:55:02 AM

I have tried this approach of finding problems and solved them.

I have done a massive code cleanup, abstracting out huge code that made it extremely readable and maintainable etc but such problems are never a problem to the upper management. For them these are red flags and a pain that they fear will cause regression and extra efforts to every other team.

So it entirely depends on the area that you solve the problem.

Also, it depends on the organization that you are working with. Especially the WITCH one's rarely care for code quality.

by codingbbq

8/24/2026 at 5:49:29 AM

The best problems to solve aren't in architecture diagrams—they're the daily friction points killing dev velocity and team momentum. Fix the papercuts first.

by pranav_tech26

8/23/2026 at 9:03:45 PM

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.

by rjbwork

8/24/2026 at 1:52:27 PM

Throughout my entire career I've always basically done this to move up the ranks when switching employers. Its frankly always been common sense to me that the business rightly or wrongly weighs engineer value based on production, so what you ideally want to do is alleviate the pain points that lead to slower production or failure to meet things such as SLA agreements. To me (assuming you're at smaller organizations) this really isn't exclusively a Staff+ concept but something I expect from senior engineers.

by rkozik1989

8/23/2026 at 11:37:10 PM

Talk to the customers. Sit along with the sales team when presenting to the customers. Join sales calls. Ask them about their problems, their pain points, and their current solutions.

by ww520

8/24/2026 at 3:40:03 AM

They tell you want tools they want and then do what you think is best. But don't understand why they really want tool x. Tool x does x and y but the case is made around x. You combine x request from different users and create your x solution never knowing about y and y is the main reason they want the tool.

by ipaddr

8/24/2026 at 2:27:57 AM

The author and I think very much alike. I felt like I was reading a journal from myself. I work for a larger engineering company and often times feel misaligned. This read helped put into words exactly how I approach problems and helps me better articulate that misalignment. Thank you to the author, great read!

by mal10c

8/24/2026 at 4:27:09 AM

What’s fun at the staff level is anticipating issues with the foresight that comes with experience. Going deep on a new tech so that when a situation arises, you are ready with the right tool and the depth to back it up. This is another way to deliver value the staff level.

by hdz

8/23/2026 at 10:33:02 PM

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.

by Syntaf

8/23/2026 at 11:55:40 PM

The honest version of "find problems to solve" is usually "find the thing you keep complaining about in meetings, then realize you have the mandate to just go fix it." Half of my best work was annoyance I finally got sick of voicing.

by luciana1u

8/23/2026 at 11:58:37 PM

Making life easier for yourself and your team is a big one for me, so I totally agree with you. Some times people don't complain about things they should be complaining about, because they don't know they can change them. I find that most big ticket items that unblock devs aren't code related but organizational which can in effect turn to coding issues.

by fishfasell

8/24/2026 at 8:31:08 PM

[flagged]

by luciana1u

8/23/2026 at 10:24:11 PM

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.

by spl757

8/23/2026 at 10:05:01 PM

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.

by lz400

8/24/2026 at 3:46:04 PM

Sounds like a dream, I'd love to be in this position and thought I was for a little while, but...

The narcissistic CTO started looking for even the most marginal of reasons to throw me under the bus; random grievances, random new technologies to add (seemingly to add keywords to the company's blog), childish manipulation tactics, literally describing how he felt the need to "whip" his engineers and that I wasn't the only one. It was a structure where basically any risk was actively discouraged, and my contract was eventually terminated for merging a mistake in a kube config that he and the DevOps owner had explicitly approved. Meanwhile, I'd been building very good vibes woth everyone on my immediate team, helping juniors, collaborating, investing myself in the success of the company, but he couldn't let go of the moment to moment control that he tried to exert at all hours of the day from across the continent.

I don't know how to avoid this in the future, if I continue in this industry, but it's overwhelmingly the norm not the exception. Give me the space to improve things and I'll work my balls off to get it done, inside the hours of the day we've agreed to. I'll delegate what I can to fresher faces in order to help them thrive and spend my time effectively, and I'll collaborate to find effective solutions or learn about areas I'm less knowledgeable about.

Incidentally, I've been wondering why I haven't really been motivated to find new work since then, and this must be a big reason why. Who the hell wants to put up with that!? It's depressing.

by brailsafe

8/23/2026 at 9:08:37 PM

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.

by yipinwong

8/23/2026 at 8:38:03 PM

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.

by alexpotato

8/23/2026 at 8:08:42 PM

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

by AlexMoffat

8/23/2026 at 8:32:06 PM

I spent the early part of my career (mid 2000s) working on a registration system for sports tournaments.

I had two jobs:

1. Writing the actual software for the registration website

2. Going to the events and managing the registration tent where people actually checked in

Doing 2 gave me a VASTLY better understanding of who the users were and how they thought. e.g. I assumed it would be tech savvy, organized people like me in their mid 20s. It was actually a mix of 40 something team dads who weren't tech savvy at all (b/c mid 2000s) but very organized and teenagers who were the opposite.

It meant effectively managing two completely different customer bases in the same product.

Coupled with the fact that cable modems were a new thing but not evenly distributed meant that we had to design the site accordingly.

At the time, I remember Joe Spolsky mentioning that at Microsoft they did two way mirror usability testing and it totally made sense. I wish more firms did that today.

by alexpotato

8/23/2026 at 11:45:39 PM

It isn’t this how everyone finds what to work on?

by lifeisstillgood

8/23/2026 at 8:50:34 PM

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

They usually find me.

by cool-RR

8/24/2026 at 5:09:17 PM

Hot take: Staff engs don't "find" problems. They find solutions to problems found by engg managers. If they wanted to find problems, they'd have went the management route instead of the IC route.

by stronglikedan

8/23/2026 at 8:09:14 PM

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

by NBJack

8/23/2026 at 8:18:50 PM

Thanks for letting me know; I cannot reproduce this myself on my mobile (it should be white text on a dark grey background) but I pushed a speculative fix which might improve things. Please let me know if it helps or, if not, I would love to know more details so I can fix this!

Thanks!

by lalitmaganti

8/24/2026 at 5:12:21 PM

It totally did. Thanks!

by NBJack

8/23/2026 at 9:24:56 PM

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

by hbarka

8/23/2026 at 11:39:05 PM

You guys have to find problems? The problems usually find me!

by throwatdem12311

8/24/2026 at 12:40:57 AM

Worked at multiple startups as an early engineer. A few were successful. One wasn't. A "staff engineer" was not an available position or job title at any of them.

by greenowl

8/23/2026 at 8:08:46 PM

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?

by zug_zug

8/23/2026 at 9:26:40 PM

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.

by 0xbadcafebee

8/24/2026 at 12:49:05 AM

Half of being a staff engineer is politics unfortunately, you need to build capital with "sponsors" in different areas of the business and use that to nudge change where you don't have direct control.

Quick coffee chats, trading favours and the like can get you pretty far in large orgs.

by dbetteridge

8/23/2026 at 8:58:38 PM

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

by johnbarron

8/23/2026 at 8:34:17 PM

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.

by zuzululu

8/24/2026 at 12:01:54 AM

This could easily be a blog. Multitasking using hermes takes skill

by bethekind

8/23/2026 at 11:12:12 PM

How do you deal with conflicting meetings? I stacked two jobs once before and ran into trouble with meeting conflicts.

by 4lx87

8/24/2026 at 3:43:36 PM

This I cannot really share for legal reasons but I will give you a hint: We cannot be at two different places at the same time.

by zuzululu

8/24/2026 at 9:16:54 AM

Listen more than you talk. Read more than you write. Don't ask people what they want, watch what they do.

This is one of my favourite blog posts of all time: https://javlaskitsystem.se/2012/02/whats-the-waiter-doing-wi... I sometimes tell this story to people. Many don't get it. A staff engineer needs to get it. A staff engineer will quietly watch and realise all the junior and seniors are merely churning away solving the wrong problems.

by globular-toast

8/23/2026 at 9:45:19 PM

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?

by theideaofcoffee

8/23/2026 at 10:58:59 PM

Eh, it’s valuable advice to a lot of people. Titles are bullshit and all over the place, true, but “how to approach the changing responsibilities that come with growing out of the kind of roles you’re used to” is useful to people regardless of what the role is called.

by zbentley

8/23/2026 at 10:21:54 PM

> 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

by einpoklum

8/23/2026 at 8:55:26 PM

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

by syndacks

8/24/2026 at 1:40:36 PM

this is going to turn into a world psychosis eventually, smelling AI on people's breath. the damned thing is plagiarizing the 5% of us that write new text, the AI is in the middle, not the beginning

by digitalsushi

8/23/2026 at 8:52:58 PM

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”

by pojzon

8/25/2026 at 1:58:30 AM

[flagged]

by nicedaylucas

8/24/2026 at 2:44:58 PM

[flagged]

by fenestella

8/24/2026 at 8:24:43 AM

[flagged]

by nicedaylucas

8/24/2026 at 8:38:47 AM

[flagged]

by plaingrid

8/23/2026 at 7:53:24 PM

[dead]

by hna8hjbqzy

8/24/2026 at 4:15:38 AM

[flagged]

by beauregardener