Building culture like a product: an agile approach to the people operating system

Agile thinking has transformed how organisations design products, solve customer problems and deliver technology. But those same principles are still rarely applied to the organisation itself.

Teams are encouraged to test assumptions, work in smaller increments and learn from real users.

Yet when it comes to culture, leadership and people systems, organisations often default to broad transformation programmes, fixed solutions and long implementation plans.

The result is a strange contradiction.

The customer experience is treated as something to continuously improve.

The employee experience is often treated as something to launch.

In a recent conversation with Everyday Agile, we explored what changes when culture is treated as the people operating system of the organisation, and when agile thinking is applied not only to products and delivery, but to how work itself happens.

The starting point is simple:

Do not begin with the framework. Begin with a hypothesis about the system.

Agile is not a collection of ceremonies

For many organisations, agile has gradually become associated with a familiar set of practices:

• Sprints

• Stand-ups

• Retrospectives

• Backlogs

• Planning sessions

  
  

Those practices can be useful.

But they are not the point.

At its core, agile thinking is about an organisation’s ability to:

• Identify the problem that matters most

• Make priorities and trade-offs visible

• Test assumptions rather than defend them

• Deliver something useful in smaller increments

• Learn from evidence

• Adapt without losing direction

  
  

A team can complete every agile ceremony perfectly and still be unable to make a timely decision.

It can arrange its work into sprints while continuing to treat every request as urgent.

It can run regular retrospectives but leave the same obstacles untouched because nobody has the authority or capacity to remove them.

You can call it a sprint, but if twelve priorities enter and twelve priorities leave, it is still just a very organised panic.

Agility is not demonstrated by the terminology an organisation uses.

It shows up in how quickly it can create clarity, make a decision, learn and respond.

Culture is the system through which agility happens

Culture is often discussed as though it sits beside the operational organisation.

There is the strategy, the product, the processes and the commercial model, and then there is culture, somewhere in the softer layer around them.

In reality, culture is the system through which all of those things operate.

It shapes:

• How priorities are understood

• How decisions are made

• Whether people feel able to challenge an assumption

• How ownership and accountability work

• What happens when delivery begins to slip

• Which behaviours are rewarded under pressure

• Whether the organisation can learn without becoming defensive

This is why so many apparent people problems are actually system problems with human consequences.

A business may believe it has a communication problem when it has unclear decision rights.

It may believe people are not accountable when ownership and expectations were never properly defined.

It may believe managers need more training when they have been given responsibility without a workable management system.

It may introduce more meetings to improve alignment when the underlying issue is that nobody knows where authority sits.

Culture is not simply what people believe.

It is what the organisation repeatedly makes easier, harder, safer and more valuable.

Culture systems are products

Once we begin to think about culture as an operating system, many familiar organisational practices start to look like products.

An onboarding experience is a product.

A performance process is a product.

A leadership rhythm is a product.

A decision-making framework is a product.

A company-wide meeting is a product.

Each one has users.

Each is intended to solve a problem.

Each creates behaviours, friction and workarounds.

And each can be designed well or badly.

Yet organisations rarely manage these systems as products.

They are often built once, launched and then left in place long after the organisation has changed around them.

Healthy product thinking would ask:

• Who is this system for?

• What problem is it meant to solve?

• What assumptions are we making?

• What behaviour are we trying to enable?

• How will we know whether it is working?

• Where are people creating workarounds?

• What have we learned since it was introduced?

• What should we change next?

A beautifully designed process that nobody can use is not a successful output.

A framework that exists but does not change behaviour has not delivered value.

Completion is not the same as adoption.

And adoption is not the same as impact.

Start with a hypothesis, not a solution

Healthy product thinking does not begin with certainty.

It begins with an informed hypothesis about the problem, the user and the conditions creating the current experience.

Culture work should begin in the same place.

Too often, organisations start with the proposed solution:

• A new values programme

• A leadership framework

• An engagement survey

• Management training

• A performance process

• Another collaboration tool

Each of these may be useful.

But none should be the starting point.

The first step should be developing an evidence-based hypothesis about what is happening inside the organisation and why.

For example:

The visible symptom:  Decisions take too long.	Initial hypothesis: Decision rights are unclear, too many people believe they need to be consulted, or leaders are repeatedly revisiting decisions that have already been delegated.
The visible symptom:  Teams are struggling to prioritise.	Initial hypothesis: The organisation has not agreed its most important outcomes, trade-offs remain implicit, or new work is continually added without anything being removed.
The visible symptom: Managers are not holding people accountable.	Initial hypothesis: Success is poorly defined, managers lack the authority or confidence to address issues, or expectations change without being made explicit.

A hypothesis is not a conclusion. It is a starting point for focused investigation.

It gives the organisation something specific to validate, challenge or refine through evidence.

Without it, culture work can become a search for general themes rather than a disciplined attempt to understand the system producing the current behaviour.

At Culture Craft, our Rapid System Read provides this first diagnostic sprint. Over two to four weeks, we build an evidence-based picture of how the organisation is really operating under pressure, at pace and as it scales. The aim is not to produce a broad culture report. It is to formulate a grounded hypothesis about where the people operating system is creating friction, and where focused intervention is most likely to unlock progress.

Diagnosis should lead to action

One of the weaknesses of traditional culture work is that diagnosis and delivery are often separated.

