Skip to main content
Trust and Verify

A ship's true condition lives below the waterline

So does a portfolio's.

I served under three Navy commanding officers in two years, aboard the same ship. Same crew, same equipment, three different outcomes. One captain trusted his team and transformed the ship's culture within weeks. He was also verifying, carefully. After two months of direct observation, he identified a real problem in the crew and moved to fix it. It didn't matter. The ship ran aground that same night, one watch cycle before the fix could take effect. He lost his command. His verification had been correct. Being right wasn't fast enough.

That gap, between confirming a problem and it costing you anyway, is the same gap I now see in how organizations report on their own investments.

The distinctionTrust and Verify asks two different questions, on purpose.

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 the team with how the work gets built, and verify that what gets built actually moves the outcome the business asked for. Neither one substitutes for the other.

This isn't just a personal observation. Amy Edmondson's research at Harvard found that trust and accountability are two separate, independent dimensions, not opposite ends of one dial you balance between. High trust paired with high accountability is the only zone where teams take real risks and actually deliver. Google's own research, Project Aristotle, found something similar from a different angle: psychological safety mattered more to team effectiveness than anything else they measured, including who was on the team.

Verification has to go deeper than outcomes, too. Trust each team at its own current stage, honestly, not the stage the roadmap needs them to be at. Teams fresh out of training haven't been handed capability, they've been handed a vocabulary and a start date. Without coaching and reinforcement, that gap doesn't close, it compounds, and teams can run the same ceremonies for years while still thinking in busyness instead of value delivered. Expecting mature output from that isn't trust, it's neglect with better branding.

Here's where it shows up as money, not just culture. McKinsey and Oxford studied more than 5,400 large IT projects and found they delivered 56 percent less value than promised, on average. The money doesn't disappear. It leaks into work that never ties back to strategy, effort nobody can see across the portfolio, and reporting that counts activity instead of outcomes.

The waterline gapThe distance between what a dashboard shows and what leadership actually needs to answer the investment question.

It exists because of a second gap sitting underneath it.

The interpretation gapSomeone has to translate feature velocity and team-level maturity into language a CFO can act on.

Or the real picture just stays below the surface until the board asks the question nobody can answer.

Closing both gaps takes scaffolding, not more hoping: strategy and execution connected in near-real time, pulling from the systems of record instead of a status deck a manager assembled by hand, one that's already stale by the time it's presented. Once that scaffolding exists, verification stops being something you do once a quarter and becomes a standing condition, visible continuously instead of reconstructed after the fact.

None of this requires a specific platform. It requires leadership willing to ask both questions, every time, instead of defaulting to whichever one feels more comfortable. Command and control never gets you predictable delivery, because it never lets teams develop. Blind trust never gets you there either, because it never notices whether they have.

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. The same lesson I learned on a ship in 1988 turns out to be the lesson most enterprise portfolios are still relearning today.

This is the short version. If you want the full story, the research behind it, and where the model actually came from, or you want to talk about where your own portfolio stands: