Live data from Hacker News

How I find problems to solve as a staff engineer

lalitm.com

81–90 of 188 posts

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

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

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.

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

#82
post #52

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.

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.

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

#83
post #32

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…

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

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

#84

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

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

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

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

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.

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

#86

Earlier quoted context omitted.

Exactly. Everywhere I've worked had at least 3-4X more bugs than we had capacity to fix, and the bug count grew over time, net of any fixing happening. There was never difficulty finding problems to solve. Unfortunately most places don't give engineering the autonomy to solve critical issues. It's just feature cram and redesigns, over and over, and let the bugs pile up.

The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.

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

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

#87

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…

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.

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

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

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.

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

#89

Earlier quoted context omitted.

The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.

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

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.

Post reply on HN