Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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 employers. I will be in a long standup meeting with company A while I am answering slack messages from company B or company C has a deadline that overlaps with another and I'd have to work on at the same time.
Previously without LLMs this was very difficult but now its manageable, especially with openclaw and hermes doing a lot of lifting. This let me discover a lot of what's discussed in the article naturally.
by zuzululu - This could easily be a blog. Multitasking using hermes takes skillby bethekind
- How do you deal with conflicting meetings? I stacked two jobs once before and ran into trouble with meeting conflicts.by 4lx87
- 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: being valued by the company, getting promotions, boosting career.
Is it generally possible to operate in big-corporate environments focused only actual success of the company and customers, and have all your needs (money, status, security, etc.) taken care of, without needing to think about them?
Or is playing to big-corporate reward mechanisms -- such as hitting known metrics, getting on high-profile projects, doing role performances, and getting credit with the right people -- the closest that you'll get to alignment and contributing positively?
by neilv - 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”
by ip26 - I advise people to seek out small companies, ideally ones going through product/market fit. Like, they recently came up with something to sell and have begun selling it. Resource-constrained, good growth, not super explosive. You can find one (including mine!). In this environment you will quickly learn how to do more with less, identify the real problems, deliver quickly, work directly with customers, learn the domain (not just tech), and how to build good products. After this, go ahead and work for a big company if you want and you'll be amazed how well you do.by stevepotter
- 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.by mcv
- 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.by therealdrag0
- 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 staffby Neywiny
- It depends on what you mean. There's lots of ways of looking at this, but I'd think of "entry level" as someone who is assigned individual tasks, and maybe needs help or oversight on completing them. Someone senior is assigned a project, or even a problem (and certainly has input on which projects they work on), and can handle the entire process of investigating, proposing, designing, and implementing the solution to that problem, which may involve oversight or tracking of other people.
Staff+ is additionally directly influencing which projects the org is prioritizing.
by joshuamorton - "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.by jb3689
- 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.by rr808
- 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 late, other teams are territorial and don't really want you to intervene.by napo
- Yes. My sweet spot is reporting to someone in the director levels.by goalieca
- 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 others have experienced thatby intoXbox
- I think that's a completely natural source of frustration for someone who is used to being able to put hands to keyboard and solve problems quickly, but IMO the higher you climb the ladder, the more you have the opportunity and responsibility to take a longer view and to delegate - which often means that other people are pushing the code.by jpitz
- 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
by dirtbag__dad - I find that I often tik-tok between organizational work and deep technical work. (I come close to the "solver" archtype on https://staffeng.com/guides/staff-archetypes/). There are weeks-months when I am not writing a ton of code. I'm still doing technical work, but it's architectural documentation, experimentation, or discussion where my contributions aren't directly visible in commits. Then there are weeks where I ship dozens of PRs.
I'm often thinking about 1-2 immediate term problems (what am I coding on now), 5+ medium term problems (what am I planning to work on next or moving such that someone else can work on it), and then a handful of long-term problems ("this is currently intractable, how do I convince leadership/this other team/etc. to make it possible for someone to actually address the technical problem I care about").
by joshuamorton - 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 week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.
At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.
It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.
by zbentley - Once upon a time my grand-grand-boss explained that he had no problem hiring top-notch engineers - pick up the phone, call recruiters for new candidates, connect the incoming stream to the interview pipeline, two months later you get the requested quantity of engineers. OTOH there is no repeatable process to hire someone who will help identify the right problems and drive them to resolution. So if such person is found they will be pushed towards doing things that have no obvious success recipe and away from the things that do.
> I don’t like being the person who talks and talks but doesn’t push code and ship features
It was fun while it lasted, wasn’t it?
by DenisM - 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!
by boulos - I 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 creating meetings and other wasteful things (doc writing) to occupy their time. Managers and directors seem to want big bloated teams, the larger their head count the more they can demand and push for a promo.by ronnier
- yea this was the case even before ai. fighting for scope is 80% of the job now. Ppl like OP dont really need to "Act like a sponge" and figure out "problems to work on" if there is natural demand for stuff they are building work will present itself.
There is also crazy ladder climbing with all these titles and difference in payscale. So ppl like the author are trying to optimize what a role X is supposed to be doing. Everyone is just the same thing everywhere.
Everywhere you go its the same ppl, same ladder , same tools same sucking up to boss blah blah. Cant wait to get out of this shit.
by dominotw - Isn't this just true for 90% of professional service industries?by alansaber
- 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.
- > other wasteful things (doc writing)
I wish people would create more and better docs. Pour as much time into a meticulously written doc details as they discuss indentation and variable naming style.
But instead, just like with your attitude, it's considered second grade or even useless work, and as a result docs always suck if they even exist. They don't get that code is made for people to consume just as much as for the machine, and docs are just an extension of that. That's one reason LLMs are so popular, they actually tell you what you'd have found in the doc, had it existed. But LLMs are restricted to the what and don't cover the why. I some places that makes good docs even rarer. In others it makes them easier since the machine generates the "fluff" and the human just fills in the rationale.
by teiferer - 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 a formality since they were already clearly doing the work. Every person I've seen 'rise to their level of incompetence' was striving to get the title/pay bump and looking to 'play the game' to get there.
If your motivation for solving people's problems is that it will get you a promotion, instead of the fact that you like solving problems, then it's probably not the right job for you.
by CSMastermind - In my org, you’re not allowed to do work like this without the title.by Drew_
- 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.by sebastos
- The issue is stuff like job security and layoffs; it’s easy to not care about what position you have until someone is looking to fire 20% of non staff engineers and suddenly you are afraid of being on the chopping block.by NewsaHackO