Trust and Verify

A ship's true condition lives below the waterline: the hull, the draft, the things nobody standing on a dock or a bridge can actually see. I learned that the literal way. The shoal we ran aground on off the coast of Norway was submerged at high tide, invisible to us and to radar, the same rock that would have shown itself plainly at low water. Years before I ever applied it to how organizations report on their own investments, I already knew what it meant for the real danger to be sitting exactly where nobody could see it.

Where it comes from

I served under three different commanding officers in two years aboard the USS Boulder (LST-1190), and each one taught me something different about leadership and trust.

The first was at the end of his career, trained in a command tradition the Navy was only just starting to walk back from, command and control. He didn't lead that way himself, he was professional and respected, and under him the ship ran well. What it lacked was any sense of mission beyond the job. About half of the crew had been replaced in the few months prior to my reporting aboard, for reasons well above the captain's pay grade. But one officer stayed who shouldn't have: unprofessional, undisciplined, the kind of presence that works on a crew's sense of mission like a slow infection. Removing him would have been the right call for everyone. Worst of all, this person was a single point of failure: he was the navigation officer. The captain never removed him.

The second captain changed the energy within weeks. He trusted people to do their best, then let them, and that built a culture where mistakes surfaced instead of getting buried, and gave us a chance to improve. He was also verifying, carefully. After two months of direct observation, he concluded that same navigation officer wasn't fit for the role, and decided to relieve him, effective the next morning. That night, during the midwatch, the ship ran aground off the coast of Norway under that officer's watch, before the relief could take effect. The single point of failure had failed. The captain's verification had been correct. The gap between confirming the problem and acting on it, one watch cycle, was enough for the consequence to land anyway: the captain lost his command, and his career was over.

The third took over command a few days after the grounding, in a dry dock in Norway, under heavy clouds and light rain. It was an appropriate setting for how the rest of my time on Boulder would feel. No matter how bright a particular day, week, or month was, there was always the impending dread that something would cause him to lash out of fear. Hours after taking command, he made me his navigation officer, on the strength of the second captain's own verified judgment of me. My welcome came with a warning: congratulations, you're my navigation officer, it's a double-edged sword, I'll be watching you like a hawk.

I want to be fair here: I loved being navigation officer. It was one of the most inspiring positions I've ever held, and it gave me one of my deepest personal lessons in the impact a leader has, watching what I built with my own navigation team, a story for another piece. But no matter how well any of us did our jobs, there was always that overcast hanging over us: the captain above.

That same pattern kept resurfacing, in wildly different rooms. In 1996, early in my consulting career, a telecom SVP was mystified: his internal reports showed provisioning commitments worth hundreds of thousands of dollars being met, but the real calendar showed jobs running weeks behind, with penalties having to be paid for late delivery. He wrote off the frontline order-entry team as "bricks." Those "bricks" turned out to hold most of the answer. The system was transactional, not historical, silently overwriting its own start date every time an order got kicked back, so the dashboard showed a process working perfectly while the real work quietly fell behind. As W. Edwards Deming put it, 94 percent of the problem belongs to the system, leadership's responsibility. Six percent of the problem belongs to the individual. Neither trust nor verification was present, twenty years before I had a name for the concept and the anti-pattern I kept seeing happening.

That pull toward leadership had been there since childhood, and it became a formal path in 2009, when I began training as a coach. I was drawn specifically to a model built on a validated assessment, the Energy Leadership Index (ELI)[1], because I wanted something more than conversation: a way to actually measure where someone stood and watch them move, not just talk about movement. That same instinct, wanting a real diagnostic instead of a gut read, is what eventually led me to build my own tools, a story for another piece.

Everything came together in 2016, when I joined AgileCraft, renamed Jira Align, now simply Align. By then I'd been in the industry over twenty years, long enough to watch the same fear-driven command-and-control instinct show up again and again: leaders burned by a string of watermelon projects, the old industry line for work that looks green right up until it explodes bright red, understandably stopped trusting their teams to self-organize. SAFe's own answer to that is servant leadership, trust your people, but you can't hand someone who has lived through repeated blowups a mandate to simply trust and expect it to take. The insight, working inside AgileCraft, was that trust isn't something you can instruct into existence; it has to be built the same way anything gets rebuilt after a failure, through evidence, in real time, connecting strategy to execution and connecting whether people actually have what they need, training, tools, support, a healthy culture, to do the job well.

