The three pillars: leadership, product, team (2 of 5 in series)

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

The labels sound tidy. Real companies rarely are. I find it more useful to ask what happens when each pillar is put under pressure.

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.

That asks for competence and character at the same time. 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. Neither gave the organization what it needed.

Lencioni's The Motive describes leadership as service rather than ego. Working Genius gives me another useful lens: Wonder to see what might be possible, then Galvanizing to help people move toward it. Frameworks aside, I tend to recognize strong leadership by a simpler test. Can people act with confidence when the answer is uncomfortable or incomplete?

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 percent in the first month, then fell to 5 percent 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 percent and dropped to 3 percent 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. There had been no shortage of creativity or technical effort. The missing discipline was less glamorous: customer interviews, looking closely at usage, and saying no to attractive ideas.

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 spent six months building strong working relationships. People spoke openly in retrospectives, code reviews were collaborative, and one-to-ones contained honest conversations. Then a critical production incident exposed a missed test case. A junior developer admitted the mistake during the postmortem.

"This is exactly why we need better code review standards," the tech lead replied. "This shouldn't happen even for a junior developer."

Those standards 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-to-ones became formal. Within about three months, the team had moved from useful disagreement to silence.

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.

So I don't ask only whether a team gets along. I want to know what happens after an incident, a missed commitment, or a serious disagreement. That is where trust and accountability become visible.

These definitions come from frameworks and my own observations, so they will carry some of my blind spots. In the next post, I look at what happened when organizations had two of these pillars working together and the third began to slip.