A pathway for digital companies · Move or fall

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

Culture is the canopy everyone sees and nobody can reach. It grows from values and practices, which grow from how teams are built, how systems are designed, how code is written and how requests turn into work. The lower you go, the easier it is to change something by next Monday.

Prefer to read it start to finish? Read the text version.

Tab. I.The whole plant, from canopy to soil. Change starts in the soil, where requests and complaints fall in. Select a part to read about it.

Where it came from

Everyone agreed. Nothing happened.

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 saw that it didn’t work, and that it wasn’t anybody’s fault. The structure of communication produced conflicts that were unavoidable in the long run. 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 recognized the arc: a generative first year, then a stretch of pure power games, then bureaucracy as self-defence. I started where I stood, with continuous delivery, behavior-driven development, trunk-based development and ensemble programming: anything that spreads knowledge and ownership. The deeper I went, the clearer it became that the problem wasn’t IT, or the business. It was the circumstances, built unconsciously by how people communicated and how they were organized. Behind them stood the big devil: culture.

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.

People adapt to circumstances. They don’t challenge them.

That failure is the method’s own lesson. Agreement isn’t a circumstance. People who don’t feel like owners will praise an idea and wait for someone else to act on it.

I wasn’t an owner either. But nothing stopped me from feeling like one: from treating the company, its people and its customers as mine to take care of. That feeling is what this tree is meant to grow.

How culture can be changed at all

Culture is a loop nobody decided on

People adapt to their circumstances. They do what gets rewarded, what keeps them safe, what earns them respect. Those adaptations become the circumstances for everyone else, and the loop closes. Nobody chose the result. It is a status quo built from thousands of unconscious decisions.

The loop has one weak point: awareness. Once you see the cycle, behavior becomes a choice, and conscious behavior is the only thing that shapes culture on purpose.

So the question changes from “how do I fight a culture?” to “which circumstances can I change, so that different behavior becomes the easy one?”

Tab. II.Behavior and circumstance, and the eye that interrupts them.

Layer 1 · Canopy

Culture: three compass points

Ron Westrum’s typology (2005) sorts organizations by how they treat information. It is not a score. It is a compass for a messy sea of behavior: you can tell which way you are drifting even when you can’t say exactly where you are.

Culture bingo · Rate your own organization

Think of your company, or your own team. For each aspect, pick the sentence that sounds most like it. There are no right answers, and the culture names stay hidden until you choose.

Or browse an aspect:

Power-oriented

Pathological

Rule-oriented

Bureaucratic

Performance-oriented

Generative

The room that rated itself

When I ran this game live, I asked department heads, team leads and executives to rate their own company, aspect by aspect. Nobody predicted the result, me included. A finance head and a country director rated things the CEO never expected. Areas everyone assumed were fine turned out complicated, and the other way round. A culture looks different from every chair in the room.

How companies drift

A young company is generative because it has no other way to work. Then pressure arrives, results disappoint, and frustration asks for control. When people tire of control, they build rules to protect themselves from it.

Tab. III.One tree in three seasons of a company.

Bureaucracy feels safer than power games, so companies stay there.

2.2×

Employees in high-performing teams were 2.2 times more likely to recommend their organization as a great place to work. (DORA, State of DevOps research.) Engagement isn’t a soft metric; it multiplies every strategy you have.

Layer 2 · Boughs

Values: say them out loud

Values set culture in motion. Like culture, you can’t change them directly. Unlike culture, you can declare them and argue about them, which gives you something to hold.

Many companies declare the right destination: stop being “a company with an IT department and a business side” and become a digital business. Then nothing happens. That is false causality, the belief that once people accept a new paradigm it will set itself into action. A declared value is a seed. It needs the layers below to grow.

The generative loop

Good practices produce good results. Results become performance, performance becomes satisfaction, and satisfied people keep the culture generative. The question is where to push the loop first.

Tab. IV.Two sides become one.

Tab. V.The generative loop.

Layer 3 · Branches

Practices: three habits that keep a culture generative

Recurrently

Adaptability

Reflect on circumstances to shape behavior, again and again.

Trust and guidance
Iterative approach
Empirical evidence

Everywhere

Close collaboration

Shorten every feedback loop to its minimum.

Direct communication instead of check-ups
Joint reflection
Structured interactions between teams

For everyone

Unit autonomy

Accountability and responsibility sit with the team that does the work.

Teams set their own goals
Teams choose how they work
Teams ship without waiting on others

Layer 4 · Trunk

Team structure: who talks to whom, how often and what about

Practices come from interactions, and interactions are dictated by team structure. To get shared ownership, a team needs accountability from the idea to the result of its implementation. Accountability turns into ownership, and ownership turns into productivity.

Count the hand-offs

Pick a piece of work. In a functional org it travels from silo to silo, and every arrow is a queue and a lost piece of context. In a cross-functional team it stays in one room.

Functional silos3 hand-offs

