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 right to keep all teams and customers happy and productive is what I'm very proud of in my career.
Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.
Even in a big corp there are always problems to solve. The point is to find problems that both:
1) are hard enough that someone junior won't be able to solve them alone, and
2) actually provide value to the company / users
I managed to get a couple of smaller tools out recently thanks to having copilot available to churn on them while I spend my time on prescribed work, but it would consume all of my time to even make a significant dent in it.
I wouldn’t overthink this.
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.
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.
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.
Often it is a result of suggesting an improvement to some PR for a program or system that someone is doing some work on, and discovering that for whatever reason it doesn't quite work. This tends to lead to a deep dive of really analyzing and understanding the problem and how the piece of the system fits into the overall picture. This analysis often leads to a more structured approach to a problem, placing it in the context of wider industry or CS theory, thus enabling us to leverage prior art and other people who have grappled with similar problems.
Basically a StackOverflow guidance on XY problem applies to the general problem solving as well.
Making sure that the work was actually done.
I've been a Staff Engineer and managed engineers and it's pretty shocking what people consider to be "done".
A couple examples:
- Doing a migration to using Tailscale and an engineer claims it's done even though there is just one giant ACL for the whole firm
- Migrating from one monitoring system to another despite only 80% of the alerts have been migrated
- etc
Some of this is business folks creating bad incentives. Some of it is not creating good "success criteria" for projects. Either way, someone has to go through and make sure that both the details and the big picture deliverables landed correctly.
This being HN, I'm sure someone will say something like "just hire better engineers". I've seen phenomenal engineers make bad choices here due to poor incentive design.
A perfect example:
- you reward people for hitting delivery deadlines
- you punish people when there are outages
you might think you're pretty smart until you realize the odds of getting yelled at if you miss a deadline is 100% but the odds of an outage are <100%. The EV+ outcome then becomes to hit the deadline even if you know the code isn't ready.
Again, the job of senior engineers/engineering managers is to make sure these things don't happen by both double checking work and also pushing back on bad incentives.
Thanks!
I had two jobs:
1. Writing the actual software for the registration website
2. Going to the events and managing the registration tent where people actually checked in
Doing 2 gave me a VASTLY better understanding of who the users were and how they thought. e.g. I assumed it would be tech savvy, organized people like me in their mid 20s. It was actually a mix of 40 something team dads who weren't tech savvy at all (b/c mid 2000s) but very organized and teenagers who were the opposite.
It meant effectively managing two completely different customer bases in the same product.
Coupled with the fact that cable modems were a new thing but not evenly distributed meant that we had to design the site accordingly.
At the time, I remember Joe Spolsky mentioning that at Microsoft they did two way mirror usability testing and it totally made sense. I wish more firms did that today.
- 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.
I see a lot of people really eager to tell other people how to staff, but a lot of them sure do seem to disagree, and most people I know get to staff anyways without any particular skill after a certain age (title inflation?) including myself.
My smell test for an engineer is -- are they trying to quantify the size of everything in terms of impact, or are they just reacting to whatever customer knocks on their door?
This is the real reason why we dont see natural path for more ppl to progress towards Staff level.
Interestingly noone talks about this. “Be first or bust”
> 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 controlled environments. I would be curious to see how many tech companies (or the average engineer's experience) have changed from being tech led where engineers have autonomy to being more product management led. My suspicion without evidence is that the overall engineering autonomy has decreased over the years as the culture of tech has (in my opinion) shifted away from tech focus to more business, management, product focus with engineers just as the widgets who are tasked with fulfilling the goals of business, management, product.
all hypothesis, only anecdata
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 explain myself to managers and get proper approvals for same thing. 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.
Being not much ambitious I use to think after these many years and multiple successful project my win is to be a kind of made guy in that same mid-level position. Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.
Turns out things I assumed, don't exist. And even if they do they are above my level. Not worked in big tech, no massive RSU based compensation and with AI flattening difference (in employer's view ) between 2 vs 20 years of experience, story is not going to end great for people like me.
My experience has been you'll be regularly moved around to mitigate the "bus factor"
If you're see as highy capable you'll be moved on to firefighting duty.
In most of my career, especially when in a Staff role, it has been up to me to propose the direction and priority of work within my scope. Usually, this is based on my estimation of the impact to the business (possible new features, security) or operations (devx, efficiency $$$). Obviously I still have to work with product to get things scheduled as they have needs that must be met, but it was as an equal partner. As a very creative person thats usually the space I enjoy the most.
However I still see a lot of "work theater" where directors couldn't care at all about changing the bottom line but just care that work that sounds plausible enough is executed in a predictable way that makes them look good (in fact they get pretty disappointed if something happens TOO fast [like half the estimate] as it illustrates they are out of touch the work they are claiming to represent). What I'm saying is that "do more top-down-product" in theory makes sense as a direction, but in practice I usually see it as wasted energy.
The general perception is that JavaScript work in the corporate world is for young people who have no idea what they are doing and lack the maturity to write original solutions. This perception is common from developers who do other work, management, and developers who primarily perform JavaScript work. If I want to be creative or have autonomy to do anything more ambitious than putting text to screen I have to save it for personal side projects or do unrelated work.
MuleSoft work was just more of the same with all decisions funneled to strict silos of a select few and everybody else was just a keyboard pressing stooge.
Yes, that does sound dreadful, but what's worse is that it amplifies the personalities of people who will throw others under the bus for attention and potential rock stars who perform their most diligent work at hiding from that attention.
tldr; this advice is probably impractical for a bigger chunk of industry.
It doesnt make sense that this would happen from an economic perspective at first glance - not unless you consider labor (devs), execs and investors to be three competing groups who are vying for power.
Further, foreign business culture is significantly more too-down than American business culture.