Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I find problems to solve as a staff engineer

lalitm.com

Post reply on HN
Print view View original

101–110 of 188 posts

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

#101

Post by nickjj »

wpasc wrote: 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 spent ~20 years working either as a contract worker and in more recent years, full time work.

Every company I did substantial work for was bottom up from the perspective of my role, which is also related to infrastructure and developer tools / workflows.

Basically I'd work alongside the dev team and report to the CTO, VP of engineering or engineering manager depending on company size. Nothing really needed sign off beyond my manager and even then in most cases I was left to self-regulate 95% of it. That style makes a lot of sense for this type of role, it's much different than writing app code with feature requests coming from a product team.

Every substantial line of work was directly related to reducing friction, pain or instability as well as saving time. These could be workflows or technical implementations. Also a lot of times it is bringing order from chaos. These could be things that directly affected me or the dev team. Internally I treat the dev team as both peers and customers.

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

#102

Post by dbetteridge »

I tend to judge my impact as a staff engineer by the things I stop other engineers from shipping, as much as the things I "fix".

It's one thing to make architecture changes and features that people need, but being in the right conversation to say "don't do X, Y will cover 80% of your requirements for no extra tech debt" is afaic more valuable.

You've just taken a feature from a 3mth chunk to a 6 week chunk and thats a big thing.

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

#103

Post by dirtbag__dad »

intoXbox wrote: post #20

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

For non-engineering teams my playbook is:

1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.

You can limit chit chat very well this way.

You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.

For technical teams, almost every single thing I ship:

1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks

You can usually knock out the non technical team work and pick off 1 from technical team work along the way

Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.

I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle

Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals

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

#105

Post by rr808 »

I wish our most senior staff eng/architects actually worked on stuff that is useful. They love playing around with new technology that has nothing to do with our current platform or where we're going. Sometimes they'll try to fix some thing the last architect started on before they too move on to another job.

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

#106

Post by dbetteridge »

0xbadcafebee wrote: post #60

I have a different problem: I can find all the problems, but I can't solve them, because they aren't within my control. The people whose control they are within aren't interested in solving them (or letting others work on them). The political and psychological games required to get people to just let you solve problems seems like a second job.

Half of being a staff engineer is politics unfortunately, you need to build capital with "sponsors" in different areas of the business and use that to nudge change where you don't have direct control.

Quick coffee chats, trading favours and the like can get you pretty far in large orgs.

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

#107

Post by johnnyanmac »

bluGill wrote: post #88
wpasc wrote: 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 comm…

Hard to feel motivated either way when both roads seem to ultimately lead to layoffs, regardless of performance. If you can even get to staff/principal level to begin with. That's more a matter of when you were born these days instead of what you know.

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

#108

Post by hinkley »

wpasc wrote: 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 confess that when I work at controlling places, I engage in conspiracies. But I can only pull the subterfuge off for about 3 years and then I have to move on before I get PIPed for making their entire engineering staff more efficient, and then they move the goalposts for 'meets expectations' and don't know exactly what it is I'm doing, but they know they don't like it and now they have some numbers that tell them what they want to hear.

Like a woodworker building his own jigs, I always build my own tools whether the company wants them built or not. When I'm in a supportive environment, I work on and share those tools loudly. When I'm not, it's over lunches, behind closed doors, pulled out during emergencies, or just snuck into the CI pipeline without comment.

Frankly, the fact that not everyone does this has always been a cultural disconnect for me. The whole point of our field is to take repeatable tasks and write code to replace them. The fact that only about one in six of us does this for the tedious or error-prone parts of our own work is just maddeningly bizarre to me.

Nevermind the overly large fraction of people who have to be dragged kicking and screaming into using tools written by others. That number has gotten smaller over the last couple of decades but it started too high and the slope of that line says something awful about the industry. I don't know what, but it's something I'm sure nobody wants to hear, so I haven't poked at that bear too much (I have plenty of other bears to poke.)

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

#109

Post by alchemism »

ravenstine wrote: post #97
wpasc wrote: 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…

Every step up in my career has, ironically, lead to less autonomy.

“It is easier for a rich man to pass through the eye of a needle than find the Kingdom of Heaven.”

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

#110

Post by zmj »

zbentley wrote: post #27
intoXbox wrote: post #20

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

I’ve experienced this. The critical realization for me was that most of those problems which I know I can solve quickly, without even having to write a Jira ticket or groom them into a sprint or whatever, are problems I should let someone else solve . Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a…

Yep. Look for the problems that aren't going to get solved without you - either because nobody else sees the problem, nobody else is positioned to be the solution, or because your skills uniquely line up. That can't be all you do, but it's the highlight reel.
Post reply on HN