Cross-functional team0 hand-offs

Illustrative example.

Shared context changes the conversation

When operations, developers and support sit in one team, an incident gets three responses at once: someone contains it, someone looks for the cause, and someone notices it’s not the same as last time. Nobody files a ticket to find that out.

supportWe got the payment timeout again.

opsI’ll organize a workaround.

devI’ll look for a permanent solution.

sysadminDoesn’t look like last time to me. Checking the gateway.

From control to enabling

Three stages of the same company. In the vocabulary of Team Topologies: stream-aligned teams own a flow of work, platform teams offer capabilities as a service, and enabling teams teach and facilitate.

reporting linecollaborationX-as-a-servicefacilitatingescalation

Control modelBusiness and IT are separate hierarchies. Work crosses the wall as escalations.

Controlled enablingCross-functional product and domain teams appear, still steered from above.

Enabling modelLeadership sets direction; enabling and platform teams serve the teams that own the flow.

A stream, from complaint to training

An operations stream owned end to end by one team. Nobody hands the problem off, so nobody has to be convinced it exists. Each turn of the loop is a small experiment: observe, guess, predict, test, decide.

Tab. VI.An operations stream.

Layer 5 · Roots

System architecture: team structure for software

Systems mirror the teams that build them, and teams bend around the systems they inherit. When both follow the same business boundaries, interactions are fast and intuitive. When they don’t, they tear each other apart.

Cohesion

Things that move together belong together.

Modularity

Distinct, independent parts with abstract interfaces.

Loose coupling

Parts interact with minimal dependencies.

Add a shared, ubiquitous language (domain-driven design) so the code, the team and the business call things by the same names.

Who owns what

Layer 6 · Fine roots

Software development: build it in, then measure

Software cannot adapt to business needs on its own. It relies on the people writing it, and development practices decide whether the architecture stays easy or hard to change. The expensive problems are the ones that slip past individual bias, and the only cure for those is collaboration.

Built-in quality

Test-driven design
Developers define acceptance criteria

Built-in security

Every design includes measures against internal and external threats
Security teams provide tools and expertise to stream teams, not gates

Built-in adaptability

Cooperative development
Everyone can see each other’s work in progress
Acknowledge the unknown and build around it

TDD and BDD are about design, not testing

“How do I write a test for this?” is really the question “what is this code supposed to do?”. Robert C. Martin compares TDD to double-entry bookkeeping: every line of code gets a line that checks it. BDD asks the same question further out, like the rings of a tree: each ring is a feedback loop, and the inner ones turn fastest.

System, minutes: does the code do what it should? Fail, pass, refactor.
User, days: can a person do what they came to do? A scenario says it in plain words.
Product, weeks: did it serve the client? Measured by outcome, not output.

Scenario: pay off a loan in the app

Given a client with an overdue loan

When they pay the full amount in the app

Then the loan is closed the same day

And no reminder is sent tomorrow

Tab. VII.Section of a trunk. Core: fail → pass → refactor.

Don’t compare people. Measure the system.

Two frameworks that look at flow instead of individuals. SPACE covers the human side of productivity; the DORA keys cover delivery.

SSatisfaction

How fulfilled, happy and healthy people are

PPerformance

The outcome of a process

AActivity

The count of actions or outputs

CCommunication

How people talk and work together

EEfficiency & flow

Work with minimal delays or interruptions

ThroughputDeployment frequency

Deployments to production per period

ThroughputLead time for changes

From commit to running in production

StabilityChange failure rate

Failed deployments ÷ all deployments

StabilityTime to restore

From detecting a failure to full recovery

Provocations for discussion ~~EstimationsSprintsStand-ups~~

Layer 7 · Soil

Change flow: how a request or a complaint becomes work

This is where it starts. Someone asks for a feature, a customer complains, an agent reports a problem. Change how those requests enter the company and turn into changes, and everything above adjusts. The conventional answer to competition is to one-up: more features, more spending, more people. That is a defensive way to build, and it keeps you following. The alternative is to accept ideas, address problems, and build less.

Request processing

Measure outcome, not output. What matters is how many clients a change served, not how many tasks closed.
Reward people for acknowledging mistakes.
Remove middlemen who add no value to the feedback loop.
Trace every problem to its core.
Define stakeholders per topic, not per org chart.
Focus on the product. Better service brings revenue, not the other way round.

Shaping: appetite over estimate

Set a time box
Build from the least known part first
Breadboards and fat-marker sketches before pixels

Get leaner to move faster

Most of our work goes into managing our work. Treat customers as the backlog. Read requests, then throw them away: the important ones keep bubbling up. Care about what people don’t want. Build general software so people can find their own solutions.

~~More~~ Less features~~More~~ Less options~~More~~ Less structure~~More~~ Less meetings~~More~~ Less promises

Grow it, don’t assemble it

