How to Understand an Organization Before Trying to Improve It

A doctor does not treat high blood pressure because the number itself is important. High blood pressure is an observable symptom, a useful indicator that something inside the body may not be working as intended. Medication may lower the number, and sometimes that intervention is absolutely necessary. But if the underlying causes are poor diet, lack of exercise and chronic stress, improving those conditions does much more than reduce blood pressure. The patient becomes healthier overall. They run faster, lift more, sleep better. Blood pressure improves naturally as a consequence of a healthier system.

Organizations behave in much the same way. Production incidents, escaped defects, delivery delays, customer complaints and even business performance are organizational symptoms. They matter, and they should never be ignored. Sometimes they require immediate action. But they rarely explain why the organization produced them in the first place.

The purpose of diagnosis is not to describe an organization. It is not to produce a maturity score. It is not to compare one team with another.

The purpose of diagnosis is to identify the next intervention most likely to improve the system. We are not trying to achieve perfection. Life is messy. Organizations are too complex to achieve perfection. We are trying to become correct enough to confidently choose the next meaningful intervention.

To achieve that, we evaluate the conditions that produce organizational outcomes rather than the outcomes themselves. We examine how people understand problems, make decisions, collaborate, learn and adapt, while also considering the organizational environment that shapes those behaviors.

What Are We Diagnosing?

Organizations do not make decisions. People do.

Every feature, deployment, production incident and customer interaction is the result of countless decisions made by individuals and teams. Those decisions rarely happen in isolation. They are shaped by experience, communication, incentives, leadership, constraints and the environment in which people work.

None of those qualities are directly observable. You cannot measure understanding with a dashboard or generate a report showing how aligned a team is. Ownership, trust and curiosity leave no convenient metrics behind. Instead, they reveal themselves indirectly through the decisions people make, the conversations they have and the outcomes they consistently produce.

This means diagnosis is necessarily an exercise in interpretation. A single observation is rarely enough to draw a conclusion. People contradict themselves, exceptional individuals compensate for weak systems and sometimes organizations simply get lucky.

This framework approaches that challenge from two directions.

The first is looking at the people doing the work. Through structured conversations we explore how people think about their product, justify decisions, where they agree, where they disagree and what assumptions remain unspoken. The conversation is not an examination with right and wrong answers. It is a way of making invisible organizational characteristics visible.

The second is looking at the environment surrounding those people. Teams operate within systems that define incentives, distribute authority, impose constraints and reward certain behaviors over others. Those forces often explain why otherwise capable people repeatedly make decisions that appear irrational from the outside. 

Neither perspective is sufficient on its own. Strong teams can struggle inside unhealthy organizations, just as well-designed organizations can be limited by teams that lack shared understanding or effective collaboration. Only by considering both perspectives together can we improve the system itself rather than merely shifting its symptoms elsewhere.

Observing the Invisible

Most organizational characteristics cannot be measured directly. Understanding has no unit. Alignment does not appear on a dashboard. Trust, curiosity and ownership leave no convenient trail of metrics behind. Yet experienced leaders often recognize their presence within minutes of joining a discussion. That is not intuition in the mystical sense. It is pattern recognition.

A diagnosis begins with observations. Every answer, hesitation, disagreement, example and contradiction provides another piece of evidence. None of them proves anything on its own. Each simply changes how confident we are in our current explanation of the organization.

When someone confidently describes an excellent deployment process, the interesting question is not whether the statement is true. It is what evidence would increase or decrease our confidence in it. We might ask for an example, explore an exception, revisit the topic later from another angle or compare that answer with someone else's perspective. Every observation is treated as a hypothesis rather than a conclusion.

Contradictions are therefore not failures of the workshop. They are often its most valuable evidence. Organizations are complex, and inconsistency usually reflects different experiences, unevenly evolving processes or assumptions that have never been challenged. Agreement deserves the same caution. A room full of people confidently repeating the same belief can still be collectively wrong. Healthy diagnosis values reasoning more than confidence and curiosity more than certainty.

