Disclaimer: Like everything else coming from me, this thinkpiece is entirely my own opinion and doesn't reflect the views of my current or previous employers.

I think it's important to share nuanced perspectives on career and personal growth to combat the stigma of failure, survivorship bias, and other things that make moving up and staying in this industry seem more glamorous or effortless than it is.

For a mainstream take, check out Gergely Orosz's "The Seniority Rollercoaster".

Theory of the Senior Developer

Every company has different expectations for senior developer performance.¹ As long as your title has "developer" or "engineer" in it, you're hired to do one of the following:

1. implement features or fix bugs independently with minimal guidance or direction, mentor less experienced devs, review code

2. research and solution complex or ambiguous problems your superiors don't have time to tackle
   

2.5 –and by extension, scale your abilities to level up team(s) as part of executing a technical vision or strategy, which may also include offering hiring, training, cross-departmental collaboration, and other leadership functions to alleviate the burden on your superiors.

Which were you hired to do? What are you able to do?

If you're not successful, why the gap between what you're doing and what you're expected to do?

What Changed?

When I first started in industry it appeared that expectations of "senior" included all items listed. Senior was a common terminal rung. Over time the career paths for technical leadership seemed to expand to include principle, staff, lead, and architect roles.²

And so it follows, title inflation and varying specialization of roles in different sized companies make expectations and opportunities for growth rather wavy when one embarks on that first rung.

It's been 10 years Edmund Lau wrote Effective Engineer. During its time of writing, interest rates were lower, allowing tech companies and VCs to borrow money more, and companies spent much more on R&D and competed for talent. The myth of rags-to-riches bootcamp-grad talent and self-taught dropout-unicorns were alive and well.³ Founders lamented over the lack of "10x developers" hires and offered 20% time to encourage devs to brew features and improvements they didn't know they needed.

Today, the cost-consciouness fueled by delayed-onset pandemic-rebound cutbacks, and the premature outlook that AI automates dev work have re-prioritized basic efficiences and delivery as senior responsibilities.

The developer traits celebrated in books that made startups-turned-tech-giants successful, aren't the ones that will help you keep your job, maintain a situational workplace reputation, or get promoted.

Hiring managers want cross-functional employees that learn fast and execute – not plan, solution, challenge and lead right out of the gate!

tldr; I think we're seeing shift in preference for Type B "rockstar" archetypes that steadily deliver results without pushing for above-and-beyond, as opposed to Type A "superstars".⁴

We don't go to work to innovate, lead, or "do agile"

We go to work to ship code expediently to meet business goals.

Some leaders mind more than others how we achieve those results, and it's best to figure this out at the interview stage or things can get acrimonious.

Unless you work in big tech company or incubator, the margin and time provided for innovation is slim to none at most workplaces. This isn't a complaint; it's a natural consequence of choosing a career where you trade knowledge work to produce products for money under capitalism.

In all likelihood, your company already has specialists with specific ideas and priorities to deliver on. Innovation requires weathering trial and error and is the most efficient in small teams in the early market validation stage of a startup.

By the time they've hired for your position, you don't have time to mess around with wheel reinvention or delivery lubrication. You're there to provide immediate value or fill a gap in capability. People need you in exactly that position for that function to do that exact type of building and maintenance work well.

Most businesses simply need people who can build well and fast enough without crossing into recommendations of plans or decisions.

You're more likely to find innovation and technical growth in OSS, community initiatives, or personal projects you share with friends who have more experience.

Staring at an undulating plateau

Expecting work to feed your sense of purpose is a tall order. In this economy, it's like expecting a romantic partner to meet all your emotional and intellectual needs.

You can jump your salary by learning different stacks or frameworks at different kinds of companies, ship working results faster. But more or less, with a track record in doing the same things in different domains, more people, over and over... you receive more of the same challenges.⁵

Your time-to-onboard is reduced, but so is the time to dispassionate feature flipping. You become so good in certain areas people would trust you less to do other areas, or they otherwise aren't able to see you go beyond it. Factory-style ticket flipping takes hold.

High performance is what your boss considers high performance

