Follow the Problem: Strategy Begins With Diagnosis

Teams often ask for better software without ever deciding who owns the work. Businesses often ask for more attention without ever explaining what they offer. Websites often ask for more traffic while leaving their visitors unsure about what to do next.

It is possible to deliver exactly what someone requested and leave them with the same problem.

Every proposed solution carries an explanation of what is wrong. Buying software assumes a tool will help. Increasing publicity assumes visibility is the obstacle. Hiring assumes capacity is the constraint. Before committing time, money, and people to a response, I want to know whether that explanation holds up.

I believe strategy begins with diagnosis, and diagnosis requires understanding the people and relationships around the problem.

That is what connects my interests in business, technology, creativity, and sociology. Each gives me another way to investigate what is happening, what people need, and what might actually be worth building.

Sociology is particularly useful here because organizations do not make decisions in a vacuum. People work within relationships, institutions, expectations, hierarchies, and established ways of doing things. A solution can make perfect sense technically while misunderstanding the social system in which the problem exists.

Paul DiMaggio and Walter Powell offered one explanation for this in their 1983 paper, The Iron Cage Revisited. They argued that uncertainty can encourage organizations to copy others they regard as successful or legitimate. They called this process mimetic isomorphism. In their account, adopting a familiar organizational practice can help establish legitimacy even when the benefits of improved efficiency are uncertain. [1]

That gives me a practical question whenever a solution arrives with the justification that successful organizations are already doing it:

What evidence connects the proposed solution to our particular obstacle?

Suppose a competitor adopts a new platform, which gives me something to investigate. It does not establish that I need the same platform.

I still need to understand the conditions that make it useful: the work it supports, the people available to maintain it, the incentives surrounding its use, and the problem it actually addresses. Otherwise, I could commit resources to a solution whose relevance I have never established.

The same principle applies when the problem appears to concern an individual.

Mark Granovetter’s 1985 paper on embeddedness challenged explanations of economic behavior that treated people as isolated decision-makers. His argument places economic action within ongoing social relationships. Understanding behavior, therefore, requires attention to the networks and relationships in which people act. [2]

Applied to a workplace, this leads me to investigate how people actually obtain information and cooperation.

Who gets called when the documented process stalls?

Whose judgment do others rely on?

Who can move something forward without formally owning it?

Can a new employee get the same help as someone who already knows the right person?

Those questions reveal something an organizational chart may not.

A process that relies on personal contacts may work smoothly for established employees while offering a very different experience to newcomers. What initially looks like an individual performance problem might instead involve access to relationships. What looks like an efficient process from management’s perspective might depend on informal work that management never sees.

My work in Army communications and IT gives me a practical setting for this kind of inquiry.

A person needs access to something to complete a task. The technical issue matters within that larger situation: the task, the deadline, the people involved, the approval structure, and the responsibilities attached to it.

Restoring access addresses the immediate need.

Repeated access problems create a different question.

If the same category of issue continues appearing, I can ask whether the problem is actually technical. Perhaps instructions are unclear. Perhaps ownership is ambiguous. Perhaps approvals create the delay. Perhaps the system works exactly as designed, but does not align with how the organization actually operates.

The investigation can move from technology into management without the underlying problem changing.

Stephen Barley’s 1986 study makes the importance of that organizational context concrete. Studying the introduction of identical CT scanners in two radiology departments, he documented different organizational outcomes. His analysis examined how technology interacted with established roles and patterns of interaction. The same equipment did not produce a uniform organizational arrangement. [3]

That matters well beyond radiology.

Organizations frequently discuss technology as though its capabilities determine its effects. But implementation introduces technology into an existing arrangement of expertise, authority, habits, incentives, and relationships.

My takeaway is that a technology decision, therefore, requires examining not only what the technology can do, but how people will use it, coordinate around it, and exercise authority through it.

The equipment’s capabilities are one part of the diagnosis.

Together, these contributions give me three things to examine before committing resources: the pressure to imitate, the relationships through which work happens, and the organizational setting into which a solution will arrive.

They also sharpen a question about power:

Who gets to define the problem?

A manager might see a lack of visibility where an employee experiences repeated interruptions. A customer might experience a confusing process that the organization considers complete. A technical team might see a tooling problem where the people doing the work see unclear ownership.

Each description points toward a different intervention.

