As you become more and more senior in your software career, you may notice more of an urge to be less of the rockstar individual contributor, and more of a team multiplier who lifts less and less “weight” individually, while having an exponentially greater impact on the team’s performance.
Personally, this is an obvious goal for me: as a self-taught software developer, I’m always finding myself surrounded by engineers whose skill in technical execution far exceeds my own. If I can find a way to make everyone’s work more effective – including those of my far-superior teammates – well that would be worth way more than any individual contribution I could bring to the table.
Moreover, even if you are that rockstar developer on the team – that one person contributing value at a rate “10-times” everyone else – no individual performance edge you bring will ever amount to more impact that your multipliers: anything that boosts the performance or effectiveness of every individual on that team. So, as a senior software engineer, your goals should always include some form of team multiplication.
Here are 3 specific ways I’ve found to easily become a team multiplier.
1. Make Code Reviews a Priority
Consider the following code review process (which may be similar to what you experience on your current team; it’s definitely something I’ve experienced before):
- You finish writing your code, so you push it up to GitHub and wait for a review
- Several hours – maybe a day or two – go by and your code is still there, waiting. You post a message in Slack: “Can someone take a look at my PR?”
- Another several hours or days later – you notice that someone has put a comment on your code; it needs changes, so you make the changes
- Another several hours later – your code is approved, and merged into master
If this describes your team, you’re in luck: you have a great opportunity to step up and be a multiplier!
Code reviews can definitely be a source of bottlenecks and frustrations. The authors of pull requests get frustrated when their code isn’t merged immediately, and the reviewers get frustrated when their own work is interrupted by the toil of having to read through someone else’s code.
I’m not going to go into why a code review is important (it is), or how to do an effective code review. Rather all I want to stress to you is that you should make code reviews a priority if only reduce the time that code languishes in an un-merged state. Your team’s goal is to deliver value in the form of software solutions - you can’t deliver something that’s just sitting on GitHub, waiting for someone else to click a green button.
What does making code reviews a priority look like? Well, here are some ideas to get you started:
- As you come back to your desk from whatever break you’ve just been on (morning, lunch, snack, exercise, whatever) - check for new pull requests!
- Before starting any new code yourself, check for new pull requests!
- Don’t request a code review for your own code until you’ve already reviewed any outstanding requests by others on your team
- Positively & publicly affirm anyone else on the team who is also actively reviewing code
Ultimately, you must decide that they matter to you, and let the rest of the team know they matter as well. Once you make the decision that they are an important part of your daily routine, and treat them as such, they will be. When you start seeing momentum pick up, then you’ll be hooked.
2. Remove Yourself from the Critical Path
Many senior engineers find themselves in a position where they’re essentially the gatekeeper for some number of critical business tasks. Maybe you’re the only one who knows how to do something; maybe you’re the author of the original code, and no one else on payroll even knows how to code in that language. For whatever reason, you end up standing in some critical path, and the only way to get a particular task done is to go through you.
Some might say this is a great way to protect your job security: if you’re the only one that knows how to perform some business-critical thing, then there’s no way you’ll ever be laid off. I say that’s a fairly pessimistic and defensive posture which leads to isolation and unhappiness. (Also, if the only reason you’re not laid off is because you know how to do X… well that gives the business a pretty simple blueprint for eliminating your position). Now, if you really want to establish job security, multiplying team performance will always earn more good-will points than constraining it.
If you are unsure whether you stand in some critical path on your team, ask yourself the following questions:
- Am I the only one on the team that knows how to do a particular thing?
- What is something I do every single day that no one else does?
- If I quit the company this afternoon, what’s the first phone call I’m going to get tomorrow? (Or rather: what’s preventing me from taking a month-long vacation right now?)
A great example is code review: if you find yourself to be the only person doing code reviews on the team, then you’re in a critical path (but great job reading the first part of this post!).
There are a couple ways out of the critical path, here are some suggestions:
- Consider automating your critical-path task
- Create a “self service” tool that replaces your critical-path function (Good example: build “infrastructure as code” instead of being the only person who knows how to do production deployments)
- Document and publicly disseminate all the critical path work that you do
- Train other team members how to do your job
Of course, there are some situations where you’ve been placed in a critical path on purpose; perhaps there is an organizational mandate that only managers can merge pull requests, or only directors can approve production deployments. You can’t eliminate every one of these – and many of them shouldn’t be – but my guess is that there are many low-hanging-fruit opportunities out there without you having to worry about organizational limits. (That being said, multiplying team performance is always a powerful argument to remove inefficiencies…)
3. Reduce Local Dev Environment “Time-To-Running”
Finally – and this one is rather straightforward – find and fix anything that bogs down everyone’s ability to get their local development environment up and running. Anything that slows down the most basic task that software developers perform - the writing of new code on their own computer - is an excellent candidate for team multiplication.
In a perfect world, it should only take a few minutes for any developer on the team to set up their local environment and start making substantive contributions. More likely, there’s always some snag or secret-sauce-recipe that everyone has to follow exactly to get things working. If your local environment feels like a “house of cards” – like if you breathe to loudly it will all fall down – then you should consider putting in some time to make it better.
Unfortunately it’s almost impossible for me to offer truly practical advice about how to improve your local development environment, simply because every team’s projects are truly unique. Besides, you probably already have an idea about that one or two things that are really slowing everyone down – go a head and make an effort to fix some of them.
A good place to start may be your “step by step” instructions: consider replacing several steps with a bit more automation. A good goal is to have a “two-command setup process” (step 1: download, step 2: install), similar to what you may see in some modern
$ git clone ... $ yarn
Of course it may be impossible to distill your entire setup routine to two commands, but if you have, say, twenty, then you almost certainly can automate something. (This is a blog post for another time, but I’ve started using
Makefiles to both document and condense setup procedures for all of my side projects, in fact, here’s the makefile for this very website.)
Finding Other Multipliers
Hopefully those 3 ideas can get you started on some form of team multiplication right away. Beyond those simple suggestions, there are honestly thousands of ways you can effectively multiply your team’s performance. Once you start making “team multiplication” a priority over “individual greatness” these ways will start becoming more and more obvious to you.
As always, good luck in your careers, and never hesitate to reach out via email (firstname.lastname@example.org) if you have questions about anything.