The three pillars: leadership, product, and team

In the first post, I gave the old "pick two" joke three more serious labels: Leadership, Strategy and Product, and Team and Organization.

I need to be more precise about those labels. A team can get along well and still fall apart during a disagreement, just as a busy product team can keep shipping things customers don't want.

Leadership

When I describe Leadership as strong, I mean that somebody can turn ambiguity into enough clarity for people to move. They can make a difficult decision, explain it, and retain trust even among people who would have chosen differently.

I've met leaders who could make a fast call but couldn't bring people with them. I've also met well-liked leaders who avoided the call entirely. In either case, people were left without direction they could rely on.

Lencioni's The Motive describes leadership as service rather than ego. The Wonder and Galvanizing parts of Working Genius also helped me think about the work: seeing what might be possible, then helping people act on it. I want people to have enough direction to make decisions even when we don't have a complete answer.

Strategy and product

Strategy and Product begins with a bet about the future and a reason to believe customers will care. The product is where that bet meets reality.

I worked with a B2B SaaS startup whose product team was exceptionally good at generating ideas. They proposed AI-powered analytics dashboards, automated workflow builders, and predictive insights. The ideas were exciting, especially to the engineers who would build them. Validation felt slower and more restrictive.

The team spent three months building an AI recommendation engine. Adoption reached 8% in the first month, then fell to 5% in the next. Rather than spend time understanding the decline, they moved to a social collaboration feature. That also took three months. Adoption started at 12% and dropped to 3% once the novelty wore off.

A senior engineer put the frustration plainly: "We're building features nobody uses. I'd rather fix the bugs that customers actually complain about."

Eventually the company made a major pivot that cost six months of runway. The team had the usage figures, but falling adoption hadn't stopped the next feature from getting built. Customer interviews and a closer look at that decline might have given them a reason to pause.

Delivery discipline doesn't protect a team from this on its own. A team can complete every item on time and still solve the wrong problem. I consider this pillar strong when exploration and delivery keep correcting each other, and when customer behavior gets more weight than the team's excitement.

Team and organization

When Team and Organization is healthy, people can trust one another without avoiding conflict. They can admit a mistake, challenge a decision, and address missed commitments before resentment takes over. Lencioni's Five Dysfunctions model and the Enablement and Tenacity parts of Working Genius describe much of that work.

I usually find out whether the trust is real once something goes wrong.

One team I observed had built strong working relationships. People spoke openly in retrospectives, code reviews were collaborative, and one-on-ones contained honest conversations. Then a production incident exposed a missed test case. During the postmortem, a tech lead publicly blamed the junior developer who admitted the mistake.

The standards that failed belonged to the tech lead too, but the blame landed on the junior developer. Afterward, the junior developer stopped speaking in retrospectives. Other people grew more careful. Code review descriptions became longer and more defensive, and one-on-ones became formal. Within about three months, the team had moved from useful disagreement to silence. I later wrote more about how quickly a moment like that can undo trust.

Accountability can fade just as quietly. In a team I managed, people liked one another and didn't want missed deadlines or buggy code to become personal confrontations. We hadn't created a clear way to address those problems. They accumulated until the person carrying the extra work finally expressed their frustration. Passive-aggressive Slack messages and blame in retrospectives followed, and people eventually left because of the tension nobody had wanted to name.

I have also seen cohesion built around a common enemy. One engineering team bonded over the product team's "unrealistic deadlines" and the CTO's "out-of-touch decisions." Stand-ups filled with inside jokes about "product's latest brilliant idea." It felt like a close team.

Then the CTO left and the product group was restructured under new leadership. Within two weeks, old disagreements surfaced. Two senior engineers argued publicly about architecture, and code reviews became tense. The external pressure had given the group unity, but it hadn't taught them how to work through conflict with one another.

Those teams all looked close until something tested the relationship. That's why I ask what happened after the last serious disagreement, as well as whether people like working together.

In the next post, I look at companies where two of these pillars were working together and the third began to slip.