Crossing the senior chasm

Until you're working well and closely with senior devs, you might not know you're ready to take on senior or staff level challenges!

For some, attaining the title has become a holy grail pre-occupation as they trudge through workplaces with uncharted growth paths and immature leadership. For others, that title is just a prefix in a long career of building things.[^1]

The skill range, compensation and responsibilities around seniority is wide across industry; it's normal to feel perplexed and never ready enough.

Since you're reading, I imagine you've been contemplating a move up. Here are some ideas after bashing my head since 2020.

What makes a senior dev?

There's many ways to be senior. Check out Neil "12 types of under-appreciated software developers" for traits you might not be aware of.

If we defer to Sara Drasner's Career Ladders, a senior engineer "[masters] how effective they can be as an individual contributor"

What about more specialized kinds of senior? Like an architect or staff engineer?
Will Larsen describes different archetypes of staff engineer.

Which path interests you? Why does it matter to you?

What kind of impact do you want to have on a team and by extension, your community and industry?

How do I get promoted?

To be promoted internally:

• you need to demonstrate you get shit done (i.e. are able to complete features independently or guide a team towards delivery)
• you've discussed a growth path with clear goals with your manager
• you need advocates who will vouch for your promotion and already see your potential
• your boss can justify paying you more to his boss

That's a lot of to line up. Wouldn't it make more sense to discover your own leadership style at a new job?

Most companies that need to scale or build product fast and will opt to hire people externally instead of internally promoting whomever has been taking on extra work. If you've been struggling to get a promotion, this is your chance.
Every new job is an opportunity to rebuild the perception of you at work.

There is no dream job. Which bowl of shit do you wanna eat?

What about seniority appeals to you as a next step?

Beyond the apparent credibility of the title, and setting yourself up for better paid opportunities, what are your inherent beliefs about the position?[^1]

Is it a step to another destination?

If you're interested for the paybump and influence, there's easier paths to do that without needing to juggle the sometimes-escalating fuckery of balancing business needs and personalities with learning everchanging technologies to build software.

Signs you're not ready to make the leap

• [ ] you're bothered by peers' achievements.

• [ ] you feel it's important be right instead of creating consensus in a situations of disagreement

• [ ] you prefer to work alone on a project or worry that someone may steal your ideas.

• [ ] you can't bear the possibility of being wrong publicly.

• [ ] you don't like to spend time connecting with people to build software.

• [ ] you don't think it's your job to improve things for your team or make their lives easier

• [ ] you don't particularly enjoy learning about emerging technologies or practices

• [ ] you're skilled at writing code or learning things fast, but don't like explaining how you do something more than once

• [ ] you're not interested in helping less experienced developers grow.

There are too many rude, morale-draining, fear-inducing technical leaders, some of which aren't worth their weight in experience or competency based on how poorly they treat others.

Let's improve the world by not being like that.

Technical rigour is a given, but communication and working with people distinctly unlike you will be the most challenging to navigate.

With that out of the way, let's talk look at how to promote yourself, mentally and occupationally.

Build a track record of Getting Shit Done

Do what you say, and say what you do. Ankita Kulkarni mentions this in "The Leaders Playbook: First 90 Days".

Some ways to demonstrate accountability besides shipping features:

• following up promptly and providing status updates to the right people
• going to meetings prepared with agenda, acknowledge viewpoints and summarize takeaways
• surface risks and tradeoffs while letting people make the final call
• helping leaders make decisions when they're unsure
• mention priority and provide nuanced but concise estimations given different scenarios
• letting people know you broke main and you're fixing it

Take projects to the finish line

If you can write features independently but are looking to gain more responsibility, you might start getting involved in conversations that involve different decision makers across the business.

Or you might be onboarding the rest of a team to implement a solution from a senior developer, unblocking folks so they can deliver their features or fixes on time.

At some point, you'll develop opinions about how to build better, safer, stabler software.

Above: Kim Scott's "Getting Shit Done" circle

The key function of a senior is to force-multiply and support those with less experience while delivering value consistently. Some passion for craft helps, too.

