Context Before Prescription: Why I Don't Start With the Solution
- moriseriki
- 1 day ago
- 4 min read
I do not walk into organizations with a formula.
I have frameworks.
I have tools.
I have experience.
I have seen patterns repeat across industries, systems, leaders, and transformations.
But I do not assume that what worked somewhere else will work here.
Because no two organizations are actually the same.
They may have similar problems.
But they have different leaders.
Different cultures.
Different histories.
Different systems.
Different operating environments.
Different levels of trust.
Different capabilities.
Different political landscapes.
Different reasons for being where they are.
So before I prescribe anything, I want context.
I start with three questions
When I enter an organization or begin working on a business problem, I want to understand:
Where are you now?
What is actually happening?
Not what the process document says should happen.
Not what leadership assumes happens.
What happens in practice?
How do people perform the work?
Where does friction exist?
What are the informal workarounds?
What is working that should not be disrupted?
What does the data tell us?
What do employees tell us?
What do leaders believe the problem is?
Those perspectives may not agree.
That disagreement is useful information.
Then:
Where are you trying to go?
What does success actually look like?
· More growth?
· Faster readiness?
· Lower risk?
· Better compliance?
· Higher productivity?
· A new operating model?
· Successful technology adoption?
· More consistent performance?
· A qualified workforce?
· A stronger leadership pipeline?
If the destination is vague, almost any solution can appear reasonable.
Clarity about the desired outcome gives the work a standard against which to evaluate decisions.
Then I ask the question that usually matters most:
Why aren't you there already?
That is where diagnosis begins.
The obvious problem is not always the real problem
An organization asks for training.
Why?
"Employees do not follow the process."
Do they understand the process?
Yes.
Can they perform it?
Yes.
What happens when they do?
It takes twice as long because the system requires duplicate entry.
Now we do not have a training problem.
We have a process or technology problem.
Another organization says managers need accountability training.
Why?
"They do not hold people responsible."
Do managers understand expectations?
Not consistently.
Do teams have clear performance standards?
No.
Do managers receive usable performance data?
Not reliably.
Again, leadership development might eventually be useful.
But it should not be the first prescription.
The same principle applies to change, competency, culture, technology, and organizational design.
Symptoms tell you where to look.
They do not always tell you what to fix.
Best practice is not automatically best fit
I believe in benchmarks.
I believe in standards.
I believe in learning from organizations that have solved similar problems.
But I am cautious with the phrase best practice.
A practice may be excellent in one operating environment and ineffective in another.
A heavily regulated organization may require governance that would suffocate a startup.
A centralized model may create consistency in one business and slow another down.
A sophisticated competency system may be appropriate for safety-critical roles and unnecessary for lower-risk work.
A technology platform may offer leading functionality but still be the wrong choice for the workforce expected to use it.
The goal is not to implement the most impressive solution.
The goal is to implement the solution that best addresses the business requirement within the reality of the organization.
I call that fit-for-purpose design.
Context includes politics
This part often gets ignored.
Organizations are human systems.
That means influence matters.
History matters.
Trust matters.
Power matters.
People remember previous transformations.
They remember systems that failed.
They remember leaders who promised one thing and did another.
They remember initiatives that disappeared after six months.
They know which executives actually make decisions.
They know which managers can quietly stop an initiative from moving.
You cannot design sustainable change without understanding that environment.
Ignoring organizational politics does not make the work apolitical.
It simply means you are operating without important information.
Diagnosis protects the organization from unnecessary solutions
Starting with context also prevents organizations from solving problems they do not actually have.
That matters because every solution introduces cost.
New technology requires implementation and maintenance.
New processes create change.
New governance creates administration.
New training consumes employee time.
New organizational structures disrupt relationships.
New metrics influence behavior.
If the intervention does not address the actual cause of the problem, the organization pays for complexity without receiving the intended value.
Good diagnosis creates restraint.
Sometimes the correct answer is not to add something.
· Simplify.
· Clarify.
· Remove.
· Realign.
· Standardize.
· Stop doing something.
That can be harder than introducing a new initiative because organizations often equate action with adding.
Design. Prove. Refine.
Once I understand the context, I design around what I learned.
Not around what I wanted the answer to be.
Then I want to test whether the solution is producing the intended outcome.
· Is performance improving?
· Are people becoming more capable?
· Is adoption increasing?
· Is risk declining?
· Are processes working?
· Are leaders reinforcing the change?
· What are we learning?
· What needs refinement?
That feedback loop matters because no diagnosis is perfect and no organization remains static.
The work should evolve as the context evolves.
The Seriki System™ begins with context for a reason
Over time, I realized that this way of working had become consistent across my career.
Different industries.
Different problems.
Different solutions.
But the principle remained:
Understand before designing.
Diagnose before prescribing.
Build for the organization in front of you.
Measure whether it works.
Refine what does not.
That became the foundation of The Seriki System™.
It is not a formula that tells every organization to do the same thing.
It is a disciplined way of making sure we solve the right problem before investing in the solution.
Because the fastest route to the wrong destination is a beautifully executed answer to a question no one needed to solve.
Context comes first.
CONTINUE THE CONVERSATION
Explore The Seriki System™ to see how Context → Diagnose → Design → Validate translates into practical business and workforce transformation.
Comments