Live data from Hacker News

How I find problems to solve as a staff engineer

lalitm.com

61–70 of 188 posts

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

#61
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…

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.

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

#62
post #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 expla…

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

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

#63
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…

[deleted]

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

#64

Earlier quoted context omitted.

Just means it can be powerful or useful technique that can feel “magical” when employed. I wouldn’t overthink this.

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

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

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

#65
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?

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

#66
post #2

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 ri…

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.

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

#67
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…

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?

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

#68
post #53
post #47

Earlier quoted context omitted.

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 expla…

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

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.

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

#70
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
Post reply on HN