← All articles
Part 4 of 6 in Good team, good product, good manager

Why good leaders don't always build great teams

In the previous post, I described the three combinations in the 2/3 pattern. Leadership + Team looked like the least troublesome one. I expected good leadership to make the team stronger.

Then I had to account for teams that worked well as long as the leader kept making the decisions. I've also seen the trouble a hands-off leader can cause when nobody is responsible for how the work fits together.

The vacation test

A product leader I worked with made nearly every important decision. They set a clear direction, prioritized ruthlessly, and the team executed it well. The product succeeded, features arrived on time, and quality stayed high.

Then the leader planned a two-week vacation. Before leaving, they narrowed a critical feature decision to two approaches and asked the team to choose between them.

The meeting went quiet.

"What do you think?" the leader asked.

"We're not sure," somebody eventually said. "What would you choose?"

They were doing what had worked until then: understanding the leader's decision and executing it well. The leader had given them two sensible options, but little practice choosing for themselves. A two-week absence wouldn't provide that practice in time for this decision.

Three versions of the same company

I later saw the opposite problem in a marketing team. Their leader was deliberately hands-off, and each person had genuine ownership of a domain.

The social media work was playful, full of silly memes and goofy posts. The brand work presented a serious company for enterprise customers. Customer communication concentrated on sales, with discounts and transactional messages.

Each person could point to good work. The social media engagement was up. The sales messages converted. The brand direction made sense for the market the company wanted.

Potential customers saw the playful posts, then received a discount email, while the company tried to build a professional reputation. Initial engagement was good, but retention was low. Everybody had optimized a part of the journey and nobody owned the experience across it.

When leadership eventually introduced a central direction for brand positioning and customer relationships, the team resisted. "We've been doing fine on our own," somebody said. People had evidence in their own metrics, and intervention now felt like an attempt to take away autonomy they had been promised.

The leader now had to explain why the team's good individual results weren't enough, after letting them use those results to judge their own work.

Moving the boundary has a cost

An engineering manager I worked with tried to draw a more careful line. He set the strategic direction and left implementation decisions to the engineers.

The group needed to break apart an overgrown monolith. Poor coding practices had accumulated, production problems were creating urgency, and the manager chose a move toward services. Each team could decide how to split its services and design the abstractions.

The autonomy ran ahead of the team's experience. Logic was duplicated, abstractions leaked implementation details, and dependencies began to defeat the reason for splitting the monolith. There wasn't enough time to teach service architecture while also racing the production problems.

The manager intervened. He defined service boundaries, standardized interfaces, and overruled several architectural decisions.

"You said we could decide how to split our services," one engineer told him. "Why did you give us autonomy if you were going to override us?"

On the next decisions, he held back. Inconsistent abstractions and unclear boundaries spread. He kept moving between taking decisions back and leaving them to the team. The architectural problems still needed attention, and the engineers had become wary of promises about what they could decide.

I've seen this described as a failure to set clear boundaries, and sometimes that is all it is. But even a well-drawn boundary moves as the work reveals new risks. Teams remember who owned yesterday's decision when a leader needs to reclaim it today.

Direction shapes what a team learns

The product team had learned to follow its leader's judgment. The marketing team had learned to judge each part of the work separately. Both were doing what their leaders had encouraged, which made asking them to change harder than it first appeared.

Making the call yourself may be reasonable when time is short or the consequences are large. It still leaves the team needing practice for the next time. Leaving decisions with individuals also takes work: somebody has to notice when their choices no longer fit together.

For me, that makes the immediate question which decisions this team should be learning to make, and what support would let them practice. "Give them more autonomy" leaves too much unanswered.

In the final post in the original series, I look at an organization that tried to improve all three pillars at once.