The senior engineer death spiral

The senior you get the more you realise that the only reward for hard work is more work. Then, you learn to say no more often and set boundaries and negotiate like if you want me to work on project A, then I won’t have capacity to work on project B.

Unfortunately, this is something you have to learn through experience and cannot be taught by someone else.

> and what happens is they start disappearing for longer periods of time... they quit their jobs because they think, “you know what, this is not salvageable.”

I've interviewed several great senior engineer candidates over the last few years, and then had to watch do this and walk themselves right out the door inside of 6 months. I've developed a marked preference for promoting internally, because you get longer to head this sort of thing off.

Incidentally, this sort of thing is why software engineering desperately needs some sort of formal levelling criteria and/or mentorship programs. It's really hard for senior folks to calibrate themselves against their rapidly shrinking peer group.

At least we know this wasn't written by an LLM (unless it was GPT-2).

The best advice I can give on moving your career forward is to not try and get a promotion at your current job. Apply for better positions at other companies while you still have your current role. You'll have maximum leverage and unlimited time to choose the best possible option. Trying to claw your way up the ladder in a single company is the least efficient (and more often than not hopeless) strategy.

Err..I would take this with a BIG pinch of salt. It massively depends on the workplace culture.

Perhaps I am lacking context on the “seniority” of this individual. Unless they are a Principal engineer, or operating as an architect/staff engineer, or as a “tech lead”, I would absolutely expect them to be solid engineers delivering code.

They would have clear deliverables in sprints that would typically be heavier and more complex than their junior peers.

Take this from someone who has worked in all of the above roles and subsequently in management.

I’m in this exact position and I don’t know the next steps forward. I’m on a sabbatical because I burnt out after a massive project but the expectation is that I come back and lead another massive project.

I’ve yet to decide if that’s what I actually want or if there is another solution out there. Is leaving the only real solution?

I'm a staff engineer and I haven't thought about trying to get promoted a single day in my life. Do good work and be nice the rest follows

i’m very happy in the “terminal” senior position at my company, there are higher levels but it’s fine to stay at the level that i’m at forever. i don’t need to pick up extra work because im not trying to get promoted and i can usually get by just by having smart sounding ideas in meetings, helping figuring out the more ambiguous tasks and just doing enough to meet expectations. the expectations of the higher levels seem pretty unpleasant , and the guys at lower levels than me are happy to pick up extra work because they want to get promoted lol

Please use capital letters when you write.

Sometimes to look like a genius you have to look incompetent for a bit.

In a place operating with SCRUM you're often expected to be shipping things every sprint, and sometimes with a large and important piece of work the experimentation, and the building of the thing, doesn't fit in a sprint, and if you tried to ship incrementally you'd just be shipping junk.

So you're going to end up giving some standup updates that do not inspire confidence for a bit. "I tried this thing, didn't work out", "still working on X, tried another thing", etc.

It's possible at the end of it you figure it out, and the result justifies the time investment.

The spiral is friction with a system that disincentivizes taking on ambitious goals.

I wouldn't just blame the engineer for not shipping smaller things, being less ambitious, talking more instead of working, I'd blame the company culture for disincentivizing deep work and ambitious goals.

Obviously there's a limit to this. You do need to ship something useful eventually. It's possible you spend extra time and still fail to accomplish the thing you wanted. It might be damaging to your reputation. You win some you lose some.

With AI there's less time between having the idea to do something or try something, and it being done or ruled out, so I see this being less of an issue now. The main barrier is knowing what to do and describing it.

> “oh, if I work harder, do a bigger thing, then I will be rewarded with promotions and what have you,” right?

Answer: No.

> he was asking me how to do a 60 to 80-hour week

It's simple: just don't do it.

AI coding tools can really make the "in the next week, I’ll do a whole month’s work. and no one will know" feel especially tempting, particularly if you're deep in the execution phase of a project. Truth is that can end up like Brooks's law on steroids.

Instead, just communicate with your stakeholders asap. Chances are they already know the project is at risk, and they'll be amendable to either descoping or pushing back the deadline.