Over time, confidence shifts. Some explanations become increasingly plausible while others quietly disappear. No single answer reveals how an organization works, but dozens of observations gradually begin pointing in the same direction. That is when observations become a diagnosis. Most organizations already possess enough knowledge to improve themselves. The difficult part is making that knowledge visible. 

The Dimensions of Diagnosis

Observations become useful only when they can be interpreted consistently. Without structure, two people can leave the same workshop having reached completely different conclusions. A diagnostic framework provides that structure.

This framework evaluates organizations through a small number of dimensions. They are not independent measures, nor are they intended to describe every aspect of an organization. They simply represent the characteristics that most strongly influence how organizations make decisions and, ultimately, what outcomes they produce.

Understanding

Every decision is based on a mental model of reality. That model may be accurate or flawed, complete or incomplete, shared or fragmented. Understanding reflects how well an organization perceives the problems it is trying to solve before attempting to solve them.

Alignment

People rarely disagree for a single reason. They may be pursuing different objectives, working under different constraints, making different assumptions or simply believing that their own approach is the right one. Alignment reflects how consistently those differences are surfaced, examined and ultimately resolved. 

Deliberation

Organizations make thousands of decisions every day. Some are thoughtful, others habitual. Deliberation reflects how consciously decisions are made, how willingly assumptions are challenged and how comfortably uncertainty is explored before action is

taken.

Learning

Learning reflects an organization's willingness to improve its understanding through experimentation, reflection and deliberate curiosity. Healthy organizations question established practices, explore alternatives and willingly discard ideas that no longer serve them rather than waiting for mistakes or changing circumstances to force improvement.

Adaptability

Organizations operate in constantly changing environments. Adaptability reflects how readily they recognize changing conditions, revise their assumptions and evolve their practices while remaining faithful to the principles they are trying to achieve.

Mutual Trust

Mutual trust reflects the extent to which information can move honestly through the organization. Leaders trust teams with responsibility and decision-making, while teams trust leaders enough to surface uncertainty, challenge assumptions and deliver unwelcome news without fear.

None of these dimensions exists in isolation. Better understanding often improves alignment. Trust encourages learning. Deliberation exposes misunderstandings. Adaptability depends on all of them to some extent. Improving one dimension frequently influences the others, which is precisely why diagnosis is more valuable than isolated observations. Strong opinions are common. Well-supported ones are much rarer. This method allows us to see the organization as an interconnected system rather than a collection of independent problems.

Working with Dimensions

The diagnostic dimensions are not a scorecard. They are lenses through which observations can be interpreted. Every answer, example, hesitation or disagreement contributes evidence that may strengthen or weaken several dimensions at once. A single observation rarely tells us much on its own. Its value comes from how it changes our confidence in the broader picture.

Consider a team that struggles to explain who their customer is. That observation primarily raises questions about understanding, but it may also suggest poor alignment if different people describe different customers. If the discussion reveals that those assumptions have never been challenged, it may even point towards weaknesses in deliberation. One observation. Multiple hypotheses.

The opposite is equally true. No dimension should be judged from a single conversation or isolated incident. A heated disagreement may indicate poor alignment, or it may simply reflect a healthy culture where difficult ideas are openly challenged. A production incident may expose weaknesses in adaptability, or it may be the inevitable consequence of deliberate experimentation. Context always matters.

Diagnosis therefore becomes an iterative process of reducing uncertainty. Every observation either reinforces an existing hypothesis, weakens it or suggests an entirely new explanation. As confidence grows, some explanations become increasingly plausible while others quietly disappear. The dimensions provide enough structure to make that reasoning consistent without pretending that organizations can be reduced to a handful of numbers.

The objective is not to determine whether an organization has "good trust" or "poor learning". It is to understand which characteristics most strongly influence the decisions being made today and, consequently, which intervention is most likely to improve the system tomorrow. The framework is also intentionally incomplete. Good diagnosis depends more on curiosity than on faithfully following a process. 

Preparing for Diagnosis