AgileCraft was the first platform where I could truly show people a visualization of the flow of value as opposed to utilization. Utilization asks whether people are busy. Flow asks whether value is actually reaching the customer, and those are not the same question, and they're often not even correlated. PMI's own research on value streams makes the point directly: treating people as efficient because they're working 100 percent of the time is flawed thinking, because full utilization forces task-switching and queuing that slows the very delivery it was meant to protect.[2] SAFe's own flow research backs this from the other direction: high utilization consistently correlates with slower delivery, because fully loaded teams create queues at every handoff, invisible to a dashboard that's only watching busyness.[3]

That's the mental model shift underneath everything else in this piece. A utilization mindset is command and control by another name: keep everyone busy, measure activity, assume output follows. A flow mindset is servant leadership applied to a portfolio: keep value moving, measure outcomes, and trust that busy people doing the right work in the right order will get there faster than busy people doing everything at once. Once I could see that difference clearly, I could finally teach it, not as an opinion, but as something you could point at and show someone.

The distinction that matters

Command and control only asks "am I verifying," and buys compliance instead of predictability. Blind trust only asks "am I trusting," and lets problems compound quietly until they aren't quiet anymore. Trust and Verify keeps both questions live: trust teams with how the work gets built, that's servant leadership in practice, and verify that what gets built moves the outcome the business asked for. Trusting the first doesn't excuse checking the second, and neither does checking the second replace actually trusting the first.

This isn't just a personal observation. Amy Edmondson's research at Harvard, developed over two decades and independently confirmed across industries, found that trust and accountability are two separate, independent dimensions, not opposite ends of one dial you balance between. Her research maps four zones: high trust paired with high accountability produces what she calls the learning zone, where teams take real risks and actually deliver. High trust alone, without accountability, produces a comfort zone: safe, but not delivering. High accountability alone, without trust, produces an anxiety zone: people protect themselves instead of surfacing real problems, which is command and control by another name. Low on both produces apathy.[4] In separate research with James Detert, Edmondson found that 85 percent of employees have withheld information they knew was important from a manager, out of fear of what speaking up would cost them.[5] That silence is expensive in ordinary business terms too: replacing an employee who disengages and leaves typically costs half to two times their annual salary.[6] Google's own internal research reached a version of the same conclusion. Project Aristotle, a two-year study of 180 Google teams, set out to find what actually made teams effective, and found psychological safety mattered more than anything else they measured, including who was on the team.[7]

Trust and Verify isn't a new idea. It's what the research has been saying for over a decade. The two questions aren't in tension. They're both required, and neither one substitutes for the other. Knowing this and acting on it are two different disciplines, and plenty of organizations that know it still don't.

Verification goes deeper than outcomes

Trust each team at its own current stage, honestly, not the stage at which the roadmap needs the team to be. Teams fresh out of training haven't been handed capability, they've been handed a vocabulary, a start date, and mental models that never actually changed. Without outside coaching and reinforcement, that gap doesn't close, it compounds. Closing it means reinforcing a new way of thinking, a new way of doing, a new way of operating, until it replaces the old mental muscle behavior instead of just sitting on top of it. Teams can run the same ceremonies for years, still thinking in utilization instead of flow of value, and believe they're agile. They're just doing waterfall with agile words.

So verification has to check two things across every team: whether the work is moving the right outcome, and whether that team is actually developing, not just performing the rituals of a framework it hasn't grown into yet.

Frameworks don't fail. Leadership does.

There's a version of this argument playing out right now at industry scale. SAFe has a reputation problem: rigid, command-and-control, exactly the kind of thing Trust and Verify pushes back against. But look at where that reputation actually comes from. An empirical study of SAFe adoptions found that leadership support and mindset is the single most important factor in whether a SAFe transformation succeeds, and that a wrong mindset among leaders is one of the most common reasons it fails.[8] A separate study of large-scale SAFe rollouts, including a multi-bank analysis across ING Benelux, BNP Paribas, Deutsche Bank, and SimCorp, found the same pattern from a different angle: organizations that rushed the rollout, skipped training senior leaders, and never actually replaced command-and-control leadership with a coaching one, got exactly the rigid, command-and-control result people now blame on the framework. Ericsson's own large-scale transformation ran into change resistance and a lack of real coaching, and ended up, in the researchers' words, still operating in waterfall mode underneath the new vocabulary.[9]

