I’ve been drawing variations on this diagram a lot lately.

These are what I think are the core components of an effective team¹. These aren’t revolutionary ideas, but they’re the ones I’ve really zeroed on from a lot of really good sources, including Marquet’s Turn the Ship Around!(which probably informed this most strongly) and Dignan’s Brave New Work, and this is how I like to summarize them.

Like all such models, it’s not perfect – there’s a bit of unpacking necessary to turn it into a story, but I like the process. In short, these are the things that a team needs to know what needs to be done (Clarity), have the skills and resources necessary to do the thing (Capability) and it able and willing to take the necessary action (Autonomy)².

Clarity

Clarity means the group can see the problem and see a path to resolution. This means that they understand the domain, have visibility into the situation, and have enough insight to be able to understand how a solution might work and test that hypothesis. Clarity need not be perfect (tip: it never will be) and it covers a number of critical things like understanding value, measuring the right things and the ability to learn.

In the absence of clarity you can have an incredibly capable team that goes nowhere or, worse, goes off a cliff at very high speed. If the team is good enough, they may still stumble onto success (broken clocks and all that), but that’s a bad thing to rely on.

Autonomy

This is probably the hairiest of the three, because it comes with all sorts of scary ideas like responsibility and independence, but it’s also the simplest to test for – if the team can see the problem (or opportunity) clearly and see how to fix (or take advantage of) it, are they able to do so? Most critically, can they decideto do so?

Usually, they don’t. There are permissions to pursue, processes to go through and a general lack of trust. This mistrust is usually framed as benign – it’s protecting the team from making mistakes or wasting resources. And it’s reasonable enough on its own – it the team has autonomy but lacks clarity, then they’re just a wrecking ball on the lookout for a load bearing wall.

However, without autonomy, even the best teams are hobbled. All that capability and clarity goes to waste as they sit around waiting for permission.

Capability

The biggest and most obvious part of capability is skill, but it’s not justskill. It also means having the resources, access, will and knowledge to do the work. There is a certain amount of flexibility demanded by this in complex situation – the necessary capabilities are not always predictable, but excess capabilities can bring in extra costs. As such, one element of capability is, paradoxically, restraint. The team does not just bring the right actions, they bring it in the right amount.

The absence of capability has the most obvious drawbacks – the work can’t get done. That might seem to make this the most critical of the three points, but it turns out that the opposite is true, for reasons we’ll get into in a second.

The Imperfect Triangle

This trio of keys is easy to spot when you find it, but most real world teams need to operate with a flawed version of these things to get through the day.

If a team has none of these, they’re going to be entirely reliant on proxies (see below) to get the work done. That’s a worst case scenario, and if that’s what’s going on, it’s almost certainly not the only problem.

If the team has only one, that can be worse in some ways. Clarity without autonomy or capability is a recipe for frustration. Autonomy without clarity or capability makes more problems than it solves. Capability without clarity or autonomy is just wasted potential. All three of those scenarios are grating on the soul.

A team that hits two of the keys might be better off. If they have clarity and capability, they might still get a lot done if the authority they follow is reasonably sharp. That is, they will be able to kick ass in the manner they’re instructed to. If they have capability and authority, then they can at least proceed with good intentions and general best practices in hopes that if they try enough things they will eventually solve the problem³. If a team has clarity and autonomy, but lacks capability, then they can learn, and since they know what they need to learn and are motivated to do so, they should have that third key in short order (which is why this is the easiest gap to overcome).

Frustration Remove Clarity => Wrecking Ball Remove Capability => Learners” class=”wp-image-126″/>

Proxies

More likely, though, the team is getting by with a proxyfor one or more of the keys – some other attribute which offers enough similar benefits for functionality, but with some other tradeoff that’s usually for the worst.

The grand-daddy of proxies is instruction– it can technically cover for any gap. Instructions can tell you what you can do, what you should do, and how you should do it. The problem, of course, is that instructions are never as complicated as life, so whichever key is replaced with instructions has now become the limiting factor on the others. This is not necessarily disastrous – instructions canbe good, timely and useful. It’s just a lot of work to keep them that way.

One common proxy for clarity is certainty, a pernicious attribute which often presents itself as clarity but actually overlaps very little. Dogma and enthusiasm can provide the kind of direction that clarity provides, but without the guarantee that the direction is the right one. Unfortunately, because certainty also lacks clarity’s ability to judge itself, the inevitable failures are almost certain to be attributed to someone else.

Capability is a little bit harder to proxy for, but if you need to fake it, then a bit of flim flamgoes a long way. Look busy, produce good looking metrics and just never deliver. If your environment is dysfunctional enough, you can surf on this patter for ages.

Autonomy has a couple proxies, but my two favorites are panicand subversion. Panic is what happens in an emergency, and it’s now all hands are on deck, all rules are set aside and all eyes are on getting the job done. For some, this is their only taste of autonomy, and they will actively find ways to turn problems into emergencies in order to be able to “do something”.

Subversion takes the other route of recognizing that the lack of rules is a problem, and then just working around the problem. Backchannel deals, shadow networks and secret work get the actual work done while maintaining nominal command and control. This is admirable work, but if people on your team need to resort to this, that’s a real problem.

Scaling and Use

Ok, so it’s a triangle. Now what?

Technically, you can use this model to plan – look ahead and see what you’re doing to provide and encourage all three keys – but I admit I find more use in it as a diagnostic tool. If things go wrong, it can be handy to look at things in these terms and ask if one(or more) of the keys is missing or damaged, and if so if there is any way to fix that. It won’t always point to a solution, but it’s a good starting point.

Beyond that, once you get used to the pattern, you can scale it up or down. For groups, the model scales up even as responsibility diffuses and communication becomes challenging. The need for the trio is there, and the patterns of failure are similar, if larger. You can also scale down – these attributes apply to individuals, or even single tasks⁴. Generally speaking, if something needs to get done and it’s not getting done, check for these three things as a quick smoke test of how solid the infrastructure is.

1. This doesn’t JUST apply to teams, but unpacking that is a bit involved. A larger group may have these attributes, but it introduces more questions about how to distribute them. An army may have all three attributes, but they’re not evenly distributed the general may have autonomy, the spies may have clarity and the soldiers may have capability, but extra steps are required to keep those things connected. For my purposes, a team is something where all of these attributes are held by everyone on the team, even if they might be a bit lopsided on an individual basis. ↩
2. If I want a TED talk, I really need to give this a C name, to make this all punchy. ↩
3. This one is really common, even in teams that usually have all three keys, because sometimes the keys are situational or partial. An operations team dealing with an outage may not have clarity on how to resolve the problem, for example. What they do have is clarity on the best ways to identifythe problems, and if those fail, then they have the smarts and the persistence to keep at it. ↩
4. Is it actionable (Autonomy), doable (Capability) and useful(Clarity)? ↩