A pathway for digital companies · Move or fall

Culture Tree

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. This is the text version of the method, for reading start to finish.

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.

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?”

The seven layers

Read from the top, each layer rests on the one below it. Read from the bottom, each layer is easier to change than the one above it.

1. Culture (the canopy): generative, bureaucratic or pathological. Visible to everyone, changeable by no one directly.
2. Values (the boughs): declared and discussed.
3. Practices (the branches): adaptability, close collaboration, unit autonomy.
4. Team structure (the trunk): who talks to whom, how often and what about.
5. System architecture (the roots): cohesion, modularity, loose coupling.
6. Software development (the fine roots): built-in quality, measured flow.
7. Change flow (the soil): how requests and complaints become work.

The ground line runs under team structure. The bottom three layers are where leadership rarely looks, and where most of a culture is actually grown.

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.

In the visual version this table is a game: you rate your own organization aspect by aspect, then copy or download your results.

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: the company turns pathological. When people tire of control, they build rules to protect themselves from it, and the company turns bureaucratic. Bureaucracy feels safer than power games, so companies stay there.

Why bother

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.

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, which produces good practices again. The question is where to push the loop first.

Practices: three habits that keep a culture generative

Adaptability, recurrently

Reflect on circumstances to shape behavior, again and again: trust and guidance, an iterative approach, and empirical evidence.

Close collaboration, everywhere

Shorten every feedback loop to its minimum: direct communication instead of check-ups, joint reflection, structured interactions between teams.

Unit autonomy, for everyone

Accountability and responsibility sit with the team that does the work. Teams set their own goals. Teams choose how they work: schedule, tech stack, infrastructure. Teams ship without waiting on others, which takes cross-functional teams and continuous delivery.

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

Take a piece of work, such as investigating an incident. In a functional organization it travels from silo to silo: service desk, then operations, then system admins, then developers. That is three hand-offs, and every hand-off is a queue and a lost piece of context. In a cross-functional team the same work stays in one room, with zero hand-offs.

Shared context changes the conversation

When operations, developers and support sit in one team, an incident gets three responses at once. Support reports the payment timeout again. Operations organizes a workaround. A developer looks for a permanent solution. A sysadmin notices it doesn’t look like last time and checks the gateway. Nobody files a ticket to find that out.

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.

1. Control model. Business and IT are separate hierarchies under one CEO. Work crosses the wall between them as escalations.
2. Controlled enabling. Cross-functional product and domain teams appear, with a platform team serving them, but they are still steered from above.
3. Enabling model. Leadership sets direction. Enabling and platform teams serve the domain cross-functional teams that own the flow, and those teams collaborate directly with functional experts.

A stream, from complaint to training

An operations stream owned end to end by one team: agents complain, the team analyses operations, proposes an interface adjustment, builds it together, ships a canary release, approves or rolls back, and trains the agents. 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.

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

When ownership follows technology layers, a change to one business domain, say lending, has to pass through four teams: web, core system, operational data and the spreadsheet keepers. When ownership follows business domains, the lending team owns its slice from screen to spreadsheet, and the change stays inside one team.

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: 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.
• Product, weeks: did it serve the client? Measured by outcome, not output.

Don’t compare people. Measure the system.

Two frameworks look at flow instead of individuals. SPACE covers the human side of productivity: satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow. The DORA keys cover delivery:

• Deployment frequency (throughput): deployments to production per period.
• Lead time for changes (throughput): from commit to running in production.
• Change failure rate (stability): failed deployments divided by all deployments.
• Time to restore (stability): from detecting a failure to full recovery.

Provocations for discussion: no estimations, no sprints, no stand-ups.

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

An estimate goes from a design to a number. An appetite goes from a number to a design: you decide what the work is worth first, then shape a solution that fits. Set a time box, build from the least known part first, and use 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. Fewer features, fewer options, less structure, fewer meetings, fewer promises.

Grow it, don’t assemble it

Incremental delivery builds finished parts one at a time, roots, then trunk, then branches, then canopy, and the result is useless until the last part lands. Iterative delivery starts with a sapling that is already alive, and grows it. (After Jeff Patton’s Mona Lisa illustration.)

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.

1. Prepare. Declare values and practices. Set up metrics (SPACE, DORA). Map areas for improvement.
2. Commit. Find the avant-garde team. Present to management. Get approval. Announce with HR and communications.
3. Pilot. Form the cross-functional team. Set up continuous integration. Organize mentorship. Process feedback. Operate for six months.
4. 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. Teams mirror modules, how teams talk mirrors interfaces, and who decides mirrors who owns the code. 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.

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.

A cage keeps a sapling in place and stops it from growing. A stake gives it something to lean on while it grows.

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:

• Tests first, as a design tool (software development). 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.
• Measured by stability and throughput (software development). 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.
• Standing approval to split work (practices). 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.
• The owner’s stressors first (team structure). 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.
• Certifying a choice isn’t making one (values). 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 noteDeciding 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 noteTests become the instructions. When agents write the code, acceptance tests and behavior specs are how you tell them what you want.
• Gloss · Claude’s noteActivity 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 noteModularity 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 noteSmaller 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 noteAI amplifies the culture you have. A pathological company uses AI for surveillance and headcount cuts. A generative one uses it to remove toil.

About the author

I’m 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.