Culture Tree Reading edition

Cultural transformation for digital businesses

Culture Tree

You can’t order a culture to change.
You can change what it grows from.

Seven connected layers, from how requests arrive to how people respond to problems. Open any layer on the plate, or let the key suggest where to start.

Find where to start

Plate IA connected whole
A delicately painted oak, with olive leaves, branching boughs, and an intricate exposed root system.CanopyCultureBoughsValuesBranchesPracticesTrunkTeamsRootsArchitectureFine rootsEngineeringSoilRequests
Seven layers, from the culture everyone sees to the requests beneath it.Select a layer to open it
Herbarium culturaeNo. 1
Specimen
A method for changing how a digital business works, from requests to culture.
Habitat
Any organization where people and software change together, at any size.
Useful for
Finding where to start, what to try first, and how to tell if it helped.
Collected by
Andrei Dvortsov · Riga · 2017–2026
Status
A method still growing: tested in practice, open to revision.
IWhat am I looking at?A field guide to changing how a digital business works, from requests to culture.IICould it help me?Answer three questions. The tree shows where to look first.IIIWhere do the conclusions come from?Seven years of practice, published research, and an AI-built product.IVHow can I apply it?A pathway for a first experiment and the instruments to run it.

The principle

Change the circumstances. Help new habits take root.

Culture is the shared pattern of how people act, decide, and respond to problems. It grows from what everyday work makes possible, rewards, or discourages.

The seven layers connect management choices with technical choices. Use them to find a practical starting point, then check whether the change supports the behavior you want. The layers influence each other; they are not a fixed sequence of steps.

How working circumstances shape behavior
The circumstances

Every decision needs approval.

How people respond

People wait to be told.

What happens next

Leaders see a need for more control.

Waiting can look like a lack of initiative, even when the approval process makes it the sensible choice.

Start with a behavior you want to change. Find the circumstances that sustain it. Change one, observe what happens, and adjust.

How an engineering change can support cultural changeAn example

Suppose a team needs permission for every small release. Automated checks and a reliable way to undo a release can make routine changes easier to trust. Leadership can then give the team clearer authority to act within agreed limits.

The team releases a change, sees its effect, and takes responsibility for the next step and stays accountable for its effects. Repeated experience can make ownership a shared habit. The technical work and the management decision support each other.

Could it help me? · A key to your situation

Find where to start.

Culture Tree applies wherever people and software change together. Your situation decides where to begin, not whether it applies. Answer three questions; the tree shows which layers to open first.

1Where do you stand?
2How many people change the product?
3What do you see? Choose any that apply.

You don’t need a title to start. Change needs someone willing to begin and someone with authority who supports it, or at least doesn’t block it. Ideas travel between people; a reader today can be the ally of whoever starts tomorrow.

Culture · Canopy

Look at how people respond to problems.

When someone brings bad news, do people learn from it, protect a procedure, or protect their position? Ron Westrum’s three culture types help name these patterns. Different teams in the same company may show different patterns.

Plate II · Three patterns of growth

Three oaks: one grows freely; one has sparse foliage, old graft scars, and a wounded trunk; one has clipped branches and roots confined to a nursery pot.

Focused on shared results

Generative

Room to grow, and care that supports it.

Focused on power

Pathological

Growth pursued at the expense of long-term health.

Focused on rules

Bureaucratic

Growth permitted only within the prescribed shape.

Comparing: Primary focus

Choose an aspect to change the three descriptions below.

Generative

Performance and mission

Pathological

Power and control

Bureaucratic

Rules and processes

Circumstances can support growth, force it at lasting cost, or hold it within prescribed limits. What circumstances shape behavior in your organization?

Try the culture exercise11 observations · compare perspectives

Choose the description closest to your team. These eleven prompts extend the culture typology for discussion; they are not Westrum’s validated survey. Compare your answers with someone in another role.

1 of 11Primary focus

Which sounds most like your team?

What sustains these behaviors? Look at the values beneath them. ↓

Values · Boughs

Make the values visible in the work.