Doing what you're asked to well and being a kind human without crossing into the lines of fire is what John Cutler calls a kind of employee that's a "skilled pragmatist". While Cutler is advocating that this type of employee is the most valuable to engage and under-activated, I consider these types to be living role models I need to learn from more.

The heightened need for professional mindreading

There's an underlying dimension of seniority that I've observed, sets those who are successful and effective beyond senior from those who aren't: professional mindreading. 🦄

This is an inordinately difficult skill to learn and master.

When you move up, anticipating what your boss and team needs without actually being told becomes important. They expect to use less time to spell things out for you. You'd hopefully develop a way of working together that complements and augments their approach. That includes keeping up with what changed before and after vacation, messages and non-updates shared in team channels.

You're expected to read between the lines of what's being said and not said in meetings to evaluate the success and buy-in around a strategy.

You're expected to read the room, know when to speak up, and when to stay quiet.

You're expected to know when to take charge, and when to let others take the lead.

Check-ins and syncs with upper management will provide leads on what matters to them, but how you perform to complement your bosses' strategies without threatening your peers in the day-to-day is the truly insane challenge.

A lot of success shells down to fit between skillset, mindset and team chemistry. There might be pushback or protest against technical strategy or changes.⁶ You'll be expected to back them.

If your manager never had a hire at your level or they're not ready to let someone with their skills take charge, then how you're used to functioning at a previous senior role might come off as overstepping. It can feel puzzling to have some of their skills out-of-the-box, yet not be trusted to do things you could be delivering with your skillset.

If you don't have the title and you're treated as senior in skill, they'll assess you on this element because promoting you and having you around stakeholders inflects on them.

People who are effective and impactful may appear popular but it's actually because they're good at mindreading, in addition to building and maintaining relationships around the org.

Your managers might throw you opportunities to take on staff-level things too, but if you're successful at influencing for desired outcomes, also be wary that your influence doesn't outshine your bosses' or veteran devs.

Proactivity on the wrong thing or misinterpreting priorities will be seen as a waste of time or inability to follow through on exec priorities.

I've been primed to defer to authority and distrust my gut through various failure-intolerant environments, but when you are situationally in authority, you experience the consequences of not acting when it's important to.

And so you're left wondering:
how do you know when to act, and when to step back?

I don't know, and I'm still learning.

That's the way work goes

Every new role comes with new challenges and expectations. Like dating, staying on track about whether a position and the current business goals would leverage your skills and experience is important.

It's become less personal over time to connect the dots that I'm a poor fit, and I'd much rather know of that sooner than go through the motions of a PIP or a textbook quiet firing.

You could on paper, be hitting every goal and OKR, yet hated by management.

You can be the wrong high-potential hire who has the right experience, yet doesn't fulfill the goals or realize the functions set out.

You could be set up to fail in landing a role where they give you the title but no actual resource or decision-making power to hire or build out a team.

Perhaps the way the org is designed doesn't actually require senior capabilities.

No two senior roles are going to function in the same way.

The longer I've been in industry, the more humble I have to be.

1. Check out Progression.fyi for examples of publically available career ladders from large tech companies.  ↩

2. See Jorge Fioranelli's Engineering Ladders or Sarah Drasner's Career Ladders ↩

3. Gergely Orosz, "The software engineering industry in 2024: what changed in 2 years, why, and what is next", Craft Conference, May 2024. "How working for Big Tech lost its "dream job" status", CNBC, April 28, 2024. ↩

4. Kim Scott, "Balancing Growth and Stability: Why Your Team Needs People On Both Steep and Gradual Growth Trajectories", Radical Candor, Jan 01, 2023.  ↩

5. As a front-end focused software dev who's worked with n JS frameworks, I've noticed I'm encountering the same kinds of problems in different scenarios, people, and constraints. In front end, this looks like migrating from one framework to another, highly available headless CMS e-commerce sites, integrating a third party lib or service that is not available in such-and-such flavor of JS, optimizing configurations to reduce build time, teaching people to unit test, rewriting more variations of the same component, finding new ways to architect state management, revamping or rebranding a website. The worst of it is pixel pushing. ↩

6. Ludic Mataroa. "Your organization probably doesn't want to improve things", October 8, 2023. ↩