The framework gets blamed for a leadership mindset it never actually replaced.

This matters because most of what's called SAFe fatigue right now isn't the framework failing. It's under-coached teams pushed through a rollout too fast, run by leaders who never did the mindset work themselves, and it produces exactly what you'd expect: the appearance of agile with the actual behavior of command and control still running underneath.

The stakes are concrete. Industry estimates put enterprise-scale SAFe rollouts at three to ten million dollars a year for two to three years before they stabilize.[10] McKinsey's own transformation research, drawn from a survey of more than a thousand executives, found the success rate stuck below a third: fewer than one in three transformations both improve performance and sustain the improvement over time.[11] And the shortfall traces back to exactly the gap this section opened with: the State of Agile Report, one of the most-cited annual surveys in the field, found lack of skill and experience among the leading barriers organizations report when scaling agile.[12]

I call the alternative the art of the possible. There's a line from Professor McAdams at Cornell's S.C. Johnson Graduate School of Management that I think about constantly, because it's one of the most obvious things I've ever heard and also one of the most profound: "that which is currently taking place is not impossible." I hear "we're different, this won't work for us" in nearly every large organization I walk into. But there are dozens of successful SAFe transformations in every industry. If it's already happening somewhere, it isn't impossible. What it requires is honesty about where an organization actually is.

That's the real first question, before framework choice, before rollout plan: is this organization ready to commit to a multi-year transformation, with the leadership awareness and team-level readiness that requires? Or does it need to start incrementally, from wherever it actually is? Or does it not want a transformation at all, just real visibility into the portfolio it already has? Trust and Verify works across all three. It's not a bet on any one framework or any one pace. It excels wherever the underlying commitment is to flow and outcomes instead of utilization, whatever the timeline for getting there looks like.

Why this shows up as a visibility problem

McKinsey and Oxford studied more than 5,400 large IT projects and found they delivered 56 percent less value than promised, on average.[13] The money leaks into work that never ties back to strategy, effort no one can see across the portfolio, and reporting that counts activity and utilization instead of outcomes. That's the waterline gap and the interpretation gap underneath it.

Or the gap just moves below the surface until the board asks the question nobody can answer.

Closing that gap requires scaffolding, not more hoping: strategy and execution connected in near-real time, pulling from the systems of record instead of a manager-assembled status deck that's stale the moment it's presented and reflects what that manager wants leadership to see as much as what's actually true. Once that scaffolding exists, verification stops being a quarterly event and becomes a standing condition, visible continuously instead of reconstructed after the fact.

None of this requires a specific platform. Trust and Verify is an approach grounded in leadership and real-time feedback loops, not a product. But it does require flow-of-value thinking and a servant-leadership mindset to actually work, which in practice means it shows up most naturally on platforms built for exactly that, rather than traditional PPM tools built to track tasks and utilization, even if they've had agile tools bolted on. The core doesn't change because the surface did. Forrester named this pattern back in 2011: water-scrum-fall, agile ceremonies and interfaces layered onto a system, and usually a mindset, that never actually stopped being waterfall underneath.[14] A 2023 academic study of large enterprises confirmed the pattern hasn't gone anywhere: teams still run modified Scrum ceremonies sandwiched between traditional upfront planning and traditional release gates, often without even realizing that's what they're doing.[15]

The payoff

Three captains, one ship, two years: that's where I first watched trust and verification decide an outcome, long before I had a name for either one. The lesson doesn't change at scale. Teams that reliably deliver what they commit to aren't just easier to manage, they're the kind of asset a CFO can plan capital against.[16]

Trust and Verify, at both the outcome layer and the human layer, is what keeps a portfolio's real position visible above the waterline, not just what a dashboard says it is, so delivery stays predictable enough to plan against.