A successful diagnostic workshop begins long before anyone enters the meeting room. Like any good investigator, your first objective is not to find answers. It is to form questions worth asking. Every document you read beforehand should help you build tentative hypotheses, not confident conclusions.

Start by understanding the organization at a high level. What problem does it solve? Who are its customers? How is it structured? Where are decisions made? Which teams depend on one another? Even a rough mental model makes it much easier to recognize when something does not fit.

Next, gather whatever evidence already exists. Delivery metrics, production incidents, customer complaints, support tickets, employee surveys, postmortems, architectural diagrams, strategy documents and roadmaps all tell part of the story. None of them reveals the truth on its own, but together they begin to suggest where further investigation may be valuable.

>> This guide uses examples. They are fictional, but not imaginary. Every workshop, conversation and organization described in the following pages is a composite built from real experiences. Details have been changed, situations have been combined and even invented from scratch. This is intentional. It protects the people involved while allowing the underlying patterns to remain intact. If a particular story reminds you of your own team or organization, that is almost certainly because the challenges themselves are not unique. Most organizations wrestle with the same handful of problems. They simply manifest in different ways. <<

>> A product organization requested help because delivery felt increasingly unpredictable. Features were generally implemented on time once development began, yet customers consistently perceived delivery as slow. The initial assumption was that engineering execution had become inefficient.

Before speaking to anyone, I reviewed the software delivery lifecycle, lead time distribution, recent production incidents and a selection of unusually long-running work items. I also spoke with several engineering leads to understand how work typically moved through the organization.

Two hypotheses emerged.

The first was that communication between teams had become fragmented, creating unnecessary delays and uncertainty throughout the delivery process.

The second was more concerning. Many of the longest-running initiatives appeared to deliver little measurable customer value despite being treated as urgent work. That suggested the organization's biggest constraint might not lie in software delivery itself, but much earlier in how ideas were discovered, validated and prioritized.

Those hypotheses were deliberately left unfinished. The purpose of the workshop was not to confirm them. It was to give them every opportunity to be disproven. <<

As you review this material, resist the temptation to diagnose. Instead, write down observations, open questions and competing explanations. A team with frequent production incidents may have poor engineering practices, unrealistic deadlines, ineffective prioritization or simply be operating in an unusually demanding environment. At this stage, all of those explanations remain plausible.

Look for gaps as carefully as you look for patterns. Missing documentation, unavailable metrics or unanswered questions are often as informative as the evidence you do have. They reveal where uncertainty is greatest and where the workshop is likely to produce the most value.

>> Early in a workshop I became convinced that the team lacked any structured way of connecting engineering work to business value. I spent several minutes looking for a capability map, impact model or some other artifact that would explain how product ideas were evaluated.

I was wrong.

The artifact didn't exist because it wasn't solving a problem they had. Every person in the room had helped build the product from the ground up and possessed years of accumulated business context. They weren't consulting a document because they didn't need one.

The diagnosis changed completely. The problem was not missing business understanding. It was that the understanding lived almost entirely inside people's heads. The organization's immediate capability was strong. Its long-term resilience was not. <<

Finally, prepare yourself as much as you prepare your questions. Enter the workshop with curiosity rather than confidence. Your hypotheses should help you notice interesting signals, not persuade you that you already understand the organization. The purpose of preparation is not to arrive with the right answers. It is to arrive ready to recognize them when they appear.

>> Before the workshop, a hypothesis about insufficient incident handling presented itself. Operational awareness seemed fragmented. Incident discussions were spread across multiple communication channels, automated notifications generated a constant stream of messages and, from the outside, the entire process looked pretty chaotic.

The evidence told a different story. Historical incidents showed that the overwhelming majority had been detected internally before customers noticed anything was wrong. Almost all were resolved within a day, despite the absence of formal on-call rotations or contractual response targets.

What initially appeared to be organizational disorder turned out to be one of the healthiest operational capabilities in the organization. <<

Running the Diagnostic Workshop

A diagnostic workshop is not an interview, an audit or an examination. Its purpose is not to determine whether people know the "correct" answers. It is to understand how the organization thinks.