Yep, been there, and I will add that they will think you are not doing anything or just slacking, meanwhile you are the opposite, and creates resentment from each side, and I wasn’t doing it for cosplaying or similar, but I am too passionate about it, plus, in these situations the team were all juniors or even coop so they won’t add much. What I am doing now is the opposite, and I keep my passion for my personal work, both business and fun, life never been better!

This is fine advice up to a certain point, but you do not accomplish bigger and grander things by working harder, nor even, as this implies, by working more diligently. You accomplish them through leverage.

It is not just about what you are working on. You need to understand what everyone else is working on, and more importantly, what they could be working on (their capabilities) and what they should be working on (the org's priorities). When you find yourself being dragged in to meetings to write roadmaps, estimate schedules, and contribute paragraphs to the annual budgeting process, you know you're on the right track.

He does have one thing right, that this is about reputation, because you cannot just go out and unilaterally take this authority. It has to be earned. Having a large number of lines of code written, commits landed, and tickets closed can be a means to that end, but it is not in and of itself the goal.

The single, most important leading indicator of your success will be who you’re having lunch with every day.

I wish that I could travel back in time and tell my 25-year-old self this information.

I didn’t understand this because of the stream-of-consciousness delivery.

I genuinely don't want to upset anyone, but as someone with 20+ years of engineering and management experience, I think it might help some people to hear what is most likely really going on here.

This is probably an example of the Peter principle:

The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.

https://en.wikipedia.org/wiki/Peter_principle

There's a huge amount of title inflation going on in the industry. We're now seeing the "Principal Engineer" title being given to people with 3 years of professional experience.

Unfortunately, this is simply not enough time to be very good at all, no matter how much raw talent you have. It takes a decade of experience just to know how to manage yourself effectively, let alone mentor others and lead large projects.

If a senior isn’t doing what they feel is meaningful work - or not communicating what they’re focused on, isn’t that partially on their manager?

obviously, more senior ICs should be creating/defining/delivering their own work. But either way, alignment with director or TL seems like a good idea to reduce anxiety

The scenario laid out is pretty dated. Most scrum shops would not permit this level of backstory anymore. Admittedly I have seen this happen in the old days but it wasnt usually very impactful. It was in places where people had too much time on their hands and not much supervision.

Also there isnt much above senior/lead engineer these days, there is no straight line career progression above that. You can try to get into architecture but thats mostly paperwork, or management which is mostly dealing with people.

If you want to call your own shots as an engineer the world is your oyster, start your own company and build it. There is not much worth "being in charge of" in corporate dev shops that I can see or would want to be a part of. Most of it is retread, make work including FAANG.

If you don't truly enjoy what you do, you'll get crushed by the pressure. Don't try to impress people. If you feel pressure, take a step back, reflect, and think about what's important to you. Then communicate this clearly to people around you, including yourself.

My plan was to always "retire" to a comfy university job but I no longer feel that way - I still really enjoy what I do.

I liked this a lot. I have also struggled with this, and I feel compelled to suggest my own angle: this is often caused by issues that are not (just) professional skill gaps, though closing those gaps can help resolve it.

Avoiding status updates, needing to “prove yourself,” things like these, were all products of a deeper lack of trust for me. TFA alludes to this with “imposter syndrome”. I was so used to this that it took a long time to figure out. What helped me (and I wouldn’t say I’m better, but better than I was) was a few ideas:

1. Trust is equal parts competence and communication. Trust is lost when you expected X and didn’t get it, which means half the problem is not getting it and the other half is expecting it in the first place.

2. So trust requires clear communication, and clear communication requires trust in the other direction. At a totally dysfunctional company, all of engineering doesn’t trust leadership, so they're not honest with leadership, and soon enough leadership doesn't trust engineering, if that hasn’t happened already. So lack of trust in one direction breaks down trust in the other direction.

3. If you don't feel comfortable saying something that's true (anything! “I got nothing done yesterday because I still don’t really understand the problem I’m solving,” or whatever kind of thing you’re afraid to say), it means you don't trust whoever you're talking to. This is a problem—see #2. In the context of TFA, this is the problem that leads to you skipping status updates or going off and building without prior discussion.

The solution is building your own trust, which can actually be hard to do and requires some self-knowledge (e.g. did you have a bad experience at a prior job? Are you dispositionally a nervous person? Did your boss/leadership break your trust in some way already—large or small?).

This is IMO what TFA is really about, and the strategy it suggests is a great one if a bit of positive feedback and encouragement is what helps you extend trust (which is fine! It's worth knowing that about yourself) and grunt work earns you that feedback (which it might, though you can't control what other people do—it may also help to communicate that you're looking for that, e.g. "I want to see what kind of contributions are celebrated here, and I thought these might be." A small trust exercise in the context of the larger one.)

It might be something else. Off the top of my head: will work respect my needs if a life event temporarily interferes with my work? If I'm missing context on a project, will I be given help or hostility? Am I being given a clear explanation of the expectations for the role?

(Finally, I think it's worth mentioning the version of this where your boss or leadership isn't building trust in you, and IMO it looks like you stuck in a marginal role and not given a path to larger ones, even though you're clear that you want them. Sometimes you can convince them to trust you, but you can't control what other people do. In particular, if you're building something without prior discussion, consider that a lack of trust from the company to you is now creating a lack of trust from you to the company. Maybe it'll be fixed, but no guarantees.)

This hits home. Had the _exact_ scenario play out last year at my last role

sounds like https://en.wikipedia.org/wiki/Peter_principle

Man this really hit close to home as a guy transitioning from engineering to GRC. The last 1.5 years I have absolutely burnt myself out going flat out trying to make the transition to the next level and it has gone so poorly.

Sadly in many organizations it really does come down to a “consensus” within the environment about if you are succeeding in the role and fit. Woof.

Disappearing for long periods of time and the giving vague updates like "everything going well guys" is not the behavior of a (even mediocre) senior. This is the behaviour of a poorly managed junior.

As a senior its your responsibility not to disappear into a cave but to do the opposite - show what you are doing, show your thought processes so juniors can learn. Discuss openly your problems and encourage discussion and feedback and show the juniors that its ok to be vulnerable and not know everything.

Then you have to keep management informed exactly whats going on, where your Blockers are, what intermediate goals you have and progress towards them.

  > the thing they do is they tell themselves they need to almost cosplay being a more senior engineer than they are.

Isn't this explicitly written in every promotion guide? Every one I've ever read says you need to be working at X level for Y months before getting promoted to X. Thats not delusion, that's codified. There's good reason people work like that.

  > like, for two, three weeks, you won’t hear anything from them.

Two might be fine, three is probably pushing it, but a lot of times this is just bad communication (which I think is more the point). But also our field is extremely rushed for some reason, especially with AI. Sometimes things do take time. Honestly, I think the whole industry could move a heck of a lot faster if we just cooled our jets for a bit. Innovation doesn't happen by slamming your head against the wall, it happens in the quiet moments after lots of head banging. But our culture acts like we can brute force our way.

We constantly say "I'll fix it later" and we never do or do it when the problem has turned from a small one into a big one. Why can't we fix problem while they're still small? It's penny wise and pound foolish. Does your manager actually know if it will become a big problem? More than you, the person in the weeds? How would they even know? Would you even tell them? Are you afraid to tell them?

We're constantly jumping from bandwagon to bandwagon, not taking any time to even check where we are or look up to see where we're going. And we attack anyone who pokes their heads up like we're afraid we'll get hosed reaching for a banana.

Is it really any wonder people burn out? You can't operate at high anxiety forever.

I have a lot of trouble reading prose that’s written without capital letters. I can’t understand why writers would do that. Nor can I understand why readers engage with this.

I am having a hard time believing that anyone who uses the word "bro" this much is capable of advising anyone with seniority, because I don't see how they themselves would have the necessary seniority to give such advise.

But I suppose the message, hard to read as it is, is something that some people need to hear. I've seen this first hand a few times, mostly in people who got promoted by working really hard and the more they got promoted the harder they felt like they must work to keep proving themselves. This often led into burnout.

I don't know; I don't really want to blame the people themselves or say that they're the ones responsible of their own condition. People, and I want to say technically minded people in particular, are each rather fallible when it comes to our own humanity and the psychology underneath. And so, I'd much rather see this same advise be targeted to managers and senior teammates: when you notice a colleague who seems to have gone in too deep, have a friendly chat. They might very well be blind to it, or trying to ignore it to push through just that one more time.

The single, most important leading indicator of your success will be who you’re having lunch with every day.