Tab. VIII.Incremental builds finished parts that are useless until the last one lands. Iterative starts with a small tree that is already alive, and grows it. After Jeff Patton’s Mona Lisa illustration.

Climbing back up

The pathway: one team first, then the rest

Don’t transform everyone at once. Find a team that wants to go first, give it real autonomy for six months, measure, and let the results make the case. Agreement in a meeting room isn’t enough, so the pathway changes circumstances, not minds.

Step I

Prepare

Declare values and practices
Set up metrics (SPACE, DORA)
Map areas for improvement

Step II

Commit

Find the avant-garde team
Present to management
Get approval
Announce with HR and communications

Step III

Pilot

Form the cross-functional team
Set up continuous integration
Organize mentorship
Process feedback
Operate for 6 months

Step IV

Spread

Present results
Make another one
Transform the rest of the teams

The AI era

The tree has a reflection

This method describes a mirror world. Software mirrors the organization that builds it. Modularity and cohesion in code mirror how teams are put together: some things belong together, some must be kept apart, and that is how both people and software scale. The same principles travel along one axis, decision-making and ownership, like a gravitational pull.

The mirror isn’t clear glass. Business objects don’t map one-to-one onto classes with the same names. What carries across is the principle, not the picture.

Tab. IX.The tree and its reflection: people above the water, software below.

An agent is both a person and a program

Working with AI agents feels like the sum of everything above. An agent is made of software and built like a mind: a neural network, something like a brain in a box. That makes ownership even harder to build into it. It has no agency of its own. But it can imagine agency, the same way people first imagined things they couldn’t reach and then built the tools to get closer.

What works with people works with agents. The only way to let an agent make good decisions is to trust it and guide it at the same time. Care is contagious: show it yourself, and the agent learns to behave the same way.

Guidance, not guardrails.

Tab. X.A cage and a stake.

Field notes from Falconer

Falconer is my SaaS project for autonomous usability audits. It is built by coding agents through a development workflow I designed, and that workflow is governed by the same tree. Five of its written decisions:

F · Fine roots

Tests first, as a design tool

Agents followed test-first as a ritual: one test, the smallest code, stop. So the rule became Kent Beck’s Canon TDD, where the steps serve the aim instead of the record.

F · Fine roots

Measured by stability and throughput

How often changes land, how long they take, how often they fail, how fast delivery resumes. Money is not a measure: you get exactly what you measure.

C · Branches

Standing approval to split work

Any agent may split a unit into smaller parts without asking, as long as each part can be accepted on its own. Asking had only ever delayed the split. Changing what gets built still needs approval.

D · Trunk

The owner’s stressors first

Before a plan starts, the owner lists what could break it, then the agent does. If the agent’s list came first, it would anchor the owner’s thinking, and two perspectives would become one with edits.

B · Boughs

Certifying a choice isn’t making one

A component that validates a decision it was handed hasn’t made that decision. For agents and for people, say who actually decides.

What changes when code gets cheap

Most of the method gets more relevant, not less. When output is nearly free, the scarce things are judgment, feedback and ownership.

Gloss · Claude’s note

Deciding becomes the bottleneck

Building a feature costs hours, so the expensive part is choosing what not to build. Appetite and “build less” become the core discipline.

Gloss · Claude’s note

Tests become the instructions

When agents write the code, acceptance tests and behavior specs are how you tell them what you want.

Gloss · Claude’s note

Activity metrics break

Lines, commits and pull requests explode in volume and mean nothing. Lead time, failure rate and client impact stay honest.

Gloss · Claude’s note

Modularity is context

An agent, like a new hire, works safely only inside a well-bounded module with a clear vocabulary. A ubiquitous language doubles as the prompt.

Gloss · Claude’s note

Smaller teams, wider streams

A stream-aligned team can own more surface. Platform teams offer AI tooling as a service; enabling teams teach how to work with it.

Gloss · Claude’s note

AI amplifies the culture you have

A pathological company uses AI for surveillance and headcount cuts. A generative one uses it to remove toil.

The article series

One article per layer, one map for all of them

Planned essays. Each one goes deep on a single layer and links back to this map.

Everyone agreed. Nothing happened.Why culture changes from below.
The driftGenerative, pathological, bureaucratic.
False causalityWhy declaring values isn’t enough.
Count the hand-offsCross-functional teams in practice.
From control to enablingThree org models and how to move between them.
Architecture is a team chartOwnership by domain, not by layer.
Measure the system, not the peopleSPACE and DORA without the theater.
Appetite over estimateShaping work and building less.
The tree has a reflectionGuidance, not guardrails, for people and agents.

About

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 handling 2,500+ loan applications a day. For years I sat in the mediator’s seat between IT and everyone else. This method grew out of that seat.

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.

Hire me to grow one

If your company wants to move toward a generative culture, I can help you implement this method, partly or fully: as a part-time consultant or as an in-house transformation lead.

Message me on LinkedIn linkedin.com/in/andrei-dvortsov