A digital business brings people and software together to help customers accomplish something—for example, complete a repayment without needing to call support. That practical improvement is a customer outcome. Values become credible when decisions, responsibilities, and tools support such improvements.

The declared valueThe circumstances that support it

Adaptability

Teams can try small changes, see the results quickly, and change course when they learn something new.

Close collaboration

People solving the same problem can talk directly and see each other’s work in progress.

Team autonomy

The team has a clear purpose, authority to make decisions, and access to the skills and tools it needs. It is responsible for the work and accountable for the results.

What makes a value habitual? Give it a repeatable practice. ↓

Practices · Branches

Make learning part of the daily work.

Try a small change, look at the result together, and decide what to do next. Direct communication keeps the evidence close to the people who can act on it.

A repeatable learning cycleSelect a step

A small experiment

Make the change small enough to learn from.

Try an interface improvement with a limited group of users. Decide in advance what you expect to improve and what would make you stop.

What is the smallest useful change we can test?

Who needs to learn together? Design the team around the flow. ↓

Teams · Trunk

Keep responsibility and accountability together.

Ownership combines responsibility for doing the work with accountability for its effects: checking results, explaining decisions, and following through when something needs to change. The team needs the authority and skills to carry both from the first report through to the result.

Follow one piece of work

Between separate departments

