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

121–130 of 188 posts

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

#121

Post by ip26 »

neilv wrote: post #119

Question from a "Staff+" engineering/product IC/leader in startup-like companies... > [...] demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed. This is framed in big-corporate worker motivation terms…

It’s a cop out, but depends on the company and it’s somewhere in between. Even with success-of-the-company as your compass, other stuff always matters. Good work done invisibly can’t be rewarded. Working on the lowest-profile projects is often interchangeable with working on the least important projects to the company. And if you are building credit with the wrong people, maybe you aren’t working on the right problems.

There’s obviously the dysfunctional form of all this, but it’s also rare that there’s one simple and obvious “do this thing and it’s best for the company and everyone will automatically understand what you did”

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

#122

Post by ipaddr »

They tell you want tools they want and then do what you think is best. But don't understand why they really want tool x. Tool x does x and y but the case is made around x. You combine x request from different users and create your x solution never knowing about y and y is the main reason they want the tool.

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

#123

Post by ipaddr »

geodel wrote: post #47
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…

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…

The higher the position the less leeway you have because you are working on bigger problems with more experienced people who want to do things their way.

It makes sense the higher up you go the more demanding the boss because their boss is more demanding.

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

#124

Post by supriyo-biswas »

0xbadcafebee wrote: post #61
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…

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…

> That's exactly what engineers are supposed to do: listen to and enable the business.

This may be the case if you're a junior engineer just crunching through individual tickets, but with the lower end of software engineering being automated away where even more junior engineers have to take more product/feature ownership, I don't think "churning widgets" is the right way to think about our job anymore.

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

#126

Post by noisy_boy »

geodel wrote: post #115
majormajor wrote: post #62

Earlier quoted context omitted.

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

> Especially if management rotates and new management didn't actually create the success in the first place. Critical point, and absolutely true in my case. With change in management all past successful projects are "failures" now. Instead of using x, y, z projects uses a, b, c so leadership is kind to dismiss me with prejudice.

How will you get bonus if you don't do anything different?

How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things?

How will you replace them without funding i.e. more budget, more power?

How will you keep moving up if you don't repeat this cycle?

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

#127

Post by jb3689 »

Neywiny wrote: post #35

It's interesting how engineer/developer levels are so meaningless across organizations. Where I am, somebody who can only do the work assigned to them isn't senior. That's borderline entry level. Doesn't mean they're a bad programmer or only have 3 hours of experience, just isn't at the higher level. Seems where this person works (Google?) that threshold is at staff

"Do the work assigned to them" has multiple levels of abstraction. You could say it's the task level which would be entry level. You could say it's the project level which would be mid level. You could say it's the a service or domain which would be senior. Staff should be tackling org wide and cross-team issues. The amount of scope and clarity needed for a "problem" changes and gets larger in expectation and more terse in explanation the further you go.

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

#128

Post by hdz »

What’s fun at the staff level is anticipating issues with the foresight that comes with experience. Going deep on a new tech so that when a situation arises, you are ready with the right tool and the depth to back it up. This is another way to deliver value the staff level.

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

#129

Post by FridgeSeal »

CSMastermind wrote: post #46

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 this is partly a function of your organisation.

Some places, do not care terribly, about what you _could_ achieve, or they have garbage internal practices which prevent you from doing this work effectively no matter how much you _care_, or maybe they’re just a garbage workplace but you need the job. In these cases, you may as well ruthlessly go-for-the-title, because they’re not going to change, so you may as well get something beneficial while you’re stuck somewhere shitty.

Now, if it’s a decent org, which looks after its people, produces a product it cares about, has actual career progression, sure, you can afford to do the work first and earn it properly, but let’s not pretend that’s amazingly common, and attempting to do this, in some places will just get you exploited and burnt out, with no pay or title bump to show for it.

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

#130

Post by JauntyHatAngle »

rconti wrote: post #118
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'm sort of in this area, and I'm fighting the same struggles because I desire "productivity", not autonomy. I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care. IMO, i…

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 could feel the turn happening to metrics.

Sure enough the only person in my team let go was because he outright refused to fill in his JIRAs and I could not get through to him the difference in what is logical and what plays well to management when they lose their minds.

Bit of a tangent, but even in the work you're describing, I treat sprint points and JIRAs as future CYA, not necessarily a work sheet.

Post reply on HN