As we mentioned last week, part of your job as a leader is to make it easier for others on your team to code and to get work done. Another part is to make your team more efficient at getting work done. This means many things, from removing roadblocks to dealing with customers so your team doesn't have to. You job is to help them be more effective, more focused, and more enthusiastic.

You do this, primarily, by getting out of their way. Let them do their part of the job, and trust them to do it well unless they prove otherwise. However, there's another piece to this puzzle, and that's what we're going to talk about in this edition. Today, let's talk about becoming a force multiplier for your team.

A well-worn staircase, where each stair is labeled with the times tables for 7, e.g. 7x1=7, 7x2=14, etc.
I never could memorize the times tables for 7. Photo by Gayatri Malhotra / Unsplash

Force Multiplier

"Force multiplier" is a term taken from the military. Wikipedia gives us a good definition: a force multiplier...

"...refers to a factor or a combination of factors that gives personnel ... the ability to accomplish greater feats [with it] than without it."

Things such as defensive fortifications, improved technology, or morale can all be force multipliers; thick, strong walls will hold out against a attack for longer; an army with tanks will crush an army with mere cavalry; and an optimistic, driven battalion will defeat a pessimistic, unsure group of the same size and armament. Force multipliers enable a group to get more things done than they would otherwise.

Comparing a software team to a military force is a wildly unfair comparison, but this truth holds: as a lead, part of your job is to be force multiplier for your team, to enable them to get things done that they wouldn't get done otherwise.

So let's talk about how exactly you can do that.

Be the First Point of Contact

There's a classic comic strip about interruption from MonkeyUser.com; go read it:

Focus
Software development satire
MonkeyUser
I am unsure if I can embed that comic here, so please visit their site.

One of our goals as leads is to prevent that situation from happening to your teammates. The single biggest cause of lost focus and lost time is interruptions, and there is one major source of interruptions that you can significantly reduce: queries from the customers.

As a lead, you should be the first point-of-contact for any questions your customers have. Don't let the customers interrupt your teammates with inane requests or "how long would it take to do X?"-style queries. Handle the initial communication with the customer yourself. There will be times when you need to delegate some questions to your team, but those times will be rarer.

By taking the majority of the customer communication duties, you will dramatically increase your team's ability to stay focused and get their tasks done.

Know Your Team's Strengths and Weaknesses

As a lead, you are responsible for the "work wellbeing" of your team; you can help them grow technically and professionally. We talked a couple issues prior about knowing your own strengths and weaknesses, and then using incoming work to shore up your weaknesses. In truth, you want to do the same thing for your team: ensure that you know each person's strengths and weaknesses, and assign them work that will allow them to either a) get things done quickly or b) enable them to get certain things done more quickly in the future.

A person pretends to be pushing a boulder several times larger than him up a hill.
Oh, Sisyphus, you never learn. Photo by Vicky Sim / Unsplash

If you already know your team's abilities, great! Now assign them work that enables them to do more stuff. But what if you don't?

You can learn about a person's strengths and weaknesses through two methods:

  • Observation
  • Asking

Observation comes in many levels, from merely reviewing your teammate's code all the way up to full pair-programming with them. This is the more truthful way to learn about someone's strengths and weaknesses, because seeing someone's work for yourself allows you to draw conclusions without their opinions interfering. For juniors, the pair programming works well, provided you let them do the coding; you can them observe them for both correctness and ability.

However, and this cannot be discounted, simply asking the person about their abilities is MUCH quicker than observation. Look, lead developers are busy people, and we do not always have the time to be pair-programming with all of our juniors. If you do not know someone's strengths or weaknesses, ask both them and people they've worked with before about it; at the very least, you can learn what their perceived strengths and weaknesses are.

Assign Work Accordingly

Once you know the strengths and weaknesses of your team, you want to assign them work accordingly. The problem is this: when do you assign them something they are good at, and when do you assign them something they need to get better at?

You assign your teammates a task that fits their strengths when:

  • Said task needs to be done sooner rather than later (though if this is happening all the time you might need to talk to your manager), OR
  • You have no one else available to do the work.

Otherwise, your default mode should be to assign tasks that shore up a person's weaknesses.

Developers are smart people; they want to learn. Giving them a particular task for a tool or framework or idea that they are not currently proficient in will most likely impel them to learn more about it, and get better at it. Choose to give them work on projects they are not familiar with until they acquire said familiarity, and you will never have the bus factor problem we discussed several issues ago.

Take care, though; none of these are hard and fast rules. You know your team the best, and you need to make decisions that will benefit the team and each individual, and those decisions may not be the ones laid out in this article.

Previews and Announcements

Quality Reads

Catch Up with the Previous Issue!

The Catch Block #27 - Keeping an Eye on the Bigger Picture
Plus the impending release of .NET 5, priorities, how to be visible, coastlines, and MediatR.
Exception Not FoundMatthew Jones

Thanks for reading, and we'll see you next week!