Becoming a Force Multiplier
Tags: mentoring, career, leadership
Published: 2022-08-23 17:34:00

For a large part of your career as a developer, your main focus is on building up your own skills and contributions. But then a strange thing happens - as you keep progressing, you actually start writing less code, and spending a lot more of your time on other activities, like meetings, and helping the rest of your team. This is deeply uncomfortable for a lot of people, but it's actually a big step in your career!

## Early Career

Let's look at the main progression for the first part of a programming career. You start out by learning to code, through a degree or a bootcamp or teaching yourself. At this point, you're going from knowing nothing about coding to knowing something about coding - this is an infinity percent improvement in your technical productivity! Suddenly you're making computers do your bidding, and it's amazing!

You keep digging, learning more languages, design patterns, frameworks -- and the net result is that  things that used to take you days now only take you a fraction of the time! Your productivity isn't going up by an infinite amount, but it's still going up incredibly fast, and it still feels great. Occasionally there's things that stump you, and once in a while you might have to pull an all-nighter to get something done, but it just takes some extra effort and learning, and you can get there.

After a few years, you're working on a team, working on larger codebases. Your big focus is still on tackling bigger and better stories, taking the lead on more of them, dividing work between you and your teammates, and generally writing big chunks of code yourself. This is usually the point where your job title has the word "senior" in it. That's also the point where the strategy of learning more and coding more yourself starts to break down. You're already a great coder, so learning a new language or framework only gives an incremental gain. You've already optimized your workflow and learned all the git secrets ([git pickaxe](http://www.philandstuff.com/2014/02/09/git-pickaxe.html) is my favourite!), so tweaking your config is also only an incremental gain.

So how do you keep getting more done, having a bigger impact, and delivering even bigger and better things?

## Changing the Math

As a seasoned veteran with years of experience and a full toolbox, this is the point in your career where you start leaning on the rest of your team more, and a bigger and bigger amount of your time is spent helping them. You switch from **adding** productivity to yourself, over to **multiplying** the productivity of others.

I'm going to pretend there's such a thing as a 5x engineer, and that's you. Levelling yourself up further so you can do 1 extra story point is hard (you’ve hit diminishing returns), but you can have a bigger impact by taking 5 other 1x engineers and helping each of them to do an extra story point! It takes about the same amount of effort on your part, spent in different places. 

![multiplying 5 people is better than adding to one](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t6jsdmp74t3k2g8ihg3j.png)
 
This works because junior devs haven’t hitting that point of diminishing returns yet - you can help them get an “aha” moment, or point them at useful resources, or give targetted feedback, all through small interactions or group conversations.

There's also the obvious fact that you probably want to be able to take vacations, sick days, and go home at a reasonable hour. If you're the only one who knows how to do any of the work, you won't feel like you can ever leave. Your own heroic effort **doesn't scale**, but investing time in teaching and mentoring junior or intermediate devs does. Not only that, but a full team of developers can parallelize the work, getting multiple things done at once, where your own single-threaded brain has to tackle them in serial fashion.

Your time should be spent working with others to help them get more done, but that doesn’t mean you stop writing code entirely. You just need to focus your coding efforts on the highest-impact things!

## Putting it into Practice

Okay, but what does that actually look like, and how can you apply your elite coding skills to the challenge? Unfortunately, levelling up others is one of those pesky soft skills that requires a completely different approach from technical problem-solving.

The first thing to do is to convince yourself that it's okay for a task to take longer. Yes, you could finish that story in 20 minutes. But you've got bigger fish to fry, like investigating weird race condition bugs in prod or selecting a new vendor, so it's okay if the intern spends a few hours flailing around with component interfaces. They'll get there in the end, and meanwhile, you've tackled a different high-priority thing in parallel. Again, repeat it until you believe it: **it's okay if that task takes longer when someone else does it**.

The second thing to convince yourself of is that if you had done that task yourself, **you would be taking away a learning opportunity from someone else**. Think back to your early career - you learned the most by getting out of your comfort zone, and I guarantee that there was a senior who was internally thinking that he could do that task faster. Delegate work to junior devs that will stretch them, and they will stretch and improve way faster than you expect! Get out of your own comfort zone by getting them out out their comfort zones.

As an aside, I've had teams that intentionally assigned tasks to the person who was least familiar with that code, in order to drive cross-training. The first couple of stories where they did that were slow, but the next ones were faster, and before very long we were in a situation where the whole team was moving faster because we didn't have to wait for the one expert to be free. It's an investment, and it works!

We're into mentoring territory here. A big part of being a good mentor is giving your mentee room to make mistakes, and find their own way. The other big part is **accepting that they'll make mistakes** - what you need to do is to keep an eye on things and make sure you're acting as a non-obvious safety net. Check in on how they're doing, take the time to do detailed code reviews, and when you find a mistake, work with them to fix it and learn from it. Teaching is just remembering that they're learning because they don't know it yet, and taking the time to share the cool things you know with them.

## The Big Picture

As a high-level developer, you still spend chunks of your time coding on big, uncertain problems. But there's also the other activities at that level which often don’t necessarily feel valuable at first, but are critical to letting your team and the larger organization function. Examples include communicating about timelines, writing documentation, build-vs-buy discussions, planning a roadmap, etc. By doing those things, your team can get on with coding, without running into roadblocks. These activities tend to come along at the same point in your career as you're realizing you can't code everything yourself. Tackling them lets you unblock and level up multiple teams, so the whole org can move faster and get more done than a single team (or a collection of individuals!).

This is a magical change in your career - you still code but not as often, some tasks are taking longer to get done, and occasional mistakes are being made, but **the team is getting more done**. Between levelling up your team and tackling blockers, you’ve become a force-multiplier, putting your skills to good use to get a lot more done than you ever could alone!

So as a developer wondering where your career is going to take you, or someone who has noticed that you're not writing as much code anymore as you used to, remember that this is normal, expected, and above all, it’s a good thing. It's only uncomfortable while your primary metric is your own productivity - switch to thinking about your team’s productivity, and suddenly it clicks into place. It's a phase-change in your career, and it's incredibly rewarding to see your whole team levelling up and accomplishing big things thanks to your efforts!

## About Jobber

Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL. 

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our [careers](https://getjobber.com/about/careers?utm_source=devto&utm_medium=social&utm_campaign=eng_blog) site to learn more!