Start with questions that invite explanation rather than confirmation. "Walk me through your last deployment." is far more revealing than "Do you have a deployment process?" In fact, refrain from asking yes or no questions as much as you can. Ask how decisions are made, not whether they are documented. Ask for stories rather than opinions. Concrete examples expose far more about an organization than abstract descriptions ever will.

>> One of the first questions asked was how the team determined whether a proposed feature would create value for customers before development began. The first answer came quickly.

"We ask customers whether they liked the feature after we've released it."

This already raised some of my attention, as I was asking about verifying idea, not verifying delivery, but before that response could be explored further, someone else interrupted.

"When you say customer, who do you mean?"

The room paused. What had initially seemed like a straightforward discussion about product validation suddenly became a discussion about stakeholders, assumptions and whether the organization even shared a common understanding of who it was building for. <<

Listen as carefully to the reasoning as you do to the answers. Two teams may reach the same decision for entirely different reasons. One may have carefully considered multiple alternatives before choosing the best option. The other may simply be repeating what has always been done. The outcome is identical. The quality of the decision-making is not.

When something feels inconsistent, resist the urge to resolve it immediately. Instead, become curious. Revisit the topic later. Ask someone else to describe the same situation. Approach it from a different angle. Contradictions are rarely obstacles to diagnosis. They are often the most valuable evidence you will encounter.

>> Earlier in the discussion, one participant explained that every feature had to satisfy a well-defined Definition of Ready before development could begin. A few minutes later, while describing refinement sessions, someone else casually remarked:

"The refinement is usually where we decide whether a story is actually ready."

Neither statement was necessarily false. Different people had simply developed different mental models of the same process. The contradiction was not something to resolve immediately. It was an invitation to keep asking questions. <<

Likewise, avoid treating consensus as proof. If everyone agrees immediately, explore why. Shared understanding is one explanation. Shared assumptions are another. Sometimes the most revealing question in the workshop is simply, "Can anyone think of an exception?"

Pay attention to the conversation itself. Who answers first? Who hesitates? Who asks questions? Who changes their mind when presented with new information? Which disagreements become productive discussions, and which quickly disappear? These observations are not the diagnosis, but they provide valuable context for interpreting everything else you hear.

>> Certain questions seemed to produce rehearsed answers.

"Why do you do it this way?"

"Because that's our process."

The interesting conversations rarely began with the first "Why?" They began with the second or third. Occasionally with the first "Why not?"

"Why not involve the customer before development?"

"Why wouldn't you skip this approval?"

Once people moved beyond describing the process and started explaining the reasoning behind it, assumptions that had gone unchallenged for years began surfacing naturally. <<

Finally, resist the temptation to solve problems during the workshop. Good ideas will inevitably emerge, and it can be tempting to pursue them immediately. Make a note of them and continue gathering evidence. Every early solution narrows your field of view. Diagnosis works best when curiosity remains ahead of certainty.

The workshop ends when new observations stop meaningfully changing your understanding of the organization. Not when every question has been asked, but when additional answers are no longer revealing new patterns. At that point, the objective shifts from gathering evidence to making sense of it.

Facilitating these conversations is a skill in its own right. Knowing when to challenge an assumption, when to let silence do the work, when to revisit a topic and when to move on comes largely from experience. There are no universal rules that apply in every situation, only techniques that increase the likelihood of uncovering useful evidence. As with any craft, good judgment develops through deliberate practice as much as deliberate study.

Diagnosing the Environment

A workshop tells you how people experience their organization. It does not always explain why.

Many recurring organizational problems have little to do with the people involved. Capable teams can produce poor outcomes when they operate inside systems that reward the wrong behaviors, distribute authority poorly or make collaboration unnecessarily difficult. Ignoring those forces risks blaming people for decisions that were, in many ways, predictable.

As you begin forming a diagnosis, step back and examine the environment surrounding the team. How are priorities decided? Who has the authority to make decisions? Which metrics influence behavior? How do teams depend on one another? What happens when deadlines conflict with quality? What is rewarded? What is quietly discouraged?