That means defining the problem is not a neutral step before strategy. The definition itself determines what receives attention, whose experience matters, what gets measured, and eventually where resources go.

I want those different accounts on the table before choosing what to improve.

That is relevant to creative projects too.

With Blaudacity, my interest in who defines acceptable expressions of Blackness raises practical questions about whose work receives attention, whose interpretations become authoritative, and how editorial decisions are made. A project’s stated purpose needs to inform the everyday choices that give it form.

Saying that a publication welcomes unconventional expressions means little if its selection practices quietly reproduce the same boundaries it claims to question.

The same diagnostic principle applies: compare what the system says it does with what people actually experience.

But a diagnosis becomes useful only when it can be tested.

Make the Diagnosis Falsifiable

To put this perspective to work, I use a five-step exercise. This is my practical application of the ideas above, rather than a method validated by those papers.

1. Describe the obstacle in observable terms. Identify who is affected, what they are trying to accomplish, and where progress stops. Record a starting measure, such as waiting time, abandonment, repeated errors, or rework.

2. Compare accounts of the problem. Speak with someone experiencing it, someone responsible for the process, and someone able to authorize a change. Pay particular attention to where their explanations differ.

3. Write down competing explanations. A delay might reflect inadequate software, unclear responsibility, insufficient capacity, or a process that makes sense to its designers but not its users. Identify evidence that would help distinguish between those explanations.

4. Test the best-supported explanation. Choose a small change you are authorized to make. Decide beforehand what improvement you expect, when you will assess it, and what adverse effects you will watch for.

5. Let the result change the decision. Continue, revise, or stop based on what happened. Record results that challenge your explanation instead of treating them as inconveniences.

Consider a hypothetical access process.

Suppose recent requests show that approvals account for most of the delay. Before proposing another system, I might test something considerably less impressive: one clearly assigned approval owner.

If the starting median approval time is two working days, I could target one working day across the next ten comparable requests while maintaining required checks, tracking errors, and staff workload. The target and sample size are choices for an initial trial, not research-backed standards.

If approval time falls, that supports further testing.

If approval becomes faster but the overall wait remains unchanged, another stage may be constraining the process.

If approvals were already prompt, then the evidence has done something equally valuable: it has given me a reason to abandon my explanation.

A failed hypothesis is cheaper than a successfully implemented solution to the wrong problem.

A small before-and-after comparison is not proof. Staffing, workload, request complexity, timing, and other conditions can affect the outcome. Those differences belong in the interpretation.

The purpose of the test is not to manufacture certainty.

It is to make the reasoning visible enough that reality can disagree with it.

You can begin with one sentence:

“I believe [specific obstacle] is caused by [explanation]. If we change [one thing], I expect [observable result] within [time or number of attempts]. I will reconsider if [result that challenges the explanation].”

Then ask someone affected by the problem what your account leaves out.

That final question matters because diagnosis is not merely an analytical exercise. It is also a social one.

DiMaggio and Powell give me reason to question whether a solution is being adopted because it fits the problem or because it resembles what legitimate organizations are expected to do.

Granovetter gives me reason to examine the relationships hidden beneath formal processes.

Barley gives me reason to expect the same technology to behave differently when introduced into different patterns of roles and authority.

Together, they complicate a familiar strategic instinct:

Find the solution.

I would rather follow the problem.

That means resisting the temptation to begin with whatever is newest, most visible, or easiest to purchase. It means treating disagreement about the problem as information rather than noise. And it means being willing to discover that the solution I originally wanted has little to do with what is actually happening.

This is the standard I want to bring to the work on this site: make the diagnosis visible, explain the decision it supports, and show what happened when it met reality.

The next time someone asks for a solution, I want to begin somewhere less comfortable:

What is happening, to whom, and what would convince us that we understand why?

References

1. DiMaggio, P. J., & Powell, W. W. (1983). The Iron Cage Revisited: Institutional Isomorphism and Collective Rationality in Organizational Fields. American Sociological Review, 48(2), 147–160.

   
   

2. Granovetter, M. (1985). Economic Action and Social Structure: The Problem of Embeddedness. American Journal of Sociology, 91(3), 481–510.

   
   

3. Barley, S. R. (1986). Technology as an Occasion for Structuring: Evidence from Observations of CT Scanners and the Social Order of Radiology Departments. Administrative Science Quarterly, 31(1), 78–108.