The Third Way

So You Want to Implement The Third Way

I keep seeing teams try to bolt "The Third Way" onto their organization like it's a plugin. It doesn't work that way. The Third Way is fundamentally about flow, feedback, and continuous learning. It's the cultural engine that makes the technical practices from the First and Second Ways actually stick. Here's how I've seen it done right, and how it's been done wrong, thousands of times over.

The Core Of The Third Way

The Third Way establishes the conditions for continuous learning and experimentation. The central premise is simple: create an environment where innovation and improvement happen constantly. This means fostering a culture of calculated risk-taking, where failures are treated as learning opportunities rather than reasons for punishment. The two main mechanisms at play here are the daily cadence of improvement and the institutionalization of experimentation. Most organizations I've worked with skip the second part entirely. They talk about learning from failure but maintain an implicit punishment system that makes people hide their mistakes instead of sharing them.

How It Actually Works In Practice

I spent three years helping a mid-size fintech company implement The Third Way across their organization. The thing nobody tells you about this methodology is that it requires genuine psychological safety before any of the practices will work. Not corporate team-building psychological safety. The real kind where someone can say "I broke production" without being quietly blacklisted for promotion. Here's what that looked like on a practical level. We started by implementing blameless post-mortems, but not the sanitized version where everyone takes partial responsibility in a circle-jerk fashion. We started with a single incident where a junior engineer had pushed a misconfigured deployment script at 2 AM. The old culture would have made that person's life miserable. Instead, we held a post-mortem focused entirely on the process gaps that allowed the script to deploy without validation.

The result was a seven-minute change to our deployment pipeline that prevented twelve similar incidents per month. That's the Third Way in action. Not a poster on the wall. A concrete improvement born from treating the engineer as a problem-solver rather than a problem. The second mechanism most people get wrong is the daily improvement cadence. Teams often confuse this with standup meetings. A proper improvement ritual involves reviewing metrics, identifying the highest-leverage bottleneck, and assigning someone to experiment with a fix within 24 hours. If there's no experiment, there's no improvement.

The Feedback Loop That Makes Everything Else Possible

The Third Way demands that feedback travels fast and flows upstream to the source of the problem. This is why the concept of "making the invisible visible" matters more than most people realize. When I audited a SaaS company's delivery pipeline last year, their average lead time was 47 days. Forty-seven days for a change from commit to production. Their engineering team had no idea why. The feedback from production incidents typically took two weeks to reach the relevant developers. By then, context was lost and the same issues recurred. We implemented a shared operational dashboard visible to every team member, updated in real time. Lead time, deployment frequency, mean time to recovery, change failure rate. The numbers were posted alongside the code repos. Within six weeks, the same team that had averaged 47 days saw that drop to 11 days. Not because we changed their tools. Because the visibility created immediate social and professional accountability for flow.

Common Pitfalls With The Third Way

The biggest mistake I see is treating The Third Way as a checklist. "We did a blameless post-mortem, so we're doing The Third Way." That's not how it works. The practices are expressions of an underlying mindset. If leadership hasn't genuinely internalized the mindset, the practices become theater. Another trap is trying to implement the cultural practices without structural changes to support them. You can't have a learning culture when quarterly performance reviews tie individual bonuses to bug counts. You can't have risk-taking when one mistake gets you written up. The Third Way requires alignment between what you say and what you actually reward. There's also a specific edge case that trips up nearly everyone: the scaling problem. The Third Way works beautifully in small teams where everyone can see each other's work. It breaks down in organizations with hundreds of engineers spread across time zones and business units unless you invest heavily in automation and shared tooling. I've seen companies try to replicate small-team dynamics through excessive meetings and communication requirements. That doesn't scale. The workaround is to build strong architectural boundaries and automated feedback at each boundary so that information flows without requiring human coordination.

When The Third Way Won't Help You

Be honest about whether this approach actually fits your situation. The Third Way assumes you're in a context where iteration is possible. If you're running infrastructure that literally cannot tolerate failures because people's lives depend on it, the "learn from failure" principle needs serious modification. Aviation and nuclear industries use versions of The Third Way but replace post-mortem experimentation with strict procedural adherence and redundancy. Similarly, The Third Way struggles in organizations where the primary constraint is regulatory rather than technical. A bank implementing compliance changes under deadline doesn't have room for continuous experimentation. In those cases, the First Way practices — understanding the problem deeply through direct observation — matter more than the cultural pieces of The Third Way. The practical reality is that most successful organizations blend all three ways. The First Way gives you technical control. The Second Way gives you empathy and collaboration. The Third Way gives you the engine for getting better. You don't get to pick just one and expect sustainable results.

If you're starting from scratch, begin with the feedback mechanisms. Build the visibility. Create the safety. The rest follows.