The organisation commissions research, receives a report and is then left to work out what to do with it.

Insight is treated as the output.

But insight only creates value when it changes what happens next.

An agile approach asks:

• What have we learned?

• What does the evidence suggest?

• Which assumption should we test first?

• What is the smallest useful intervention?

• Who owns it?

• What change would we expect to see?

• How will we know whether it worked?

The important point is sequencing.

Understand the system first.

Then direct effort toward the constraint most likely to be holding performance back.

Work with the organisation you actually have

One of the most useful ideas within product thinking is that we should learn from the way users really behave, rather than designing around an idealised user.

The same should apply to organisations.

A culture system should not assume:

• Leaders will always have enough time

• Priorities will remain stable

• Every manager will interpret a framework consistently

• People will adopt a process simply because it has been explained

• Employees will speak honestly when the environment does not feel safe

• Informal founder-led systems will continue working as the organisation scales

The system needs to work inside the real organisation, under real pressure.

This is why evidence matters.

A process map may show how work is supposed to happen.

A policy may show who is theoretically accountable.

A leadership team may believe expectations are clear.

But the real system is revealed through behaviour:

• Where decisions stall

• Where work is repeatedly escalated

• Where leaders step back in

• Where teams create workarounds

• Where priorities conflict

• Where accountability becomes blurred under pressure

The purpose of diagnosis is to understand that lived system, not simply document the intended one.

Design, deploy and learn in sprints

Once the organisation has a credible hypothesis, the next step is not to design the entire future state at once.

It is to turn that hypothesis into a focused sprint, identify the smallest viable version of the system to build, deploy it in a real operating context and learn from what happens.

The aim is not simply to test whether the diagnosis is right.

It is to begin an iterative process of designing the culture system through delivery.

For example:

• If the hypothesis is that decision-making is slow because ownership is unclear, the first sprint might redesign decision rights within one critical workflow and deploy them with the team using it most often.

• If the hypothesis is that managers are avoiding accountability because expectations are inconsistent, the first sprint might introduce a minimum viable performance rhythm with one team, then refine it based on how managers and employees actually use it.

• If the hypothesis is that priorities are constantly shifting, the first sprint might establish a visible prioritisation process that forces explicit trade-offs, then observe where the process holds and where leaders continue to work around it.

Each sprint should produce something usable.

Not a presentation of the proposed solution, but a working version of the system that people can experience, respond to and improve.

The first version does not need to solve the entire problem. It needs to be complete enough to generate meaningful evidence.

That evidence can then shape the next sprint.

The organisation can assess:

• Whether the original hypothesis still holds

• Whether the intervention changed the intended behaviour

• Wow people used the system in practice

• Where friction, resistance or workarounds emerged

• What should be retained, adapted or removed

• Which capability or user group the next sprint should address

• When the system is ready to scale more broadly

This creates a continuous rhythm of design, deployment and learning.

Each sprint moves the organisation closer to a more effective operating system, while reducing the risk of investing heavily in a solution built on untested assumptions.

This is where agile thinking becomes particularly valuable.

The organisation does not wait for complete certainty before acting, nor does it treat the first intervention as the finished answer.

It learns through delivery, improves through use and scales what proves valuable.

Accountability begins before the work starts

Agile environments rely on people being able to take ownership, make decisions and respond to new information.

That is difficult when accountability is introduced only after something has gone wrong.

Real accountability begins before the work starts.

People need to understand:

• The outcome they own

• The authority they have

• The constraints they are working within

• The support available

• What good looks like

• When and how progress will be reviewed

Without that clarity, accountability can quickly become blame.

Leaders cannot ask people to take ownership while continuing to step back into every important decision.

Nor can they hold people accountable for outcomes when authority remains concentrated elsewhere.

Accountability should create agency.

Blame creates self-protection.

An agile culture requires enough clarity for people to act, and enough trust for them to surface problems before those problems become crises.

Build, observe and adapt

Culture is not something an organisation launches.

It is designed through the way work happens every day.

That means culture work should not be approached as a single transformation with a neat completion date.

It should be treated as a continuous process of diagnosis, hypothesis, design, delivery and adaptation.

Start with the friction.

Trace it back to the system.

Form a hypothesis.

Gather enough evidence to challenge or strengthen it.

Test the smallest useful change.

Make ownership clear.

Observe what changes.

Then adapt from what you learn.

The aim is not to make the organisation endlessly flexible or to introduce more agile terminology.

It is to build a people operating system that creates clarity, supports good decisions and makes effective performance more repeatable.

Because the real test of an agile culture is not whether the organisation runs sprints.

It is whether the organisation can learn and change without losing the ability to deliver.

Where to start

Before committing to a larger piece of culture or organisational work, it helps to understand where your system may be creating friction.

Culture Craft’s free Scale Readiness Review is a quick, ten-minute assessment that scores your organisation across six areas and identifies where your people operating system may be leaving growth opportunity on the table.

It is a practical first step for founders and leadership teams who can feel the friction of scale but are not yet clear on what is causing it.

Take the free Scale Readiness Review

From there, the Rapid System Read can provide a deeper, evidence-based view of how your organisation is really operating and help you form a clear hypothesis about what should change next.

Feeling the friction but unsure where to start? Book a free call and we’ll talk it through.