You guys have to find problems? The problems usually find me!
How I find problems to solve as a staff engineer
91–100 of 188 posts
Re: How I find problems to solve as a staff engineer
#92The 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 comm…
(author here) I really like your framing here! I think it captures the essence of my thinking in a really concise and coherent way.
Re: How I find problems to solve as a staff engineer
#93It isn’t this how everyone finds what to work on?
Re: How I find problems to solve as a staff engineer
#94The 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.
Re: How I find problems to solve as a staff engineer
#95The 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.
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.
Re: How I find problems to solve as a staff engineer
#96My 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…
This could easily be a blog. Multitasking using hermes takes skill
Re: How I find problems to solve as a staff engineer
#97The 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…
Every step up in my career has, ironically, lead to less autonomy.
Re: How I find problems to solve as a staff engineer
#98The 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…
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!
Re: How I find problems to solve as a staff engineer
#99Earlier quoted context omitted.
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.
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.
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”
Re: How I find problems to solve as a staff engineer
#100Funny 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.
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