When the business needs it, you'll be the firefighter or code janitor for anything that goes wrong on the codebase. Learning fast to find solutions, unblocking and coaching others, descoping features so folks know what to work on, reminding people to merge their features sooner than later, exploring solutions on shaky ground become common responsibilities in seniority.

It might have seemed heroic when you weren't senior to stay late to hotfix a broken release. After that, it's just part of your job.
Note: I don't believe it's a requirement to work overtime, but such tasks often fall onto senior devs due to mismanagement.

If you've done this, well there's a few more more lines on your resume! ✨

Adjust your signal to your audience

Being able to talk to contributors and leaders from other departments will be important in building trust and improving your visibility across your organization. Outside of talking to developers, you'll need to reframe technical subjects and concerns in laypersons terms with analogies and metaphors.

For example, a product manager doesn't need to know the exact mechanics of what is causing a critical error, but more likely, which error, how severe and feasible it is to be fixed, and who might be best to assign it to.

A tech executive might still code and know exactly what you're talking about if you describe all facets of a problem, but won't have time to read 3 paragraphs.

Build relationships with other senior folk

Assuming you have been doing this for a while (couple years, or even 10!) and you're genuine in your attempts to help others, along the way, you'll meet people above or below or adjacent to your levelling that will inspire, encourage and guide you, or simply be there to help in your darkest hour. Some might even sing your praises.

Or by engaging with online communities you might encounter regulars who you end up getting to know, and they may offer on-the-fly advice or perspective on situations at work.

When you meet develop such relationships, ensure you mutually agree on how they can help you, and your own goals.
The formality and structure may vary.

I've even found as of late, having conversations every six months or a year with someone I used to work with, or with more experience, has been helpful for my own growth.

Don't screw up with mentors, coaches or sponsors

In all likelihood you're a respectful human so this section is more for well, just in case.

Jobs and leads don't show up on a plate just, especially not just because you know someone, intern or volunteer for them.

The one who is your supporter may be sticking their neck out for you by recommending, referring or advocating for your promotion.

So, don't be late to a referral-offered interview, or drop the ball on practicing a presentation you agreed to give, etc.

Performing poorly or being unprofessional will lower the credibility of the sponsor recommending you, thus making it less likely they'd recommend you in the future as it inflects poorly on them.

Reflect and process feedback

Working closely with a team over time, you'll notice gaps between on-the-ground work and management vision. You're inevitably going to encounter disagreements on approach.

If you've gained the trust of your team and stakeholders, they'll be turning to you for help, clarification, for decisions, or just to vent. People all kinds of experience will also be approaching you with opportunities. You may also find yourself manipulated, pressured or gaslit to fulfill different expectations and agendas.

Higher communication overhead from increasing seniority requires increased self management: the ability to maintain professionalism and calm in the face of doom, to identify and reduce personal frustration, or perhaps to not let as many different opinions and reach-outs clog up your work time.

Journaling to document and understand thought patterns and sus out politics without letting stress become a venting chamber to those close to you.

Build a track record of going Above and Beyond

Improve delivery or business outcomes

Your ability to learn a business domain and translate that to an agreeable implementation for a team while ensuring they're productive will be your best asset. This might involve teaching a team how to performance test, a reading group on cleaner code, a multi-sprint or multi-quarter initiative to mitigate tech debt etc.

The tricky part is getting leaders to believe there is a problem and your time would be well spent by solving it for maximum impact. In the same way you have to forge relationships with seniors, regular check-ins with stakeholders up and across will become part of relationships to maintain such that you're able to get buy-in for your ideas. This larger the company, the longer it will take to build trust, and the more layered politics are.

Create welcoming environments

A team is just a group of people that trusts each other enough to work towards the same goal.

Culture ends up being the things people feel able to say and do day-to-day at work; relational "vibes" are almost immediately recognizable within 2 weeks. Consider:

• Whose opinions are valued when they speak?

• Do leaders ensure those who haven't said anything have their opinion invited?

• How do leaders respond to genuine concerns, questions and improvements to the business?

• Who ensures their work stays on track, and how do contributors respond to them?

