Are you building a team of mercenaries or missionaries?

There are plenty of obvious reasons to care about the culture you build on your tech team or with your tech partners - retaining top talent, employee satisfaction, project quality - but how can you tell if you’re doing it?

We look at one very key indicator - how you treat your tech team.

Mercenaries or Missionaries?

There are two stereotypes that describe the type of engineers you create on your engineering team - mercenaries or missionaries. Most engineers could be either, and the environment and expectation you create are what moves them from one type to another.

Mercenaries

The idea of a mercenary describes a team member who simply accepts your orders and works down a list of features you hand to them. They cannot see the forest, because they are focused on the trees (feature lists) you set before them.

Someone who does what I say? At first, that doesn’t sound too bad, does it?

But this type of working relationship is one-way. You give information to your engineer and expect them to give you exactly what you’re looking for.

Have you ever been the recipient of a to-do list that:

  • you don’t agree with

  • you don’t understand the purpose behind

  • you know isn’t the best way to accomplish an intended goal

  • makes you feel like a cog in the system?

Was your boss receptive to feedback or did they hold fast to what they expected? If it’s the latter, you probably didn't get to apply your experience to the solution or advocate for any new ideas pitched by your overlord. And you definitely moved on from that job.

By expecting your team to act like mercenaries and fulfill your every commandment, you are undermining three main ingredients of healthy communication between your business and product teams: critical thinking, feedback, and context.

Missionaries

A missionary is a team member who understands your vision, agrees with your mission, and can therefore make better technical decisions because they see the forest (greater product/company vision) through the trees.

This is a two-way working relationship. You communicate the outcomes you are seeking through technology and invite your tech team to weigh in on the best technical solutions to achieve those business goals.

You might even get some push back from your technical team, but wouldn’t you prefer their input on how to solve a technical problem (especially if you’re nontechnical). By applying their technical knowledge to the outcomes you’re seeking through your product, they may have an even better solution.

A team of missionaries advocates for your product vision, critically thinks about the best way to achieve the outcomes your company is after, provides feedback around best practices or better ways, and uses your shared context to prioritize the same things within your technology that you are prioritizing for your business.

We need teams of missionaries, not teams of mercenaries.
— John Doerr

How to create a team of missionaries

Like most good things in life, you need to be intentional to build a culture of missionary engineers.

A few tips we've seen work:

  • Communicate a clear product vision (bonus points if you can relay your product vision in only 1 or 2 sentences). A clear and concise vision is easier for everyone to understand and easier for your team to determine if what they’re working on is supporting that vision.

  • Restructure your thinking around task delegation. First, define the outcomes you are seeking to achieve through your product (feature lists will come later).

  • Focus team discussions on your intended outcomes and ask your team their thoughts on how they would go about achieving those outcomes. Their answers will define your feature lists (see, I told you they’d come later).

  • Don’t stop at asking your team what they accomplished. Ask them how they know that what they accomplished was valuable for accomplishing the intended outcomes.

  • Most day-to-day effort should be focused on what needs to be built now. But periodically (~monthly), bring your team out of the day-to-day to look at the bigger picture. Discuss long-term vision, share expertise, ask others to share their expertise, and ideate as a group about strategies to achieve your long-term product vision.

Your job is to see and fill gaps in their understanding of your business; their job is to provide valuable ways to apply technology to the understanding you have provided them to help your business scale.

Approach the relationship as a two-way street, not a one-way chain of command.


Enjoy this article? Sign up for more CTO Insights delivered right to your inbox.

Previous
Previous

Cognitive Overload is Killing Your Tech Team’s Productivity

Next
Next

Four nontechnical ways to build better products