[flagged]
How I find problems to solve as a staff engineer
141–150 of 188 posts
Re: How I find problems to solve as a staff engineer
#142Earlier quoted context omitted.
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 co…
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.
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.
Re: How I find problems to solve as a staff engineer
#143The 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 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".
Re: How I find problems to solve as a staff engineer
#144Listen 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.
Re: How I find problems to solve as a staff engineer
#145Earlier 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.
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.
Re: How I find problems to solve as a staff engineer
#146Earlier 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.
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.
Re: How I find problems to solve as a staff engineer
#147The 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 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 improve…
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.
Re: How I find problems to solve as a staff engineer
#148I 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…
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.
Re: How I find problems to solve as a staff engineer
#149The 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 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)
Re: How I find problems to solve as a staff engineer
#150Funny 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…
> “… 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?