Pushing teams without pushing people

Most leaders I know quote Conway's Law as a warning. Melvin Conway's observation from 1968 is that any organization that designs a system will produce a design that copies its own communication structure. Four teams building a compiler get a four-pass compiler. Three teams that don't talk to each other ship a product with three seams the customer can feel.

The warning version is: watch out, your org chart will leak into your product. True. But the more useful version is the reverse. If the shape of the team decides the shape of the product, then the shape of the team is the first design decision you make. And it's the one leaders most often make by accident.

This matters most when the problem is hard and nobody knows the answer yet.

Ambiguity is where teams stall

Give a strong team a clear problem and they will solve it. Give the same team a vague, high-stakes problem, like “figure out how we win the small business market,” and something predictable happens. Everyone does reasonable work. Nobody does bold work. Design explores ten directions. Engineering waits for the direction to settle. Data builds a dashboard for the metric they guess will matter. Each function protects itself against being wrong, and the product that comes out is the average of everyone's hedges.

That isn't a talent problem. It's a direction problem. And the usual fix makes it worse.

More information is not more direction

When a team seems lost, the instinct is transparency. Share the strategy deck. Open up the exec notes. Put everyone in the same room so everyone hears the same thing.

I believe in transparency, but it doesn't do the job people expect. Give ten smart people the same information and you get ten different pictures of what to build. Context tells people what's true. It doesn't tell them what you're going for. On an ambiguous problem, “everyone knows everything” usually turns into “everyone is right about something,” and the team spends its energy arguing about which part matters.

What they need is not the same information. It's the same picture.

A vision concrete enough to say no to things

A vision is useful when it's specific enough to rule things out. “Delight small businesses” rules out nothing. “An office manager sets up rides for her whole team in under five minutes, on her phone, without calling anyone” rules out a lot. It says who the person is, what she does, how long it takes and what she doesn't have to do. A designer can sketch that. An engineer can spot what makes it hard. A data scientist knows what to measure on day one.

The test I use: could two people on different teams read the vision and independently make the same call on a tradeoff? If not, it's still a slogan.

Getting there is the leader's job, and it's uncomfortable, because a concrete vision can be wrong in public. A vague one can't. That's exactly why vague visions are so common. But a team can't be bold on behalf of a leader who won't commit to anything. Somebody has to plant the flag first, and it has to be someone with the authority to be wrong.

Then organize, on purpose

This is where Conway comes back. Once the picture exists, I don't want everyone working on everything. I want each function going deep in its own lane against the same target, with clear handoffs between them.

That sounds like the opposite of creativity. It isn't. People take bold swings when they know where their edges are. An engineer who knows the five-minute setup is non-negotiable can try a bold architecture to hit it, because she isn't also re-arguing the product direction in every meeting. A designer who knows engineering owns the hard constraint can push the experience further, because he trusts the constraint will be raised early, not discovered late.

If you want a product with one clean experience, the teams need one clear place where their work meets, and a person who owns that meeting point. If you want a product that feels bold, the structure has to give people room to be bold inside their part of it. You design the communication you want the product to reflect.

Unstructured collaboration feels creative and produces the average. Structured work against a sharp picture feels constrained and produces the surprise.

What pushing actually means

“Pushing teams” has a bad reputation, and mostly it's earned. Pushing on hours, on pace, on how busy people look burns trust and rarely raises the quality of the work.

The push that works is on the picture. Raise the bar on what the end state should be. Hold it there when the first version comes back short. Ask “what would it take to actually get to five minutes?” instead of accepting eight. Then make sure the structure lets each team answer that question in their own domain without waiting on everyone else.

People don't mind being pushed toward something they can see. What wears them down is being pushed toward fog.

So when a team is stuck on a hard, ambiguous problem, I've stopped asking whether they have enough information. I ask two other questions. Can they see the same thing I see? And is the way we're organized going to produce it?