3 Practical Ways to Become a Team Multiplier

May 18, 2019

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):

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:

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:

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:

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 yarn projects:

$ 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 (quentin@qdonnellan.com) if you have questions about anything.