Delivery Is a Visibility Problem
I’ve been a Toronto Blue Jays fan since I was eleven, so the past few weeks watching them rise from last place in 2024 to the World Series finalist in 2025 has been a wild ride.
As a sports fan, it’s so easy to critique the decisions of players and coaches from the comfort of the couch or sitting in the stands. Anyone who has been part of a team understands that there’s far more context than what we see on screen. Even interviews during or after the game are only a small window into the hundreds of micro decisions being made throughout a game and series. After getting over the disappointment of my favorite team being so close to winning it all, I kept wondering what information they were optimizing for in those key situations.
Fans never get the context. We only see the outcome. The same thing happens in delivery work every day. People inside companies make decisions with incomplete visibility, and everyone else is left reacting to calls they were never read into.
Delivery is a visibility problem. Modern delivery teams have analytics, dashboards, and scripts. They know their metrics and what the outcomes are supposed to be. None of that matters if the situational reads are off. A team can have perfect data and still have things go wrong, even when something ships successfully. When milestones or deadlines are missed, the reflection often lands on individuals rather than stepping back to examine what we assumed, what we missed, or what the team was actually focusing on.
The frameworks we use to ship products assume that shared context will naturally emerge. It doesn’t. In practice, delivery work gets noisy. People who see issues early don’t always have the authority or confidence to raise them. We design for control instead of awareness, and that’s where visibility breaks down.
Too often we treat someone’s ability to manage others as a reflection of their worth, yet we rarely teach what management actually requires. We don’t build the capacity to read situations, facilitate convergence, or recognize when someone close to the work has the clearest view.
Even if every person on the team is good at their job, the risks compound the further you move from the work itself. The people closest to it often see risks first. Leadership provides different visibility: to threats, dependencies, strategic constraints. Knowing which of those matter most is what separates good judgment from noise. That gap is where projects stall.
I run design teams, teach undergraduates, coach high school tennis, and led an all-volunteer board. You wouldn’t expect those to have much in common. The patterns are consistent. I’ve written before about how my coaching philosophy adapts across contexts, but the core insight remains the same.
The best teams I’ve seen all share three traits. They can describe what they are doing and why. They can question assumptions without fear. They can recover quickly when something changes. When a junior engineer spots a performance issue, they raise it. When priorities shift mid-sprint, the team adjusts without losing the thread.
I’ve come to think of these as three core capabilities that most delivery frameworks assume teams already have. When teams build them, everything else gets easier. When they lack them, no amount of process helps.
1. Shared Situational Awareness
The ability to see the same problem at the same time.
This means more than having information. Everyone has Slack and Jira. It means being able to describe what you’re actually seeing in the code, the product, the user behavior, the team energy. Then converge on what it means.
Most teams skip this step. They go straight from individual observations to competing solutions. Someone sees a performance issue. Someone else sees a scope problem. Leadership sees a timeline risk. Everyone’s solving a different problem, and no one realizes it until the retrospective.
Shared awareness requires practice. It needs structure: space to surface observations without immediately jumping to solutions, and discipline to separate “what’s happening” from “what should we do.”
When teams have this, decisions feel obvious. When they lack it, every choice feels like a negotiation.
2. Adaptive Authority
The ability to let clarity unlock action, regardless of hierarchy.
Most organizations default to positional authority: decisions flow up and down the org chart. The people closest to the work often have the clearest read. The junior engineer who spots the performance issue. The designer who notices the user pattern. The PM who sees the dependency no one else tracked.
The question is: do they feel permission to call it?
Adaptive authority means the person with the clearest view gets to act, regardless of title. Leadership’s job becomes recognizing when someone else is better positioned and creating the conditions for them to move.
This is situational. When you’re closest to the information and you have clarity, you’re cleared to act. When you don’t, you surface what you’re seeing and help the team converge.
This requires trust. It also requires practice. Teams need reps learning to recognize readiness in themselves and others.
3. Continuous Recalibration
The ability to rebuild the shared picture as the situation shifts.
Most teams treat alignment as a one-time event. You align at kickoff, then execute. Situations change. Priorities shift. New information surfaces. Assumptions turn out to be wrong.
The teams that move fastest are the ones that notice when the game has changed and adjust without losing the thread.
This means treating every cycle (every sprint, every incident, every review) as a chance to rebuild shared understanding. Asking “What did we learn about the situation? What would we see earlier next time?“ are a lot more actionable than simply asking “what did we ship?”
When teams do this well, they stop getting caught off guard by the same patterns or stuck in reactive loops. Teams develop a shared vocabulary for reading situations, but more importantly, shared trust in their colleagues to rely on the skills each has and even a willingness to share responsibilities or provide slack in tense situations.
During my time at 18F, the secret sauce in building teams was that we invested heavily in getting it right. Because the organization was designed so people would rotate out, there were defined rituals around documentation and knowledge transfer.
We had rituals for surfacing what we were seeing, beyond just what we were doing. Authority rotated based on who had the clearest read, regardless of seniority. We rebuilt the picture constantly. Because term limited employees meant teams were always changing, we couldn’t afford to let context drift.
That level of clarity made it easier for new people to join without losing rhythm. The resilience came from building templates, processes, and frameworks that could flex to the next person up.
I’ve seen this pattern hold everywhere.
When I launched the Portland Digital Corps this spring, or even last year when I taught a service design class which resulted in having to teach college juniors how to ship prototypes and present them to political stakeholders, or even coaching my high school team, the unified theory here is getting people to a place where they can understand the minimum viable problem, empowering leaders across the teams by focusing more on having every person feel like they have a contributing role and being less concerned about the credit. It doesn’t mean you don’t applaud people for their effort, but rather, figuring out how to spread the plaudits and the responsibility.
Watching the World Series reminded me that every organization is just a dugout full of decisions waiting to be made. Some nights you win because you guessed right. Most nights you win because the people closest to the play were trusted to call it. Besides the salaries, the big difference between “winning” and “losing” in iterative software delivery is the lack of eyeballs on the outcomes. Minus a catastrophic failure or massive success, most people aren’t facing public scrutiny for their decisions day-to-day. For folks who do, you understand more acutely why so many constraints exist on getting from zero to done.
In my tennis coaching, early on in my career, I noticed players looking at me in crucial moments when their eyes should've been on the court. I vowed at that point to instill a level of confidence in them that even when their decisions don't work out, that they can learn to trust themselves. On changeovers, I am very often saying "I trust you." When a kid grinds out a victory using bad technique, I don’t chide them for their form. We’re trying to get through it. We can fix technique in practice, but a competitive match isn’t the time for that. It's also super rewarding to see a kid dig deep and problem-solve in real time or reflect on an earlier loss in the season and resolve not to let the same mistakes happen again. These are all life lessons that go well beyond tennis.
When we started Portland Design Month, my goal was to establish the event structure and make it manageable rather than create the biggest, flashiest thing. I remember emphasizing that it didn't matter if we only had a few events the first year, the most important thing was establishing the thing. Providing people the framework, setting the milestones, and giving people freedom to fill in the blanks and achieve it their own way, even if it's not how you'd do it.
Not every project is shaped to enable this kind of flexibility, and even ones that do, require strong coordination and collaboration to make them successful. It's why establishing norms, team rituals and keeping communication open across roles is so crucial. Everything thinks they know the answer, but until we're in the middle of solving the problems, it's hard to really know what we haven't discovered.
Developing successful teams is not just about frameworks, it's about investment, and the three capabilities are just a starting point for what makes them work well.