3 hand-offs

    Within a team that owns the work and its results

    Shared context

    The people involved can investigate and act together. The team remains responsible for the work and accountable for its results.

    Each hand-off can add waiting or lose context. Where work crosses team boundaries, make responsibility and accountability explicit.

    How the organization supports the teamControl → enabling

    Stream-aligned teams follow a customer need through to its outcome.

    Platform teams provide shared tools and services.

    Enabling teams help other teams develop skills and remove obstacles.

    An operations stream, end to endComplaint → learning
    1. Hear the complaint
    2. Analyze the problem
    3. Shape an improvement
    4. Build together
    5. Release to a small group
    6. Approve or roll back
    7. Train and observe

    The team can address the immediate problem, investigate the cause, and check whether the change helped. When another team is needed, agree how they will work together, who is responsible for each part, and who remains accountable for the result.

    Can that team change its own software? Align the architecture with ownership. ↓

    Architecture · Roots

    Let teams change the software they own.

    A team needs more than permission to act. If every change depends on software owned elsewhere, it still has to wait. Align team responsibilities and software boundaries where this helps work move.

    Who needs to coordinate this change?

    Follow a change to lending through the highlighted column. Compare how many teams need to coordinate.

    Ownership of four business domains across four technical layers
    Technical layerLendingCollectionsAssetsProduct

    Cohesion

    Keep things that usually change together close together.

    Modularity

    Give each part a clear job and a clear way to interact with other parts.

    Loose coupling

    Reduce the number of other parts that must change at the same time.

    Use the same words for the same business concepts in conversations, requirements, and code. Domain-driven design calls this a shared, or ubiquitous, language.

    What keeps those boundaries healthy? Build quality into the everyday work. ↓

    Engineering · Fine roots

    Check the code, the experience, and the outcome.

    These are three different questions. Code can pass its tests while a customer still struggles. A feature can work as designed while solving the wrong problem.

    Plate III · Layers of feedback
    An intricate oak cross-section with natural concentric growth rings and radial grain.
    Different layers of one connected system.
    The times shown are examples; choose a useful pace for your work.

    Does the code do what it should?

    Test-driven development (TDD) uses a test to describe the behavior you need. Make the test pass, then improve the code’s structure while keeping that behavior intact.

    The working loop

    Write a failing test → Make it pass → Improve the design

    Quality

    Define acceptance criteria and make feedback fast.

    Security

    Address security during design, with specialist advice and checks built into delivery.

    Adaptability

    Share unfinished work and unknowns early, while changing direction is still affordable.

    Check delivery, customer outcomes, and team experienceSPACE · delivery measures

    SPACE

    Satisfaction & well-being
    Do people feel supported and able to do good work?
    Performance
    What did the work achieve?
    Activity
    What work happened, and what does that tell us in context?
    Communication & collaboration
    Can people share knowledge and work together effectively?
    Efficiency & flow
    Where does work wait, repeat, or get interrupted?

    DORA delivery measures

    Deployment frequency
    How often changes reach production.
    Lead time for changes
    Time from commit to production.
    Change fail rate
    The share of deployments needing immediate intervention.
    Failed deployment recovery time
    How long it takes to recover from a failed deployment.
    Deployment rework rate
    The share of deployments that are unplanned responses to production incidents.

    Read these measures together and follow the same service over time. Pair them with customer outcomes and team experience. DORA’s current definitions explain these five measures.

    What should enter this system in the first place? Begin with a real need. ↓

    Requests · Soil

    Start with a real need and a useful first change.

    A feature request or a bug report is a clue to a problem. Find out who is affected and what they need to accomplish. Then choose a small response that can help them and teach the team something.

    Plate IV · Assembled or grownThe same oak, two ways

    Assembled from parts Nothing works until the last part is in place.

    An oak built from parts: a root stump with a sawn top; a sawn trunk tied onto the roots and propped by a stake; bare sawn boughs bolted on with brackets; finally a leafy crown, still held together by cord, brackets and a stake.

    Plan it all

    Build the base

    Add the features

    Release, at last

    Grown from a seed Small, but whole and alive at every stage.

    The same oak grown from a seed: a germinating acorn, a seedling with two leaves, a young oak with several leaves, and a young tree with a full crown, each with living roots.

    A real need

    A useful first step

    Observe and adjust

    Expand what works

    Both rows end with a tree. Only the lower one is alive at every stage: people can use it early, and each step teaches the team something while there is still time to change course.

    Sort what arrives

    Is it asking for something new, or for a repair?

    Value

    A need the product does not meet yet

    Failure

    Something that should already work

    John Seddon calls these value demand and failure demand. Bug reports, status chasing, and repeated complaints are failure demand: work the organization creates for itself. Count both, and treat a high share of failure demand as a signal from the layers above.

    Follow failure demand up the tree

    Where does it come from?

    • Bugs and risky releases Engineering
    • “Where is my request?” Teams: a hand-off nobody owns
    • The same complaint, again Practices: nobody learns from it
    • Problems reported late, or not at all Culture: reporting feels unsafe

    Decide how much to invest

    How much time is this problem worth?

    Estimate

    Design Time required

    Appetite

    Time available A fitting design

    “Appetite” means the time you are willing to invest. Shape a useful response within that limit, and explore the least understood part before committing to the rest.

    Keep the work lean

    Make room for what matters.

    • Measure who was helped, not just how many tasks closed.
    • Let people hear feedback directly when an extra hand-off adds no value.
    • Look for recurring needs, including those customers cannot easily report.
    • Reduce features, meetings, and promises that obscure the product.
    • Reward people for noticing and acknowledging mistakes.

    How can I apply it?

    Run one experiment, with the right instruments.

    Start with one team and one real problem. The pathway below sets up the experiment; the instruments help the team look at each layer together. Use them in the order your situation needs. The key suggests where to begin.

    A naturalist’s field kit: a hand lens, a field notebook, a specimen tag, a folding rule, an oak sprig, and a seed vial.

    From the model to a first experiment

    Start with one team. Learn before expanding.

    Choose one team and a concrete problem. Agree what it can change, what support it needs, and how you will judge the result. Choose a duration that fits the question you need to answer, with regular opportunities to review progress.

    1. 01

      Prepare

      Name the behavior you want to change and the circumstances behind it. Record the current customer, delivery, and team experience.

      A shared starting point
    2. 02

      Commit

      Agree the team’s authority, support, and limits. Discuss what could disrupt the experiment before committing.

      Permission to work differently
    3. 03

      Pilot

      Make the agreed changes to responsibilities, tools, and practices. Help the team learn from small deliveries and regular feedback.

      A real change in circumstances
    4. 04

      Learn & spread

      Compare results with the starting point. Keep, revise, or stop the changes. Help another team adapt what worked to its own situation.

      Evidence others can build on

    The instruments

    Look at one layer at a time.

    Each instrument opens a conversation about one layer: what you see now, and what one changed circumstance would do.

    The principleCircumstance switchSee how one changed circumstance changes behavior.CultureCulture exerciseRate your team on eleven observations and compare perspectives.PracticesLearning cycleAct, observe, adjust: questions for each step.TeamsHand-off tracerFollow one piece of work and count the hand-offs.ArchitectureOwnership matrixCompare ownership by technical layer and by business domain.EngineeringFeedback ringsCheck the code, the experience, and the outcome.RequestsAppetiteDecide how much a problem is worth before designing.AI field notesStress testGather concerns before committing to a plan.

    Field notes / The AI era

    An agent stands at the waterline.

    An AI agent is software you design and a contributor you guide, so both halves of the tree apply to it at once. Who chooses the next action? What does it know? How will the result be checked? The questions are the same; agents make the answers explicit.

    Plate V · People & software

    The same principles take different forms in human collaboration and software design. Read across the waterline to see how one reflects the other.

    An oak above still water and its complete reflection below. Human practices sit beside the crown; their software counterparts sit beside the reflection.

    How people work together

    Autonomy
    Teams can decide and act within clear boundaries.
    Shared context
    People understand the purpose and use a common language.
    Feedback
    People review results and learn from one another.
    Ownership
    Responsibility for the work goes with accountability for its effects.

    How those principles appear in software

    Autonomy reflected
    Components can change independently within clear interfaces.
    Shared context reflected
    Models, interfaces, and instructions carry the same business meaning.
    Feedback reflected
    Tests, evaluations, and observation guide the next change.
    Ownership reflected
    Software has a defined role; people remain accountable for its effects.
    A reflection reveals a shared pattern, not an identical nature. People and software need different forms of care, judgment, and control.

    Seven layers, read for agents

    The method took shape before agents joined everyday work. Read layer by layer, it already describes how to work with them.

    CanopyCulture

    Look at how people respond to problems.

    Let bad news travel fast, from agents too.An agent that cannot say “I’m stuck” will produce something that only looks finished. Ask for uncertainty and blockers. Treat an agent’s failure as information about its circumstances, not a reason to blame or ban the tool.

    BoughsValues

    Make the values visible in the work.

    Values reach an agent only in writing.What people learn by example, an agent does not. Put the values where it works: instructions, examples, acceptance criteria, and review checks.

    BranchesPractices

    Make learning part of the daily work.

    The agent forgets; the circumstances remember.A lesson from one session is gone in the next unless it changes an instruction, a tool, or a check.

    TrunkTeams

    Keep responsibility and accountability together.

    An agent can take responsibility, not accountability.Name the person who answers for each agent’s work. Keep hand-offs between agents few: like hand-offs between departments, each one loses context.

    RootsArchitecture

    Let teams change the software they own.

    Context is contextual.Modularity gives a team autonomy; it gives an agent a context it can hold. Keep each iteration inside one bounded context, with its own language and interfaces. Crossing a border starts a new iteration.

    Fine rootsEngineering

    Check the code, the experience, and the outcome.

    Tests carry intent.Write acceptance criteria before an agent implements: they guide the work and check the result. More code is not more value, so review the outcome, not the volume.

    SoilRequests

    Start with a real need and a useful first change.

    Judgment becomes the scarce part.An agent will build the ready-made solution it is given. Find the need first, hear the owner before the agent’s analysis, and set an appetite for agent work too.

    Learning from work with AI

    Make learning change the way work runs.

    I’m developing Falconer, a tool that uses AI to review how easily people can use a website. Designing its workflow has brought two practices into focus.

    1. Test the plan before committing. Gather the owner’s concerns first, then ask technical contributors or agents what else could go wrong. For each possible disruption, ask how you would notice it and what would let the work continue.
    2. Turn recurring failures into lasting improvements. A lesson should change a responsibility, a tool, a check, or the information available at a decision. Require evidence that a repair works before treating the problem as resolved.

    These practices are still being developed; their effect on organizational culture remains to be tested. Read the practices and their connection to Culture Tree.

    More practices for work with AIFive working principles
    1. Use tests to clarify behavior. Test-driven work should improve the design, with each step serving that aim.
    2. Measure delivery as a system. Look at speed, failures, and recovery together.
    3. Allow useful smaller steps. A team or agent can split work when each part can be accepted on its own; changing the intended outcome still needs a decision.
    4. Hear the owner’s concerns first. Give business knowledge room before an agent’s analysis shapes the discussion.
    5. Name who decides. Checking a proposed choice and choosing what to do are different responsibilities.
    A young oak supported by a slender stake and loose ties, with room for its crown to grow.
    Support that leaves room to grow.
    Questions to explore as AI changes the workIdeas to test
    • Activity is easier to inflate. More commits or code do not necessarily mean better outcomes.
    • Team scope may expand. Small teams may own more, with platforms providing shared tools.
    • Existing culture shapes AI use. The same tools can support learning or intensify control.

    These are questions for further work, not demonstrated outcomes of Culture Tree.

    Where do the conclusions come from?

    Three sources, kept apart.

    The method draws on lived experience, published research, and current practice with AI agents. Each is labelled so you can weigh it for yourself.

    ILived experience

    Seven years between IT and “the business”

    A multi-country lending company where the same conflicts kept returning. The method grew from trying to change them, and from seeing agreement fail to change anything.

    Read the account ↓     IIResearch

    Published work on culture and delivery

    Westrum’s culture types, the DORA research, Team Topologies, SPACE, domain-driven design, and Shape Up. Influences on the synthesis, not proof that it works.

    See the sources ↓     IIICurrent practice

    Falconer, built with AI agents

    A product developed through an agent workflow governed by the same principles. Its practices are still being developed and tested.

    Read the field notes ↗

    Where the method came from

    Everyone agreed. Nothing happened.

    The method grew out of years spent between IT and “the business,” watching the same conflicts reappear despite good intentions.

    The proposal found support. A year and a half later, almost nothing had changed. That experience is part of the method: agreement alone does not change the circumstances people work in.

    Read Andrei’s accountThe experience behind the method

    For seven years I worked at a lending company. IT sat in one country; finance, operations and everyone else were spread across others. The distance shaped the relationship: it worked like contractor and client, not like one company building its own product. IT people were treated as executors, and a layer of mediators translated between the two sides: product owners, project managers, IT managers. I was one of them.

    About five years in, I began to see how the structure of communication kept producing the same conflicts. IT called everyone else “the business” and blamed it. The business blamed IT. Every new rule arrived as a way to protect the executor from the requester.

    Reading Ron Westrum, I found a vocabulary for what I had experienced: early collaboration, later power struggles, and rules introduced as protection. I started with the work I could influence: making software ready to release in small steps, discussing expected behavior before coding, integrating changes frequently, and programming together. These practices helped people share knowledge and responsibility. They also led me to wider questions. How did the software constrain the teams? How did the teams’ responsibilities shape communication? What behavior did those circumstances encourage?

    So I went from development practices to architecture, from architecture to team structure, and from there to values. The result was this method. I presented it to department heads, team leads and executives. Most of them supported it. The CEO even asked HR to turn the culture bingo into a company-wide survey. The survey never happened.

    A year and a half later, almost nothing had changed.

    Sources & influences

    What the method builds on.

    These works influenced the synthesis. Culture Tree itself is a set of hypotheses to test, not a validated intervention.

    About the author

    Andrei Dvortsov

    I’ve spent 10+ years in fintech and software, based in Riga, Latvia. I started in QA, went on to lead QA teams, and then worked as a software architect on a multi-country lending platform.

    Now I’m building Falconer, a SaaS product developed by AI agents through a workflow I designed, and advising early-stage products as a consultant.

    Put the method into practice

    Find a practical starting point.

    I can help connect the culture you want with changes in team responsibilities, software design, and daily practice—as a consultant or an in-house transformation lead.

    Start a conversation