How to build high-performing teams fast: lessons from consulting companies

I’ve noticed that consulting companies, at least the best ones, seem to be typically faster than even leading tech companies in building high-performing teams.

Why is this?

“You’re billing for team setup time? Haha, that’s what I like about you, all the joking!”

When revenue is based on billable hours AND the typical client doesn’t like paying for setup time, you learn how to get fast at building teams.

The 3 things that matter when building high-performing teams fast:

• Same training, same assumptions;
• Focus on the craft, not on the mission;
• Practice teaming and re-teaming.

Same training, same assumptions

“I don’t know you but I assume you’re into XP and Martin Fowler.”

One of the thing you could rely on when working at ThoughtWorks is/was that without ever having met the person, you could assume that they had similar assumptions about how effective software development should be done AND had a certain level of competence. I assume Pivotal had/has a similar environment.

The more you can rely on similar assumptions about ways of working, the less time you need to spend on working this out when joining or setting up a new team.

I think this effect comes from two things:

1. Being particular about selection and hiring. ThoughtWorks was known for having a selective, difficult interview process, more so than well-known tech companies.;
2. Having a much more involved onboarding process. ThoughtWorks University started a little while after I had joined. “After you’ve been officially hired into ThoughtWorks, you’ll spend several weeks with a global network of peers learning how to build working software and how to be a great consultant from day one.” The key thing is that dedicated onboarding is at least on the order of weeks, not days.

Focus on the craft, not on the mission (aka mercenaries, not missionaries)

Being able to rely on the “certain level of competence” I mentioned earlier comes from a focus on craft.

Via Marty Cagan, John Doerr has apparently said “we need teams of missionaries, not teams of mercenaries.”

American With No Medical Training Ran Center For Malnourished Ugandan Kids. 105 Died.

I say enthusiasm for a mission doesn’t compensate for lack of skill.

I prefer teams of competent professionals focused on their craft over enthusiastic novices focused on any particular mission. This is easier with consulting teams given typical client missions aren’t that interesting anyways.

People focused on craft spent a lot of time building skills outside of delivering on a particular mission. Examples include Brown Bags, Hack Nights (skill-focused, not necessarily idea-focused), coding dojos, mob code reviews, etc.

Practice teaming and re-teaming

The typical lifetime of a consulting team might be weeks to months; the typical lifetime of a product team, on the other hand, might be multiple quarters.

This means that consulting team members simply have more practice teaming and re-teaming.

There’s a phrase from the Extreme Programming community: “If it hurts, do it more often.” The general idea is frequency creates the incentive and experience to improve. This seems to apply to building high-performing teams.