• Do people meet and talk outside of required meetings; are they excited to find ways to improve things?

• Are people of different levels open to sharing work-in-progress?

• Are your leaders mature enough to handle inconvenient truths? What would that mean for how you can do your job?

Signs that people feel empowered and valued for going above and beyond, should read as whether this is a place you can thrive with your expertise.

Creating a climate where people feel safe to surface glaring issues, troubleshoot and unblock each other, share solutions results in improved performance and delivery.

What kinds of experiences of collaborating with others did you feel safe and accepted?

It might be through pair-programming, group discussions, casual chit-chat on DM or getting to know someone's career path one-on-one.

Without psychological safety, people become fearful of surfacing risks and incidents, get competitive for solo recognition, or become disengaged. Departures might be common. Remaining members might shoulder an unfair amount of work, leading to burnout.

Elevate and Guide Others

Pick the most important fights and fires

While working on a single project team, you might have an easy time agreeing on linting rules and naming patterns. If you hop between firefighting or unblocking different products and projects, you may slow a team down by asking them to change too many practices at once.

No one is going to do everything the same way you would, and it's demoralizing for a more-or-less effective team to have someone point out every single flaw on their work. Your time and energy might be better spent solving ambiguous problems and turning stones others don't have the experience to look under.

It takes courage and self-confidence to say what's achievable in a certain time, and whether that time from you or your team is worth it. It takes courage to also identify who might be underperforming and taking more time from you than they should.

Recognize and reward initiative that is oriented to improving team performance and delivery. Acknowledging the effort people goes a long way.

Protect your energy

While managing a community and being a lead dev, I burned the candle at both ends by:

• being too involved in everyday ops of all teams
• being too hung up on details of how things are done
• not pushing back on added priorities often enough

I spread myself too thin and was constantly underwater and completing the next most important task or making decisions to qualm whoever was complaining. Trying to make everyone happy isn't leadership, and people lose respect for you if you don't make hard decisions.

If you are conflict-aversive or have immense people-pleasing syndrome, learning to say no to requests for help and have difficult conversations to advocate for your team (and yourself) will be challenging but necessary.

The difference between now and after with that "Senior" title

Before

When you don't yet have the title people are more likely to treat you in the way that's "one of them" on the team. Your margin for error is relatively high. Reasonable workplaces will resource someone firefight if something goes south.

In the absence of leadership some might even start turning to you as defacto leader for having all the know-how on the project. (Or they're just glad someone is doing the glue work.) Regardless of whether you're promoted, know what you did made you able to move a team and lead them towards delivery and ensure the success of a project. ✅

After

After you land the title, all kinds of expectations and feedback come your way. Your margin for error lowers to a three-stamp punchcard, and recovery from them becomes crucial. (i.e. having a plan of action or finding workarounds, rolling out patches after discovering a solution you created is buggy throughout the software)

If you were a very competent performer, a lot of what you did will still be your job. Code reviews, writing features, unblocking others, etc. But now you'll be expected to that on top of architectural meetings, learning initiatives, firefighting and validating technical decisions or solving problems with no clear prior path.

Navigating ambiguity, full days of meetings to rectify and chunk down initiatives, reorder scope and providing the path forward for teams whether there is one, will become a regular part of the job.

But if you've done this before, you can and will do it again.

Making your way

Figure out what kind of senior you want to be, gather impact notches on your resume, and start applying!

The first 90 days and especially the first year, are a test of whether your idea of "senior" and a particular company's ideas of it aligns with your values and career goals.

If it doesn't work out; don't take it as a personal failure.

So:

• [ ] You get shit done. ✅
• [ ] You help others get shit done. ✅
• [ ] You communicate considerately. ✅

That's all you need to start interviewing in senior roles.

Go forth!

Footnotes

[^1] This is not to deride anyone who believes a title matters. Having a title is helpful for setting expectations around experience to external parties more than it matters internally. Tanya Reilly discusses this in "Staff Engineers' Path" –how Black women are more likely mis-recognized as janitors at workplaces. I am frequently mistaken for a student.