>> As observations accumulated, the discussion gradually shifted away from engineering practices and towards the environment surrounding the teams.

Product leaders could describe what they wanted to build, but often struggled to articulate the underlying customer problem each initiative was meant to solve. At the same time, engineering teams were expected to adopt a growing number of company-wide initiatives designed for an organization thousands of people larger than their own department.

Neither issue appeared dramatic in isolation. Together, they explained many of the patterns observed during the workshop. Teams were making sensible local decisions inside an environment that rarely provided enough shared context to optimize globally. <<

Pay particular attention to incentives. Organizations rarely behave according to their stated values alone. They behave according to the consequences of their decisions. If delivery speed is rewarded while technical debt is ignored, teams will naturally optimize for speed. If production incidents are punished more harshly than delayed releases, unnecessary caution becomes a rational strategy. These are not individual failures. They are properties of the system.

Likewise, examine the paths through which work and information must travel. Every additional approval, hand-off, dependency or organizational boundary increases the opportunity for delay, misunderstanding and local optimization. Sometimes the most significant obstacle to improvement is not a lack of skill or motivation, but the structure of the organization itself.

>> As the workshop shifted towards organizational structure, one recurring frustration emerged. Several teams depended on a shared platform team whose backlog was consistently overloaded. Waiting for changes had become a normal part of delivery.

Instead, one team described a different approach. After discussing the required change with the platform team, they requested temporary access to the repository, implemented the solution themselves and then reviewed it together with the platform engineers before merging it.

The dependency remained, but the behavior around it was remarkably healthy. Rather than waiting for someone else to solve the problem, both teams found a way to share responsibility while respecting ownership. <<

The goal is not to catalogue every environmental factor that influences the organization. It is to identify those that meaningfully shape the decisions people make every day. When the observations from the workshop and the realities of the environment begin telling the same story, the diagnosis becomes substantially more reliable.

From Diagnosis to Intervention

A diagnosis has little value unless it changes what happens next. The purpose of this framework is not to identify every weakness an organization has. Every organization has weaknesses. The objective is to identify the smallest number of changes most likely to improve the system as a whole.

That decision is rarely straightforward. Every intervention carries costs, trade-offs and unintended consequences. Improving one part of an organization may create pressure elsewhere. Solving today's constraint may expose tomorrow's. Choosing where to intervene is therefore a discipline in its own right.

A good diagnosis narrows the field. It helps distinguish symptoms from causes, reveals which problems are reinforcing one another and increases confidence that an intervention will address the system rather than merely its visible outcomes. It does not eliminate uncertainty, but it makes acting under uncertainty considerably more informed.

Selecting, sequencing and evaluating interventions deserves more attention than this guide can reasonably provide. It is a subject in its own right. The purpose of diagnosis is simply to ensure that when you choose to change an organization, you are changing it for the right reasons.

>> One pattern stood out above the others: teams understood their own work reasonably well, but had little understanding of one another's constraints and responsibilities.

The first intervention was therefore a deliberately small experiment. Rather than redesigning processes or introducing new ceremonies, engineers from different teams were temporarily paired to shadow each other's work, observe daily challenges and build personal relationships across organizational boundaries. <<

Closing Thoughts

Organizations are among the most complex systems we attempt to build. They are shaped by people, technology, incentives, history, culture and countless decisions made every day. No framework can capture that complexity perfectly, and no diagnosis will ever eliminate uncertainty entirely. Fortunately, it does not have to.

It only needs to understand the system well enough to confidently choose the next meaningful step. Every thoughtful intervention improves your understanding of the organization, creating new observations, new evidence and, inevitably, new questions. Diagnosis is not a phase that ends. It is a capability that grows alongside the organization itself.

The same is true for this guide. It is intentionally focused on one part of a much larger discipline. Understanding organizations is only the beginning. Improving them requires a different set of tools, and facilitating those conversations is a craft that rewards years of deliberate practice. I want you to leave with better questions, a clearer way of reasoning about organizations and greater confidence in choosing where to look next.

That is enough to begin.