Live data from Hacker News

How I find problems to solve as a staff engineer

lalitm.com

41–50 of 188 posts

Re: How I find problems to solve as a staff engineer

#44
post #6

The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…

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.

Re: How I find problems to solve as a staff engineer

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

Re: How I find problems to solve as a staff engineer

#47
post #6

The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…

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.

Re: How I find problems to solve as a staff engineer

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

Post reply on HN