The Three Pillars refined; leadership, product, team (2 of 5 in series)

Make sure you read the previous article: Good boss, good product, good team, pick two. (1/5)

Following up on the previous post about the 2/3 pattern, let me break down what I mean by three pillars.

Drawing from Lencioni's work and my own experience in engineering teams, here's how I've been thinking about them:

1. Leadership

When this is strong, you have someone who translates ambiguity into clarity, makes hard calls with empathy, and earns followership without force. It's not about being the loudest voice, it's about service over ego (Lencioni's The Motive). In Working Genius terms, it's high Wonder (vision) and Galvanizing (rallying people).

But I've been reflecting on what makes leadership "strong" versus just present. Having a leader isn't enough, you need someone who can create clarity in uncertainty, who can make decisions that others trust even when they're hard, and who can inspire followership without coercion. Something I think requires both competence and character, which turns out is a rare mix.

2. Strategy/Product

This is about having a bet on the future that's grounded in customer truth, with a product that delivers measurable value. Lencioni talks about clarity on "Why we exist, How we behave, What we do." Working Genius highlights Invention (ideation) and Discernment (vetting ideas). For engineers, this is the difference between building something scalable versus endless firefighting.

But here's what I've noticed: strong strategy isn't just about having a plan, it also needs to be a plan that's grounded in reality. I see too many teams have beautiful strategies that don't connect to what customers actually need. And here strong product isn't just about features, it also needs to deliver value that's measurable and sustainable.

The creativity-discipline tension

The tricky part is that this combination requires both creativity and discipline. Creativity wants to explore, ideate, experiment, chase interesting problems. Discipline wants to execute, focus, measure, deliver results. When teams lean too hard on creativity, you get endless brainstorming sessions with no follow-through. When they lean too hard on discipline, you get features shipped on time that solve problems nobody has.

A real example: innovation without validation

I've seen this play out in a B2B SaaS startup I worked with. The product team was brilliant at ideation. They'd come up with innovative features that felt exciting: AI-powered analytics dashboards, automated workflow builders, predictive insights. But they struggled to validate whether customers actually wanted them.

Here's what happened: They built an AI recommendation engine that took three months to develop. The team was excited about the technology, the engineers loved the technical challenge. They launched it, got 8% adoption in the first month, then 5% the next. Instead of digging into why, they pivoted to the next creative idea: a social collaboration feature. Same pattern: three months of development, 12% initial adoption, then it dropped to 3% as the novelty wore off.

The discipline side, doing customer interviews, measuring real usage, saying no to good ideas, felt constraining to them. So they kept innovating without validating. I remember a senior engineer telling me in frustration: "We're building features nobody uses. I'd rather fix the bugs that customers actually complain about." Product felt like they were constantly chasing the wrong thing. The lack of discipline around validation meant all that creativity was going in circles. Eventually the system collapsed: the engineering team lost motivation, product lost credibility, and the company had to do a major pivot that cost them six months of runway.

That's why teams struggle with Strategy + Product, it's not enough to have one or the other. You need both working together, and that tension creates real dysfunction when it's unbalanced.

3. Team/Organization

When these are strong, trust is the default. Conflict is productive. People hold each other accountable, and still enjoy Monday mornings. It's Lencioni's classic Five Dysfunctions pyramid in reverse: trust leads to healthy conflict and results. Working Genius adds Enablement and Tenacity, the work gets done without drama.

The fragility of trust

What's interesting about this one is how fragile it is. Trust takes time to build and can be destroyed quickly. One bad code review comment can undo months of trust-building. One decision made behind closed doors can erode psychological safety. I've seen teams that felt solid crumble after a single incident, a manager throwing someone under the bus in a meeting, or a missed deadline that got blamed on the wrong person.

Psychological safety requires ongoing attention

Psychological safety requires ongoing attention, it's not something you achieve once and then forget about. It's built in small moments: how you respond when someone admits a mistake, whether people feel safe to disagree in stand-ups, if retrospectives are actually safe spaces or just performative.

I've watched teams that had great psychological safety lose it gradually. Here's a specific example: A team I observed had built strong trust over six months. People spoke up in retros, code reviews were collaborative, 1:1s were honest conversations. Then a critical production incident happened. During the post-mortem, a junior developer admitted they'd missed a test case. Instead of treating it as a learning moment, the tech lead responded with: "This is exactly why we need better code review standards. This shouldn't happen even for a junior developer." Blame assigned to the Junior, when in reality those very code review standards were defined by the Tech Lead.

That one comment shifted the dynamic. The junior developer stopped speaking up in retros. Others noticed and became more cautious. Code reviews became more defensive, with people writing longer explanations for every change. 1:1s became formalities instead of real conversations. It happened so slowly you barely noticed until it was completely gone. The team went from healthy conflict to silent compliance in about three months.

Accountability needs both systems and culture

And accountability sounds simple, but it requires both systems and culture working together. You can have all the performance reviews and OKRs in the world, but if calling someone out on missed commitments feels risky, accountability breaks down. On the flip side, you can have a culture where people hold each other accountable, but without systems, clear roles, defined commitments, measurement, it eventually becomes personal and messy.

I've seen this in a team I managed. The culture was collaborative and friendly, but when someone missed a deadline or shipped buggy code, nobody wanted to be the one to call it out. It felt too harsh, too confrontational. So issues would pile up, technical debt would accumulate, and eventually someone would explode in frustration, usually the person who'd been silently carrying the load. We had the culture part (people cared about each other) but not the systems part (clear ways to address issues without it feeling personal). The dysfunction showed up as passive-aggressive Slack messages, blame-shifting in retros, and eventually people leaving because they couldn't take the unspoken tension anymore.

Most teams think they have this, trust, but when you dig deeper, you find the cracks. The trust that exists only when things are going well. The psychological safety that disappears when stakes are high. The accountability that's there in theory but absent when it matters.

The common enemy trap

But here's a recent observation to complicate things: sometimes there are even teams that think they absolutely love their team culture, but it's not because they have real trust and accountability. It's because they have a common enemy. That other department that's always causing problems. That manager above them who makes bad decisions. That external pressure that makes everyone feel united.

I've seen this play out in an engineering team that felt incredibly cohesive. They'd bond over complaining about the product team's "unrealistic deadlines" and the CTO's "out-of-touch decisions." Stand-ups were full of inside jokes about "product's latest brilliant idea." The team felt tight-knit and collaborative.

Then the CTO left, and product got restructured with new leadership. Suddenly, the common enemy was gone. Within two weeks, conflicts that had been buried surfaced. Two senior engineers disagreed publicly about architecture decisions. Code review discussions became tense. The unity that felt real turned out to have been situational, not structural. Without the external pressure to unite against, the team had to actually work through their differences, and they didn't have the trust or accountability systems to do it productively.

That's not a strong team; it's cohesion built on external pressure rather than internal trust. A strong team can handle pressure because they have trust and accountability built in. They don't need a common enemy to stay together. They can disagree productively, hold each other accountable, and still function when things are calm. The teams I've seen that actually have this? They're rare, and they're noticeably different, they have conflict, but it's healthy. They have accountability, but it's not personal. They have trust, but it's tested and earned, not just assumed.

This observation changed how I think about team health. It's not enough to ask if the team is cohesive. You have to ask what's making them cohesive. Is it internal trust and accountability, or external pressure? The difference determines whether the cohesion survives when things get calm.

Help me find the blind spots

These aren't my inventions; they're distilled from the mentioned frameworks I've been testing with real teams, combined with my own observations. But I'm curious: What's missing? Where are my blind spots?