# Alexey Krivitsky
> I help leaders design & evolve organizations for the agentic AI age — not just buy Copilot licenses and spread them across silos.
Co-creator of Org Topologies. Co-author of 10X ORG (#1 Amazon Bestseller). Full-stack consultant — from Claude Code to C-level.
## Bio
[object Object]
[object Object]
[object Object]
[object Object]
[object Object]
Based in Munich. And happy to talk.
## Differentiator
Most org design consultants treat technology as a black box. Most AI practitioners treat organizational structure as someone else's problem. I work in the space where they meet.
## Services
- **Speaking:** Keynotes and conference talks at the intersection of AI and organizational design. Developer conferences, leadership summits, corporate events.
- **Education:** Agentic Engineering courses. AI OD School. Org Topologies Practitioner (C-OTP) certification. Hands-on workshops.
- **Consulting:** Organizational design diagnostics. AI adoption strategy. Structural transformation with real organizations under real pressure.
## Books
- **10X ORG** — Amazon #1 Bestseller in Management Science. Co-authored with Roland Flemm and Craig Larman. Why AI-native startups move at 100X. Why legacy organizations don't. And the structural changes — the Ferrari Effect, the MADE Loop, displacement patterns — that close the gap.
## Expertise
- **Organizational Design:** Co-created Org Topologies — a structural diagnostic used internationally. Worked with BMW Group, FlixBus, PandaDoc, Y Soft, Poster POS. 50+ teams coached through structural transformation.
- **AI X Engineering:** Builds agentic systems daily — not theorizing from a distance. Teaches Agentic Engineering and Claude Code courses. Started writing code in Kyiv in 2000; still ships every day.
- **Speaking & Education:** 100+ conference stages since 2008. DevWorld main stage, AI Summit, code.talks. AI OD School, C-OTP certification, 10X ORG book tour across Europe.
## Stats
- 26 years in tech
- 100+ conferences
- #1 Amazon bestseller
- 15 countries
## Clients
BMW Group, Boehringer Ingelheim, Rovio, FlixBus, PandaDoc, Poster, XING, COMFY, PrivatBank, ING Bank, SkyUp Airlines
## Contact
- Email: alexey@krivitsky.com
- Site: https://krivitsky.com
- LinkedIn: https://www.linkedin.com/in/alexeykrivitsky/
- Telegram: https://t.me/alexeykrivitsky
---
---
# Slide Decks
2 presentations.
---
# Hypothetical AI Adoption Fallacies (Slide Deck)
**Date:** 2026-06-18 · **Event:** Munich · 2026 · **Slides:** 37
**URL:** https://krivitsky.com/slides/ai-adoption-fallacies
### Slide 1 (title)
{green}AI{/} Adoption {crimson}Fallacies{/}
What can we learn from the recent management fads? What can we avoid?
### Slide 2 (statement)
"{green}Agile{/} is {crimson}Dead{/}"
### Slide 3 (statement)
We all know how it went:
- Release Trains
- Squads
- Tribes
- Chapters
- Scrum of Scrums
- Velocity
- PI Planning
- User Stories
- Servant Leaders
- Definition of Done
- Definition of Ready
- Backlog Grooming
- Agile Maturity Model
- …
{mark}Orgs attracted to new & shiny objects: fancy terms, models, frameworks …{/}
### Slide 4 (photo)
This is how {green}Agile{/} {crimson}died{/}
### Slide 5 (photo)
Manifesto for Agile Software Development
### Slide 6 (statement)
Something must've gotten very, very {crimson}wrong{/} …
### Slide 7 (statement)
Can we {green}learn{/} anything from that in the AI {strike}race{/} age?
### Slide 8 (photo)
Your AI is fast. Your org isn't?
### Slide 9 (card-grid)
Most AI adoption strategies invest in individual fluency of the so-called "individual contributors" and wonder why org-wide impact never lands. I came to realize there are three layers that multiply to produce the desired global effect.
- Fluency | Can you put AI to work in your own job, end to end? | The layer everyone's on right now and where almost the whole training budget goes. This is a necessary but not sufficient condition for success.
- Flow | Can the work reach 'done' without a human becoming the bottleneck? | Pipelines, guardrails, reviews, tests — not a skill you learn individually, but a collective system you design.
- Fit | Do your organizational structure & policies turn work into real outcomes, not just output? | When org design fits the strategy, local speed turns into global performance. When it doesn't, you just make the wrong thing faster.
These three layers multiply and the weakest one sets the ceiling.
### Slide 10 (photo)
The Rise of Agentic Product Engineering — through the Org Topologies Mapping lens
### Slide 11 (photo)
Pre-AI Product Engineering
### Slide 12 (statement)
{crimson}Pre-AI{/} Product Engineering
Engineers owning components → {green}Engineers working on outcomes{/}
Proxies collecting req's from users → {green}Engineers working with users{/}
I & T-shaping → {green}M-Shaping{/}
Rigid org design → {green}Flexible org design{/}
### Slide 13 (statement)
{green}AI-Era{/} Product Engineering
Engineers owning components → {green}Engineers working on outcomes{/}
Proxies collecting req's from users → {green}Engineers working with users{/}
I & T-shaping → {green}M-Shaping{/}
Rigid org design → {green}Flexible org design{/}
### Slide 14 (book-promo)
How do we **learn**, **adapt** and **perform** to become **10X** more **impactful** and **relevant**?
### Slide 15 (photo)
10X ORG — on stage
### Slide 16 (photo)
From four values on one page … to this.
### Slide 17 (statement)
Something must've gotten very, very wrong …
{green}So let's learn and try avoiding.{/}
Any guesses?..
### Slide 18 (statement)
{crimson}Complexity Bias!{/}
**The "Intellectualization" Trap:** We often equate complexity with sophistication, intelligence, or expertise.
**Impression Management:** Complex solutions are often viewed as more impressive by others, which can influence decision-making in corporate environments.
**Search for Order:** We often mistake chaos for complexity. When we face unpredictable situations, we may attempt to impose a complex, rigid order rather than accepting that the system may be fundamentally unpredictable.
### Slide 19 (statement)
Simple solutions often lack the {mark}satisfaction{/} of a rich, nuanced narrative.
When a solution is too straightforward, it can feel {crimson}dull{/} or {crimson}unfulfilling{/} — even if it is the most {green}efficient{/} path forward.
### Slide 20 (statement)
What if you are making the **AI adoption** at your org *slightly* more complicated than it needs to be?
1. What are the things you might be {crimson}overengineering, overthinking{/}?
2. Where can you go {green}easier, leaner{/}?
### Slide 21 (statement)
Breaking a law?
### Slide 22 (quote)
A {crimson}complex system{/} that works is invariably found to have evolved from a {green}simple system{/} that worked.
A {crimson}complex system{/} designed from scratch never works and cannot be patched up to make it work.
You have to start over with a {green}working simple system{/}.
### Slide 23 (statement)
We all know how it went:
- Release Trains
- Squads
- Tribes
- Chapters
- Scrum of Scrums
- Velocity
- PI Planning
- User Stories
- Servant Leaders
- Definition of Done
- Definition of Ready
- Backlog Grooming
- Agile Maturity Model
- …
{mark}Orgs attracted to new & shiny objects: fancy terms, models, frameworks …{/}
### Slide 24 (statement)
This is how it is going so far:
- Agentic AI
- Context Engineering
- Vibe Coding
- Spec-driven dev.
- Skills
- Plugins
- Token maxing
- Feature Factories
- Agentic Engineering
- Harness Engineering
- Loop Engineering
- Eval Engineering
- …
{mark}Orgs attracted to new & shiny objects: fancy terms, models, frameworks …{/}
### Slide 25 (photo)
The tools are powerful. The question is what you point them at.
### Slide 26 (photo)
72 Claude Code skills you need to install now
### Slide 27 (divider)
Cycles of industrialization.
### Slide 28 (photo)
The cycle of industrialization, complification & entshittification
### Slide 29 (statement)
What else killed Agile?
- {crimson}"Agile Theatre"{/}
- {crimson}"Agile without structural reinforcement"{/}
- {crimson}"Agile transformation as a project"{/}
- {crimson}"Centers of Agile Excellence"{/}
- {crimson}"Agile as internal IT game"{/}
### Slide 30 (statement)
Hypothetical AI adoption fallacies:
- {crimson}"AI Theatre"{/}
- {crimson}"AI without structural reinforcement"{/}
- {crimson}"AI transformation as a project"{/}
- {crimson}"Centers of AI Excellence"{/}
- {crimson}"AI as internal IT game"{/}
### Slide 31 (statement)
**Park AI. Slow down.** And think business and org development.
### Slide 32 (photo)
"Slow the F*ck Down" — AI Engineer Europe
### Slide 33 (statement)
**1) Park AI aside for a moment.**
### Slide 34 (statement)
**2) As an organization, what do we need to be better at to make our customers & business strive?**
### Slide 35 (statement)
Pick one primary organization goal that will support creation of a fit-for-purpose organization:
1. **Output Predictability** — delivering consistently and reliably.
2. **Lead Times & Throughput** — reducing waste, delays, improving flow.
3. **Specialist Expertise** — maintaining deep skill and craft where it counts.
4. **Customer Value** — delivering outcomes that truly matter to users.
5. **Adaptiveness** — responding flexibly to change.
6. **Employee Engagement** — sustaining motivation and satisfaction.
7. **Operational Reliability** — ensuring stable day-to-day operations.
8. **Ideation and Innovation** — generating and testing new ideas.
9. **Organizational Learning** — continuously learning and improving.
10. **Resource Efficiency** — using resources wisely, without excess.
### Slide 36 (steps)
0. Park "AI topic" aside for a moment.
1. Pick {green}one primary org goal{/} that you believe your org needs to focus on for its business & customers.
2. Close your eyes and {green}see it{/} as if it happened (own it!) — describe observable change.
3. Backpropagate your vision: what needs to happen next quarter, next month, next week, on Monday…
4. How AI comes into the picture? How can Agentic Engineering help accelerate that change?
5. And {green}K.I.S.S.{/}!
### Slide 37 (closing)
Thank {green}you{/}!
---
# 100X Developers vs. 1X Organizations (Slide Deck)
**Date:** 2026-05-19 · **Event:** Munich · 2026 · **Slides:** 46
**URL:** https://krivitsky.com/slides/agentic-shift
### Slide 1 (title)
100X Developers vs. 1X Organizations
Why AI Productivity Gains Don't Compound and How to Create 10X Organizations
### Slide 2 (statement)
This talk, roughly:
70% {green}Agentic engineering{/}
30% {crimson}Organizational impact{/}
### Slide 3 (photo)
Alexey Krivitsky: SWE (paid developer since 1998), OD (self-employed org consultant since 2009), AI (last few years, like most), CHG (survived the agile transformation shift).
### Slide 4 (book-promo)
How do we **learn**, **adapt** and **perform** to become **10X** more **impactful** and **relevant**?
### Slide 5 (statement)
AI replacing?..
### Slide 6 (statement)
"How could you write a book on AI adoption when there are no best practices, new model drops every week, and everything is emergent and novel?"
### Slide 7 (photo)
An abundant spread of fresh fruits and vegetables — variety and balance.
### Slide 8 (photo)
An AI-native developer at a multi-monitor setup — working at more than 100X.
### Slide 9 (photo)
A pre-AI, established organization — a dense modular concrete building.
### Slide 10 (photo)
Your org had been on a certain trajectory — AI is an accelerator.
### Slide 11 (photo)
A pin factory of the 18th century. Adam Smith: concentrating each worker on a single subtask often leads to greater skill and greater productivity than if each worker tried to make a whole product on their own. — The Wealth of Nations, 1776.
### Slide 12 (statement)
Anyone working in a pin factory?
### Slide 13 (quote)
"Right now, your company has 21st-century Internet-enabled [plus AI] business processes and mid-20th-century management processes, all built atop 19th-century management principles."
### Slide 14 (photo)
Fresh, varied produce beside a rigid modular concrete building — a living system versus a fixed structure.
### Slide 15 (photo)
100X locally, 1X globally — system costs up 72% while performance shows no significant change. The local improvements do not compound globally.
### Slide 16 (photo)
A red Ferrari on an open country road — raw speed with nowhere to lose it.
### Slide 17 (photo)
The Ferrari Trap — a Ferrari stuck in dense city traffic behind a GO SLOW sign.
### Slide 18 (statement)
AI adoption in established organizations:
Socio{crimson}/{/}technical
### Slide 19 (photo)
Let's visit one cubicle inside the pre-AI organization.
### Slide 20 (photo)
Here is Debian, a DB Designer. Historical org trajectory: leveraging experts' primary deep skills — "efficient".
### Slide 21 (photo)
Now with AI, Debian can do things 100X faster. So, in 3 days, he can do the yearly load of DB design.
### Slide 22 (photo)
...But what is he supposed to do with the remaining time now? It is unlikely there is demand for 100X more databases...
### Slide 23 (photo)
An after-hours desk — a hand-drawn schema, a "Ship Value Repeat" sticky note, and a checklist marked DONE.
### Slide 24 (photo)
Minimizing transaction costs — closing the value loop: Discovery to Delivery to Observability to Operations and back to Discovery.
### Slide 25 (photo)
Org Topologies — Four Intelligences. Debian sits in the DOING quadrant: narrow skills mandate, incomplete work mandate.
### Slide 26 (photo)
In another part of the office …
### Slide 27 (photo)
There is the Search Team, building and maintaining an e-Commerce search. Historical org trajectory: creating fast-flow teams — "efficient".
### Slide 28 (photo)
Minimizing switching costs — making it easier and cheaper to follow value across domains and team boundaries. Plus minimizing transaction costs by closing the value loop.
### Slide 29 (photo)
Now, with AI, they can crack search features 100X faster. They've got AI SDLC: "being faster within their lane." But is there unlimited demand for search improvements?
### Slide 30 (photo)
The empty Search Team room — whiteboards full of strategies, a toy Ferrari on the table.
### Slide 31 (photo)
The Law of Diminishing Returns — productive, then diminishing, then negative returns. AI accelerates… you along the curve, not past it.
### Slide 32 (photo)
Org Topologies — both are boxed: Debian in DOING, the Search Team in DELIVERING. Both stuck in the outputs half of the map.
### Slide 33 (photo)
The Displacement Map — as AI absorbs narrow output work, that space is disappearing; people are pushed up and right, toward complete work and broad skills.
### Slide 34 (photo)
How do we stay relevant? Debian the specialist on one side, the fast-flow Search Team on the other.
### Slide 35 (photo)
Millions of years of brain evolution as multi-learners. Temporary local optimization only lasted 200 years. Back to our strength.
### Slide 36 (statement)
Redesign, then AI.
### Slide 37 (statement)
Towards 10X ORG:
Keep experts utilizing their primary expertise → {green}Allow growing more skills{/}
Keep teams fixed for fast flow → {green}Allow working in new domains{/}
### Slide 38 (photo)
Multi-learning is not new. Takeuchi & Nonaka, "The New New Product Development Game", HBR 1986 — built-in instability, self-organizing teams, overlapping phases, multilearning, subtle control, organizational transfer of learning.
### Slide 39 (photo)
Real Org Topologies case studies — LeSS adoptions, wartime transformation, e-retail replatforming, fintech, and more, at orgtopologies.com/case-studies.
### Slide 40 (statement)
Historical Counterarguments Against Multi-learning
- **"Too costly, too disruptive."**
- **"…But our people cannot know everything!"**
- **"I'm more valuable as a deep specialist."**
- **"Cognitive overload will hit our people hard."**
### Slide 41 (photo)
A pin factory of the 18th century. Adam Smith: concentrating each worker on a single subtask often leads to greater skill and greater productivity than if each worker tried to make a whole product on their own. — The Wealth of Nations, 1776.
### Slide 42 (statement)
Building the Case for Multi-learning
- Avoid extremes. This isn't about "learn everything."
- It is not a "specialist vs. generalist" dilemma. Debian stays the DB expert. The Search team members are still fast when it comes to search.
- Can Debian update the API after finishing modifications to the DB schema?
- Can the "Search" team pick next high-value product change that is just 15% technically different from their core expertise?
- They are now allowed to gradually develop {green}new skills{/} and enter {green}new domains{/}.
### Slide 43 (photo)
100X vs. 1X — the AI-native developer's speed against the established organization's structure.
### Slide 44 (statement)
{green}Good news:{/} We can use AI to accelerate multi-learning.
- Have you used AI recently to do smth you didn't do before?
- How was the ride?
- How is it helping you to stay relevant?
- How can your organization support your better?
### Slide 45 (photo)
Back to human strength — Org Topologies, with a green arrow moving from the outputs half up into DRIVING: complete work, broad skills, real outcomes.
### Slide 46 (closing)
Thank {green}you{/}!
---
---
# Essays
90 articles on AI × Org Design, organizational transformation, and product development.
---
# Own, Not Rent: Why Change Can't Be Outsourced
**Date:** 2026-07-10 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/10xorg-p1-own-not-rent
**TL;DR:** Buy-in is permission to proceed, not ownership. A change you hand off is a change that gets handed back. The first principle from 10X ORG: own, not rent.
This kicks off a Friday series — one principle from *10X ORG* each week, the ideas that make an organization ten times more effective, not ten percent. We start with the one everything else rests on.
## The six weeks that got erased
Years ago I made an expensive consulting mistake. Expensive not in money — in learning.
A Hamburg startup had hit its first real scaling pains. I studied the system, saw what was wrong, and pitched a vision of change to the CEO. He gave me the green light and left to raise the next investment round. I had a six-week window, and I used it.
I formed a guiding coalition — the CTO, the CPO, product managers, engineers. Together we reshaped the place. What had been a set of isolated teams, each guarding its own slice of the product, became a **team-of-teams**: small groups with a shared purpose, working toward outcomes instead of tickets. People were in the room while it happened. They argued, adjusted, and made it theirs. Most of them loved it.
One moment stays with me. A machine-learning engineer had spent months alone in a one-person department, tuning algorithms nobody used. In the new setup he joined a full-stack team, and the web developers there were hungry to learn what he knew. At a product review he grinned and said, "OMG, the brain I've been developing all these months actually works." It did. And the bigger brain — the team-of-teams — had started working too.
Then the CEO came back.
He looked around and didn't recognize his own company. He asked a few questions, heard the loudest voices of the unhappy minority, and flipped it all back. Overnight, six weeks of progress were gone.
## The blessing was not ownership
So what was my mistake? I secured executive buy-in. I had the blessing. Isn't that the thing you're supposed to get?
Apparently not. **Buy-in is permission to proceed. It is not ownership.** The CEO had handed the change to me the way you hand a problem to a contractor — *you deal with it* — and a change you've handed off is a change you can hand back. He rented it. And rented things get returned.
Craig Larman once put it sharply: call it a "process change" and you'll get management support, at best; call it "a deep change to the organizational design" and you'll get their involvement. The distance between support and involvement is the whole game.
Which is the principle — the first one in the book, because everything else leans on it: **own, not rent.**
## Rented ideas draw resistance; owned ones draw care
Organizations rent change all the time. They buy the polished slide deck, roll out the popular framework, install the target operating model — and then discover the people inside don't believe in any of it. The ideas aren't necessarily bad. They were just imported before anyone inside understood the problem they were meant to solve. **Rented ideas get treated as someone else's responsibility**: best as bought, not to be questioned, adapted, or improved.
And people can tell when they're being changed rather than changing. That is what resistance actually is — not stubbornness about a new process, but a reaction to being *acted upon*. Under pressure to show improvement, they comply on the surface and send up green status reports while little shifts underneath, and the gap between the reports and the reality widens by the day.
Ownership does the opposite. When people help discover the need for change and shape what "better" looks like, it stops being extra work handed down from above and becomes their own insight. People protect what they own — they defend it when things get hard, adapt it when reality moves, keep it alive in a hundred small daily decisions. **10X performance can't be installed from outside. It grows from the inside out.**
## Change with people, not to them
The clearest counter-example I know is [Poster](/post/case-study-poster-pos-org-topologies), a Ukrainian SaaS company.
Its CEO didn't hire anyone to transform it. He gave his people 90 days to learn the fundamentals of systems thinking and organizational design, then turned them loose on their own system. They studied it, iterated on the org blueprint, and co-created a future state they actually wanted. It looked slower than a top-down rollout. It was. But speed without ownership doesn't stick — and this stuck.
The proof came later. When COVID hit, and then the full-scale invasion, Poster didn't have to redesign under fire. Its teams already held the mandate to adapt and refocus on whatever mattered most. That adaptive capacity is what carried the company back to profitability within a year. Nobody had to defend the change; it was theirs from the start.
This is also why I've grown wary of the phrase "transformation project." A project has a start date, an end date, and a neat block diagram. Organizational change has none of those cleanly — it is slow, human, and unpredictable, and treating it like a machine to be reassembled only teaches everyone to make the change look good on paper instead of real. I've written before about why [transformation exists only in retrospect](/post/agile-transformation-televised), and why [AI amplifies whatever organization you already have](/post/redesign-for-ai-why-transformation-requires-organization-design) rather than fixing it.
## Own, not rent — in the age of AI
The same trap is being reset right now, in AI costume. A vendor sells you an "AI operating model," you buy a few thousand agent seats, someone rebrands the PMO as the "AI orchestration layer" — and you've rented your AI transformation exactly the way that Hamburg CEO rented his. New labels, the old structure underneath. The uncomfortable part is that AI doesn't fix a rented organization; it amplifies whatever one you already have. Bolt agents onto fragmented ownership and narrow mandates and you don't get a better org — you get [the old traffic jam, faster](/post/the-ferrari-trap). DORA's 2025 research puts numbers on it: hand AI to a struggling team and stability actually drops. The dysfunction was already there. The tools just found it sooner.
Which is why the AI-era version of this principle is the line I keep coming back to on the book tour: first design, then AI. AI is a lever, not fairy dust — it accelerates a direction you've already chosen and owned, and it can't choose one for you. The organizations that will actually absorb agents are the ones that already own their adaptive capacity, the way Poster did: teams with the mandate to study their own system and reshape it. A top-down AI rollout onto a rented structure just teaches people to fake AI adoption the way they once faked agile. Own the redesign first, then let the agents in.
## The one that everything rests on
If there is a single reason change fails to produce lasting performance, this is it: it was rented, not owned. The conditions for deep, durable change are simple to name and hard to live — shared direction from the top, and real ownership of the problem by the people closest to the work.
Own, not rent. That's principle one. Eight more Fridays to go.
If you want the whole argument — the stories, the map, and the eight principles that follow — *10X ORG* is [on Amazon](https://www.amazon.com/10X-ORG-Topologies-Elevating-Performance/dp/9083670406), a bestseller in Management Strategy and several other categories, in Kindle, paperback, and hardcover.
Happy Friday, all.
---
# A Sprint Is Not a Mini-Waterfall
**Date:** 2026-07-08 · **Reading time:** 4 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/jul-google-sdlc-critique
**TL;DR:** Google's AI SDLC whitepaper models a sprint as a tiny waterfall with phases. That misses the core of iterative development — and it's exactly the misunderstanding worth avoiding as we build the AI-era lifecycle.
Google released a [whitepaper on the AI software development life cycle](https://drive.google.com/file/d/1IR7CddF_2FyQo_PdfBNTaEA50EGiVt2r/view). A good one, in general. It aims to systematize the knowledge that's been emerging in fragments — blog posts, threads, conference hallways — and to draw the line between three modes people keep blurring together: vibe coding, AI-assisted development, and agentic engineering. That's a genuinely useful thing to do. These ideas are new enough that most teams can't yet name which one they're doing, let alone choose deliberately between them. Making them learnable is real work, and the paper does a lot of it well. (I've argued the [spectrum between vibing and engineering](/post/vibing-or-engineering-spectrum) matters more than any single tool, so I was glad to see someone put structure on it.)
But there's one chapter that doesn't hold up: the part where the new AI model gets compared to "agile."
The authors seem to believe that a **sprint is just a small waterfall**. Requirements for two or three days, then design for a day or two, then build, then test — the classic phase sequence, shrunk down to fit inside two weeks. It's a tidy picture. It's also a serious misreading of the last twenty to thirty years of how software delivery actually evolved.
## What the picture gets wrong
Here's the idea it misses. The big move of the agile SDLC was not "do the waterfall faster." It was to remove the distinct phases from the iteration altogether.
Inside a well-run sprint there are no gates. Each feature naturally travels from a rough idea toward working software, passing through ideation, design, implementation, and testing along the way — but the *cycle itself* has no stages. Things happen in parallel. A developer and a product person shape a slice of behavior together while it's being built; a tester's question reshapes the design mid-stream; the "requirement" for the next feature gets sharper *because* the last one just shipped and someone looked at it. Nobody hands a finished requirements document across a wall to a design team who hands it across another wall to builders.
That last part is the whole point. Phases create handoffs, and handoffs turn colleagues into stations on an assembly line. Removing the phases is what lets a team [**co-create**](/post/flotilla-extreme-cocreation) instead of passing gated tasks between workers. "A sprint is not a mini-waterfall" is a sentence we repeated constantly when teaching Scrum, precisely because this was the mistake everyone made first. One could have googled that.
I'm not raising this to score a point on a whitepaper. I'm raising it because the same misunderstanding is about to get baked into the AI-era lifecycle, and that would be a waste.
## Three questions worth sitting with
The reason this matters isn't nostalgia for agile. It's that we're rebuilding the SDLC right now, in real time, around models and agents — and we get to choose what we carry forward. So:
🤔 **What if we studied the best agile adoptions** instead of building on the common misunderstanding of them? Most people's mental model of "agile" is the industrialized, ceremony-heavy version they suffered through — not the fluid, co-creating teams the ideas were meant to produce. Those good adoptions exist. [DORA research](https://dora.dev/guides/value-stream-management/) consistently shows that value stream thinking — removing handoffs and wait time across the whole system — is what separates high performers from the rest. That's worth reading before we build the next lifecycle on top of a misread.
🤔 **What if the "old" model isn't out of date at all?** Iterative, incremental, phase-free development wasn't a fad that AI replaces. It was a hard-won answer to a real problem: how do you build something when you can't know the full spec up front? That problem hasn't gone away. If anything, agents make it sharper.
🤔 **What if there's more to re-apply from the last decade than it looks?** The failure modes we learned to name — the handoff, the gate, the local optimization that speeds one station while the whole system stalls — don't disappear when you add an LLM. They come back wearing new clothes. I've written about that in [You Say You've Got an AI SDLC](/post/you-say-youve-got-an-ai-sdlc): a fast engine bolted onto a phased, hand-off-heavy org just produces the same traffic jam, more expensively.
If we take those questions seriously, we can skip a whole category of pain — the "agile theater and industrialization" era, where the mechanics of a method got copied while its point got lost — and put this genuinely wonderful new technology, LLMs and agentic engineering, to its full use. Google's paper is a good start. It'll be a better one if the next version reads a sprint for what it actually is.
---
# The AI Rush Is Self-Inflicted
**Date:** 2026-07-08 · **Reading time:** 3 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/jul-ai-rush-self-inflicted
**TL;DR:** Outside the frontier labs, the feeling of being behind on AI is mostly self-inflicted. Put the tools aside, decide what you actually want to improve, then bring AI back to that.
The AI rush is self-inflicted in most cases. If you work for OpenAI, Anthropic, or Google — yes, the race is real. Your product *is* the frontier. A model that ships a week late, or a capability a competitor demos first, shows up directly in your numbers. That pressure is earned.
But if you work in a regular product or service organization — a bank, an insurer, a logistics company, a mid-sized software shop — the feeling of being behind and needing to catch up is largely of your own making. It arrives through your feed, not through your P&L. The demo that made your stomach drop was built by someone whose whole job is to build demos that make stomachs drop.
**No one and nothing can move you faster than you are allowing yourself.** Sit with that for a second, because it cuts against most of what crossed your screen this week.
I should own my part in this. Being a change agent and org consultant for many years, I have spent a good chunk of my career manufacturing urgency — helping organizations feel enough discomfort that a stalled change finally starts moving. I still believe in that work. Meaningful change usually needs a push, and I am happy to be the one pushing. So this is not a plea to slow down for its own sake.
But rushing to apply AI *because it is all over your feed* is a different animal. That is not urgency in service of a goal — it is anxiety wearing the costume of strategy. And anxiety is a terrible planner. It picks the tool first and goes looking for the problem afterward, which is exactly backwards. I've watched teams stand up an "AI initiative" before anyone in the room could say, in one sentence, what would be better if it worked. Cheap tokens hid the cost of that for a while; [they won't for much longer](/post/subsidized-tokens-are-ending).
So here is how I'd approach it instead. Three steps, and the order is the whole point.
## Step 1 — Put AI aside for a moment
Close the tabs. Mute the feed for an afternoon. Not forever — just long enough to think without a countdown clock running in the corner of your mind. The goal is to get back to a state where *you* are choosing the direction, not the algorithm that decides what you see.
## Step 2 — Ask what you actually want to improve
With the tools out of the frame, the real question surfaces: what would you genuinely wish were better in your organization? Name it concretely. Code quality that keeps costing you weekends. A release process that still needs three handoffs and a prayer. Support costs creeping up quarter over quarter. A new offering you've wanted to test but never had the hands for. Onboarding that takes a new hire two months to feel useful.
Write down two or three of these. Not aspirations — the specific frictions you'd fix if a genie showed up. This list is the thing that should be driving you, and it has nothing to do with AI yet.
## Step 3 — Now bring AI back
Only here does the tool re-enter the room. Take your list and ask, for each item: could AI ease or accelerate a *meaningful* step in this direction? Sometimes the answer is an obvious yes. Sometimes it's "a little, at the edges." Sometimes it's "not really — this is a structure problem, not a tooling one," and that answer is just as valuable, because it stops you from bolting a fast engine onto a car that can't steer. (I've written before about [that particular trap](/post/the-ferrari-trap).)
The difference between this and the panic version is subtle but total. In the panic version, AI is the goal and your organization is the thing you retrofit around it. In this version, your organization's own priorities are the goal, and AI is one of several ways to get there faster.
I'm on this ride too — enjoying these tools most days, genuinely. That's exactly why I'd rather point them at something I actually care about than sprint in a direction someone else's product launch chose for me. The wave is real. You just don't have to let your feed decide when you paddle.
---
# Building Organizations of the Future Today: Rehire
**Date:** 2026-07-05 · **Reading time:** 4 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/rehire-future-worker
**TL;DR:** AI workshops on top of a 2019 job definition get you the same org, slightly faster. The move: define the AI-Partnered Worker profile — a new term, a new standard, a new mindset — and invite your people to step into it.
Job descriptions at many tech companies haven't changed since 2019.
The job has. The org just didn't update the file.
Many transformation programs try to fix this by changing behavior without touching what the job actually is — what decisions a person owns, what "good" looks like. You can run AI workshops on top of a 2019 role definition and get the same org, slightly faster (see [Redesign, Then AI](/post/redesign-for-ai-why-transformation-requires-organization-design) for why tooling alone doesn't move the needle).
The consultants running these programs typically aren't more informed about your specific AI strategy than your own senior engineers. They bring a framework. The answer — what the job looks like now — is yours to write.
So write it.
Define the profile of an **AI-Partnered Worker** at your company ([not the same as AI-native](/post/ai-native-vs-ai-augmented)). Not a new title. A new definition of what this job now requires.
## Eight traits
Eight things show up consistently in that profile:
**Learners first.** In [10X ORG](https://10xorg.com), we call this **multi-learning** — the capacity to keep expanding your skills as the environment moves, not to master the current version and stop. Multi-learning is the durable edge.
**AI-partnered.** Not just AI-augmented — not "uses ChatGPT sometimes", that was 2022. The standard now: actively delegates everything possible to AI, finds the boundary of what it can handle, and moves it further.
**Customer-centric.** The job exists to solve a customer's problem, not to deliver a ticket. That orientation has to be built into the role definition, not assumed.
**Outcome-focused.** Measured by results, not by output. What actually changed for the customer — not how many tasks were closed.
**Problem solvers.** Someone needs to hold the full context and make judgment calls. The "give me a ticket, I'll do my part" arrangement is over in roles where AI now handles the routine.
**Flexible.** The work environment will keep changing. That's the new baseline. The job in 2027 may look different from the job in 2026. Comfort with that is a job requirement.
**Self-managing.** Knowing what to work on — and when to switch — without waiting to be told. AI removes a lot of management overhead, but only if the person doesn't recreate it by needing constant direction. Self-management is what makes autonomy productive.
**Ready to work alone — and smart about when not to.** AI handles much of what you used to need a colleague for. But people who disappear for weeks on the wrong problem, or never surface what's stuck — that's a judgment gap, not a tools gap.
## The two mandates
In 10X ORG, we frame this through **two mandates**: the **skills mandate** — how broad and complete a person's capabilities are — and the **work mandate** — how much of the outcome they actually own ([explored in depth here](/post/teams-and-scope-of-skills-mandate)). The AI-Partnered Worker needs both to expand. Narrow skills on narrow tasks is where AI displaces. Broad skills on full outcomes is where it amplifies.
This profile is already emerging in some organizations under a specific name: the **forward deployed engineer** — someone with full technical depth who works directly with customers, deploying, adapting, problem-solving on the spot. No ticket queue. No handoff chain. Both mandates expanded. It's the same pattern as the [Super IC](/post/super-ic-trap-guild-hypothesis): when AI makes individuals more complete, the org shifts from coordinating fragments to converging whole craftspeople.
That's the preview of where this goes.
## The rehire conversation
The people you have now were hired for different times, different needs, different jobs.
Be transparent about that. And be radical enough to act on it.
Define the new profile clearly. Then invite your people to join the future — genuinely, not as a formality. Offer retraining programs. Offer coaching and support. Give people a real path into the job as it is now.
Don't drag anyone there alone. Let them decide.
Be humane. Be nice. But be clear.
That's the rehire.
---
# When Contributors Are Complete (1/2): The Super Individual Contributor and the Guild Hypothesis
**Date:** 2026-06-29 · **Reading time:** 6 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/super-ic-trap-guild-hypothesis
**TL;DR:** AI restores the end-to-end craftsperson — a Complete Super Individual Contributor (IC). But whole individuals alone aren't an organization. The medieval guild shows what they still need — quality, learning, reputation — and where even that falls short.
A shoemaker in fourteenth-century Florence made the entire shoe. Cut the leather, shaped the last, stitched the sole, finished the edges. He was a specialist — nobody confused a shoemaker with a blacksmith — but inside his craft, he was whole. He owned the work from raw material to finished product.
Nobody micromanaged the craftsmen into splitting the shoemaking process into phases and components and assigning individuals to work on those parts alone.
Software followed the same arc. In the 1960s and 1970s, a programmer was a craftsperson. You took a problem, understood it, designed the solution, wrote the code, tested it, deployed it. You owned the whole thing. The craft was whole.
Then came the pin factory.
## The 200-Year Detour: The Pin Factory
Adam Smith's pin factory is where the modern story begins. One worker draws the wire, another straightens it, a third cuts it, a fourth sharpens the point. Eighteen operations, eighteen specialists. Productivity explodes — but any one of those workers, pulled out of the line, cannot make a pin.
The industrial revolution did this to everything. For two hundred years, the dominant organizational logic has been fragmentation: break complex work into narrow tasks, assign specialists, coordinate through hierarchy and process. The factory model.
Adam Smith said: "Concentrating each worker on a single subtask often leads to greater skill and greater productivity than if each worker tried to make a whole product on their own". And then he showed more than 1'000-times improvement to the pin manufacturing when using the single-worker paradigm.
Following this claim, many crafts were Shattered.
## How the Software Craft Was Shattered
Three forces broke software into fragments:
**Scale.** Systems outgrew what one mind could hold. Mainframes gave way to distributed architectures, and distributed architectures demanded people who could think about databases, networks, UIs, and business logic separately.
**Taylorism.** The factory metaphor infected software. Waterfall is literally an assembly line: requirements → design → implementation → testing → deployment. Each phase owned by a different group. The org chart became the production line.
**Vendor economics.** Oracle DBAs. Microsoft stack developers. Cisco network engineers. Platforms created captive niches, and those niches became careers. The vendor's business model shaped the profession's structure.
By the early 2000s, delivering a single feature might require a business analyst, a UX designer, a frontend developer, a backend developer, a database administrator, a QA engineer, and an ops person. Seven people touching seven fragments of one thing.
*Are you working in a pin factory?* –— our famous quote in the [10X ORG book](https://10xorg.com/).
## The Agile Cure
Cross-functional teams were the fix. The Agile movement recognized that fragmentation was the disease and tried to reassemble the craft inside a team boundary. Put all the specialists in one room, give them a shared backlog, let them self-organize. The team becomes the unit that can deliver end-to-end — even if no individual inside it can.
It worked, to a degree. A well-formed cross-functional team delivers faster and with fewer handoffs than a collection of functional silos. Scrum, Kanban, XP — these approaches made fragmented organizations more effective at coordination.
But they didn't restore the craft — because the fragmentation was baked into the org design itself. Scrum perhaps went the furthest, with its strong push for multi-learning within a team. But we know how that story goes. The team members largely stayed narrow specialists, reinforced by the career paths built around them. The team was the whole; the people were the parts.
What made it harder still: many organizations treated agile as a team-level improvement. So instead of optimizing the whole product, they assigned teams to lanes and locked them there.
And the teams were [locked in lanes](/post/how-adaptive-are-team-topologies). Each [stream-aligned team owned its domain](/post/whole-product-focus-team) — search, payments, checkout. Efficient inside the lane. But when demand shifted, when the market moved, when a cross-cutting opportunity appeared — the convoy couldn't scatter and reform. This is [the Ferrari Trap](/post/the-ferrari-trap) applied at the team level: faster inside the lane, paralyzed between lanes.
How does the saying go in systems thinking? "The cure can be worse than the disease." This was perhaps exactly that.
## AI Makes the Individual Whole Again
Large language models and agentic AI tools are collapsing the specialization gradient. A developer with Claude or Copilot can write frontend and backend, design a database schema, draft tests, configure CI/CD, write documentation, and handle deployment — competently, in a single session. They can even open up an unfamiliar repository and figure out how to change it — learning the codebase alongside the AI. Not because the developer became a polymath overnight, but because the AI fills the specialist gaps in real time.
We are seeing the return of the end-to-end craftsperson. Not the generalist who does everything poorly — the augmented craftsperson who does the whole thing well, with AI as the master's toolkit. And not just shipping code — working end to end on a complete customer problem. That's a jump straight to the top-right quadrant of the [Org Topologies map](/post/org-topologies-key-archetypes): Driving Intelligence.
This isn't speculation. It's happening. Solo developers are shipping full products. Small teams are building what once required departments. The "super individual contributor" (Super IC) pattern — a single individual plus AI doing the work of a small team — is already a recognized mode of production.
And this raises a question that goes beyond AI as a technology — to its implications for organizational design:
**If the individual is whole again, what are the teams and organization for?**
## The Guild Hypothesis
The naive answer is "we don't need teams." That's the Super IC trap — the fantasy that organizations become collections of autonomous individuals, each shipping their own thing. It sounds liberating. And when your product is a shoe, it perhaps makes a lot of sense. But in product R&D — at small scale and large — it inevitably produces local optimizations, waste, and even chaos. And worse: people inside the organization stop understanding what's being built. Organizational learning stops.
Is there something we can learn from the medieval shoemakers here?
When every craftsperson was end-to-end, they didn't work alone. They formed guilds. And guilds existed for exactly the things that end-to-end craftspeople couldn't provide individually:
**Quality standards.** The guild set the floor. A master's stamp meant the work met a known standard. Without it, every buyer assessed every craftsperson from scratch. The guild was a trust infrastructure.
**Training and learning.** The apprentice-journeyman-master pipeline ensured that knowledge transferred across generations. No individual craftsperson could reproduce the profession alone. The guild was the learning organism.
**Reputation and market access.** The guild's collective name opened doors that no individual name could. Buyers trusted the guild, and that trust flowed to its members. The guild was a brand.
**Innovation diffusion.** New techniques spread through the guild network — across workshops, across cities. A discovery in one workshop became common practice across the profession. The guild was the knowledge network.
**Collective negotiation.** Trade rights, pricing, workspace access — these were guild-level conversations. No individual craftsperson had the leverage. The guild was the political actor.
None of these are production functions. The guild didn't coordinate who makes what. It created the conditions under which individual craftspeople could be trusted, could learn, could access markets, and could improve.
**My hypothesis: when AI makes individuals whole again, the organization itself becomes a guild.**
Perhaps, in some way, this is true. Not "teams become guilds." The organization. The entire structure shifts from coordinating fragments of production to providing what whole craftspeople need from a collective.
This maps directly to what we call the Adaptive Topology in [Org Topologies](https://www.orgtopologies.com/). The factory is the Resource Topology. Agile teams are the Delivery Topology. The guild is the Adaptive Topology — seen through a new lens.
## Where the Guild Is Enough — and Where It Isn't
A consulting firm is a guild, and it works. Each consultant takes their own engagements end-to-end. The firm provides reputation (the name opens doors), quality standards (up or out), learning (training programs, knowledge sharing), and market access (the sales machine). The work is genuinely independent — my engagement doesn't depend on your engagement shipping first. Privateers with separate destinations? Fine. The guild functions are all they need.
But product R&D has shared outcomes. My search improvement is useless if your checkout breaks. The user experiences the product, not the individual contribution. The work is interdependent by nature — not because we chose to make it so, but because the customer demands coherence.
Here are some basic heuristics:
- **Independent work** (consulting, freelancing, research labs) → Guild is enough. Privateers work. Each ship has its own destination.
- **Interdependent work** (product R&D, integrated systems, platform companies) → Guild is necessary but not sufficient. You need the flotilla.
Most of my clients adopting AI are in the second category. And that's where the guild gap bites.
## The Guild Gap
Consider a small robotics startup. Ten people, all AI-augmented, all capable of working end-to-end. Each one is a whole ship — independently navigable, independently capable. They have the guild functions: shared standards, a learning culture, collective reputation.
But they're privateers. Each capable vessel sailing roughly the same waters, serving roughly the same customers — yet without shared intelligence, without formation discipline, without the infrastructure that makes autonomous action converge on shared outcomes.
The guild answers "why do whole craftspeople need an organization?" Quality, learning, reputation, knowledge networks. Good. But it doesn't answer "how do they align on product outcomes?" And inside a product R&D organization, that second question is the one that determines whether you ship something coherent or a portfolio of individual brilliance that never adds up.
Here is what the gap looks like from inside a team. A practitioner watching an agentic engineering team described it like this: the team felt a fear of missing out — everyone shipping fast, nobody quite sure what the others had built. The obvious fix? Generate an AI podcast of the commit log so everyone could catch up.
But that only addresses outputs. It says nothing about outcomes — what customers are actually doing, how the business landscape is shifting, whether the product strategy still holds. None of that is answered by a better feed of what got built. It needs people to gather and talk it through.
That's the guild gap, named precisely. Everyone is complete. The output layer is humming. The outcome layer — customer behavior, business signals, strategic re-prioritization — stays manual, stays conversational, and gets crowded out by the sheer volume of individual production.
The traditional answer is ["aligned autonomy"](https://www.orgtopologies.com/post/aligned-autonomy-at-scale) — treat alignment and autonomy as two independent dials, find the sweet spot, give teams a North Star and let them run.
But I feel this is the wrong frame. Alignment isn't a dial you turn up when you sense it's lacking. It isn't something you impose on top of structural misalignment — it's something that must emerge from the structure and the way of working.
But how?
---
That question is the whole of Part 2. If the guild explains why whole craftspeople still need an organization, the next piece explains how to keep them well-connected — so that whatever they work on autonomously plays into the grand scheme of things naturally. Without an imposed hierarchy. But with a joint pulse.
**Continue → [Extreme Cocreation and the Product Pulse (2/2)](/post/flotilla-extreme-cocreation)**
---
# When Contributors Are Complete (2/2): Extreme Cocreation and the Product Pulse
**Date:** 2026-06-29 · **Reading time:** 7 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/flotilla-extreme-cocreation
**TL;DR:** A guild of whole craftspeople produces privateers, not a fleet. The flotilla — guild plus shared intelligence — and the Product Pulse turn autonomous work into a shared direction.
In [Part 1](/post/super-ic-trap-guild-hypothesis), AI made individuals whole again — the Super IC — and a collection of whole craftspeople turned out to be a guild. The guild gives them quality, learning, reputation, market access. But it left a gap: everyone complete, the output layer humming, and nobody converging on shared outcomes. Whole ships, no fleet.
So we ended on the question: what if alignment isn't something you impose — but something that emerges from structure? Here's the answer.
## From Guild to Flotilla
Think about how a navy organizes its ships.
**The battleship** is the factory. One massive vessel, centralized command, everyone at a narrow station. The admiral commands every action from the bridge. Incredible concentrated firepower — but slow to turn, and if a torpedo hits the engine room, the whole thing sinks. This is the Resource Topology at sea.
**The convoy** is the agile organization. Ships in formation, each with a clear role and a clear lane. The convoy moves from A to B efficiently. But it moves at the speed of the slowest vessel. The escort can't suddenly carry cargo; the tanker can't fight submarines. When the route needs to change, the entire formation must turn together. This is the Delivery Topology — the Demand Ceiling on water.
**The flotilla** is something else. A fleet of small, self-sufficient vessels. Each one carries its own navigation, propulsion, communications, and armament. Not a miniature battleship — a whole ship, designed for independence.
The flotilla commander sets direction: "Control this strait" or "Find and engage the threat." Not "Ship 3, turn to heading 270, fire at grid reference 4-7." Each captain navigates their own water. They scatter when the situation demands it. They converge when mass matters. They enter shallow coastal waters the battleship can't reach.
What holds the flotilla together isn't hierarchy. It's shared intelligence. Common charts. Real-time signals. A shared understanding of the mission that makes coordination emerge from autonomous action rather than requiring it through command.
This is the [Adaptive Topology](/post/org-topologies-key-archetypes) at sea.
And the privateers — our guild without a flotilla — are whole ships without the shared intelligence layer. Each one is excellent. None of them converge.
## The Platform of Shared Intelligence
The flotilla doesn't work because an admiral tells each ship what to do. It works because the infrastructure — shared charts, signals protocol, common mission brief — makes autonomous decisions converge by design. Alignment isn't imposed post-factum. It's baked into the conditions.
[Haier figured this out at scale](/post/studying-org-designs-haier-rdhy-bayer-dso). Four thousand micro-enterprises, each autonomous, each capable of forming temporary partnerships. They don't have "aligned autonomy" as a management philosophy. They have a digital platform — shared data, user-facing metrics, contracting mechanisms, idea-pitching processes, time-bounded ventures. The platform doesn't tell micro-enterprises what to do. It creates the conditions under which their autonomous actions converge on customer value.
Software engineers will recognize this pattern instantly. AI-augmented craftspeople are microservices — self-contained, independently deployable, each owning its own logic and data. The guild is the service registry and shared protocols: health checks, quality standards, discovery. But [microservices without orchestration produce chaos](/post/microservices-are-technical-debt). Each service works fine in isolation; the user experience is incoherent. You decomposed the monolith — good. You forgot to build the platform — fatal.
Here the microservices analogy breaks — and that's the point. The platform that turns craftspeople into a flotilla isn't a piece of technology. It isn't Kubernetes routing traffic between services, and it isn't a tool that assigns tasks. Microservices coordinate by passing messages: each does its job, hands off the result, and never needs to understand the whole. People aren't like that. What connects whole craftspeople is shared understanding — a common read on the customer, the strategy, the stakes. And building that understanding is itself creative work; it happens when people think together, not when a system passes a message from one to the next. The platform is social before it is technical.
The guild addresses the broader discipline concerns: quality, learning, reputation, standards.
The platform of intelligence provides the immediate context: signals, metrics, dashboards, shared understanding, a space to cocreate, a human rhythm.
Neither is alignment-as-correction. Both are structural conditions. Together, they turn privateers into a flotilla — coherent enough to take on larger challenges, yet with the dynamic coupling and decoupling that lets fast, independent, AI-augmented individuals do their own work.
## Extreme Co-Design
NVIDIA runs on something Jensen Huang calls *extreme co-design*. He keeps around sixty direct reports — no compact "leadership team," no cascade of intermediaries filtering the picture. The reason is structural, not stylistic: a modern GPU can't be optimized one layer at a time. Memory, compute, optics, cooling, networking, the software stack, and the algorithms running on top all constrain each other. Tune the silicon in isolation and you leave performance on the table at the system level. The only way to reach the global optimum is to co-design every layer at once — in the same room, with the people who own each layer fully present.
That is not coordination. Coordination is what you do with fragments: hand-offs, contracts, integration meetings to reconcile parts built apart. ([A phased SDLC — even one called a sprint — does exactly this](/post/jul-google-sdlc-critique).) Co-design is the opposite — whole experts, each holding a complete perspective, working a problem whose constraints are too entangled to split first and assemble later. No single brain holds all the constraints at once, so you put all the brains in one room and let the design emerge from their collision.
This is the human shape of what AI now makes possible everywhere. Once individuals are whole again — augmented, end-to-end — gathering them isn't about filling skill gaps. It's about holding a constraint space no one of them can hold alone. That's what I call **extreme cocreation**: not the coordination of fragments, but the collaboration of whole craftspeople on a problem that demands multiple complete perspectives at the same time.
## Recap: History Is Not the Past
Let me recap the evolution — and decomposition — of the craft as we've witnessed it so far.
1. **The Pin Factory shatters the craft** — narrow tasks, specialists, hierarchy coordinates production (200 years) — and still wired into the management systems of most organizations today
2. **Agile teams reassemble fragments** — the convoy. Cross-functional delivery, efficient in lanes, locked between them
3. **AI restores the craft to individuals** — the guild returns. Whole craftspeople, but the organization hasn't caught up
4. **Guild alone produces privateers** — the guild gap. Whole ships, no fleet. Quality and learning but no convergence on outcomes — a novel problem to have: before, we were too dependent and blocked; now we're free, roaming in different directions. New times, new problems
5. **The Product Pulse** — when what the guild offers isn't enough for coherent work, Super ICs adopt a merge–diverge rhythm: merging is a short interval to slow down, talk, challenge assumptions, build joint theories, and prioritize — then they diverge again
## The Pulse
Inside the flotilla, work follows a rhythm. Not permanent teams, not permanent solo work — a pulse.
**Solo craft** is the default mode. The augmented individual delivering end-to-end. This is where most work happens.
**Co-design assembly** kicks in when the problem exceeds one person's cognitive bandwidth — when the constraint space is simply too large for a single head. This is extreme cocreation in motion: whole craftspeople convening not to divide the work, but because the work can't be divided yet.
**Decompose and return.** After the co-design session resolves the constraint space, individuals take their pieces and execute in solo mode again.
Solo → gather → co-design → decompose → solo. The permanent team disappears. What replaces it is this rhythm — the pulse of the flotilla. Ships scatter, ships converge, ships scatter again. The stable structure isn't the formation. It's the fleet.
The word matters. Machines run continuous processes. Living things pulse. Heartbeat, breathing, circadian rhythm — biological systems alternate between states. Systole and diastole. Inhale and exhale. The pin factory never pauses; it's a process. The flotilla pulses; it's an organism.
**The Product Pulse** — [an idea I first floated on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7465500579440709632/) — names the specific gathering triggered by outcome drift. When individuals are producing fast — AI-augmented, end-to-end capable — the output layer hums. But something starts to decay: the shared understanding of what customers are actually doing, what the business landscape is signaling, and where the product direction should actually go.
This is the Fabian problem: a team generating FOMO about commits, reaching for a "podcast of the commit log" to stay synchronized — when the real gap isn't what people built, but whether any of it moved the needle on customer outcomes. And it's the production-speed-outruns-alignment-speed problem: two rooms, one fast and one slow. The fast room builds while the slow room — strategy, customer insight, direction — tries to keep up, often failing to until alignment is forced at a code review or a sprint demo.
The Product Pulse closes this gap. Not by slowing the fast room down — by making the outcome layer keep pace. Complete workers bring what they observed in solo mode: a customer pattern, a business signal, an assumption that cracked under contact with reality. The group synthesizes it, the shared intelligence updates, and the fleet stays coherent. No manager required to translate between business and engineering; the people doing the work are close enough to the customer to read the signals themselves.
Lighter than a sprint review, more pointed than a strategy offsite. A recurring rhythm — the heartbeat of the shared intelligence layer that keeps the guild from fragmenting into privateers who each build brilliant things that never add up to a direction.
It's not another meeting to restore lost alignment. It's a platform that makes autonomy valuable — the structure that ensures individual capability adds up to something.
Without it, whole individuals become privateers — brilliant, fast, each sailing in their own direction. The pulse is the force of gravity that turns them into a fleet. A powerful flotilla that follows the wind — together, in the same chosen direction, exploring new lands, hunting for treasures, and showing the best of joint intelligence.
## We Don't Need Teams Anymore, Right?
Not quite. That's a false choice.
There are times when you need to work alone — and now, because we can be complete at solving customer problems end to end, there will be more of them. Individual contributors will increasingly enjoy solo problem-solving: the whole person, close to the customer, the distance shrunk to zero. This is what Scrum and XP were reaching for all along.
But if the product is bigger than any one person's contribution, there will still be important moments when the team gets together — not to coordinate work or untangle dependencies (those barely exist anymore), but to address common concerns, discuss business, share what they've learned, work through the hard challenges, and arrive at a joint strategy.
**I claim that in the AI-era, we will start seeing stronger teamwork and better teams.**
When everyone is a complete craftsperson with a strong connection to the reality (users, market, feedback), the team becomes a home for group intelligence——the place of co-creation and learning.
*Missed the setup? Start with [The Super IC Trap and the Guild Hypothesis (1/2)](/post/super-ic-trap-guild-hypothesis).*
---
# Extracting and Scaling Intellectual Assets with AI
**Date:** 2026-06-17 · **Reading time:** 3 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/jun-ghosttown-intellectual-asset
**TL;DR:** You can't copy an expert's time. But you can copy the way they reason — and that part can be shared. That's the Intellectual Asset.
[Ghosttown](https://github.com/krivitsky/ghosttown) is an open-source project for extracting expert voices and reasoning patterns from public corpora — mailing lists, newsletters, LinkedIn posts. You open it in Claude Code, point it at an expert's writing, and get a Ghost you can talk to.
I just added John Cutler to the list of ghosts. Of course, it is nothing like John and his wisdom, just an echo of his tone. But what if we could go further and learn not only what experts say, but also how they reason about things? Would AI then be more helpful in making strategic decisions?
## The easy part — a demo
Copying how someone talks is the easy part. It makes a nice demo. Here is what that looks like in Ghosttown. You activate a ghost and ask it anything:
```
/ghost-me trump
explain me this repo https://github.com/openclaw/openclaw
```
**Trump:**
> *Look, I know repos. I know GitHub, okay? Some people don't know GitHub — I know GitHub very well. The best people tell me about it.*
>
> *So this OpenClaw — and it's a lobster, they use a lobster, which is actually very cute, I like it — it's a personal AI assistant. Runs on your own computer. Very smart, actually.*
>
> *And you know what's beautiful about it? It's YOUR assistant. Not Google's assistant. Not some RIGGED system where they read all your messages. Yours. On your device. That's America First thinking right there, okay?*
Funny. And it works. But it doesn't make a business. The real value is somewhere else.
## The real prize
An expert's judgment lives in one person's head. It can't go beyond what their calendar allows, and it's gone the day they quit. You can't copy their time. But you can copy the way they reason — and that part can be shared.
This connects to something I've written about before: AI [doesn't replace people, it replaces tasks](/post/ai-replaces-tasks-not-people) — but only when the organization is designed to let expertise flow. A Ghost is one way to make that happen.
## The Ghost
Picture the one engineer who understands the whole system. At 2am, or when ten people need them at once, they're not around. **The Ghost is.** It doesn't replace them. It covers the moments they can't be there.
The real question changes. Not "can it sound like me?" but "can it reason like me?" Show it an org chart or a tough decision. Does it see the problem the way the expert would? Does it spot what's broken, find where things get stuck, and say what to fix first?
## The Intellectual Asset
Those thinking patterns are the real prize. We call them the **Intellectual Asset** — IA for short.
An IA isn't a fact about the company; it's a rule the expert carries from one job to the next. "We have 500 employees" is just a fact. "Once you pass about 300 people, decisions slow down unless you do X, Y, Z" is an IA — a rule that works on any company, not just this one. The expert's methods, rules of thumb, and mental models are the asset. The Ghost is just how you reach it.
This is also where [routine and adaptive expertise diverge](/post/routine-vs-adaptive-expertise) — what makes an expert irreplaceable isn't their ability to repeat a process, it's the judgment they've developed across contexts.
Extracting an IA takes four passes over the expert's writing: first, their **rules of thumb** (if X then Y); then the **principles** behind those rules; then their consistent **biases** and stances; finally, **voice** — how they frame and deliver it. Strip those four layers out and you have something that holds up on new problems, not just the ones it was trained on.
The test is simple: a Ghost built from the IA should tackle problems the expert was never asked about — and still reason the way they would. If it can't do that, it's a quote machine, not a Ghost.
These are my thoughts behind Ghosttown.
## The ladder
There are four layers here, and most projects stop at one:
| Layer | What it copies | Status |
|---|---|---|
| 1 — Voice | How the person talks | ✅ This repo |
| 2 — Persona | How the person reasons | 🟠 This repo (MVP) |
| 3 — **Intellectual Asset (IA)** | Their methods, rules of thumb, mental models | Pipeline starts this |
| 4 — Institutional Ghost | The IA plus a company's own data | Future |
Ghosttown is the first step — a small, copyable example that shows the idea works. The four-step extraction process (rules of thumb → principles → biases → voice) is how we pull an expert's IA out of their writing.
The first sign it's working is how much it packs into an answer. If it says 2–4× more per word than plain Claude on the same question, it's really using the expert's judgment, not just copying the style. Craig Larman's ghost hits 3× in early evals — also available as a separate repository: [Craig as a Service](https://github.com/krivitsky/craig-as-a-service).
Toy with it, fork, add your content, expand: [ghosttown on GitHub](https://github.com/krivitsky/ghosttown).
Be my ghost.
---
# AI Impact = Fluency × Flow × Fit
**Date:** 2026-06-04 · **Reading time:** 3 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/fluency-flow-fit
**TL;DR:** Organization-wide AI impact isn't just AI fluency of the individuals. It's Fluency × Flow × Fit — a multiplication, where your weakest layer caps the result.
Many organizations right now are focused on getting individuals up to speed with AI — fluent with Copilot, prompts, agents, slash commands. For most of us, these tools are new, and we all need some help building fluency with them every day.
But to achieve organization-wide impact with AI, individual fluency usually is not enough.
**AI Impact = Fluency × Flow × Fit.**
Let me explain:
**Fluency** is personal: can you actually put AI to work in your own job, end to end? It's the layer everyone's on right now — and almost the whole training budget goes here.
**Flow** is about the system: can the work you produce reach 'done' without a human becoming the bottleneck? This is the layer of pipelines, reviews, tests, and handoffs — the path your work has to travel once you've made it. When it's weak, AI writes the code in minutes, then waits for hours or days in someone's review queue. Flow isn't a skill you can teach a person — it's a path you have to [redesign for](/post/two-wings-of-a-10x-bird).
**Fit** is the match between the organization's shape and the value it's meant to produce. Does its structure allow work to flow into real outcomes, and do people's jobs, as they are defined, aim at what the customer needs? When the shape fits the work, [local speed turns into organizational performance](https://10xorg.com). When it doesn't, you just make the wrong thing faster.
To make it simple: fluency is person-to-tool, flow is system-to-work, fit is organization-to-value.
**AI Impact = Fluency × Flow × Fit.**
That × is the whole point. Multiplication, not addition, so the weakest factor sets the ceiling, not your strongest. (I've mapped the same three layers as nested loops in [The Value Factory](/post/value-factory-nested-loops).)
Most of my client work starts at Fluency, then we move on to Flow and Fit — because that's where the real leverage lies, where individual speed either becomes [organizational performance](/post/ai-native-startups-100x) or quietly disappears.
So which of your three is lowest right now — and what's it capping?
---
# Agentic Factory: Which Level Are You Automating?
**Date:** 2026-06-02 · **Reading time:** 5 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/value-factory-nested-loops
**TL;DR:** Coding Loop, Feature Loop, Impact Loop — three nested agentic loops. Most agentic tools stop at the middle. The outer loop is the one that matters.
Yesterday I got a chance to participate in an insightful webinar by Benedikt Stemmildt, *"Don't build features, build factories."*
Benedikt was very clear in the very beginning that he didn't like the term **feature factory**. I agree it carries a weight, as it is used to contrast intelligent value-adding to mechanically factory-like outputting of stuff.
I agree. And that got me thinking, so I had to reconceptualize the factory thing. Below is my take.
Agentic AI systems operate through **nested work-and-learning loops**.
## 1) Coding Factory
The innermost loop is the **Coding Loop**, where agents (AI and in older times human programmers) optimize implementation quality through rapid feedback cycles such as Red → Green → Refactor. This loop is excellent at producing working tested code. Yet having only one loop, such a Coding Factory can optimize toward technically correct irrelevance, as more code doesn't mean more value.
This is the same trap I described in [The Ferrari Trap](/post/the-ferrari-trap) — a faster engine doesn't help if it's pointed at a wall.
## 2) Feature Factory
The next level system is the **Feature Factory**, which adds a Feature Loop (on top of a Coding Loop): Refine → Specify → Verify. This is where behaviors, workflows, and executable specifications emerge.
As of mid year 2026 all current "agentic product development" systems describe this level of AI automation. They become highly efficient factories capable of generating and validating functionality at scale. However, obviously feature optimization alone does not guarantee meaningful outcomes either, so here **humans are required to operate the factories**, directing and ensuring the value. It's the same gap I keep circling in [Pair Programming in the AI Era](/post/pair-programming-in-the-ai-era) and [AI-Native vs. AI-Augmented](/post/ai-native-vs-ai-augmented).
## 3) Impact Factory
Adding the outermost **Impact Loop**: Opportunity → Hypothesis → Impact turns the system into a real Impact Factory.
The external loop continuously learns from real-world effects and redirects the lower loops toward meaningful goals.
Imagine three concentric feedback systems in motion: at the center, code rapidly iterates toward correctness; around it, features evolve toward usability and coherence; and at the outer edge, real-world signals continuously reshape priorities based on measurable impact. Each loop feeds constraints and learning inward, while insights from the inner loops propagate outward, creating a **living adaptive system** rather than a linear production pipeline.
In this model, a common "Feature Factory" is not the final stage of agentic AI maturity — **it is only the middle layer.** The progression from Coding Factory to Feature Factory to Impact Factory reflects an expansion in what the system is capable of learning from: first implementation correctness, then behavioral usefulness, and finally real-world impact. (I've written before about how [AI amplifies whatever trajectory your org was already on](/post/ai-native-startups-100x) — a Feature Factory with no Impact Loop is that amplification made literal.)
Each outer loop constrains and guides the inner loops, ensuring that local optimization contributes to broader objectives rather than drifting into isolated efficiency.
Truly adaptive agentic systems require all three nested loops: code optimization, behavioral optimization, and outcome optimization.
To learn more about building these levels with an 8-tier model for mastering agentic product engineering, see the [Agentic Engineering Guide](https://agentic-engineering.guide/).
---
# Specialization, Generalization, and Who Gets to Be Complete
**Date:** 2026-06-02 · **Reading time:** 5 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/specialization-generalization-demand
**TL;DR:** Specialize when demand is infinite and stable. Generalize when it's dynamic. AI is washing away the stable narrow demand in software — but the org chart decides who's allowed to be complete.
**Specialization makes perfect sense when you have close to infinite demand for that skill. Generalization makes sense when you want to serve a dynamic, broader demand.** It is that simple.
Should doctors operating on knees also do hips? No. Why would they? There is an infinite demand of misplaced meniscus and torn ACLs. Should a neurosurgeon also set broken bones? No need — there's more than enough demand to fill a career ten times over.
Must a classical pianist also learn to play other instruments? Not required. There are more piano tunes than she can ever play in her lifetime.
What about a backend Java developer? The one that is on a payment team? Should she stay in that narrow niche?
Well, it depends. Depends on the stability of the demand. And historically perhaps it used to be more or less stable. Or we thought it was — and we covered the fluctuations by making up work. But that worked well for a while.
As a result the ultimately holistic discipline of **software engineering** got artificially split over time into dozens upon dozens of micro-specializations.
Now I see the pendulum is accelerating the other way.
In the age of AI / agentic engineering almost anyone can open almost any repository, prompt an architectural diagram, figure out how to run tests, build, deploy, add missing coverage — and eventually make necessary changes. The stable narrow demand that justified "I only do payments in Java" is collapsing. The **sand castles of narrow career paths** are being washed away. (It's the same shift I traced in [AI Replaces Tasks, Not People](/post/ai-replaces-tasks-not-people) and [Routine vs. Adaptive Expertise](/post/routine-vs-adaptive-expertise).)
But here's the thing that bothers me the most: **the individual can't generalize if the organization won't let them.** A developer ready to work end-to-end hits a wall when the org chart still carves work into component teams, hands it through queues, and measures people by role, not outcome. **The structure — not the tooling — determines who gets to be complete.** I keep running into this same wall in [The Super IC Trap](/post/super-ic-trap-guild-hypothesis) and in the [Multi-Learning org design pattern](/post/multi-learning-org-design-pattern-ai).
For those few domains with genuinely infinite demand — designing and training LLMs, perhaps — specialization holds. For the vast majority of software engineers, radical broadening is already necessary.
Perhaps, you don't like the term "generalist"? Call it **broad specialist**. The label doesn't matter. What matters is: does your organization allow it?
We're entering a world where makers can finally be complete. The question is whether your org will let them — or keep slicing the work into pieces no one person is allowed to finish. You can hear the same tension in [why roles built on artificial scarcity are getting squeezed](/post/why-scrum-masters-are-getting-fired).
---
# Vibing or AI Engineering? A Spectrum for Personal Growth
**Date:** 2026-05-30 · **Reading time:** 3 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/vibing-or-engineering-spectrum
**TL;DR:** Vibing feels like a slot machine — drop a prompt and hope. But it's a spectrum, not two camps. Used right, AI isn't a slot machine but a gym with a coach.
There seem to be two camps. On one side, **vibing**: you treat the AI like a slot machine. Drop a coin — a prompt — pull the lever, and hope for magic. Sometimes the cherries line up; often they don't, so you feed it another coin.
On the other side, **agentic engineering** as a serious craft: design, guardrails, lifecycles, tests — things you can maintain and extend.
Most people read these as opposites. Black or white. You're either gambling or engineering.
I prefer to think of it as a **spectrum**. You can sit closer to either end, and the right place depends on the task — its complexity, and the maintainability and extensibility you actually want. A throwaway script and a system you'll live with for years don't deserve the same spot on the line.
And here's the part I find exciting and human-centric: even if you start by vibing (which I often do), you can ask the AI to explain what it just generated. Name its assumptions. Explain the technology. Drill deeper into the terms you don't know. Prompt it to sketch you a diagram.
So the random process of finding luck turns into an **intentional learning process**. And each prompt is now a step toward engineering.
So maybe that "spectrum from vibing to engineering" is just another word for depth of skill. And skill isn't binary — it's something we grow over time. Which flips the metaphor on its head. Used this way, the AI isn't a slot machine at all. It's a **training machine — a gym**.
So perhaps the real question isn't where you are on the spectrum at the very start, but whether you're using the machine to gamble, hoping for a sudden breakthrough — or to grow strength one step at a time. And to build on the sport metaphor: AI can be a [great coach with infinite patience](/post/ai-augmented-multi-team-pbrs).
---
# AI-Native, AI-Augmented, AI-Sprinkled: The Three AI Strategies That Explain the Performance Gap
**Date:** 2026-05-28 · **Reading time:** 4 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/ai-native-vs-ai-augmented
**TL;DR:** Three AI strategies: 100X (AI-native, clean-slate), 10X (AI-augmented, deliberately restructured), 1X (AI-sprinkled, same structure + tools). Most companies think they're at 10X. The performance gap is striking.
These terms aren't absolutely defined. They get redefined daily — by analysts, vendors, whoever is presenting the slides. In my consulting work, I use all three as distinct levels, because I see real differences between the organizations they describe. This is a short article to lay down those three definitions — the kind that are useful when a conversation needs to go somewhere concrete.
## The Three Levels
**100X — AI-native.** Built from scratch with AI as a first-class assumption. No legacy structure, no mandate pinning, no coordination overhead inherited from a pre-AI era. Anthropic's release cadence in Q1 2026 — major model improvements and new capabilities shipped consecutively across weeks — is a visible data point. A company structured for AI from the start moves at a pace that restructured organizations can observe but rarely match. These organizations are the [new performance benchmark](/post/ai-native-startups-100x) — not a future threat, a present competitive fact.
**10X — AI-augmented.** A legacy organization that has been deliberately restructured for AI. Not because it swapped tools, but because it changed structure: broader mandates, fewer handoffs, people following value instead of defending their assigned lane. This is what compound gain looks like in practice — AI tools multiplying across an expanded mandate rather than accelerating a narrow one. Getting here requires structural work. The [subsidized token era masked who had done that work](/post/subsidized-tokens-are-ending).
**1X — AI-sprinkled.** Same structure, same team formation, same coordination habits — with AI tools added on top. Copilot on every machine. AI-assisted PR reviews. Ticket summarization. Individual developers move faster. The system-level performance difference between this and 10X is striking — AI amplifying the [Ferrari Effect](/post/the-ferrari-trap), not dissolving it.
## The Practical Goal
100X is the benchmark. 10X is the goal.
Getting there is a structural question: mandate width, not skill levels. The org that compounds AI owns outcomes end-to-end — it isn't the one where everyone has Copilot. [That distinction was supposed to be what agile transformation achieved](/post/agile-was-homework-ai-is-assignment). Most organizations didn't get there. The urgency to get there is higher now.
## The Diagnostic Question
Not "are you using AI?" but "has your structure changed?"
If your teams still form around the same specializations, own the same narrow component, and hand off to the same downstream queues — you're at 1X. The tools sit on top of a structure that was never designed for them. That's the [Ferrari Trap](/post/the-ferrari-trap): local speed that doesn't add up to system-level performance.
If you've deliberately redesigned for the agentic AI age — not just accelerating old habits within legacy structures — you're building toward 10X. AI tools start to compound instead of just accelerate.
---
# AI Replaces Tasks, Not People — Unless Your Org Is Designed That Way
**Date:** 2026-05-20 · **Reading time:** 7 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/ai-replaces-tasks-not-people
**TL;DR:** When your job equals the task you do, AI finishes the task and you sit idle. The fix is organizational, not technological — broaden mandates or watch displacement happen by design.
I talked to a CEO recently. He runs a 70-person company — deep learning for manufacturing quality control, video cameras on factory lines. His developers had been writing the code that trains and deploys those models. Then AI got good enough to do most of that work.
So he made them an offer: transition from developer to consultant. When AI handles the implementation, what's left for humans is understanding customer problems and driving solutions end to end.
Some developers took the offer. Some didn't.
The ones who didn't are now in an uncomfortable position. The CEO is hiring consultants externally and figuring out what to do with developers whose daily output AI can match in a fraction of the time.
This CEO is an exception. He didn't treat his developers as costs to be reduced — he saw them as potential to be developed. New titles, new mandates, a deliberately redesigned organization that offers people an elevated path when their current tasks get automated. Most companies don't do this. Most companies see the automation and reach for the headcount spreadsheet.
This is not an AI story. This is an org design story.
## The Task Trap
Think about the roles in your organization. A database designer who only touches databases. A frontend developer who only writes React. A QA engineer who only runs test suites. Each role is scoped to a single task type, and each person's identity is wrapped around that scope.
When AI arrives, it doesn't evaluate whether you're a good database designer. It evaluates whether the task "design a database schema" still requires a human at all. If your job equals the task you do, and AI can do that task, the math is straightforward.
I worked with a database designer at a company I'll call DBN. Individually brilliant. With AI, his productivity on database work went through the roof — 100X by any reasonable measure. But the organization only allowed him to do database work. He was mandated to stay in his lane. When I ran the numbers, he had roughly 297 idle days per year. There simply wasn't enough pure database work to fill a calendar, even before AI made it faster.
AI didn't create his problem. It exposed it. Narrow specialization was already a fragile arrangement. AI just removed the ambiguity.
## 100X Individuals, 1X Organizations
Peter Steinberger runs 20 AI agents in parallel. Individual developers are hitting productivity numbers that would have been career-defining five years ago. The individual AI moment is real.
But organizations are still on their old trajectory. No tests, no documentation, mountains of tech debt, the same handoffs and queues and approval chains. Gary Hamel calls this the "crack of history" — powerful new technology wielded inside organizational structures designed for a different era. The mismatch, not the technology, is the problem.
Most companies respond to AI the way they responded to agile: layer it on top of the existing structure and hope the structure doesn't notice. The paradigm stays the same; only the speed changes. More code, faster. More designs, faster. More of exactly what you were doing before, at higher velocity, on the same trajectory.
That's the paradigm trap. You need to change the paradigm first, then amplify with AI. When you amplify first and change never, you're accelerating in the wrong direction. [The Ferrari Trap](/post/the-ferrari-trap) applies perfectly here: a faster car on the wrong road just gets you to the wrong place sooner.
## The Displacement Map
This is where the Org Topologies Displacement Map becomes useful. It has two axes: Scope of Work Mandate (narrow to broad) on the vertical, and Scope of Skills Mandate (narrow to broad) on the horizontal.
The bottom-left corner — narrow work, narrow skills — is the black zone. "Space Disappearing." That's where the DBN database designer sits. That's where every role scoped to a single repeatable task sits. AI compresses that space first.
The arrows on the map point up and to the right: from Outputs to Outcomes, from Incomplete to Complete. People who move in that direction own broader work (not just "write code" but "solve customer problems") and broader skills (not just databases but the full stack of understanding needed to deliver value). The top-right quadrant is where humans remain irreplaceable — not because AI can't do individual tasks there, but because the judgment, context-switching, and problem-framing required don't decompose into automatable units.
The CEO's offer to his developers was exactly this move. He was pointing at the top-right quadrant and saying: go there. Some made the shift. Others stayed put.
## Elevation of Human Intelligence
What the CEO was describing — whether he used these words or not — is the elevation of human intelligence. You stop being an execution resource and start owning the bigger picture. On the Org Topologies map, that's the driving quadrant, where people figure out what to build, not just build what they're told.
This isn't about becoming a manager. It's about broadening what you're responsible for and what you're allowed to know. A developer who understands the customer domain, participates in discovery, owns deployment and monitoring, and can switch between value areas when demand shifts — that person doesn't have a task that AI replaces. They have a role that AI amplifies.
But here's the catch that most AI optimists skip over: the organization has to allow this move. And most don't.
## The Organizational Ceiling
Most organizations are designed to prevent exactly the kind of broadening that makes humans resilient to AI displacement. The structure keeps people in narrow task boxes. Job descriptions define boundaries. Reporting lines enforce lanes. Performance reviews measure output within a specialty, not impact across a value cycle.
When AI finishes the narrow task faster, the person sits idle, and management sees rising costs with no matching improvement. Eventually it becomes a cost-cutting conversation, and engineers get associated with costs, not value. Not because AI replaced them, but because the organization was already designed to treat them as interchangeable task-executors. AI just made the price comparison unfavorable.
This is the ceiling. Individual developers can be 100X productive, but if the organization pins them to narrow streams and measures them on task throughput, the system absorbs none of that potential. 100X individual, 1X organization. The [DORA 2026 report](/post/dora-2026-developers-faster-teams-messier) quantified this exact gap: individual developer effectiveness up, software delivery instability up right alongside it. The gains evaporate into idle time, overproduction of the wrong things, and queues that existed long before the first token was generated.
## Two Wings
The structural fix maps to two organizational capabilities — what we call the Two Wings in *10X ORG*.
**Wing 1: Full value cycle mandate.** Give people and teams ownership of the complete flow from idea to production. Not "the backend part" or "the QA step" — the whole thing. Fast-flow teams, not functional silos. When a team owns the entire cycle, AI accelerates the whole arc, not just one phase of it.
**Wing 2: The ability to switch between value areas.** As I explored in [*Two Wings of a 10X Bird*](/post/two-wings-of-a-10x-bird), Wing 1 without Wing 2 is local optimization. A search team that owns its full value cycle is great — until search demand drops and that capacity sits unused. The organization needs people who can move between value areas as demand shifts. Unpin from streams.
Management has two dials to turn: grow multi-expertise (help people broaden their skills) and unpin from streams (stop assigning people permanently to one value area). These aren't binary switches. They're dials. You turn them gradually. But the point is that management must turn them, not leave them at zero and wonder why AI investments aren't paying off.
## AI Broadens, Not Just Accelerates
Here's what gets lost in the "AI replaces jobs" narrative: AI is a broadening tool, not just a speed tool. Developers can open repositories they've never touched and navigate them with AI assistance. They can learn new domains faster, co-own systems they'd previously needed months of ramp-up to understand, and modify things they were never supposed to modify.
AI doesn't just make the database designer faster at databases. It makes the database designer capable of doing frontend work, infrastructure work, customer analysis. AI is a teacher as much as a doer. Organizations that recognize this and deliberately use AI to broaden their people's capabilities — rather than just to accelerate their existing narrow tasks — will find themselves in a completely different position.
The [multi-learning](/post/multi-learning-200-years-wrong-model) idea isn't new, by the way. It was described in HBR in the late 1980s and was actually the core idea behind Scrum before the industry buried it under ceremonies and certifications. People are the real learning machines. AI makes that learning faster and cheaper than it has ever been. The question is whether your organization allows it.
## AI Is a Threat, and a Savior?
AI can do more than accelerate your current work. It can help you broaden — acquire new skills, work across domains, own bigger problems. But only if your organization lets you. When it doesn't, you're not being replaced by AI. You're being replaced by a job description that was already too small for any human.
## Keep People, Elevate the Work
AI automates tasks. It does not automate judgment, curiosity, or the ability to sit with a customer and hear what they're actually saying.
Humans are good at talking to customers, finding problems worth solving, connecting insights across domains, navigating ambiguity, and making decisions when the data is incomplete. These are the things that create value — and they don't decompose into prompts.
The question for every company isn't whether AI will automate tasks. It will. The question is what happens to the people who used to do those tasks. Do you broaden their mandates, invest in their growth, redesign the organization so they can take on bigger work? Or do you wait until the math catches up and the conversation turns to headcount?
The CEO in our story chose elevation. Most organizations haven't made that choice yet. The ones that do will find that AI doesn't reduce the need for people — it raises the bar for what people do.
Change the company — or change the company.
---
# DORA 2026: Developers Faster, Teams Messier
**Date:** 2026-05-12 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/dora-2026-developers-faster-teams-messier
**TL;DR:** DORA's 2026 data confirms it: individual developers are measurably faster with AI, but team-level delivery is flat or worse. The 280x inference cost drop removed the technology barrier. What remains is organizational design — and that is where the ROI actually lives.
[DORA's 2026 AI study](https://dora.dev/ai/roi/report/) just dropped. It puts a dollar figure on what many of us have been feeling.
39% first-year ROI. $8.4M invested, $11.6M returned. Google Cloud customers report 727% over three years. The financial case for AI-assisted development is now officially closed.
Except for the chart on page 20.
Individual developer effectiveness is the strongest measured effect. Right next to it — software delivery instability. Second strongest. Moving in the wrong direction. Team performance barely registers. Burnout unchanged.
Developers are getting faster. Teams are getting messier.
DORA introduces the J-Curve to explain this: learning curve, verification tax, pipeline adaptation. When organizations adopt AI tools, they slow down before they speed up. The dip is real, it's measurable, and most organizations are still in it.
The greenfield/brownfield split makes the pattern concrete. 35-40% productivity gain on new code. 10% on legacy systems. Most organizations run mostly on legacy. The productivity headlines describe a world most companies don't actually live in.
This is the central argument of 10X ORG book we published in February. AI amplifies whatever trajectory your organization was already on. Cross-functional teams with clear ownership and short feedback loops see AI gains compound across the value stream. Siloed components with handoff queues see faster developers producing more code into the same bottlenecks — what I call [the Ferrari Trap](/post/the-ferrari-trap).
DORA's five organizational keys — trust, platform thinking, accessible data, user-centric focus, automated guardrails — are all structural decisions. None of them are tooling decisions.
The 280x inference cost drop since late 2022 tells us the technology barrier is gone. What remains is organizational design — [redesign first, then AI](/post/redesign-for-ai-why-transformation-requires-organization-design). That's where the ROI actually lives. The fix requires [both wings](/post/two-wings-of-a-10x-bird): full value cycle ownership and the ability to redirect capacity when demand shifts.
---
# Multi-Learning: 200 Years of the Wrong Model
**Date:** 2026-05-09 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/multi-learning-200-years-wrong-model
**TL;DR:** For six million years our brains evolved to learn across domains. Two hundred years of factory logic pinned people to single tasks. AI is automating the repetitive work that justified that pinning. What remains is exactly what our brains were built for: multi-learning.
For millions of years, our brains evolved in environments that demanded everything at once. We hunted, gathered, raised children, fought, explored territories, developed languages, and sketched on cave walls. The same brain, the same day.
This is called "multi-learning" in scientific journals, but simply put, this is how humans naturally operate.
Then, about 200 years ago, someone realized you could make more money by putting a person on a single task. Cheaper to train. Easier to replace. The industrial revolution redesigned human activity around a principle that had nothing to do with the nature of our cognition.
That was a temporary optimization. A local maximum that lasted two centuries. But these are just a blink compared to the 6 million years of evolution of our species.
Now it's ending. As I argue in [*Redesign, Then AI*](/post/redesign-for-ai-why-transformation-requires-organization-design), AI collapses the cost of learning — which erodes the very advantage that narrow specialization was built on.
AI is taking over the repetitive, routine work that justified pinning people to single tasks in the first place. And what's left is exactly what our brains were built for: learning across domains, directing, reasoning, envisioning, orchestrating, making judgment calls that no single-purpose agent can make.
Look at the best practitioners today. They're not narrower — they're broader. They sit at the center of their own organization of agents, directing work across boundaries that used to require separate departments.
In the photo on the right, it is not an AI-generated person; it is Peter Steinberger, the creator of the famous OpenClaw, carefully driving this stack of dozens (hundreds?) of AI agents working for him.
We spent 200 years suppressing our strongest capability to make the factory floor more efficient. The factory floor is automated now. And when people stay pinned to narrow tasks in this new reality, [AI doesn't replace them — the org design does](/post/ai-replaces-tasks-not-people).
Time to go back to our strength. To multi-learning at work, which we know so well from non-office hours. Organizations that embrace this shift need [both wings](/post/two-wings-of-a-10x-bird) — full ownership of the value cycle and the ability to switch when value shifts.
---
# Two Wings of a 10X Bird
**Date:** 2026-05-02 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/two-wings-of-a-10x-bird
**TL;DR:** A 10X organization needs two wings: near-zero transaction costs (no handoffs slowing the learning loop) and near-zero switching costs (redirect when value shifts). Most AI adoptions only address one wing. That is why 100X individual gains fail to compound into system performance.
A two-person startup just redesigned a live publishing platform with AI. One prompt builds a working online shop in thirty minutes. The 100X is real.
But why? What makes a tiny team 100X while your organization — with better engineers, deeper pockets, and more data — barely moves the needle?
Two things. Two wings.
Wing one: transaction costs are near zero. A small team runs the full cycle — discovery, delivery, observability, operations and back to discovery— without handing anything off to anyone. No tickets across team boundaries. No three-week intake process. They outlearn everyone because nothing slows the loop.
Wing two: switching costs are near zero. When the data says pivot, they pivot by Tuesday. No sunk-cost roadmap. No six teams committed to last quarter's plan. They don't just run fast — they run the right direction, and they change direction the moment it stops being right.
Running fast isn't enough if you're running the wrong way. Running the right way isn't enough if every course correction takes a quarter.
Now look at how most organizations adopt AI.
The resource model: give every specialist an AI license. The database designer finishes in three days. Then waits. Transaction costs? Through the roof — every handoff, every "wait for the other team." Switching costs? Impossible — people are pinned to their specialty. Neither wing works. This is [the Ferrari Trap](/post/the-ferrari-trap) — faster cars on a jammed highway.
The delivery model: cross-functional teams with AI. Better — the BML (Build-Measure-Learn) loop runs fast inside each lane. But teams can't repoint to where the real value is. They're locked to their stream. One wing flaps. The other is pinned.
The adaptive model: teams that co-own broad customer problems, acquire skills across boundaries, and redirect when value shifts. Both wings work. That's where 100X individual gains compound into 10X organizational performance — what [multi-learning](/post/multi-learning-200-years-wrong-model) makes possible when the org structure allows it.
Most AI adoption conversations start with tools. The better question is: which wings does your organization have? As the [DORA 2026 data confirms](/post/dora-2026-developers-faster-teams-messier), individual developers are measurably faster — but team-level delivery is flat or worse when the structure hasn't changed.
---
Material from the 10X ORG book tour leanpub.com/10xorg — Amsterdam next week (LeSS meetup May 7, DevWorld May 8).
---
# Agile Was Homework, AI Is the Assignment
**Date:** 2026-05-01 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-was-homework-ai-is-assignment
**TL;DR:** You could fake agile for a decade — rename roles, run ceremonies, call it transformation. AI-native startups shipping at 100X just made faking visible. The gap is public now, and the structure of your organization determines which side of it you land on.
This is a digest from the ideas explored in [10X ORG](https://www.10xorg.com/) by Alexey Krivitsky, Roland Flemm, and Craig Larman — a book about what happens when AI meets organizational structure, and why the structure usually wins.
**Listen as a podcast:**
## You could fake agile...
Many did. You could rename your project managers to Scrum Masters, your status meetings to standups, your milestones to sprints. You could buy SAFe licenses, certify 200 people, hang a Kanban board in the hallway, and call the whole thing a transformation.
And it worked — in the sense that nobody called you out. The board saw the slide deck, the consultants got paid, the teams did their retros. Everyone played along. Change theater, done well, can run for a decade.
Your Scrum Master would have told you that's fine. "Agile is an adjective," they'd say. "What matters is that we're more agile this year than last year." And that sounded reasonable, because slow change was tolerable. The market moved at a pace where incremental improvement felt like enough, and nobody was keeping a public scoreboard of how fast your competitors shipped.
But here's the thing about slow change: in most organizations, it was cover for no change at all. The language got better. The ceremonies got smoother. The underlying structure — who decides what, who learns what, who is allowed to work on what — stayed exactly where it was.
That was survivable. Until now.
## You Are Now Being Compared to 100X
[AI-native startups are building full products](/post/ai-native-startups-100x) with one CEO and five Mac Minis. They don't need your org chart, your review cycles, your handoff protocols. They started clean, with no legacy structure and no historical management system weighing them down.
From now on, your organization will be benchmarked against what they can do. Not by you — by your board, your investors, your competitors, your customers who notice that someone else ships in days what you deliver in quarters. One hundred times faster, and not as a metaphor. As a measurable gap.
So your leadership will ask — if they haven't already — why can't we move like that? And why do we see only costs increasing with no visible gains?
The answer is uncomfortable. Your organization didn't start from scratch when AI arrived. It was already on a path — a management system, team structures, habits built up over years. AI found all of that in place, and it is very likely your org is on the same trajectory as before, now with AI spread like fairy dust. Increasing costs, not necessarily gains.
With agile, you could hide in the theater. Fake a transformation, skip the hard parts, and nobody benchmarked you against a fundamentally different kind of organization. With AI, the 100X baseline is public. The gap is visible, and faking it gets expensive fast.
## The Part That's Already Happening
Here's what makes this different from every previous technology wave: your developers already know.
They go home in the evening, open Claude or Codex, and build something in a few hours that would have taken their team two sprints. They pair with an AI agent and ship a working prototype before midnight. Then they come to the office at nine in the morning and sit down in the same org structure, the same approval chains, the same narrowly defined role boundaries that were designed for a world where building software was slow.
They feel the gap every single day. And the ones who are good — the ones you most want to keep — are already thinking about where they could work without that friction. You're not just competing with other employers anymore. You're competing with the experience your own people have at home, where they already operate at ten times the speed your organization allows.
This isn't a theoretical risk. It's a retention clock that's already ticking.
## The Uncomfortable Part
AI doesn't just speed things up. It pushes people away from single-skilling and toward orchestration and outcomes.
Take a database designer — there's an entire section in 10X ORG called "Nobody Needs 1,000X More Databases" that unpacks this example. If AI allows other people to handle much of that work, and allows the designer to do their traditional load in a few days instead of a month, then the question becomes obvious: what will the organization do with this person? Producing more of the same thing is not the answer. There is no customer demand for a thousand times more databases. There won't be enough demand for what they do.
The same goes for UI specialists, business analysts, frontend developers, and a growing list of roles defined by a single skill performed within a fixed boundary.
AI doesn't fire anyone. It just makes certain roles easy to not refill. The people with the narrowest mandates and the least leverage to negotiate are the ones who leave first, and they don't get replaced. This is the displacement pattern — not by job title, but by mandate. In 10X ORG (Chapter 3: Org Topologies), we call this the Scope of Skills Mandate: how many skills an organizational unit possesses and is authorized to apply. When that scope is narrow, the unit depends on handoffs, coordination, and other people's calendars. AI makes narrow units faster at what they do — but it doesn't give them anything else to do.
And here's where diminishing returns hit. If that database designer is kept pinned to the same work — structurally mandated to keep designing databases because "that's what database designers do" — then the acceleration has nowhere to go. The designer finishes in three days what used to take a month, and then sits in a system that has no mechanism for deploying their freed-up capacity elsewhere. The local gain doesn't compound. It dissipates. That's 1X dynamics: faster parts, same system, no global improvement.
The same pattern applies at the team level. Consider a Search team or a Payments Integration team — what 10X ORG describes as Delivery Topology (Chapter 3): units that "ship rapid improvements within a bounded area but are neither expected nor designed to contribute to other, perhaps higher-value work beyond it." If AI makes them ten or a hundred times faster at their bounded work, will there be enough valuable search or payments work to fill their capacity? Almost certainly not. But if they're structurally mandated to keep working on that thing — because "it's faster if a search team works on search" — there won't be any system-level gain. The team is optimizing locally while the organization stays flat.
This is [the Ferrari Trap](/post/the-ferrari-trap) (10X ORG, Chapter 2): adding faster engines to a jammed highway doesn't fix congestion. As Principle 3 of the book puts it, "mandates determine the maximum complexity the organization can handle. If mandates are narrow, the organization can only solve narrow problems, and anything broader turns into dependencies, coordination meetings, and delayed decisions."
[Multi-learning](/post/multi-learning-200-years-wrong-model) — people and teams expanding beyond their primary craft, building capabilities across domains — is no longer a nice principle to put on a slide. It's what Principle 8 of 10X ORG calls "Embed Multi-Learning": a structural requirement, not a training initiative. Without it, AI augmentation gives you a local efficiency gain, not a compound, org-wide one. You get 1X, not 10X.
## The Part Nobody Tells You
Here's the twist: multi-learning is not new.
In 1986, Takeuchi and Nonaka published "The New New Product Development Game" in Harvard Business Review — the paper that later inspired Scrum. They studied Honda, NEC, Canon, and others. The teams that produced breakthrough products weren't narrow specialists. They were multi-learning teams, people with depth who also developed capabilities across domains. They followed value and they learned while delivering.
That was forty years ago.
Most organizations ignored it, or paid lip service. They took the Scrum part — the ceremonies, the roles, the cadence — and left the multi-learning part on the table. Too hard, too expensive, too disruptive to career ladders and HR policies that reward growth within a single funnel. As 10X ORG puts it: "learning has traditionally been treated as a cost to minimize, not a capability to grow."
The agile homework was never about standups and sprints. It was about building organizations where people can learn, follow value, and contribute beyond their job description. The companies that did this homework — that embedded multi-learning as a structural principle, not a training initiative — those companies know how to handle AI. They already have the muscle: broader mandates, cross-boundary work, people who are allowed and expected to grow beyond their current role.
They don't need to panic. They need to accelerate.
### Must-Shaping
M-shaped people. Not T-shaped — that was the polite version. Multiple strokes of depth, connected by the ability to learn across boundaries and contribute wherever the value sits. This is not optional anymore. This is must-shaping.
AI democratizes knowledge and skills, making it easier for people to go beyond their primary craft. As Aiden — the AI character in 10X ORG — explains: "tutors, copilots, and research agents make multi-learning practical in weeks and days, not years. We are entering the new era of flattened learning curves."
But the organization has to allow it. Traditional HR policies and career paths still reward growth within a single clearly defined funnel, and that system is becoming outdated fast. The technology is ready. The structural permission is not.
So leaders need a sense of direction, and the direction is clear: broaden the definition of expertise. Allow people to learn, follow value, and use AI in ways that are still emerging. Not replacing people with AI — amplifying human intelligence with AI. 10X ORG calls this the move toward Adaptive Topology: "a network of interdependent units where adaptation doesn't require a reorganization — it is built into how these units work."
The organizations that did the agile homework know this direction. They've been walking it, slowly, for years. AI doesn't change the direction. It removes the excuses for not moving faster.
And the ones that faked it? They're about to discover that the AI assignment doesn't grade on a curve. The [DORA 2026 data](/post/dora-2026-developers-faster-teams-messier) already shows it: individual developers faster, team-level delivery flat or worse.
The ideas in this digest come from [10X ORG](https://www.10xorg.com/) — available now. If this resonated, the book goes deeper: nice principles, real case studies, and a diagnostic map to see where your organization actually sits.
---
# The Subsidized Tokens Are Ending
**Date:** 2026-04-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/subsidized-tokens-are-ending
**TL;DR:** Cheap AI tokens masked the difference between real restructuring and AI theater. When prices rise, companies that wove AI into their delivery lifecycle will justify the budget. Companies that sprinkled it on unchanged structures will face a CFO asking what they got.
## The Subsidized Tokens Are Ending. Did You Seize It — Or Just Sprinkle AI on a Dysfunctional Org?
Two things happened this week. GitHub Copilot — used by 4 million people weekly — moved to usage-based billing and paused new signups. Separately, Anthropic tested removing Claude Code from their $20/month plan. They reversed it within hours after backlash, but the signal was loud: flat-rate AI is becoming unsustainable.
The all-you-can-eat buffet can be closing soon.
If this trend holds over the next 3–6 months, it will expose a split that cheap tokens have been masking.
Some companies used the cheap-token window to actually restructure. Not just hand out Copilot seats — but rethink product development end to end. Discovery, delivery, observability, operations. AI woven into the lifecycle. These teams learned, measured, and got faster at building the right stuff rightly. They have the numbers to prove it.
Other companies sprinkled AI on top of what was already there. Same org chart, same handoffs, same processes — [the Ferrari Trap](/post/the-ferrari-trap) in action. A chatbot here, a coding assistant there. When leadership asks "what did we get for the AI spend?" — everyone speaks of local improvements without a clear compound effect.
Now imagine the price doubles.
The company that restructured goes to the CFO. Talk about the budget and the opportunities. Budget approved. They keep on learning and accelerating.
The company that sprinkled goes to the CFO: "We need more AI budget." The CFO asks: "What did the last one produce?" Here, AI became a cost center to be minimized. Not a value generator.
**Cheap tokens masked the difference between real transformation and AI theater. Expensive tokens will expose it.**
The gap between the best and rest will only grow. [AI-native startups are already moving at 100X](/post/ai-native-startups-100x) — your organization will be benchmarked against that baseline.
The subsidy window was your chance to [redesign, then AI](/post/redesign-for-ai-why-transformation-requires-organization-design). It is still there. So seize it. Spawn experiments. Allow the product engineering teams to do what they believe is right. Break some old rules here and there. Learn. Ship. Adapt.
There has never been and won't be a better time to try new things.
---
# AI-Native Startups Are Moving at 100X
**Date:** 2026-04-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-native-startups-100x
**TL;DR:** AI-native startups move at 100X with no legacy structure. Your organization will be benchmarked against that baseline. The org design choices of the last two decades — handoffs, queues, narrow mandates — now determine how much of that potential actually lands.
AI-native startups are moving at 100X. One CEO, five Mac Minis, a full product. They don't need org design consulting. They started clean, no legacy, no inherited structure. Good for them.
From now on, your organization will be benchmarked against what's now possible. And the question your leadership will face, if they haven't already, is: why can't we move like that? And why do we see only costs increasing (tokens and subscriptions) with no visible gains?
Your organization did not start from scratch when AI arrived. It was already on a path — a management system, team structures, habits built up over the years. AI found all of that already in place. And it is very likely your org is on the same trajectory as before, now with AI spread like fairy dust, increasing costs but not necessarily gains.
Your "Search" stream-aligned team is shipping features in its lane at a record pace. Your "Payment" component team produces more integrations than ever — but still depends on the same queues and hand-offs. Your DB designer outputs 100X more DB designs — [then sits idle for most of the year](/post/ai-replaces-tasks-not-people). Everyone now works according to an "AI SDLC". But has anything really changed? Is there real demand for this much of the same stuff? Are the old dependencies still in place?
**What if [agile was the homework, and AI adoption is the real assignment](/post/agile-was-homework-ai-is-assignment) now?**
The org design choices made (or not made) over the last two decades now determine how much of that 100X potential actually lands as system-wide improvement. 100X? 1X? 10X?
For agile practitioners, this is familiar ground but with new urgency. Broad co-ownership, cross-component work, [multi-learning](/post/multi-learning-200-years-wrong-model). AI is not just pushing harder in those directions, but it can also be used to challenge the historical beliefs about why that was never possible. When applied strategically, it can make the learning itself more feasible, and it can help change the historical organizational trajectory. Finally.
---
# Pair Programming in the AI Era
**Date:** 2026-04-16 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/pair-programming-in-the-ai-era
**TL;DR:** Pair programming is not dead in the AI era. The navigator's job was never reading code line-by-line — it was holding the broader frame: what test is missing, what feature next, do we need this at all. Treat AI-generated code like compiled binary and pair on high-level BDD tests instead.
Pair programming and AI-augmented engineering.
I hear people saying that the practice of pair programming is now dead because no human can read the code at the generation speed.
I agree. With the fact that one can’t read and understand code so fast.
But let me offer you a reframing.
First. The practice of pair programming assumes two distinct roles: navigator and driver. While the driver holds the keyboard and types, the navigator is welcome to read. But mainly the value from the addition pair of eyes and the navigator’s intelligence comes from holding a broader frame.
What is a missing test?
Which feature do we build next?
Do we need this at all?
These are navigator’s challenges.
In the AI age? Can still be (and I claim must be) performed by the human. As I explored in [*Agile in the Age of AI*](/post/agile-in-the-age-of-ai), developers are becoming mini-Product Owners — deciding what code needs to be written, not writing it.
And now for the more important reframing. Imagine the old-times pair programming with two humans. One clicks to compile. A binary is produced. The tests are run. Feedback is generated.
Will the programmers bother to read the binary code?..
Likely not. So why don’t we look at the code that is AI-generated at the speed of light as the binary code and instead focus on high-level tests (like BDD level) that still can be discussed and paired on. This shift from [routine to adaptive expertise](/post/routine-vs-adaptive-expertise) — from executing known procedures to navigating novelty — is exactly where human pairs add value that AI alone cannot.
---
# I Hired a Scrum Master AI
**Date:** 2026-03-21 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/hired-a-scrum-master-ai
**TL;DR:** An AI agent now coaches my team by reading session memories and surfacing recurring dysfunctions — approval gate violations, destructive ops without confirmation, plan-mode confusion. It catches patterns across sessions that humans forget. The role works because it observes relentlessly and never tires of pointing out drift.
While [Scrum Masters are getting fired](/post/why-scrum-masters-are-getting-fired) across the industry, I have just hired a Scrum Master!
In the interview, I asked:
What other issues have you observed in my recent sessions?
Then she replied without hesitation:
Here are the recurring issues I can see from the memories + today's session:
Issues observed
And she continued with a great level of detail:
1. Approval gate violation (repeated offense) — Memory says "NEVER jump to implementation without approval." Has its own memory file.
Still happened 3+ times today. The memory/CLAUDE.md approach isn't working — needs a structural fix, not another reminder.
2. Destructive data operations without confirmation — Cache version bump wiped 3.6MB of WA history. No warning, no backup, no confirmation
asked. This pattern (making irreversible changes silently) is the most dangerous.
3. Plan mode confusion — Plan mode's auto-"approved" message gets treated as user approval. This has happened before (it's explicitly in
the memory file) and happened again today.
4. Spec/plan location drift — Specs kept ending up in plan files instead of /specs. User had to say "MAKE A SPEC" and "follow OUR
WORKFLOW." The memory file for this exists too.
5. Testing against live resources — Previous incident with git e2e tests against working repo. Today: cache flush overwrote real data
file. Pattern: not isolating test/dev operations from production data.
6. Over-eagerness / not listening — When user says "stop", I often do one more thing before stopping. When user asks a question, I
sometimes start implementing instead of just answering.
-----
That's awesome, I said. You are hired! This is [AI as a teacher, not just a doer](/post/ai-augmented-multi-team-pbrs) — observing patterns humans miss and surfacing them relentlessly.
Welcome to the team of:
- product manager (me, for now)
- expert UX researcher + user interviewer
- elite BDD (Behavior-Driven Development) specialist
- and a good coder (Opus 4.6) — a setup that maps directly to how [agile teams work in the AI era](/post/agile-in-the-age-of-ai)
---
# The Gigantic Shift
**Date:** 2026-03-19 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/the-gigantic-shift
**TL;DR:** Companies are using AI as an excuse to cut headcount while single-person unicorns loom. Old recipes are expiring. Organizations cannot learn fast enough for you — install a coding agent, build something, play. 2026 is your window. Waiting for permission is the surest way to become irrelevant.
We are witnessing a gigantic shift in what is technically possible.
We are also witnessing companies using that as an excuse to cut its overstaffed organization loose.
These two things are appreciated by the stakeholders.
This affects many of us. All of us.
This is a very personal technological change.
I am committing myself to understanding how we can keep people relevant in these changing and challenging and exciting and scary times.
I see posts of Jeff Sutherland spawning an agentic Scrum team. And how this is the new new new game.
I hear Jensen Huang promoting agentic operating system. And first single-person unicorns are around the corner.
I read product managers of advanced organizations like Anthropic claiming that when their engineers turn to becoming real product developers, what remains is packaging and pricing. This is the shift from [routine to adaptive expertise](/post/routine-vs-adaptive-expertise) — and organizations that don't allow it will [displace people by design](/post/ai-replaces-tasks-not-people).
I hear many signals. This is the time to listen and absorb, do and try.
This is the time when old proven recipes might stop making sense. When new practices and skills emerge with an unprecedented speed.
I am committed to learn and try things first-hand. I encourage everyone to do the same.
Learning is a personal journey.
Most organizations won’t cope up with this speed of learning. And if you sit there and wait to be given permissions to try new things you will lose your precious time.
Don’t wait. Don’t stay in the past.
Go install your coding agent. Build a simple app. No matter what. Find a pet project to play with. As [Shopify's CEO put it](/post/shopify-ceo-reflexive-ai-usage), reflexive AI usage is now a baseline expectation.
2026 is your playing time. Our time.
---
# Redesign, Then AI: Why AI Transformation Requires a Multi-Learning Organization
**Date:** 2026-03-12 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/redesign-for-ai-why-transformation-requires-organization-design
**TL;DR:** AI tools without org redesign just amplify existing silos. AI collapses the cost of learning, which erodes the advantage of narrow specialization. The real unlock is broader skill mandates and cross-boundary work — multi-learning organizations. Redesign first, deploy AI second.
## The missing piece is organizational design
Organizations around the world are investing heavily in generative AI. Leaders are deploying copilots, automation tools, and AI agents across functions in the hope of dramatically improving productivity and innovation. Yet many executives are discovering that introducing AI tools does not automatically lead to meaningful transformation. Individual employees may become more efficient, but the organization itself often changes very little — the [DORA 2026 data](/post/dora-2026-developers-faster-teams-messier) confirms this exact pattern at scale.
The missing piece is organizational design.
Most organizations today are still structured around narrow roles and specialization. Teams are defined by functional expertise, ownership of components, or tightly bounded responsibilities. These structures were effective in an era when learning across domains was slow and costly. If acquiring new expertise required years of training, it made sense to organize work around specialized skills.
## AI lowers the cost of learning
Generative AI changes this assumption. With AI tutors, copilots, and agents, individuals can acquire new capabilities much faster than before. Developers can explore unfamiliar technologies, product managers can analyze complex data sets, and designers can prototype solutions beyond their traditional domains. In other words, AI dramatically lowers the cost of learning.
When learning becomes faster and cheaper, the advantage of narrow specialization begins to erode. What increasingly matters is the ability of people and teams to expand beyond their primary craft and recombine skills as work evolves. This capability can be described as **multi-learning**.
However, most organizations are not designed to support it. Rigid role definitions, siloed ownership of systems, and tightly bounded team responsibilities often discourage people from expanding their capabilities or contributing beyond their immediate domain. In such environments, AI simply amplifies productivity inside existing silos rather than transforming how the organization solves complex problems. This is [the Ferrari Trap](/post/the-ferrari-trap) — faster cars on a jammed highway.
## Redesign first, then deploy
To unlock the full potential of AI, leaders must therefore rethink how their organizations are structured. Instead of designing organizations primarily around specialization, they need to enable broader skill mandates, cross-boundary collaboration, and continuous learning across teams.
This shift also changes how AI itself should be applied. Rather than using AI primarily for task automation, organizations should integrate it into learning and capability development. In this sense, AI becomes a strategic amplifier of human adaptability.
> The most successful AI transformations may therefore begin not with technology deployment but with organizational redesign.
By creating environments where people and teams can continuously expand their skills and collaborate across domains — what requires [both wings of a 10X organization](/post/two-wings-of-a-10x-bird) — leaders can build organizations that are capable not only of adopting AI but of evolving with it.
## Further reading
These ideas are explored in more detail in the book [10X Org](https://www.10xorg.com/), which examines how organizations can elevate performance in the age of AI through intentional organizational design.
The book introduces the concept of multi-learning organizations and presents the Org Topologies approach for diagnosing and redesigning structures that limit adaptability and collaboration.
Since its release, *10X Org* has become a #1 Amazon bestseller in several strategic management and business categories. Leaders interested in understanding how organizational design can unlock the full potential of AI can explore these ideas further in the book.
---
# The Ferrari Trap
**Date:** 2026-02-20 · **Reading time:** 9 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/the-ferrari-trap
**TL;DR:** AI is an accelerator — but it accelerates whatever is. Developers expected 24% speedup from AI — actual result: 19% slower. The Ferrari Trap: faster cars on a jammed highway. Fix the road first.
[METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — a respected AI evaluation organization — ran a randomized controlled trial with sixteen experienced open-source developers across 246 real issues. Developers expected a 24% speedup from AI assistance. Actual result: 19% slower. And even after experiencing the slowdown, they still believed AI sped them up by 20%.
That perception gap is the Ferrari Trap in one sentence. The feeling of speed without the reality of progress.
Everyone's engine is revving louder. The cars are still stuck.
In [*10X ORG*](https://www.10xorg.com/), we call this the Ferrari Effect. But I've started calling it the Ferrari Trap, because "effect" sounds like something that happens to you. A trap is something you walk into — and most organizations are walking into it with their eyes open and their wallets out.
## The Metaphor
Aiden, the AI advisor in [*10X ORG*](https://www.10xorg.com/), explains it to Hanna, the Head of HR, after she asks why the roadmap is still slipping even though every developer is moving faster:
*"Think about car traffic. The goal is for cars to move fast and get where they're going. But what we often get are traffic jams. Now imagine swapping every car for a Ferrari. Although each one could now go much faster, that alone doesn't fix congestion."*
Hanna tries to absorb this. "So... if we've got AI super-specialists revving their engines... this is not helping?"
*"We're just flooding a blocked highway with faster cars. And more cars mean more traffic, more traffic means less flow."*
After a pause: *"Perhaps we should fix the road first — and only then let the AI-powered Ferraris fly."*
The metaphor lands because everyone has felt it. Your database designer finishes the month's workload in three days. Then waits. Your frontend team triples their output. Then waits — for the backend team, for the architect review, for the product manager who owns the intake queue. Individually, they're Ferrari-fast. Organizationally, the roads haven't changed since 2003.
## The Data
[Faros AI's research](https://www.faros.ai/ai-productivity-paradox) found the same pattern in delivery metrics: developers completed 21% more tasks and merged 98% more pull requests. But PR review time increased by 91%, and AI-generated code produced 1.7 times more issues than human-written code. Net organizational throughput: flat.
Meanwhile, an [NBER study](https://www.nber.org/papers/w34836) of six thousand CEOs and CFOs across the US, UK, Germany, and Australia found that 90% said AI has had no impact on productivity or employment — even though 70% actively use it. The modern Solow paradox. Executives average 1.5 hours per week of AI use. The cars are faster. The highway is still blocked.
## The Ferrari Trap in Siloed Specialists
The Ferrari Trap isn't a failure of intelligence. It's a failure of paradigm.
In [the book](https://www.10xorg.com/), Eric — the Director of Engineering — takes Paula, the newly hired Head of Product, on a tour of the development floor. Paula owns the roadmap. She sees execution performance across all teams — not one team's velocity, but whether the whole system delivers on its commitments. Devi, a frontend developer, is tripling her output with GenAI. Eric can barely contain himself: "What used to take days now takes hours. Sometimes minutes." Paula watches, then says quietly: "Everyone seems faster individually. But the whole? It's not getting any better."
Paula had spotted the jam. Eric was still admiring the Ferraris.
Eric isn't wrong about the individual gains. He's wrong about what they add up to. And that's the trap: the local evidence is overwhelmingly positive. Dashboards light up. Sprint velocity doubles. Every team demo is impressive. The data says faster. The roadmap says stuck.
The problem is structural. When specialists in silos all accelerate, they produce more work-in-progress that jams organizational queues. Dependencies between teams create bottlenecks that local speed can't resolve. Handoffs, waiting, and coordination overhead dominate total cycle time. You're not speeding up the constraint. You're speeding up everything except the constraint — which is the organizational structure itself.
Amdahl's Law, from computing, formalizes this: the speedup of a system is limited by the fraction of the system that can't be improved. If 80% of your end-to-end delivery time is spent in queues, handoffs, and coordination, then making the remaining 20% infinitely fast still only gives you a 25% improvement. AI tools can't fix the 80%. Only redesign can.
## The Ferrari Trap in Fast-Flow Teams
But what if your organization already did the transformation? What if you built autonomous, cross-functional teams — each owning their full value stream from idea to production?
You're still vulnerable.
Consider a typical post-transformation setup: a search team, a payments team, a recommendations team. Each cross-functional. Each empowered. Each fast inside its lane. They've got what [*10X ORG*](https://www.10xorg.com/) calls Wing One — [full ownership of the value cycle](/post/two-wings-of-a-10x-bird). No handoffs, no waiting, no review queues.
Now add AI. The search team accelerates search. The payments team accelerates payments. But demand for search stabilizes — the product doesn't need more search improvements. Meanwhile, a new AI-powered capability needs building urgently, and the people best suited for it are pinned to a payments lane that's already saturated.
These teams can't switch. They're autonomous inside their lanes but locked to them by design. When value shifts — and with AI, it shifts fast — they can't follow it. They hit what we call the demand ceiling: speed without scope.
This is the one-winged bird. [Wing One without Wing Two](/post/two-wings-of-a-10x-bird) — ownership without flexibility. AI hits the demand ceiling in each lane, and the organization has no mechanism to redirect capacity where it matters most. The Ferrari is fast on its road. But when the road ends, it can't change lanes.
## The Accelerator Problem
AI is an accelerator. But it accelerates whatever is. If you had a traffic jam before AI, you're going to have a faster one now — burning tokens, revving engines, but not moving value.
If your organization was building the wrong thing, it now builds the wrong thing faster. If your teams were producing untested code, they now produce more untested code. If your culture rewarded output over outcomes, AI turns that reward function into overdrive. If your org was into crap coding, it's now faster at crap coding.
This is what makes the Ferrari Trap especially dangerous: AI doesn't just amplify speed — it amplifies trajectory. Gary Hamel observed that we're running 21st-century technology on 19th-century management principles. AI walked into most organizations and found exactly that arrangement. It didn't disrupt the structure. It accelerated the structure. And an accelerated misfit is worse than a slow one, because it burns resources faster, creates more waste, and the gap between the organization's self-image ("We're an AI-powered company!") and its actual performance widens with every token purchased.
Sooner or later, leaders notice. "We rolled out copilots and GenAI licenses," they say, "but we saw no meaningful performance gain." What they do see is higher running costs — AI licenses, training budgets, consultants. These are symptoms of non-strategic AI adoption: naive, sporadic, ad hoc — spreading AI across existing silos and hoping it will do the trick.
## Fix the Road
Paula's line in [*10X ORG*](https://www.10xorg.com/) lands hard because it reverses the instinct: "First design, then AI."
Most organizations do the opposite. They buy the tool first, distribute it widely, measure individual adoption, and then wonder why the organizational needle didn't move. They're trying to solve a structural problem with a technology purchase.
The structural problem has a name in Org Topologies: narrow mandates. When a database designer is mandated to touch only databases, AI makes her finish the work in three days — then she sits idle for twenty-seven. Nobody needs a thousand times more databases. When a search team is mandated to own only search, AI makes them ship search improvements at record speed — then they hit what we call the demand ceiling. Speed without scope. The lane becomes the constraint, not the pace within it. The question isn't whether [AI replaces people](/post/ai-replaces-tasks-not-people) — it's whether your org structure turns displacement into elevation or just idle time.
The fix maps to two organizational capabilities — the Two Wings in [*10X ORG*](https://www.10xorg.com/). Wing One: give people and teams ownership of the full value cycle, from idea to production. Not "the backend part" or "the QA step" — the whole thing. Wing Two: enable switching between value areas. A team that can redirect its capacity when demand shifts, instead of sitting idle inside a lane that doesn't need more work.
Management has two dials to turn: grow multi-expertise (help people broaden their skills — AI makes this faster than ever) and unpin from streams (stop assigning people permanently to one value area).
These aren't binary switches. They're dials you turn gradually. But someone has to turn them. Leaving them at zero and distributing AI licenses is how you buy more Ferraris for the same jammed highway.
## Recognizing the Trap
You're in the Ferrari Trap if:
Your developers report feeling significantly faster while your roadmap timelines haven't meaningfully improved. Your AI spend is climbing but customer-facing outcomes are flat. Your teams are producing more pull requests, more code, more artifacts — and your cross-cutting initiatives still take quarters. Your sprint demos are impressive, and your annual planning conversation sounds the same as last year.
The uncomfortable question from [*10X ORG*](https://www.10xorg.com/) that I now ask in every workshop: "Where are you seeing local speed improvements that still don't show up in roadmap-level progress?"
Every hand goes up.
## Escaping
The sequence matters. Redesign, then AI. Not the other way around.
That doesn't mean stopping AI adoption. Try it everywhere — that's fine and necessary. Learn what it does to your system. Watch where the Ferrari Trap appears, where the demand ceiling hits, where faster workers produce longer queues. Use the evidence to diagnose where the structure, not the tooling, is the constraint.
AI is an accelerator. It will accelerate whatever is. So point it at the right thing. Use it to accelerate [improving your organizational design](/post/redesign-for-ai-why-transformation-requires-organization-design) — broadening mandates, compressing the [multi-learning](/post/routine-vs-adaptive-expertise) curve, dissolving the silos — instead of revving harder inside a jammed highway.
---
# Routine vs. Adaptive Expertise
**Date:** 2026-01-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/routine-vs-adaptive-expertise
**TL;DR:** Routine expertise executes known procedures well in stable conditions. Adaptive expertise handles novelty without freezing. Post-COVID research confirmed they are different capabilities — seniority alone offers no protection from disruption. Adaptive expertise must be deliberately built through broader mandates and continuous exposure to variation.
For decades, we have rewarded **deep specialization**.
A radiologist reads scans. A frontend developer writes UI code. A paralegal prepares contracts. These roles were seen as focused, professional, and trustworthy. We encouraged our kids to get an education that makes them experts—the go-to person for one well-defined kind of work.
The times are changing. As AI [takes over the repetitive work](/post/ai-replaces-tasks-not-people) that justified narrow specialization, success depends on more than executing well-learned domain and well-practiced tasks. Professionals are increasingly expected to learn as they go, apply knowledge in unfamiliar contexts, and respond when standard solutions no longer fit.
This is new in practice for most of us, but the theoretical distinction is not. In the 1980s, cognitive researchers Giyoo Hatano and Kayoko Inagaki introduced a useful concept to describe this phenomenon: **routine expertise**versus **adaptive expertise**.
_Routine_ expertise is the ability to perform known tasks efficiently and accurately by applying established procedures. Routine experts excel in stable conditions. They produce reliable, high-quality outcomes—as long as the situation remains familiar.
_Adaptive_ expertise goes further. Adaptive experts can extend, recombine, or reinvent their skills when conditions change. They handle novelty without freezing. They learn while acting.
The COVID-19 pandemic made this distinction painfully visible. Health professions educators around the world were forced to abandon standard training models almost overnight. One post-pandemic study showed that adaptive expertise did not correlate with age or years of experience. Instead, it emerged as a distinct capability that had to be deliberately developed. Those scoring higher in adaptive expertise also performed better during periods of disruption, while seniority alone offered little protection from disruption.
As it turns out, work experience does not automatically result in adaptive expertise.
Adaptive expertise is a different kind of mastery—one built through continuous learning, exposure to variation, and the embrace of new challenges. In other words: purposefully and with broader mandates. This is the foundation of [multi-learning](/post/multi-learning-200-years-wrong-model) — the organizing principle that makes teams genuinely versatile.
After the pandemic, the professionals who had demonstrated their surprising adaptive expertise were able to return to business as usual. But are there domains where such behavior is not a crisis response, but the daily norm? Organizations moving toward [AI-supported org design](/post/ai-supported-org-design) are making adaptive expertise the operating default, not the exception.
---
# Craig Larman on 10X and The Future of Jobs
**Date:** 2025-11-20 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/craig-larman-10x-future-of-jobs
**TL;DR:** Craig Larman's thesis: within years, AI will meaningfully replace entire job categories. A 10% improvement pitch won't save humans when AI is cheap, tireless, and good enough. The answer is 10X — dramatic business impact through adaptive organizations. The Org Topologies upper-right quadrant is our children's fighting chance.
> I am here to save jobs for our children.
Transcript of Craig Larman's keynote at LeSS Conference 2025. The ideas below became the foundation of [*Agile Was Homework, AI Is the Assignment*](/post/agile-was-homework-ai-is-assignment).
"This is my new professional mission for perhaps the next 10 or 20 years. And you can, those of you who have been at the previous conferences with me understand my motivation for this and our grandchildren. I have grandchildren. So my thesis is I've shared each year in these keynotes since 2020.
That within a few years, maybe by the, maybe by October, 2027, we'll see news of the first job category that's been meaningfully replaced by an AI. I think that could be possible within two years. I've got a sister and a daughter who work in the film industry and you should see what's happening there.
Things that currently take 1000 - 2000 people to do a production it's just, dramatically dropping and on. Of course, these are very early days, so I understand that it sounds like I am crying wolf or describing a situation that isn't going to happen. But I think this could be a boiling frog dynamic over the next 10 years.
And of course, these things are gonna be cheap as dirt. They work 24/7. They don't ask for vacation. They don't ask for time off. So the labor economics incentives to replace humans by AIs will be compelling, I suggest. And we humans won't compete. If the only thing that we can suggest is, please hire me, I'll make you 10% better.
It's just not gonna cut it. I suggest, because these AIs are going to be so economically desirable. Cheap as dirt, good enough, no vacations, that if humans want to be attractive in the future labor market, I suggest that 10% isn't gonna do it anymore. Now, if you've read the Book of "Secrets of Consulting" by Gerry Weinberg, what do you know?
One of Jerry's chapters is "never recommend more than a 10% improvement in business". And there's a whole bunch of interesting reasons for that. And I suggest that at this, what's going to be coming milestone or disruption in intelligence-as-a-service that we're going to have to suggest something more ambitious.
And I call this "10X Org". So the idea is, as in LeSS, one of the guides is more outcomes, less outputs, the focus is on some business impact or some meaningful impact, not just on creating outputs. And so when we say "10X Org", what I'm trying to suggest is 10 times the amount of business impact, 10 times the market share, 10 times the revenue.
Or whatever the business impact is. And I think that although before the age of AI, it would've been ludicrous to have these kinds of messages or suggestions, as a consultant. I think we're gonna be entering an age where aspirationally we need to make that pitch. And aspirationally, we humans will have to step up our game if we want to compete to actually achieve this goal.
And so I think we're at a point in the industry where actually we can be bold and suggest a much deeper improvement than would've seen ludicrous before.
And so with Roland and Alexey. Roland and Alexey! Over the last year, I've been starting to explore how to do this and the three of us are working on a book together, which we're gonna be releasing in not too long. And the basic idea, if you think of this from an Org Topologies point of view, this is Org Topologies as a 2x2, and quite simply where the scope of skills mandate is high and the scope of work mandate is high, that's the quadrant that is adaptive.
And this has always of course been the message of LeSS. But what we're trying to do with Roland and Alexey with the "10X Org" message is expand this to a far broader audience to all the different markets that are gonna be affected by AI. And I suggest that in many of these, moving to this quadrant — through [multi-learning](/post/multi-learning-200-years-wrong-model) and [broader mandates](/post/teams-and-scope-of-skills-mandate) — is the fighting chance for our children to have good jobs.
The adaptive quadrant. And it's also, I would suggest the perfection vision of where LeSS gets to as well. Thank you."
---
# Copenhagen: Flat Danish Management
**Date:** 2025-09-30 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/copenhagen-flat-danish-management
**TL;DR:** A memoir of joining a Danish company in 2004 — flat culture where sales and developers sat in a circle each morning without ceremony. Introduced CI, unit testing, incremental refactoring. The pattern repeating across assignments: arrive, revamp, make impact, move on when the adventure turns into business as usual.
Today watching the clouds as I am flying in to København, I remembered my first flight to Denmark 🇩🇰… year 2004.
I was just hired to lead an to-be development office of a Danish digital assets management software company. Pre-cloud era.
As a life-time skier, guess what was the first thing I did when learning about my assignment in this country? Right, go and check the map. The country appeared to be completely flat …
… as its management culture. Next morning in a small city of Odense, full of overrated H.C.Anderson’s portraits, I saw the first all-company meeting in my life. There were not doing Scrum yet (it would take me another 7-8 months to seed that idea), but in a style of a super-flat org, they just sat and talked each morning about their business.
What really shocked me is that they didn’t greet each other with their favorite “hej” before they got mugs with coffee and sat in that circle. In comparison to my previous assignment in Alcatel, en Bretagne, where you would literally need to go through the multi-level office building and kiss each other cheek to cheek before you open up your laptop. And then it is already time for lunch. And if Friday with wine.
Ok, so the Danish did say “hej” eventually to sit and talk about the business: sales people, developers, founders, and me…
And me? On my second day in the office, I was granted code access and dag into it. I wanted to quit right away…
But instead, ended up spending next a couple of years with great folks like Mykola Gurov on refactoring it.
That taught me a powerful lesson: you cannot (and should not) refactor everything. So we did it bit after bit. Smartly and safely. The kind of [adaptive expertise](/post/routine-vs-adaptive-expertise) that comes from doing, not from reading about it.
Trying to remember those times, 20 something years ago, I almost remember writing the first unit test and configuring the first build server with CI on it… I did that many times in other companies too during my employment career. Is there a pattern?
I quit ~3 years later (embarking on my Zurich journey) when my org revamping impact was declining and the wonderful adventure was slowly turning into a steady business as usual.
I ain’t no do usual. I do impact and move on. That’s probably a pattern too — a kind of [agile transformation that won’t be televised](/post/agile-transformation-televised), because it happens through doing, not through slide decks.
Happy to bring back to this country what I have been learning since then — the pain and pride, the ups and dows and the privilege
that goes with helping the orgs to improve.
Cheers to all my old friends from that era.
(The old Kastrup airport hasn’t changed a bit since then. That is an unfortunate find.)
---
# Why Scrum Masters Are Getting Fired
**Date:** 2025-09-27 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/why-scrum-masters-are-getting-fired
**TL;DR:** Scrum Masters get fired because org design locked them into team-level influence where they couldn't show real value. A vicious cycle: narrow mandate prevents impact, lack of impact prevents trust, lack of trust prevents broader mandate. Never stay where you are not allowed to perform. Your relevance is in your hands.
Another large company in my circle just fired a bunch of scrum masters and agile coaches.
That has been coming for almost a year with very strong signals, but now, that this happened, it came down as a “big surprise”.
This had nothing to do with the financial picture of the enterprise. (That was pure a managerial decision, weighted, strategic, and all that.)
So if you think your company is doing all right, and because of that you will be safe – you can be mistaken.
Most of the fired folks are skillful people, loving what they do and trying to get better at it. Others have given up over time but not because they wanted to.
In my analysis, there has been a very painful vicious cycle in motion (and I know it from other similar cases, so it is a generalization):
- the existing org design was made in a way that it limited the scope of influence of these people — what Org Topologies calls a narrow [scope of skills mandate](/post/teams-and-scope-of-skills-mandate)
- so the only thing they were mandated to do is making local improvements (eg at team level)
- but exactly because of that, they could not show real benefit over time or gain trust based on value delivered
- organizational performance improvements stagnated
- and because of the lack of trust and acceptance as significant party, these coaches could not influence the org design and get a broader mandate
Can you see how this reinforcing loop is making things only worse over time? Imagine it running for like 2 or 5 years.
My personal take from this: never allow yourself staying in a place where you are not allowed to show your true potential and make real impact.
Your relevance as valuable workforce is in your hands. And only in yours. No HR partner will save you when you have not been allowed to perform and just decided to hang in the comfortable limbo for years. The same pattern applies to developers — when [AI replaces the task and your mandate is narrow](/post/ai-replaces-tasks-not-people), you are exposed.
Get yourself going! (Or you will be gone.) The path forward is [multi-learning](/post/multi-learning-200-years-wrong-model) — broadening beyond a single craft so you have something to offer when the current task no longer needs a human.
(Sorry for this harsh truth. And all the best to the people who find themselves in a similar situation. There are companies that need your expertise and would be happy having you in.)
---
# Reactive to Creative Leadership
**Date:** 2025-09-02 · **Reading time:** 11 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/reactive-to-creative-leadership
**TL;DR:** Leadership style and organizational structure are inseparable. Reactive leaders — fear-driven, controlling — lock organizations into rigid designs. Creative leaders — purpose-driven, trusting — enable adaptive structures. You cannot shift your org topology without shifting your leadership first.
## TL;DR
In modern organizations, leadership style and organizational design are deeply interconnected.
When we talk about _Org Topologies_(Resource, Delivery, Adaptive), we usually think of structure. However, structure doesn’t shift without leadership shifting as well.
**The Leadership Circle gives us a useful lens here:**
* **Reactive** leadership is fear-driven. It leans on control, compliance, and protecting one’s image. It stabilizes, but it stifles learning.
* **Creative** leadership is purpose-driven. It emphasizes vision, trust, collaboration, and systemic improvement. It unlocks adaptability and innovation.
**Org Topologies show us the organizational side:**
* **Resource** Topology is siloed and efficiency-focused.
* **Delivery** Topology is cross-functional and output-focused.
* **Adaptive** Topology is versatile, outcome- and learning-focused.
**Now put them together:**
* Resource Topology runs on Reactive leadership– command, compliance, and tight control.
* Delivery Topology needs a blend– Creative “achieving” combined with just enough Reactive discipline to keep flow predictable.
* Adaptive Topology thrives only under Creative leadership– visionary, empowering, learning-oriented.
This article examines two frameworks – **The Leadership Circle**(which differentiates leadership styles, notably _Creative_ vs _Reactive_ orientations) and the **Org Topologies**model that describes different organizational design archetypes. We first summarize each framework’s core components, then map how various leadership styles align with each type of organizational topology.
Finally, we discuss how leadership development needs to evolve as an organization shifts from one topology to another.
## The Leadership Circle Framework: Creative vs. Reactive Leadership
The Leadership Circle framework (often delivered via a 360° Profile assessment) divides leadership behaviors into two primary categories: **Creative Competencies**and **Reactive Tendencies**.
The Leadership Circle is a model that maps leadership behaviors and mindsets into two overarching orientations – **Reactive**and **Creative**– each of which represents a distinct way of leading organizations and people. Like Org Topologies, it offers a map of different archetypal patterns.
Each half contains specific dimensions that capture a leader’s internal assumptions and outward behaviors:
* **Creative leadership**is characterized by effective, growth-oriented behaviors. Leaders high in Creative Competencies **“achieve results, bring out the best in others, lead with vision, act with integrity and courage, and improve organizational systems”**. For example, creative dimensions include _Relating_(building teams, developing others) and _Achieving_(setting vision and accomplishing strategic goals) . These competencies stem from inner confidence and a focus on purpose rather than fear. Notably, leaders who score high on the creative scale tend to be far more effective. High Creative leadership correlates strongly with better leadership performance and business outcomes.
* **Reactive leadership**is associated with self-limiting or fear-driven behaviors that can constrain effectiveness. The Reactive Tendencies reflect inner beliefs that **limit a leader’s authentic expression and impact**. Examples include _Controlling_(a tendency to micromanage, push for perfection, and derive self-worth from being in charge or “on top”) and _Complying_(a tendency to seek others’ approval and follow others’ expectations to feel secure). Such leaders often emphasize caution, control, or defending their image over innovation and engagement. In the Leadership Circle Profile, high reactive scores are **inversely correlated**with leadership effectiveness (often coinciding with low creative scores). In short, a predominantly reactive “command and control” style may undermine a leader’s impact, whereas a creative, empowering style enhances it.
**In summary:**
* _Reactive leadership_ optimizes for safety and control.
* _Creative leadership_ optimizes for trust, learning, and purpose.
## The Org Topologies Framework: Organizational Design Archetypes
Org Topologies is a framework for strategic organizational design that maps out archetypal ways to structure an organization. It introduces a **visual mapping technique**using two key dimensions of org design and defines multiple archetypal unit types.
Sixteen base archetypes (team or department patterns) are categorized into four groups, and, importantly, these are distilled into **three distinctive organizational “topologies”**– common overarching patterns of how work and authority are organized . Each topology represents a fundamentally different organizational ecosystem with particular characteristics and fit-for-purpose use cases . The three topologies are summarized below:
* **Resource Topology:**A siloed, efficiency-oriented design with frozen functional roles and high specialization. Here, work is divided among specialized units (e.g., separate functional departments), and _resources_ are managed to be 100% utilized. Leadership in this topology relies on **top-down coordination**– managers (or project management offices) plan work, allocate tasks, and monitor utilization across narrow skill silos. Because each group only performs a fragment of the process, extensive handoffs are needed for end-to-end delivery. Learning and innovation are limited; improvement tends to occur only within one’s specialization rather than through new discovery . _Use case:_ Resource Topology fits stable environments where maximizing resource efficiency and specialization is the primary goal (e.g., a project-based organization hiring specialists for defined tasks).
* **Delivery Topology:**A fast-flow, output-focused design that **upgrades to cross-functional teams**delivering value with fewer dependencies. Compared to Resource Topology, work in Delivery Topology is organized into independent _delivery units_(e.g., feature teams) that can produce “completely done” increments with minimal handoffs. This is often likened to a _“feature factory”_– teams churning out a steady stream of features for a product. There is a strong focus on **outputs and local efficiency**(throughput of features), and teams are kept **narrow in scope**so they can deliver quickly and predictably. High-level analysis or product decisions are still handled by “directing” roles or upstream units (product managers, analysts), meaning _discovery_ of _what_ to build remains somewhat separate from _delivery_. This topology excels when the challenge is not figuring out what to build (the requirements are known and of proven value) but rather delivering it rapidly at scale. _Use case:_ Delivery Topology is well-suited for environments where **predictable, speedy delivery**of features is critical and the market/problem is well-understood (for example, a software company rolling out frequent minor enhancements or a restaurant kitchen executing a set menu) .
* **Adaptive Topology:**A highly **adaptive and innovative**design that merges directing, doing, and delivering into unified, empowered teams. In Adaptive Topology, traditional functional boundaries are dissolved; instead of silos, the organization might form a _“team-of-teams”_ or network of multi-skilled teams that **work in unison across the entire value stream**. The goal of this topology is to maximize _adaptiveness_– enabling easy, continuous change based on learning, and true customer-centric innovation . Teams (and individuals) in an adaptive org are expected to collectively **discover**what customers need and **deliver**solutions rapidly, adjusting course as necessary. This requires a culture of continuous learning, high autonomy, and synchronous collaboration (often supported by real-time data and AI tools to inform decisions). The design makes it “cheap and easy” to pivot strategy because teams are broadly skilled and tightly aligned with the overall purpose, not confined to narrow tasks. _Use case:_ Adaptive Topology is fit for dynamic, uncertain environments where **innovation and agility**are paramount – for example, product R&D groups, startups, or market disruptors that must rapidly experiment, learn, and respond to change. It promotes long-term business resilience by enabling higher-impact outcomes and continuous adaptation.
**In summary**, each topology serves a different strategic goal and entails a distinct organizational structure: Resource topology optimizes for **resource utilization and specialization**, Delivery topology for **fast flow of outputs**, and Adaptive topology for **rapid learning and innovation (outcomes)**. These differences in structure and goal create different demands on leadership style, as we explore next.
## Mapping Leadership Styles to Organizational Topologies
The effectiveness of a leadership style is often context-dependent. A leadership approach that succeeds in a tightly controlled, efficiency-driven organization may falter in a fast-changing, innovative company, and vice versa. The Leadership Circle’s distinction between Reactive and Creative orientations provides a useful lens to map leadership styles onto the needs of each Org Topology.
Broadly, as an organization’s design shifts from **Resource**→ **Delivery**→ **Adaptive**, the leadership culture must shift from predominantly **Reactive**(command-and-control, cautious, task-focused) to increasingly **Creative**(visionary, empowering, collaborative) to support the organization’s purpose.
The table below summarizes this alignment:
**Organizational Topology****Best-Suited Leadership Style (Leadership Circle)****Organizational Needs & Rationale**
**Resource Topology**_Goal: maximize efficiency & specialization_**Predominantly Reactive**– directive, controlling style focused on stability and compliance.This topology’s siloed, plan-driven structure requires leaders who tightly coordinate and **enforce standard processes**. Reactive leadership tendencies (e.g., emphasizing control and risk-aversion) align with the need for predictability and utilization in a Resource topology, ensuring everyone follows the plan and stays “100% busy.” However, this can limit flexibility and innovation.
**Delivery Topology**_Goal: fast, predictable delivery of outputs_**Balanced/Transitional**– leaning Creative (achievement-oriented) but with some Reactive discipline.Delivery topology introduces **cross-functional teams and faster flow**, so leaders must **empower teams**to own delivery while still maintaining focus on output targets . A _Creative_ leadership approach that drives results and continuous improvement (high on the **“Achieving”**competency) suits this environment. Leaders foster collaboration and adaptiveness within teams, yet may retain **Reactive**elements like process control to ensure reliability and alignment with product requirements.
**Adaptive Topology**_Goal: continuous adaptation & innovation_**Predominantly Creative**– visionary, empowering, and facilitative style.An adaptive organization needs **leaders who inspire purpose, trust, and innovation**. Creative leaders excel here by providing vision and strategy while **empowering teams**to experiment, learn, and self-organize towards outcomes. In this high-change ecosystem, **reactive, control-oriented management would be counterproductive**– as research notes, truly adaptive/agile cultures _“require Creative Leadership”_, and reactive leadership cannot easily usher in the needed innovation and engagement. Leaders must cultivate a culture of trust, agility, and learning, embodying competencies like _Relating_, _Self-awareness_, and _Systems Thinking_ to enable the organization to thrive in uncertainty. At its core, [agile frameworks don't make you agile](/post/agile-frameworks-not-what-makes-you-agile) — treating people like adults does.
As the table illustrates, **leadership style and organizational topology need to be in sync**. A mismatch can create friction – for example, a purely reactive, micro-managing leader will likely stifle an Adaptive topology that demands empowerment and quick learning, while a purely visionary, hands-off leader may struggle in a Resource-focused bureaucracy that expects tight control. In practice, organizations often evolve through these topologies, and leadership mindsets must evolve in tandem.
## Evolving Leadership Development as Topologies Shift
Shifting an organization’s topology (e.g., moving from a Resource model to a more Adaptive model) is not just a structural change – it is a cultural and leadership transformation. Leaders must **develop new skills and mindsets**to support the new way of working. Below are some insights on how leadership development needs to evolve when an organization transitions from one topology to another:
* **From Resource to Delivery Topology:**Leaders need to **shift from micro-management to empowerment**as the organization moves toward cross-functional teams and faster delivery cycles. In a Resource topology, leaders were accustomed to detailed upfront planning, strict role boundaries, and ensuring compliance with plans. To succeed in a Delivery topology, they must _unlearn_ the overreliance on rigid plans and resource control. This means developing more Creative behaviors: trusting teams to self-organize within their scope, encouraging collaboration across functions, and focusing on outputs/outcomes rather than hours worked. Leaders should practice delegating decision-making to teams and fostering a culture of continuous improvement. In short, they transition from being task masters to being **enablers**– providing clarity and removing obstacles, while allowing teams more autonomy. This can be challenging, as it requires overcoming reactive impulses (e.g., the need to control every detail), but it is crucial for faster flow. By _“supporting testing of new approaches and learning from quick adjustments, instead of sticking strictly to preset plans,”_ leaders create an environment of trust and motivation in the Delivery context.
* **From Delivery to Adaptive Topology:**This shift demands an even deeper leadership transformation – from a results-oriented agile mindset to a truly **innovative and learning-focused**mindset. In moving to an Adaptive topology, leaders must fully embrace Creative leadership. They need to cultivate qualities like **visionary thinking, humility, curiosity, and systemic awareness**. Practically, this involves encouraging experimentation and accepting the risks of failure as opportunities to learn. Leaders must focus on _outcomes_ and customer impact over output, which means guiding teams with a compelling vision and then giving them freedom to discover solutions. Developing a **culture of empowerment and trust is paramount**: agile/adaptive leaders _“cultivate a culture of trust and empowerment, encouraging team members to take initiative and innovate,”_ which fosters an environment where experimentation thrives. Many traditional management habits (e.g., top-down decision making, extensive upfront analysis) must be shed in favor of facilitative leadership, coaching, and adaptation. According to Anderson and Adams (creators of the Leadership Circle), the _“innovative, agile, adaptive”_ organizational cultures of the future **require Creative leadership**– reactive, compliance-driven leadership **cannot**generate the level of engagement and innovation these organizations need. Thus, leadership development efforts should focus on building creative competencies (such as relationship building, strategic foresight, and self-awareness) and transforming leaders’ mindsets from controlling to **inspiring**. This often involves personal development work, coaching, and hands-on experience in agile ways of working. As leaders grow into this new mindset, they enable their organizations to fully realize the benefits of an Adaptive topology.
## Conclusion
Aligning leadership style with organizational topology isn’t optional — it’s decisive for performance.
Shifting from **Resource → Delivery → Adaptive**is never just about moving boxes on a chart. It also demands a parallel shift in leadership: **Reactive → Creative**. The two evolutions are inseparable.
Organizations that chase adaptability without Creative leadership will stall — this is exactly the [vicious cycle that gets Scrum Masters fired](/post/why-scrum-masters-are-getting-fired). Leaders who try to operate creatively inside a rigid Resource structure will suffocate. Both maps — the Leadership Circle and Org Topologies — point to the same truth: **you can’t elevate the system without elevating how you lead.**
The takeaway is clear: as companies push toward greater agility and innovation, they must invest in Creative, growth-oriented leadership at every level. Leaders who learn to act from **purpose and vision, not fear and control**, create the conditions for truly Adaptive organizations — ones capable of sustaining high performance in a world of constant change.
## Sources
* [The Leadership Circle –](https://leadershipcircle.com/leadership-assessment-tools/leadership-circle-profile/)[_Overview of Creative Competencies vs. Reactive Tendencies_](https://leadershipcircle.com/leadership-assessment-tools/leadership-circle-profile/)
* [Kestria Insights –](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)[_“Adaptable leaders: Embracing agility and lifelong learning”_](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)[(on empowering leadership in agile transformations)](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)
---
# Remote Work: Synthesizing the Studies
**Date:** 2025-08-08 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/remote-work-synthesizing-the-studies
**TL;DR:** A synthesis of remote work studies reveals consistent themes: loss of spontaneous interaction weakens cohesion, informal learning collapses, onboarding suffers, and trust requires active effort. The hallway conversations we dismissed as waste actually drove both team bonding and cross-pollination of skills.
Working on synthesising multiple studies related to remote work and co-locations. More coming about that in the future — see also my earlier piece [*Agile Teams Working From Home, WTF?*](/post/agile-teams-working-from-home-wtf) for practical principles on building virtual offices. I did a ChatGPT 5 research on it so far and asked for the impact on teamwork and learning. The result:
Synthesis of Key Patterns Across Studies
Consistent Themes in Teamwork and Learning
Several clear patterns emerge regarding teamwork under remote work. Almost every study noted the loss of spontaneous, informal interactions, which in normal offices serve to build camaraderie, share quick updates, and solve problems on the fly. This led to weaker team cohesion and social connection in many cases, as people felt more isolated or siloed from their colleagues. Communication had to become more deliberate and structured, usually via digital tools and scheduled meetings, which kept work moving but often at the expense of creativity, agility, and the richness of face-to-face dialogue. A related theme is diminished trust and team spirit – without regular in-person contact, teams had to work harder to maintain a sense of trust and shared purpose.
On the learning front, many studies highlighted reduced informal learning opportunities. Mentoring, coaching, and on-the-spot feedback were harder to come by in remote settings, impacting newcomers and junior staff the most. Onboarding new employees became a notable challenge in several cases, as it’s tough to integrate someone into the team and culture purely over video calls. Likewise, knowledge sharing often suffered – without hallway conversations or overheard discussions, employees had fewer chances to pick up insights outside of formal meetings. Over and over, the research underscores that casual “water-cooler” exchanges play a big role in both team cohesion and learning; when those vanished, organizations saw hits to collaboration quality and the ease of skill transfer. This is especially damaging for [multi-learning](/post/multi-learning-org-design-pattern-ai) — the cross-boundary skill growth that organizations increasingly need to stay adaptive. Social isolation and a weaker sense of belonging were repeatedly mentioned, which not only hurts teamwork but also deprives people of the confidence and networking that fuel professional growth.
---
# Multi-Learning in the Age of AI
**Date:** 2025-05-16 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/multi-learning-org-design-pattern-ai
**TL;DR:** Three patterns for matching skills to work: Static Matching locks people in place, Dynamic Reteaming shuffles them reactively, Multi-Learning grows them continuously. AI changes the economics — it acts as teacher and mentor, making multi-learning viable where it was previously too expensive.
An essential part of organizational design is aligning demand (work) with skills (resources) effectively. What does the Age of AI change?
Let's study three patterns of skill-to-work matching first.
## STATIC MATCHING
Static Matching is the most popular approach within IT and R&D organizations. It establishes a fixed, pre-planned mapping of usually single-skilled parties to roles through clear team boundaries and responsibilities. Here, organizations set up teams with specific, narrowly defined roles. This approach is prevalent in Resource Topologies, where predictability and deep specialization drive efficiency.
Static Matching reduces uncertainty and minimizes cognitive overload by ensuring every team member knows exactly what is expected.
Static Matching tends to be inflexible. When market conditions or technology requirements change, these rigid structures can become bottlenecks, forcing the organization to suffer delays while teams struggle to adapt. This inflexibility is what produces [the Ferrari Trap](/post/the-ferrari-trap) — everyone is faster individually, but the system doesn't improve.
## DYNAMIC RETEAMING
The common answer to these drawbacks? Dynamic Reteaming is a reactive strategy wherein teams are reorganized on an as‑needed basis to address emerging gaps or mismatches between work and skills.
When a gap is detected—such as a critical skill deficiency or a new technology challenge—leaders may temporarily reassign or shuffle team members to patch the problem. The benefits are clear -- a short‑term quick fix that enables the organization to meet immediate demands, potentially speeding up problem resolution.
Dynamic reteaming comes at a significant cost. It disrupts team cohesion, creates knowledge discontinuity, and introduces coordination overhead.
Are there more strategic? Yes, thanks for asking!
## MULTI-LEARNING
Unlike Dynamic Reteaming, which can be seen as a quick fix, Multi-Learning (ML) is a continuous, cross-disciplinary learning culture where individuals and teams regularly expand their skills and knowledge across functional boundaries.
In this paradigm, teams are encouraged to go beyond narrow roles—integrating tasks like client onboarding, support, and cross‑departmental collaboration into their core responsibilities. This may involve stretching the team’s Definition of Done to incorporate outcomes that previously lay outside their remit.
Advantages? ML fosters true adaptability. By building broader skill sets, teams become more resilient and capable of addressing unforeseen challenges without the need for constant reconfiguration.
Limitations? Also known as ML requires a significant investment in training, cultural change, and often a rethinking of performance metrics. Without sufficient support, the burden of multi‑learning can lead to overload.
## AGE OF AI
But in the Age of AI, these limitations are quickly softening as AI can be used as a teacher, mentor, and advisor — making [routine expertise give way to adaptive expertise](/post/routine-vs-adaptive-expertise). A multi-learning, versatile team can open a code repository they have never yet worked in and ask their AI coding assistance to describe the architecture, explain conventions, run tests, generate missing ones, and then eventually, bit by bit, build new functionality. For a deeper look at how 200 years of narrow specialization led us here, see [*Multi-Learning: 200 Years of the Wrong Model*](/post/multi-learning-200-years-wrong-model).
---
# Learning Modes of Adaptive Topology
**Date:** 2025-05-02 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/learning-modes
**TL;DR:** Four deliberate learning patterns for adaptive teams: Scouting (sense early), Mirroring (build empathy), Weaving (integrate across teams), Synthesizing (codify insights). These are operating patterns, not transformation tools. AI makes each mode cheaper and faster — multi-learning becomes ambient rather than expensive.
> _How work units learn inside an Adaptive Topology._
### **What Are Learning Modes?**
**Learning Modes**are lightweight, deliberate patterns that help individuals and teams continuously learn across boundaries—**without reorganizing**.
They are to learning what interaction modes (from Team Topologies) are to coordination: **repeatable, intentional behaviors**that make learning systemic.
In an Adaptive Topology, learning is not a side activity—it’s the primary flow. **Learning Modes describe how that learning happens inside the structure.**
### **How They Differ from Elevating Katas**
* [**Elevating Katas**](/post/elevating-katas-structured-routines)are structured practices that help an organization **move from a Resource or Delivery Topology toward an Adaptive Topology**. They drive transformation—by shifting roles, rituals, responsibilities, or mindsets.
* **Learning Modes**describe **how work units operate once they’re inside an Adaptive Topology**, where **continuous learning is part of the work itself**.
Think of Elevating Katas as _change agents_, and Learning Modes as _operating patterns_ for evolved teams.
### **Why Learning Modes Matter**
Learning Modes offer a better alternative: **practices that support**[**multi-learning**](https://www.linkedin.com/posts/alexeykrivitsky_i-think-by-now-everyone-read-the-letter-from-activity-7316739319560388609-qzn2?utm_source=share&utm_medium=member_desktop&rcm=ACoAAACU2WIBRxv-fzfhRRzp_TnWRfGcaiV3tk0)**within long-lived teams**, enabling them to evolve from within.
### **The Four Learning Modes**
1. **Scouting**
2. **Mirroring**
3. **Weaving**
4. **Synthesizing**
Each mode enables learning across different dimensions: individuals, teams, roles, and systems.
#### **1.Scouting**
> _Explore the unknown. Sense early._
Small groups or individuals go outside their team to gather insight from other domains, users, or markets. Scouting brings early awareness of friction, trends, and ideas.
**Example:**
A backend developer joins customer support sessions to learn common complaints.
An AI agent might suggest, “Team X solved a similar problem—want a summary?”
#### **2.Mirroring**
> _Build empathy. Transfer tacit knowledge._
One person shadows another in a different role to understand their challenges, decision points, and context—not to replace them, but to see through their lens.
**Example:**
Developers sit with real users to observe how they work—learning what to improve or automate based on actual behavior and struggles.
#### **3.Weaving**
> _Learn across teams. Integrate perspectives._
Multiple teams work together—temporarily or regularly—on a shared challenge. This mode breaks silos and builds cross-team coherence.
**Example:**
Several teams collaborate to solve a major customer problem, combining technical, business, and support perspectives.
#### **4.Synthesizing**
> _Institutionalize the learning._
Insights from other modes are codified into shared tools, practices, or standards. This mode ensures learning sticks and scales.
**Example:**
After repeated Mirroring between QA and Dev, teams co-develop a shared onboarding template and update their Definition of Done.
### **What Learning Modes Enable**
* Cross-role learning without reteaming
* Capability growth inside stable teams
* Resilience without overload
* Continuous adaptability in a fast-moving context
### **What Learning Modes Are Not**
* **Not Elevating Katas**– which change the structure or culture to help reach an Adaptive state
* **Not interaction modes**– which focus on delivery coordination (like X-as-a-Service or Facilitation)
* **Not team reshuffling**– which breaks trust and momentum
### **How AI Accelerates Learning Modes**
Learning has always required time, trust, and exposure. But with AI agents now embedded in everyday tools, **learning can happen faster, just-in-time, and context-aware**.
Here’s how AI augments each learning mode:
#### **Scouting + AI**
* Agents can proactively surface relevant examples, documents, or team artifacts.
* AI copilots can “scout” across internal tools, Slack, Confluence, or code to find prior solutions.
**→ “This pattern was used in a similar case—want to see the code or talk to the team?”**
#### **Mirroring + AI**
* AI agents can track sessions, summarize insights, or suggest questions to deepen learning during a mirroring experience.
**→ “While observing the user workflow, notice how they hesitate on this step. Want to explore why?”**
#### **Weaving + AI**
* During cross-team problem-solving, AI tools can surface common dependencies, conflicting priorities, or shared risks.
* Agents can document shared learnings across teams automatically.
**→ “These 3 teams use different auth flows—would you like a synthesis report?”**
#### **Synthesizing + AI**
* AI can generate first drafts of shared artifacts—onboarding guides, updated playbooks, or code documentation—based on conversation logs and patterns.
**→ “Here’s a suggested update to the team’s Definition of Done based on what was discussed.”**
Without AI, learning across teams is expensive and slow. This is why [multi-learning has been misunderstood for 200 years](/post/multi-learning-200-years-wrong-model) — it was seen as prohibitively costly.
With AI, it becomes ambient and constant—**multi-learning becomes a background capability.** And as [strategic AI adoption](/post/elevate-org-with-strategic-ai-adoption) shows, the investment should target the specific archetype bottlenecks in your organization.
Learning Modes don’t change. But AI makes them **cheaper, faster, and easier to sustain and with manageable levels of cognitive load.**
### **In Summary**
> In an Adaptive Topology, learning is the work.
They help teams stretch, connect, and grow—**without needing to be rebuilt.**
Used consistently, they reduce the need for structural change and make adaptability scalable — the same adaptability that distinguishes [routine from adaptive expertise](/post/routine-vs-adaptive-expertise).
---
# AI-Augmented Multi-Team PBRs
**Date:** 2025-04-28 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-augmented-multi-team-pbrs
**TL;DR:** Multi-team PBRs are where teams learn together. AI applied during refinement — not before or after — lets teams interrogate knowledge directly, reducing dependency on expert preparation. The cognitive load criticism of LeSS dissolves when AI delivers information just-in-time in digestible chunks. AI is not just a doer; it is a teacher.
LeSS—an org design system for large-scale product development—describes Multi-Team Product Backlog Refinement as one of the key enablers of organization-wide adaptability.
Multi-team PBRs are where teams learn from customers, stakeholders, and each other. This is where all the involved teams dive into the problem space to come up with innovative and effective product experiments.
## Forward-Looking Orgs with AI-Augmentation
Today, AI augmentation offers a powerful and complementary capability: accelerating deep, multi-directional learning during PBRs without compromising the core LeSS design principle of simplicity.
We can think of many AI applications that can streamline the learning process, especially in product backlog refinement events.
Using my recent post on Never Read Alone, I explained how AI can enable teams to interrogate vast datasets, including user feedback, legal regulations, and competitor analysis, with just-in-time learning via AI-powered dialogs over any given corpus of knowledge. This amazing innovation must also be used during refinement.
And not before or after—a critical aspect.
A typical dysfunction of a PBR event is overpreparation by product managers and other expert roles who act as knowledge providers, turning the teams into students. Though it is essential for teams to learn, minimizing the associated process waste of knowledge transfer would be beneficial.
Namely, applying AI right in the PBRs to learn and structure knowledge, by the teams directly, can dramatically reduce the need for an expert or a special role to prepare for these meetings.
I predict that this will become increasingly common now, in the age of AI. For the broader organizational pattern, see [*Multi-Learning in the Age of AI*](/post/multi-learning-org-design-pattern-ai).
AIs (even before the hypothetical emergence of AGI) are already more knowledgeable than any average subject-matter expert and can easily cross-pollinate between domains. Teams that find ways to learn from AIs will no longer need to rely on and wait for part-time human experts. Thus, streamlining the learning process makes it way leaner than imaginable.
The main criticism of LeSS-inspired org design is the high cognitive load in teams, potentially caused by the constant need to learn and switch context — the same concern raised in discussions about [the scope of skills mandate](/post/teams-and-scope-of-skills-mandate). AI, when applied systemically and methodically, can reduce the burden of absorbing complexity by providing information in a clear structure, in smaller chunks, just in time, with runnable examples, etc.
These a few examples I'm bringing above are very different from how most people currently see and use AI.
Somehow, the whole narrative revolves around using AI agents as free labor. Although this is probably where many innovations will be made due to obvious economic reasons, AI is not limited to doing things. The broader story is [AI-supported org design](/post/ai-supported-org-design) — using AI strategically to evolve how organizations are structured and how people learn.
> AI is not (just) a doer, it is a great teacher.
---
# Shopify CEO: Reflexive AI Usage
**Date:** 2025-04-12 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/shopify-ceo-reflexive-ai-usage
**TL;DR:** Shopify's reflexive AI mandate is bold but insufficient. Amplifying a single skill with AI won't save you — single-skill jobs are the first to be automated away. The real move is becoming an M-shaped multi-learner with several deep specialisms. AI makes that feasible for the first time in history.
I think by now everyone read the letter from Shopify CEO on “Reflexive AI Usage as a Baseline”?
This reads like a mega-bold statement and very timely. We can now expect a wave of CEO letters to follow. Good. Everyone agrees that AI is something that cannot be ignored if your business aims to keep the market relevancy.
And I want to take this one level higher. Let me explain.
Yesterday I did a talk for our Org Topologies members titled “Versatile”. There I shared a premise that it is not just enough to amplify your current primary skill with AI.
Example: visual design, frontend coding, or alike. Such single-skill jobs will be the first ones to be taken away from humans by AI agents; already starting in 2025. When [AI replaces the task and your job equals the task](/post/ai-replaces-tasks-not-people), the math is straightforward.
If we want to stay relevant (a repeated keyword) we need to multi-learn. In other words: become M-shaped professionals with several deep specialisms. Scary? Difficult? Impossible?
[Multi-learning](/post/multi-learning-200-years-wrong-model) is not a new topic. For example it was referred to in HBR already in 1986. But it had been vastly seen as a myth and a trait of very rare high-IQ individuals. And fairly so.
But that was before 2025.
Now—is when the history branches off. Embrace versatile multi-learners.
Most who tried AI augmentation at work, realize that the AI facilitates and accelerated learning like nothing else. And the technological progress is still accelerating.
We are entering not just the era of AI and AI augmentation of work.
We are about to witness the rise of multi-learners that are 100x in value they can produce (that’s not some marginal step process improvement).
And on the personal level? What does it mean for all of us?
Our claim: m-shaping is an ultimate solution for staying relevant, preserving our jobs, and on top of that do amazing things for our customers, communities, and the whole world. The organizational structure must support this — as [*Tailwind Career Paths*](/post/tailwind-career-paths) explores, traditional career ladders reward narrow specialization and punish exactly the breadth that makes people resilient.
---
# AI-Supported Org Design
**Date:** 2025-04-10 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-supported-org-design
**TL;DR:** AI OD is the strategic use of AI to evolve how organizations are structured and how people learn. Two anchoring principles: AI makes versatile teams viable by collapsing the cost of learning adjacent skills, and multi-learning becomes the engine of continuous adaptation. This is not a productivity story — it is an org design story.
## A larger landscape than individual productivity
AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025 — but as [the Ferrari Trap](/post/the-ferrari-trap) shows, faster individuals in unchanged structures produce no system-level gain. There is a much larger landscape. Let me share.
AI-Supported Org Design — *AI OD* for short — will become a hugely impactful topic affecting all of us and all the organizations in which we work.
AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.
It is not about replacing managers or employees. It is about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day.
Two principles anchor it:
- **The core organizing principle:** AI makes versatile teams viable.
- **The core operating principle:** With multi-learning as the engine.
How do these principles differ from applying AI for individual performance gains? Let me unpack.
## Organizing principle: AI makes versatile teams viable
Most organizations are still designed around narrow specialization — single-skill roles, component ownership, hand-offs between functions. That design made sense for [200 years of factory logic](/post/multi-learning-200-years-wrong-model), when learning a new craft was slow and expensive.
AI changes the economics of learning. When an AI agent can teach a backend developer the basics of customer support flow, or walk a support agent through writing a Python script, the cost of acquiring adjacent skills collapses. What used to require a re-org now becomes a learning act inside the team.
That is what unlocks *versatile teams* — teams broad enough to follow the work end-to-end, with AI as the always-available teacher and accelerator.
## Operating principle: with multi-learning as the engine
If we unpack this principle, it is all about applying AI to support the organization's development direction and accelerate its evolution to gain high performance and other competitive advantages.
That is strategic AI application.
Three sub-principles guide it:
### #1 — Multi-learning enables adaptivity
Especially in Adaptive Topologies (see the *Org Topologies* primer for details), learning — not just delivery — is the primary currency. AI enables this by making the unknown known and the unlearnable learnable, with ease.
Sample scenarios:
- A backend developer shadows a customer support session and begins contributing to onboarding scripts.
- A frontline support agent learns enough Python to automate common diagnostic steps, reducing ticket escalations and easing the load on developers.
- An end-to-end team includes privacy review and data protection steps in their regular sprint workflow — not because they were forced to, but because someone on the team got curious, shadowed legal, and brought that knowledge back in.
- A delivery manager starts using AI tools like Cursor or GitHub Copilot — not to replace anyone, but to better understand how her teams are using it, what it is good at, and the current limits.
### #2 — Matching work to skill in real time
Rather than static org charts or disruptive reshuffles, AI supports the continuous alignment of skills to work based on live data and evolving interests. When multi-learning is too expensive, AIs will suggest *micro-reteaming* without major upheaval as a temporary, quick-fix solution.
- **Static matching:** pre-analyze and pre-plan work.
- **Dynamic reteaming:** reallocate people when needed.
- **Multi-learning:** give people the mandate to learn.
When multi-learning is a part of work, managers do not need to waste time and energy preplanning or reteaming. People can follow the work and learn what is necessary to achieve the expected outcomes. This is the organizational capability that makes [both wings of a 10X organization](/post/two-wings-of-a-10x-bird) work.
### #3 — Learning becomes the flow
AI agents will surface relevant prior work and recommend five-minute learning prompts when patterns emerge.
> "Team X solved this two sprints ago."
>
> "Want to see how testing was solved in a similar sprint?"
That is learning embedded in the flow of work, not pulled out into a separate training program.
## Strategic AI in org design
AI-powered org design harnesses AI to make teams inherently versatile and learning deeply integrated — driving adaptable, resilient organizations without the need for constant structural upheaval.
This requires practicing a new mindset: seeing AI not as a tool to output more, but as a strategic lever that enables humans with easier multi-learning and higher outcomes.
> AI OD is not a productivity story. It is an organizational design story — with AI as the amplifier of human adaptability.
That is what [Org Topologies](https://orgtopologies.com/) offers as a field guide for leaders in this disruptive era of AI we all happen to live in, in collaboration with Roland Flemm and Craig Larman.
---
# Org Topologies meets EBM
**Date:** 2025-02-24 · **Reading time:** 10 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/org-topologies-with-evidence-based-management
**TL;DR:** OT tells you what to change in the structure; EBM tells you whether it worked. Together they close the loop: EBM identifies symptoms, OT treats root causes, EBM measures treatment effectiveness. Each structural change becomes a testable experiment with measurable outcomes — scientific org evolution.
This article starts by laying down the key principles of EBM applied within an OT-inspired org change. It opens with a crisp description of both methods and then dives into how they work together to reinforce a systemic org change with a strong focus on measuring value.
Org Topologies recognizes **Measure and Improve Value with EBM (for Enhanced Performance and Agility)** as one of the [Elevating Katas](https://www.orgtopologies.com/elevating-katas) — a set of principles, methods, and guides for moving an org design closer to the upper right on the Org Topologies map.
If you know both methods, jump to the later section where they are compared, contrasted, and integrated. For a complete guide on Evidence-Based Management, refer to the [Scrum.org EBM page](https://www.scrum.org/resources/evidence-based-management).
In this article, we claim the following to be true:
> OT provides the actionable changes and EBM provides the measure of success, enabling a *scientific approach* to organizational evolution.
> EBM identifies the symptoms, OT treats the *root cause*, and EBM then measures the treatment's *effectiveness*.
> EBM measures act as a *compass* ensuring Org Topologies changes truly lead to *agility*.
## Org Topologies: Principles and Methodology
**Org Topologies (OT)** is a framework for strategic organizational design and change. It is described as the first *"human-centric plus AI-friendly"* approach to organizational change. This means it emphasizes the human side of change (people need to *own* their change and find it engaging) while anticipating the integration of AI into the workforce.
Key principles and components of Org Topologies include:
- **Psychology of Change:** OT recognizes that lasting change occurs when people across the organization participate and take ownership, rather than having changes imposed top-down. It provides a *visual and collaborative mapping* process so everyone can *"visualize, discuss, understand, and shape the change"* together. This shared understanding creates a common language for organization design and engages everyone in the transformation.
- **Fit-for-Purpose Design:** Org Topologies aligns organizational structure with the organization's strategic goals or "North Star." Different business goals (e.g. rapid delivery, adaptability, resource efficiency, innovation) *require different tailored org designs*. OT helps leaders define the right target design to achieve their specific objectives and keep the organization *"fit for purpose"* as those objectives evolve. It works at any scale — entire enterprise or subdivisions — to ensure structure, strategy, and change process are all aligned.
- **Organization Mapping and Archetypes:** A core methodology in OT is mapping the current organization into **archetypes** on a two-dimensional grid. The two axes represent fundamental dimensions of org design, such as the growing **scope of skills mandate** (depth of cross-functional skills) and **scope of work mandate** (breadth of product/customer scope). OT defines a set of common patterns (archetypes) for how teams or units are structured and operate — a deeper look at how these archetypes emerge is in [*Determining Archetypes*](/post/determining-archetypes). In the latest version, there are 16 archetypes organized into four groups and positioned along the two axes. This **Org Topologies Map** is a visual tool to assess where the organization is today and identify mismatches between the current design and the capabilities needed to meet business objectives.
- **Topologies and Organizational Patterns:** The archetypes are further grouped into three broad **topologies** — often described as **Resource**, **Delivery**, and **Adaptive** topologies. Each topology represents a distinctive way the organization coordinates work:
1. *Resource Topology* (traditional model): characterized by specialized, siloed teams managed via centralized coordination (emphasis on resource utilization). *Directing* units (like PMOs or managers) decide work, and *Doing* units execute, often leading to hand-offs and dependencies. This can maximize local efficiency but often sacrifices adaptability and speed.
2. *Delivery Topology:* focuses on the fast flow of outputs by using cross-functional teams and removing inter-team dependencies. Teams are structured as "complete" delivery units (often called feature teams or *"feature factory"* style) that can produce a steady stream of features with short lead times. However, work definition (the *"what to build"*) is usually still driven by separate planning or analysis roles (discovery is handled apart from the delivery teams). This topology excels when the main challenge is **predictable, rapid delivery** of known features rather than exploring unknown market needs.
3. *Adaptive Topology:* aims for maximum *adaptiveness and innovation*. It **merges directing, doing, and delivering into one** unified unit. In this model, teams (or *"team-of-teams"* networks) are empowered to both discover and deliver value continuously, often working with a broad product scope and high synchrony across the organization. Humans, AI agents, and even robots collaborate in these *"Driving"* units to solve complex problems, learn, and adapt on the fly. The Adaptive topology's goal is to enable quick, cheap responses to change and to *"discover and deliver higher-impact customer outcomes"*, supporting long-term business resilience. This design is fit for organizations where growth, learning, and customer-centric innovation are paramount.
### Intended Application of OT
Org Topologies is intended for any industry or domain seeking to improve organizational agility and performance — from software product companies to farms or construction firms. It is especially useful in agile and digital transformations, where existing structures hinder fast delivery, adaptability, or innovation. By using OT, leaders gain a "critical managerial tool" to drive performance via org design. For example, OT can be overlaid with frameworks like SAFe, LeSS, or even non-tech models like Haier's Rendanheyi to map and enhance an Agile Release Train or a networked organization. (For a real-world case of this in action, see [*Studying Org Designs: Haier, RDHY, Bayer, DSO*](/post/studying-org-designs-haier-rdhy-bayer-dso).) Overall, Org Topologies helps organizations "align all the moving pieces" — structure, strategy, and change efforts — to achieve strategic goals in a sustainable way.
## Evidence-Based Management (EBM): Principles and Methodology
**Evidence-Based Management (EBM)** is a framework developed by Ken Schwaber and [Scrum.org](https://www.scrum.org/resources/evidence-based-management) to help organizations continuously improve by making decisions based on evidence and measurable outcomes. EBM is built on three core pillars: clearly defined **Goals**, targeted **Measures**, and the discipline of **Empiricism**. These pillars work together — our goals set the strategic direction, the measures (including KVAs) provide evidence, and empiricism drives continuous learning and adaptation. The method provides a disciplined, empirical approach for management and teams to achieve strategic goals in the face of uncertainty.
Key principles and components of EBM include:
- **Empiricism and Experimentation:** EBM advocates that organizations tackle complex, uncertain challenges through *intentional experimentation and frequent feedback*. Rather than making big up-front plans, teams and leaders set *incremental goals*, run experiments, and use data to decide the next steps. In practice, this means forming a hypothesis about how an improvement or change might move the organization closer to its goals, implementing that change on a small scale, and measuring the results against expected outcomes. Based on the evidence gathered, the organization adapts its tactics or even revises its goals. This iterative loop mirrors Scrum's empiricism at a management level, ensuring that *decisions are grounded in real-world data* rather than assumptions.
- **Value-Focused Goals:** In EBM, all efforts are oriented toward improving *outcomes* (value delivered), not just outputs. Organizations are encouraged to express their aspirations at multiple levels — a Vision (the ultimate change they seek to make in the world), a Mission (why they are uniquely positioned to achieve that vision), and concrete Goals that lead toward fulfilling them. However, EBM notes that many organizations struggle to create effective goals that drive real progress toward their mission and vision. EBM addresses this by helping organizations set **Strategic Goals** (long-term objectives connected to mission), break them into nearer-term **Intermediate Goals**, and then into very short-term **Immediate Goals** that teams can act on now. Crucially, each goal should have *measurable criteria* so the organization can inspect whether changes are actually moving the needle. This keeps goals outcome-oriented (e.g. improving customer satisfaction) rather than activity-oriented, and it ensures every level of goal is aligned with delivering real value.
- **Key Value Areas (KVAs):** A cornerstone of EBM is measuring value and capabilities in a **balanced way**. EBM defines four broad **Key Value Areas** which act as lenses on different aspects of organizational performance. These KVAs help teams and managers focus on what to improve and avoid blind spots.
The four KVAs are:
1. **Current Value (CV):** How much value the product or service delivers to customers *today* (e.g. customer satisfaction, revenue, market share).
2. **Unrealized Value (UV):** The potential future value that could be unlocked if the organization better met all possible customer or user needs — essentially the gap between current value and what *could* be achieved (e.g. untapped market segments, additional features that could attract new customers).
3. **Ability to Innovate (A2I):** How effectively the organization can deliver new capabilities or improvements (e.g. innovation rate, technical excellence, experiment frequency). This reflects the organization's capacity to adapt and innovate in response to market needs.
4. **Time to Market (T2M):** How quickly the organization can deliver a new idea or change and gather feedback on it (e.g. release frequency, lead time for changes).
### Intended Application of EBM
EBM was initially formulated in the context of software and product delivery organizations adopting Scrum, but it is broadly applicable to any enterprise seeking to improve its results under uncertainty. It is especially useful when an organization has adopted Agile practices but wants to ensure those translate into real business value. For example, a company might use Scrum for development; EBM provides the *management framework* to measure whether Scrum is delivering the expected improvements in customer value, time to market, etc., and to guide further changes. Typical applications of EBM include setting organizational OKRs or targets in terms of KVAs, assessing the impact of transformations (e.g., "Are we actually reducing time-to-market with this new process?"), and steering investments toward initiatives with evidence of high impact. Because it is framework-agnostic, EBM can overlay any process or structure, providing a way to *"measure, manage, and increase the value [an organization] derive[s] from their product delivery"*. Ultimately, it helps organizations *"improve outcomes, reduce risks, and optimize investments"* by empirically guiding decisions at all levels.
## How OT and EBM Complement and Contrast Each Other
Because Org Topologies and EBM operate in different yet related domains (structure vs. measurement), they can be used together in a complementary fashion.
### Complementary Use Cases
In an organizational transformation, one can use Org Topologies to *design the change* and EBM to *drive and verify the change*. For example, if a company's strategic goal is to improve innovation and adaptability, Org Topologies might suggest moving toward an Adaptive Topology — merging discovery and delivery functions into autonomous product units.
EBM would complement this by tracking **Ability to Innovate** and **Unrealized Value** metrics to see if the structural change actually increases innovation output or unlocks new market value. In fact, Scrum.org notes that their EBM framework is a good way to ensure *"rigorous experimentation and a balance between value indicators"* during change efforts.
Meanwhile, Org Topologies *"offers a powerful tool for assessing the [current] situation and outlining the changes needed"* to reach those objectives. Together, OT can tell you *what* to change in your org design, and EBM can tell you *whether those changes are producing the desired results*.
This closes the loop between design and outcome:
- **Strategy Alignment:** Org Topologies helps translate strategic objectives into an appropriate organization design (e.g. choose a topology that fits a strategy of rapid delivery or one that fits a strategy of innovation). EBM ensures that those strategic objectives are clearly articulated as measurable goals and provides feedback on progress toward them. The two together ensure that structure and strategy are continually aligned and validated. If strategy shifts, EBM will catch changes in outcomes, and OT provides a mechanism to adjust structure accordingly.
- **Navigating Change Safely:** Both frameworks stress incremental change, so used together they encourage a safe-to-fail approach. Org Topologies might implement a pilot re-organization in one product line (Elevate step with experiments), and EBM would measure the pilot's impact in terms of value (did customer outcomes improve? did time to market improve?). If the metrics show positive evidence, the new design can be rolled out wider; if not, the organization can iterate on the design. This complementary approach reduces the risk of large-scale changes — you're not "flying blind" with a new org structure because EBM is instrumenting the change with data.
- **Balancing People and Performance:** Org Topologies brings in the human element — making sure people understand the why of changes, and that roles and team boundaries are set up for collaboration rather than confusion. EBM brings in the performance focus — making sure the changes actually deliver business results, not just feel good. In some transformations, there's a risk of over-focusing on org charts and forgetting to measure outcomes (which EBM prevents), or conversely over-focusing on metrics and ignoring morale or clarity (which OT prevents by involving people in design). Together, they provide a more holistic transformation: *structural, cultural, and outcome-based* considerations are all addressed.
### Contrasting Considerations
On the other hand, using both requires understanding their different mindsets. Org Topologies might identify a **structural problem** (say, too many narrow-component teams causing slow integration). EBM might identify a **value problem** (say, low customer satisfaction). These may or may not point to the same solution initially — it takes skilled interpretation to connect the two.
For instance, EBM could reveal a problem (low Current Value) that is due to factors outside org structure (maybe a poor product-market fit or outdated technology). Org Topologies might propose structural changes that need careful justification via evidence (to avoid reorgs that don't pay off). In some cases, one framework might challenge the other: EBM's data might suggest that a recent structural change (inspired by OT) is not yielding results, which could mean re-thinking the change or giving it more time.
Conversely, an OT practitioner might caution that certain performance drops are expected short-term during re-structuring and that patience is needed. Therefore, while they complement each other, it's important to synchronize **cadence** and **perspective** — using EBM's evidence to inform Org Topologies decisions, but also using Org Topologies wisdom to interpret EBM data in context.
Another contrast is in **scope of impact**: Org Topologies changes can have far-reaching consequences on people's roles, team identity, and day-to-day work (which can be disruptive even if ultimately beneficial). EBM's introduction (measuring things, setting new goals) is usually less structurally disruptive but can change mindsets and accountability. An organization needs to manage both the structural change management and the cultural shift to evidence-driven management. Leaders might choose to introduce EBM practices first (to identify where change is needed and build a culture of empiricism), or introduce Org Topologies first (to fix glaring structural bottlenecks), or do both in tandem. There's no one right sequence, but it's wise to communicate how they interrelate so teams don't feel like "yet another initiative" piled on.
## Elevating Kata: Measure and Improve Value with EBM
When integrated thoughtfully, Org Topologies and Evidence-Based Management can reinforce each other to significantly enhance organizational performance and agility. Here are some ways an organization might combine the two frameworks:
- **Data-Driven Org Design:** Use EBM **metrics as diagnostics** to drive Org Topologies interventions. For example, suppose EBM reveals that *Time to Market* is too slow and *Current Value* is stagnating. This quantitative evidence can trigger a closer look at org structure: perhaps teams are organized in a Resource Topology with many dependencies causing delays. Org Topologies would then provide a method to redesign toward a Delivery or Adaptive Topology (e.g. introduce more cross-functional teams, reduce hand-offs) to address the problem. After making structural changes, the organization continues to track the relevant KVA metrics. If Time to Market improves and Current Value starts rising, it validates the structural approach; if not, further adjustments are made. In this way, **EBM identifies the symptoms, OT treats the root cause**, and EBM then measures the treatment's effectiveness.
- **Continuous Feedback into Structure:** Apply an **EBM loop within the OT "Elevate" phase**. As Org Topologies changes are implemented incrementally, each change can be treated as an EBM experiment. Define an expected outcome (e.g. "by merging Team A and B into a single value-stream team, we expect deployment frequency to double in that product line"), implement the change, and measure the outcome (deployment frequency is a proxy for Time to Market KVI). This creates a tight feedback loop: structural change → metric outcome → learn → next structural change. It prevents the organization from over-correcting or making broad changes without evidence. Essentially, OT provides the *actionable changes* and EBM provides the *measure of success*, enabling a **scientific approach to organizational evolution**.
- **Strategic Goal Alignment Workshops:** An integrated practice could be running a workshop where leadership uses EBM to set or refine strategic goals/KVAs, and simultaneously uses Org Topologies mapping to evaluate if the current org can meet those goals. For instance, leadership might set a goal to increase **Unrealized Value** (capturing a new market segment). In the same session, using Org Topologies maps, they might discover that the current structure has no dedicated product team exploring that new market (perhaps all teams are tied up delivering current features). This insight leads to an Org Topologies design solution (e.g. create a new "Explore" team archetype or reassign an existing team's mandate to include the new segment). They would then implement that and use EBM to monitor if Unrealized Value (e.g. percentage of market captured or new customer adoption) starts to go down, indicating value is being realized. This illustrates how strategy → structure → metric integration can happen in a seamless flow.
- **Combining Language and Measures:** Org Topologies provides a **common language** for org structure (with terms like CAPS, WHOLE, topologies, etc.), and EBM provides a common language for value and improvement (CV, UV, etc.). Together, they can help different parts of the organization communicate. For example, an agile coach might say *"We need to elevate from a CAPS-1 to a CAPS-3 team to reduce dependencies,"* and a product manager might add *"Yes, that should improve our Time to Market."* When both the structural change and the expected outcome are clearly expressed, it creates alignment between organizational development efforts and business results. This integration of lexicon — structural terms coupled with value metrics — ensures everyone understands not just *what* change is happening, but *why* (what outcome is expected). It ties the abstract concepts of org design to concrete business metrics that people care about.
- **Ensuring Balanced Change:** EBM's four KVAs ensure that while pursuing one improvement, you don't hurt another. An organization integrating OT and EBM will use those metrics to check that a structural change aimed at one dimension doesn't inadvertently damage another. For example, moving to a Delivery Topology might speed up delivery (better T2M) but, if done in isolation, could lead to feature factory syndrome where lots of output doesn't increase customer value (CV). By keeping an eye on Current Value and Unrealized Value, leaders can detect if they are churning out features with no outcome — and then course-correct by incorporating more "Adaptive" elements (e.g. ensure teams also have discovery capability, not just output focus). Thus, the **EBM measures act as a compass** ensuring Org Topologies changes truly lead to agility (ability to respond) *and* real value creation, not one without the other.
- **Scaling and Sustaining Gains:** Over time, as an organization iterates between OT-driven changes and EBM-driven measurements, it can develop a capability for **self-tuning**. The structural changes (OT) solve immediate bottlenecks, and the measurement (EBM) ensures new bottlenecks or opportunities are quickly identified. This synergy can accelerate an agile transformation or any continuous improvement initiative. Org Topologies changes might happen at a slower cadence (since structural moves take planning), while EBM cycles can happen very frequently. An integrated approach might use EBM continuously (say, quarterly outcome reviews, monthly metric check-ups) and use Org Topologies periodically (say, an annual structural review or on-demand when EBM indicates a plateau). When both are embedded into the management practices, the organization is equipped to *adapt both its strategy execution and its structure in concert*. This leads to what we might call **organizational agility** in the truest sense: the organization can reconfigure itself (structure, teams, processes) and redirect itself (goals, investments) with relative ease, based on evidence, to seize opportunities or avoid threats.
## Key Metrics Aligned to Organizational Topologies
The **Evidence-Based Management (EBM) Guide (2024)** Appendix provides example Key Value Measures (KVMs) that organizations can use to gauge value and improvements. Each organizational topology — **Resource**, **Delivery**, and **Adaptive** — emphasizes different goals, so certain metrics from the EBM examples will be more suited to each.
Below are three exemplary key metrics fit for each topology, along with explanations of how each metric aligns with that topology's characteristics and goals.
### Resource Topology
*Org Goal: maximizing resource utilization and specialization*
| Metric (Key Value Area) | Alignment with Resource Topology |
|---|---|
| **Product Cost Ratio** *(Current Value)* | Measures total product expenses relative to revenue. A lower cost-to-revenue ratio reflects greater efficiency in resource utilization, supporting a Resource-focused organization's aim to optimize costs and maximize the output from each resource. |
| **Revenue per Employee** *(Current Value)* | Indicates how efficiently each employee (resource) generates value. A higher revenue per employee means the organization gets more output per resource, aligning with the Resource Topology's goal of maximizing resource use and efficiency. |
| **On-Product Index** *(Ability to Innovate)* | The percentage of time teams spend working directly on product value (vs. overhead). A high on-product index means most of the workforce's time is spent on productive, value-adding work, which aligns with maximizing resource productivity in a Resource Topology (minimizing idle time or context-switching). |
### Delivery Topology
*Org Goal: maximizing output and predictability of delivery*
| Metric (Key Value Area) | Alignment with Delivery Topology |
|---|---|
| **Release Frequency** *(Time to Market)* | Measures how often the product is released (e.g. daily, weekly, etc.). Frequent releases indicate a high throughput of features to customers, matching the Delivery Topology's emphasis on steady output and regular delivery of value. This metric shows the capability to deliver predictably and often. |
| **Lead Time (to Value)** *(Time to Market)* | The time from an idea or requirement being proposed to it being delivered and benefiting the customer. Short lead times demonstrate fast turn-around from concept to delivery, reflecting the Delivery Topology's goal of rapid, predictable delivery of proven value. |
| **Change Failure Rate** *(Ability to Innovate)* | The percentage of releases that result in failures (e.g. require hotfixes or rollbacks). A low change failure rate means releases are generally stable and successful, supporting the Delivery Topology's focus on predictability and quality in output. This ensures that increasing release speed doesn't come at the cost of reliability. |
### Adaptive Topology
*Org Goal: maximizing outcomes and innovation through fast adaptation*
| Metric (Key Value Area) | Alignment with Adaptive Topology |
|---|---|
| **Customer Satisfaction** *(Current Value)* | Gauges how happy customers/users are with the product (e.g. via surveys or NPS). High customer satisfaction indicates the organization is delivering valuable outcomes, not just outputs. This aligns with the Adaptive Topology's goal of maximizing customer-centric outcomes (delighting customers through continual learning and adaptation). |
| **Time To Pivot** *(Time to Market)* | Measures how quickly the organization can change direction in response to feedback or market changes. A short time to pivot reflects true business agility — the hallmark of an Adaptive Topology — demonstrating easy, cheap change based on learning and a capacity to rapidly adapt strategy. |
| **Innovation Rate** *(Ability to Innovate)* | The percentage of effort spent on developing new product capabilities (versus maintenance). A higher innovation rate means the organization dedicates more of its resources to creating new value. This supports the Adaptive Topology's focus on innovation and exploration, ensuring the organization can continuously evolve and deliver novel solutions. |
## Summary
In summary, Org Topologies and Evidence-Based Management are distinct but highly complementary frameworks. **Org Topologies** provides the *"where and how to change"* from a structural perspective, ensuring the organization's form enables agility and aligns with its purpose. **EBM** provides the *"whether and why to change"* from a value perspective, ensuring the organization's operations remain focused on delivering measurable value and that any change is justified by evidence.
Their key principles differ — one is about *designing the system*, the other about *measuring and steering the system* — yet they share a foundation in agile, empirical thinking and can mutually reinforce success. By integrating the two, organizations can avoid the pitfalls of structure-blind improvement or improvement-blind structure. Instead, they gain a powerful combined approach to become both well-organized and continuously learning — ultimately enhancing performance, adaptability, and agility in a sustainable way.
For a broader look at what "adaptive" means in practice, see [*In Search of Adaptivity and Fit*](/post/in-search-of-adaptivity-fit). This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous.
---
# Strategic AI Adoption
**Date:** 2025-02-15 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevate-org-with-strategic-ai-adoption
**TL;DR:** AI makes specialization cheap — broader skill mandates and higher archetypes become feasible. Don't spray AI generically. Three strategic questions: Where are you elevating? What archetype bottlenecks can AI break? Do the AIs need human monitoring? Focus investment where it unblocks the specific move you're making on the OT map.
> **Any management approach that doesn’t include AI as a central part of the future workforce is of the past. We are rapidly entering a world of AI agents and humanoid robots playing a role at work and home.**Org Topologies Primer 2025
A key insight when designing with OT: _Specialization and expertise are vanishing as limited resources, due to intelligence as a service_. This is the practical consequence of what I describe in [*Multi-Learning: 200 Years of the Wrong Model*](/post/multi-learning-200-years-wrong-model). That makes it _much_ easier to elevate an organization! So when you are deciding on new teams requiring new expert knowledge, shed the old assumptions, “We don’t have enough experts, therefore…”. Spin up another 10,000 agents.
Evolving rightward on the horizontal axis to broader skills mandate will become ever easier due to AI. And likewise upward on the vertical axis to a broader work mandate. So, top-right _Driving_ archetypes will become more feasible.
Obviously, “adopt AI everywhere you can” will be the general guidance — but as [the Ferrari Trap](/post/the-ferrari-trap) shows, generic AI adoption without structural change produces no system-level gain. Given the limited resources of money, time, and attention, in strategic org design with OT we recommend that you ask and answer these questions:
> 1. What parts of the organization are the focus of development with OT?
Focus your AI investment in the area you are elevating, where competitive advantage may come from early _adoption of new technology._
> 2. What archetypes are part of your target, and what are the major bottlenecks or constraints limiting their rapid adoption?
Find the early points where AI can make an outsized impact.
> 3. Do the AIs need monitoring by humans?
That implies new responsibilities and processes in your organization. We predict that _monitoring_ will become an important responsibility for human workers.
For example, a pet-supply company creates e-commerce software in a Resource topology. It’s a mature, uncomplicated market. Competition has delivered a better website and app that customers love. Leadership has decided on a business objective of retaining customers, with an org goal of fast flow to parity, by targeting a Delivery topology with CAPS-3 teams.
Now let's evaluate this set-up with the three questions:
_Q> What parts of the company are the focus of org development?_ The Product Management and R&D departments, so focus on AI investment there.
_Q> What archetypes are part of the target? What’s a dominant constraint from one to the other?_
The R&D department has mostly TASKS-1 individuals, and the target is CAPS-3 teams. On investigation, it’s a lack of front-end design and coding skilled people. Focus time, money, and management attention on AIs, especially on that big bottleneck, over a generic “adopt AI.”
_Q> Do the AIs need monitoring by humans?_
Yes, because people have decided on AI agents that autonomously design and code front ends, independently creating and iterating on variations that they deploy and measure. The small number of existing front-end designers and developers joining the new CAPS-3 teams will be trained in agent monitoring and take on that responsibility.
As a part of the Org Topologies Primer 2025 — a table of how AI adoption can be strategized in each of the four archetype groups:
## More on AI Implications on Org Design
---
# Haier's RDHY vs. Bayer's DSO
**Date:** 2025-02-04 · **Reading time:** 10 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/studying-org-designs-haier-rdhy-bayer-dso
**TL;DR:** Haier and Bayer both dismantled hierarchies but took different paths. Haier's micro-enterprises are independent P&L centers with digital contracting; Bayer's squads are cross-functional but still lean on centralized coordination. Mapped on Org Topologies, Haier reaches higher on both axes. Both prove decentralization works — the question is how far you push autonomy.
## What This Article Covers
Two of the most ambitious organizational redesigns in modern industry — Haier's **Rendanheyi (RDHY)** and Bayer's **Dynamic Shared Ownership (DSO)** — share a common ambition: dismantle the traditional pyramid and push decisions to the frontline. They also differ in almost every respect that matters: origin, structure, age, cultural drivers.
This piece walks through both models, maps their work units on the [Org Topologies](https://www.orgtopologies.com/) two-axis grid, and shows what each gets right — and where each is, in different ways, still incomplete.
Sections, in order:
1. Haier's transformation
2. Bayer's transformation
3. Similarities and differences: RDHY and DSO
4. Studying org designs of RDHY
5. Studying org designs of DSO
6. Comparing and contrasting the two models
7. Putting it all together
## 1. Haier's Transformation
The Haier **Rendanheyi** model (**RDHY**) is a management philosophy developed under the leadership of Haier's founder, Zhang Ruimin. It is a radical departure from traditional hierarchical structures — built on the idea that every employee's effort should align directly with customer (or user) value creation.
Haier's journey toward a decentralized, customer-centric organization began in earnest around **2005** — a sharp break from conventional hierarchy. Over the following years, and especially around **2012**, Haier refined the approach by breaking its operations into thousands of micro-enterprises that interact directly with users, institutionalizing entrepreneurial autonomy and customer-focused value creation.
Reported outcomes include: hierarchical layers reduced from 12 to 3 across subsidiaries, a 67% faster decision-making cycle compared to 2021 benchmarks, and a target — by 2025 — to derive 60% of revenue from ecosystem services through AI integration and cross-industry partnerships.
## 2. Bayer's Transformation
Bayer's **Dynamic Shared Ownership** (**DSO**) is a sweeping transformation of a traditional hierarchical structure into a more agile, decentralized system — one that shifts decision-making and ownership closer to the frontline. Much like Haier's RDHY, DSO is designed to empower employees and create a more responsive, customer-centric organization. But it emerges from a very different corporate context and set of challenges.
Bayer began restructuring its traditional pyramid-shaped organization into small, empowered squads around **2018–2019**. The initiative accelerated significantly around **2020** in response to performance challenges and the need for faster, market-responsive decision-making. The creation of agile, cross-functional squads is a more recent development of the model. The goal: shift power to frontline teams while maintaining interdependent coordination through digital platforms and agile processes.
It is still early to judge the success of the DSO implementation — Bayer is only a few years into the change (compared to Haier, who started almost two decades ago). As of February 2025, Bayer's CEO Bill Anderson, who was appointed in 2023, continues to lead Bayer through a major restructuring program aimed at reducing hierarchy and cutting costs by €2 billion by 2026. Bayer's recovery toward a shinier future is likely still ahead.
## 3. Similarities and Differences: RDHY and DSO
Both models share similar ambitions — decentralize decision-making, empower frontline employees, focus on customer value. The contexts and drivers, however, differ:
- **Origin.** Haier's model was born out of the need to transform a manufacturing company in a rapidly evolving Chinese market. Bayer's DSO is a response to internal performance challenges and the demands of a global pharmaceutical and life sciences conglomerate.
- **Structure.** Haier's approach breaks the organization into thousands of micro-enterprises and ecosystem micro-communities. Bayer is reconfiguring its structure into autonomous, cross-functional squads within a "flat army."
- **Cultural drivers.** Both require a significant cultural shift. Haier's journey is about aligning every employee's value with customer value. Bayer's DSO is similarly designed to transform mindsets from hierarchical control to shared, mission-driven ownership.
In summary:
- **Haier.** Most employees are reorganized into micro-enterprises (and aggregated into ecosystem micro-communities), but some functions — especially centralized support — remain outside the direct micro-enterprise structure.
- **Bayer.** A significant portion of the workforce is restructured into agile, cross-functional squads, yet certain central functions and corporate support roles are not organized this way.
## 4. Studying Org Designs of RDHY
### Core Principles of RDHY
**1. Human-centric value creation.** At its heart, the model is built on the idea that "Ren" (人, meaning "people" or "employees") and "Dan" (单, "orders" or customer demands) should be "HeYi" (合一, "integrated"). In other words, the personal value of every employee is directly tied to the value they create for users. This "win-win" concept drives a culture where **every individual is seen as an entrepreneur**, with incentives and rewards linked to how well they serve customer needs.
**2. Decentralization and self-organization.** Traditional middle management and rigid bureaucracies are replaced with a **network of micro-enterprises (MEs)** — autonomous units. Each small unit (often around 10 people) operates almost like an independent startup within the larger organization. This decentralization enables rapid decision-making and agile responses to customer feedback — what Haier calls "zero distance" between the employee and the end-user.
**3. Entrepreneurial autonomy.** Rather than a top-down, command-and-control system, the Rendanheyi model delegates authority to the lowest levels. Employees are given decision-making power and a share in the success of their projects. The entrepreneurial spirit is encouraged through systems that reward innovation and accountability, making every micro-enterprise **responsible for its own profit and loss**.
### Work Units of RDHY
Haier's RDHY isn't limited to autonomous micro-enterprises (MEs). Over time, the model has evolved to include several complementary unit types:
1. **Micro-enterprises (MEs).** Small, autonomous business units — typically 10 to 15 employees — that operate as independent profit-and-loss centers within the larger corporate structure. They are empowered to make critical decisions, hire and manage talent, and directly engage with customers to identify and meet their needs, fostering an entrepreneurial culture where every employee acts as a mini-entrepreneur. MEs are the foundational building blocks of Haier's decentralized organization, and they often collaborate and interconnect through ecosystem micro-communities (EMCs) to share resources and co-create value.
2. **Ecosystem Micro-Communities (EMCs).** MEs are not isolated; they are designed to interconnect. Groups of MEs come together to form EMCs — clusters or communities that collaborate to address more complex user scenarios. In practice, EMCs are often divided into subtypes (for example, "solution EMCs" and "experience EMCs"), with one set focusing on developing solutions (R&D or manufacturing) and the other on user engagement and experience. The grouping helps the organization tackle larger market challenges while still maintaining the agility of small entrepreneurial units.
3. **Supporting shared services and platforms.** In addition to MEs and EMCs, Haier has built internal service platforms that function as support units. These manage essential services — HR, procurement, logistics — reducing the need for traditional middle management and allowing the MEs to focus on value creation and customer engagement. Platforms like COSMOPlat serve as internal marketplaces where units can interact, bid for services, or share resources in a transparent, market-based manner.
Together, these three layers create a dynamic ecosystem in which individual entrepreneurial units drive rapid innovation and customer-centricity, while centralized platforms and inter-unit communities ensure coordination and resource sharing across the whole enterprise.
### Disclaimer
Below are publicly available real-life examples. These are probably some of Haier's most advanced and successful cases — that's why they have been promoted. They are great for illustrating the power of the model.
When we later map these teams with Org Topologies, it is worth remembering that those assessments are likely the outliers — in the positive direction. We predict that not all teams at Haier are this advanced and would probably be assessed lower on the map. The same applies to Bayer's example teams further below.
Our intention is not to create a statistically correct assessment — we simply lack the data for such a study. Our goal is to show the qualitative (not quantitative) potential of these two very different models. Our mission is to inspire other organizations to *get the change going*. (For another case study using Org Topologies mapping, see [*LeSS Adoption at Poster POS*](/post/less-adoption-at-poster-pos).)
### Real-Life Examples of MEs
**Mask Supply Microenterprise.** During the COVID-19 pandemic, a small group of Haier employees recognized a critical shortage of protective masks. They quickly formed an ME to source raw materials, organize production, and distribute masks at scale. While it emerged to solve a specific crisis, it evolved to manage the entire supply chain for the product line, leveraging external suppliers and digital tools for smart contracting.
**Smart Home Appliance Microenterprise.** One of Haier's flagship MEs focuses on the development of integrated smart home solutions. This unit designs, produces, and continuously refines products like refrigerators, washing machines, and air conditioners by directly engaging with customers. Its work spans the entire value chain — from R&D and manufacturing to marketing and service — and it often collaborates with other MEs within an EMC to address complex user scenarios.
**GE Appliances Microenterprise (global adaptation example).** Following Haier's acquisition of GE Appliances, parts of the U.S. business were reorganized into autonomous micro-enterprises. Each ME targets a distinct product line (for example, air conditioners or washing machines) and is empowered to handle everything from product innovation to market launch, tailoring solutions to local customer needs. The structure has allowed the unit to operate with startup-like agility while contributing to overall brand performance.
### Mapping Haier's Org Design with Org Topologies
The Org Topologies map offers a visual aid to make sense of org design, beyond frameworks and ambiguous terminology.
The horizontal axis represents the **[Scope of Skills Mandate](/post/teams-and-scope-of-skills-mandate)**: the levels of skill composition that work units are allowed to apply doing certain work — from Functional, to End-to-End, and even Expanding beyond that.
The vertical axis represents the **Scope of Work Mandate**: the levels of work that units are expected to perform — from the lowest Task level, to Partial, and even Whole Business.
**Below are the assessments of the sample value-creating units of Haier's RDHY model.**
**Mask Supply Microenterprise**
- **Horizontal:** Expanding — although this unit initially formed with a functional/multi-skill base to address a crisis, it rapidly integrated external partners and digital contracting, continuously acquiring new capabilities.
- **Vertical:** The unit is responsible for a specific product line (protective masks) and manages a substantial portion of the supply chain without covering a fully diversified business — Partial-Business Focus.
**Smart Home Appliance Microenterprise**
- **Horizontal:** This flagship unit covers the entire value chain (from R&D and manufacturing to marketing and service), operating independently to deliver complete End-to-End smart home solutions.
- **Vertical:** It functions as an independent profit-and-loss center with Partial-Business Focus, managing a complete business segment that delivers end-to-end value to customers within Haier's broader product landscape.
**GE Appliances Microenterprise**
- **Horizontal:** Following Haier's acquisition, this unit was reorganized to handle an entire product line with full End-to-End autonomy, mirroring a startup-like approach.
- **Vertical:** Structured as a standalone profit center responsible for delivering a complete business solution in its segment — Partial-Business. Each unit is dedicated to a distinct product line (for example, air conditioners or washing machines) and is empowered to manage everything from product innovation to market launch.
The visual representation of the assessment:
**Now let's assess the supporting shared services and platforms.**
- **Horizontal:** Typically mapped between the Multi-Skill and Expanding levels — they are capable of building internal service platforms. We don't have the exact details of their composition or dependencies on other units, so we assume they are mostly complete units.
- **Vertical:** Positioned in the Task Focus to Capabilities Focus range. Their responsibility is narrowly defined — manage critical support tasks and provide operational capabilities. They do not handle complete business outcomes; they ensure that processes and resources are in place for the MEs and EMCs to function efficiently.
On the map:
We did not assess Ecosystem Micro-Communities (as clusters of MEs) because our focus is on fine-grained work units. Evaluating larger groups, such as ecosystems or business divisions, does not accurately reflect workers' mandates and usually creates a misleading picture.
## 5. Studying Org Designs of DSO
### Core Principles of DSO
**1. Mission-driven value creation.** Bayer is shifting the focus from traditional quarterly KPIs to **outcomes aligned with its long-term mission** — "Health for all, Hunger for none." Decisions and rewards are now tied directly to how well teams create real, tangible value for customers.
**2. Network of autonomous, cross-functional teams.** Instead of a rigid, top-down hierarchy, Bayer is restructuring into a "flat army" of **multidisciplinary, self-governing teams** (often called "squads"). These teams are empowered to make decisions independently, drawing on diverse skills that span functions such as R&D, marketing, and supply chain management. The decentralized model encourages faster, more informed decisions at the point of customer contact.
**3. Shared ownership and empowerment.** DSO replaces conventional management control with shared ownership. Frontline employees — from field sales reps to technical advisors — are given real **decision-making authority and held accountable for outcomes**. Their performance and compensation become directly linked to the value they deliver to customers, fostering a strong entrepreneurial spirit across the organization.
### Work Units of DSO
Bayer's DSO reconfigures the organization into several types of work units that work both autonomously and collaboratively. Although detailed internal information is not fully disclosed publicly, industry reports and management insights suggest the new structure includes the following key units:
1. **Agile squads.** Small, cross-functional teams (typically 5–15 members) composed of employees from various disciplines — R&D, marketing, sales, supply chain — who are empowered to make quick, autonomous decisions. Squads execute on specific projects or market opportunities and are oriented toward rapid innovation and customer responsiveness.
2. **Cross-functional cells.** In certain strategic areas, Bayer has set up specialized cells that bring together experts from multiple functions to tackle complex, integrated challenges. These cells often work on end-to-end value creation projects, such as new product development or digital transformation initiatives, ensuring every aspect from conception to market delivery is coordinated.
3. **Centralized support platforms.** Although the aim is decentralization, Bayer maintains certain central service units that provide standardized functions and services (IT, HR, procurement, finance) underpinning the agile squads. These platforms support the squads by delivering standardized tools, resources, and process frameworks that enable faster decision-making and smoother inter-team collaboration. Rather than engaging directly in market-facing innovation, they streamline operations, reduce overhead, and enable faster decisions by automating routine tasks and ensuring consistent processes across the organization.
4. **Integration and coordination forums.** These forums — regular "scrum-of-scrums" meetings, digital collaboration platforms, designated liaison roles — exist to synchronize the work of Bayer's agile squads. They facilitate the sharing of progress, resolution of inter-squad dependencies, and alignment of outputs with overall corporate strategy. They are the glue connecting autonomous teams while ensuring collective efforts drive toward shared business outcomes.
Each of these work units contributes to the overall DSO approach by combining decentralized autonomy with the mechanisms for coordination and shared value creation. This blend of independence and interdependence is central to Bayer's effort to transform into a more responsive and innovative organization in today's fast-paced market environment.
### Disclaimer
There is much less information publicly available on DSO compared to RDHY. For one, DSO is much younger. Secondly, its power is yet to be seen. Lastly, all the information we are basing our assessment on has been pushed out by Bayer's marketing itself, which is likely the best-case scenario plus some early, hard wins.
So, we hardly know anything about the model's downsides or how broadly the model has been adopted in the enterprise.
Yet, even without quantitative accuracy, we believe our analysis can be useful to see the potential of the DSO model — not its particular implementation at Bayer, which is yet to be studied thoroughly in the years to come.
In any case, DSO is by far the boldest change model that we know of in the pharma and chemical industry. If it proves successful, we will see it spread across the industry. Then we will get more data and insights to perform a more thorough study.
### Real-Life Examples of Squads
**Bayer Crop Science Squad (Southern Iowa).** Led by Barry Jacobson in Bayer Crop Science, this squad is composed of field sales representatives, technical agronomists, and customer business advisors. The team rapidly develops proposals based on direct interactions with farmers and local ag retailers. They identify specific challenges in the field, collaboratively design solutions, and implement them without the delays of traditional approval hierarchies. Their work has led to faster decision-making and improved responsiveness to market needs, directly aligning with Bayer's push for frontline empowerment.
**Bayer Italian Innovation Squad (healthcare/pharma).** In Bayer's European operations, an agile squad was formed to address a pressing healthcare challenge. The team — drawing talent from R&D, design, and operations — collaborated to develop a tool designed to make injections easier for hemophiliac patients. By rapidly iterating their solution over a period of just 2–3 months, the squad demonstrated high responsiveness and creativity. Their cross-functional collaboration allowed them to innovate swiftly while directly addressing user pain points — a critical aspect of Bayer's transformation.
**Bayer Global Design Teams.** Bayer has instituted around 70 design teams globally, which operate as agile work units responsible for redesigning key corporate processes — from supply chain management to digital transformation initiatives. These teams work cross-functionally to reengineer and optimize processes across the organization. Their efforts are critical for aligning disparate parts of the business under the new DSO model, ensuring that innovation and efficiency improvements are integrated throughout Bayer's operations.
### Mapping Bayer's Org Design with Org Topologies
**Similar to Haier's assessments above, below are the Org Topologies mappings for Bayer's sample value-creating units.**
**Bayer Crop Science Squad**
- **Horizontal:** This cross-functional Multi-Skill squad (field sales reps, technical agronomists, customer advisors) combines diverse expertise to develop and execute market-specific solutions.
- **Vertical:** Focused on a specific segment within the crop science division (Partial-Business Focus), delivering targeted outcomes rather than managing an entire business.
**Bayer Italian Innovation Squad**
- **Horizontal:** This agile squad — drawing talent from R&D, design, and operations — was able to take a healthcare innovation (a tool for easier injections) from concept to market in 2–3 months, delivering a complete End-to-End solution.
- **Vertical:** The mandate is centered on a specific innovation project within the healthcare/pharma segment (Partial-Business) rather than an entire business vertical.
**Bayer Global Design Teams**
- **Horizontal:** Composed of multidisciplinary experts, these teams work on comprehensive process redesign and digital transformation, integrating a wide array of skills to deliver full solutions (End-to-End).
- **Vertical:** Their primary focus is on enhancing and optimizing operational processes (e.g., supply chain, digital workflows) rather than managing a complete business line — assessed as Capabilities Focus.
The visual representation:
**Below is the Org Topologies mapping of the sample supporting units of Bayer.**
**Centralized support platforms**
- **Horizontal:** These platforms support the agile squads by delivering standardized tools, resources, and process frameworks that enable faster decision-making and smoother inter-team collaboration. That spans the whole range from Functional to End-to-End.
- **Vertical:** Placed in the Task Focus to Capabilities Focus range. Their work mandate is narrowly defined — they are responsible for specific support tasks or developing certain operational capabilities, not for managing a complete business or customer value chain.
**Integration and coordination forums**
- These are merely events and virtual teams, so we won't assess them.
And on the map:
## 6. Comparing and Contrasting the Two Models
Both Haier's micro-enterprises (MEs) and Bayer's agile squads are advanced work units — but they excel in different dimensions of organizational transformation.
**Haier's micro-enterprises (MEs).** These units are highly advanced in terms of decentralization and entrepreneurial empowerment. Each ME functions as an independent profit-and-loss center with full decision-making authority and direct customer engagement. Their structure not only dissolves traditional hierarchical boundaries but also integrates deeply into larger Ecosystem Micro-Communities (EMCs), enabling a near-seamless alignment between employee incentives and user value creation. This radical shift — where nearly all operating staff are treated as mini-entrepreneurs — is a breakthrough in dismantling bureaucracy and fostering sustained innovation.
**Bayer's agile squads.** Bayer's squads are advanced in adopting agile, cross-functional collaboration within a traditionally hierarchical, large multinational context. These squads (typically 5–15 members) are empowered to work rapidly and iteratively, leveraging digital collaboration tools to shorten decision cycles and respond to market demands quickly. Although they enjoy significant autonomy on project-specific tasks, they still operate within a framework that includes centralized support functions for strategic alignment and resource sharing. This approach excels in creating rapid, flexible responses but may not be as radically decentralized as Haier's MEs.
Both models rely on **shared supporting units** that enable the work units by offering standardized commodity services and platforms.
### Managing Interdependency with Digital Contracting and Agile Coordination
MEs and squads can do a lot independently, yet they are interdependent and should not function as broader silos. They have to find ways to collaborate with each other. Here, Haier and Bayer apply different strategies.
**Digital contracting** is a cornerstone of Haier's RDHY, enabling its vast network of MEs to function as an integrated, agile ecosystem. Rather than relying on traditional, paper-based agreements, Haier employs digital contracting through platforms like COSMOPlat and the Workbench. These systems utilize **smart contracts and blockchain** technology to automate and secure agreements between MEs and their external partners.
When an ME issues a **digital tender** for a service or resource, competing units bid for the work; once agreed upon, the contract is automatically executed and recorded on a blockchain. This streamlines negotiations, minimizes errors, and ensures payment is directly linked to the value created for customers — embodying Haier's "paid by users" principle. In essence, while each ME operates with significant autonomy, digital contracting ensures they remain interdependent, sharing resources and expertise across EMCs.
In contrast, Bayer's DSO — which effectively operates as a [Delivery Topology pushing toward Adaptive](/post/three-ecosystems) — addresses alignment and coordination among its agile squads through a set of complementary **digital and procedural tools**.
To manage dependencies across squads, Bayer employs **agile ceremonies** such as "scrum-of-scrums," where representatives from different squads meet regularly to synchronize efforts, resolve conflicts, and ensure alignment with the company's broader strategy.
Additionally, Bayer relies on **digital collaboration platforms** that provide real-time transparency through shared dashboards, performance metrics, and project updates. Dedicated liaison roles further facilitate coordination by managing inter-squad dependencies, ensuring overlapping resources and joint initiatives are effectively integrated.
In summary: Haier's digital contracting transforms micro-enterprises into semi-independent, entrepreneurial nodes that operate through automated, transparent agreements — ensuring that autonomy is balanced with ecosystem collaboration. Bayer's DSO emphasizes agile alignment among its squads through structured coordination mechanisms, digital tools, and dedicated liaison roles. Both approaches aim to dismantle traditional hierarchies, yet Haier's model focuses on creating a tightly integrated digital marketplace for value exchange, while Bayer's strategy is centered on aligning and coordinating autonomous teams within a larger corporate framework.
## 7. Putting It All Together
> Haier's Rendanheyi, initiated around 2005 and refined by 2012, dismantles traditional hierarchies by reorganizing most employees into small, autonomous micro-enterprises that operate within an interconnected ecosystem. It decentralizes the organization into MEs that are integrated into a broader ecosystem through digital contracting and Ecosystem Micro-Communities.
On the horizontal axis (scope of skills mandate), these units are positioned as End-to-End to Expanding — they begin as end-to-end units but continuously acquire new skills and external capabilities via digital tools.
Vertically (scope of work mandate), some MEs (e.g., Smart Home Appliance or GE Appliances units) are mapped as Partial-Business because they manage the full value chain for a given product line, while others — like the Mask Supply Microenterprise — operate at a Partial-Business level, focusing on a specific product segment with some dependency on shared services.
> In contrast, Bayer's Dynamic Shared Ownership — an ongoing roll-out started in 2018 — restructures the organization into agile, cross-functional squads that work rapidly on specific projects. Bayer's squads, supported by centralized platforms and coordination forums, are generally positioned as Multi-Skill units with a Partial-Business mandate.
On the horizontal axis, these squads generally fall within the Multi-Skill to End-to-End range, reflecting their integration of diverse expertise to rapidly deliver innovations and adapt to market feedback.
Vertically, the squads are mostly positioned in the Capabilities to Partial-Business zone, as they are tasked with delivering specific projects or capabilities rather than running an entire, standalone business. Bayer reinforces alignment and coordination through centralized support platforms and integration forums that help manage interdependencies among squads.
This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous.
---
# Teams and Scope of Skills Mandate
**Date:** 2025-01-15 · **Reading time:** 7 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/teams-and-scope-of-skills-mandate
**TL;DR:** The difference between functional and multi-function teams is not individual skills — it is the team's organizational mandate. What scope of customer problems is the team authorized to solve end-to-end, without handoffs? That mandate is an org design decision, not a staffing one.
The key question this article addresses is:
> How do we tell if a team is truly multi-function or just functional, and why does it matter for delivering end-to-end value?
There has been a high-volume discussion exploring this and skill-related questions in our [Slack community](https://www.orgtopologies.com/community) with great input from Aimé Flemm, Steve Alexander, Sven Müller, and Zoltán Dósa. I decided to summarize key discoveries in this article.
**TL;DR**: Functional teams specialize in one domain—even if they have multiple subskills—while multi-function teams span multiple domains, letting them deliver end-to-end value without handoffs. The big difference is the _team's mandate_ (an org design decision), which shapes how quickly and efficiently they can respond to customer needs.
## Embracing the Spectrum: From Functional to Multi-Function Teams (Updated)
Organizations often struggle to explain the difference between **functional**(“single-function”) and **multi-function**(or “multi-skilled”) teams. On the surface, one might assume “functional” means a person can only do a narrow set of tasks, whereas “multi-function” means having a broad skill set. But what if individuals in a so-called “functional” team already use multiple subskills—like an Ops engineer proficient in networking, security, and disk management?
The crux is not whether a person can do multiple things. Rather, **Org Topologies**emphasizes the **organizational mandate**: what scope of customer problems is the team authorized and expected to solve, _end to end_, without formal handoffs?
## Functional vs. Multi-Function: The Scope of Mandate
In **functional**teams, members share a single overarching role or domain—e.g., front-end development, Ops, product management, or marketing.
* Yes, they might each have “subskills” in that domain (a front-end developer who knows React, Angular, CSS, etc.), but they remain in _one function_.
* To deliver new features involving other domains, they typically coordinate with separate teams (e.g., a back-end or product design group).
A **multi-function**team, by contrast, includes roles spanning multiple domains under one shared purpose—e.g., front-end, back-end, product management, UX design, marketing, and sometimes operations (DevOps).
* They can handle various tasks, from discovering customer needs to coding, testing, and promoting a feature.
* They reduce external handoffs because they already have the necessary expertise in-house.
**Why use “functional” instead of “single-skilled”?**Because “single-skilled” suggests someone only knows one tool or framework, which is rarely true. In reality, it’s about how the organization structures the team’s mandate, not the total number of frameworks each individual can handle.
## Why This Matters
Below is a quick summary illustrating why the difference between **functional**and **multi-function**matters for delivering value:
* **If a functional unit tries to build a truly new product feature and ensure customer adoption,**it typically lacks the product management, design, and marketing expertise to guarantee it’s desirable, user-friendly, and effectively promoted. They must hand off tasks to other functional teams or departments.
* **On the other hand, a multi-function team**includes (or has access to) those complementary skills—so they can easily iterate, test with real users, market, and refine solutions without waiting in line for another team. This often leads to faster feedback loops and more holistic product outcomes.
When the time to market and adaptation to change is critical, these distinctions can become make-or-break. The [whole product focus team](/post/whole-product-focus-team) — capable of working on any feature end-to-end — is the natural endpoint of this evolution. A purely functional structure can bottleneck innovation if teams struggle to collaborate across organizational silos. By contrast, a well-supported multi-function team can operate like a mini-startup within the enterprise: they discover, design, develop, and launch features under one roof.
## An “Outside-In” Example
One simple way to explain this concept to leadership is to focus on **what the customer can expect**from a team rather than the internal skill sets:
* **Functional Team**: If the team can solve only one type of problem—for instance, handling front-end UI—then it’s functional (or single-function). Even though each member might know multiple frameworks, all of those subskills remain under “front-end work.” If the customer also needs changes to the back-end or advanced user research, that functional team has to reach outside for help.
* **Multi-Function Team**: If the team can solve a wide variety of problems across the stack—front-end, back-end, testing, infrastructure, UX—then it’s multi-function. They have the authority and ability to manage all key tasks end to end, meaning fewer handoffs and faster delivery.
From an **executive viewpoint**, this outside-in framing underscores how quickly and effectively a team can satisfy customers. A multi-function team can deliver a “one-stop shop” experience, improving responsiveness and overall accountability.
## It’s About Organizational Design—Not Just Skills
A major misconception arises when a functional team argues: “We’re already multi-skilled because we combine various tasks within our domain.” For instance, a front-end specialist might also do design tweaks and user testing. In reality, if the team’s **formal organizational mandate**remains the front-end, they’re still considered “functional.” They have multiple subskills within one primary function but must hand off anything beyond that function.
This distinction highlights an **environmental**aspect: even if individuals possess overlapping abilities, does the **organization**encourage them to apply those abilities collaboratively, or does it enforce silos through strict role definitions? Multi-function teams need **organizational support**—clear goals, decision-making authority, and a culture that fosters collaboration.
## Less Handoff, More Ownership
Imagine you have:
* **Team A**: front-end
* **Team B**: back-end
* **Team C**: design and user research
In a functional setup, a new feature request might bounce between these specialized teams, each handling their part. This can work if requirements are stable but slow iteration and discovery if the feature’s final shape is uncertain.
In a **multi-function setup**, a cross-domain team includes front-end, back-end, and design expertise. They can talk to the customer, sketch a design, code it, and test reactions without waiting for separate teams. They have **end-to-end ownership**, boosting adaptability and speed of learning.
## Addressing Executive Concerns
When explaining Org Topologies to executives, focus on:
1. **Reduced coordination overhead**: Multi-function teams minimize handoffs by integrating key roles in one group.
2. **Faster innovation**: They can swiftly adapt to user feedback because discovery, design, and delivery happen together.
3. **Contextual choices**: Functional teams still excel in stable or compliance-heavy environments where deep specialization is needed. If rapid learning is crucial, multi-function teams often thrive.
Forming multi-function teams requires a supportive environment: leadership support, psychologically safe collaboration, and well-defined missions unifying diverse roles. It’s not enough to place cross-domain experts in the same Slack channel—there must be a shared commitment to work as a single unit. Career structures matter here too — [tailwind career paths](/post/tailwind-career-paths) reward breadth rather than punishing it.
## Evolution and “Scope of Skills Mandate”
Teams can **expand**their scope over time, gradually incorporating product discovery, UX, or marketing capabilities. A front-end team might learn how to validate user needs. An infrastructure group might add DevOps or QA tasks to reduce external dependencies. As they grow their **scope of skills mandate**, they move along the spectrum toward multi-functionality.
This is why **functional vs. multi-function**isn’t strictly binary. It’s a continuum anchored by how many domains a single team is empowered to address. Org Topologies helps visualize these evolutions and clarifies how structural decisions align with organizational goals.
## My Key Takeaways
* **Functional (single-function) teams**specialize in one domain. Members often have multiple subskills, but their **mandate**is still narrow; they rely on handoffs to cover other domains.
* **Multi-function (multi-skilled) teams**span multiple domains—front-end, back-end, design, product, and marketing—so they can build and deliver end-to-end solutions in-house.
**Why This Matters**:
* When tasked with new features and adoption, functional teams may lack product, design, or marketing expertise. They must coordinate externally.
* Multi-function teams have these skills under one roof, enabling quicker iteration, testing, marketing, and refinement.
**An “Outside-In” Example**:
* A team that can solve only one category of problems (e.g., front-end UI) is functional.
* A team that can tackle multiple parts of the stack (front-end, back-end, infra, etc.) is multi-function.
* Organizational **culture**and **authority**matter. Even if individuals have overlapping skill sets, they need an environment and mandate that allows them to perform cross-functional work seamlessly.
Ultimately, choosing between functional and multi-function structures depends on your **strategic goals**and related **market context**.
Functional teams can be ideal in stable, specialized settings, while multi-function teams shine in fast-evolving markets where quick learning and customer responsiveness are essential. In the age of AI, the economics tip further toward broad mandates — [multi-learning](/post/multi-learning-org-design-pattern-ai) becomes viable when AI collapses the cost of acquiring adjacent skills. Understanding the difference—focusing on what the team can deliver _end to end_—is key to designing modern, adaptive organizations.
---
# Tailwind Career Paths
**Date:** 2024-12-17 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/tailwind-career-paths
**TL;DR:** Traditional career ladders reward narrow specialization and punish breadth. Tailwind career paths flip this: broad roles like Product Developer, peer-driven promotions, back-me-up skill tables, and mentorship baked into the structure. Y Soft's manager-less R&D shows the model works — simplicity and transparency over HR theater.
In today's rapidly evolving technological landscape, organizations face increasing pressure to build adaptive, multi-skilled teams.
Traditional career paths, however, often act as barriers rather than enablers, rewarding narrow specialization and promoting hierarchical roles as the only path to success. In the age of AI, this rigidity is especially dangerous — [narrow-mandate roles are the first to be displaced](/post/ai-replaces-tasks-not-people). For those attempting to adopt frameworks like [**Large-Scale Scrum (LeSS)**](https://less.works/) or operate in dynamic environments, these outdated systems quickly become obstacles. Instead, organizations need **"tailwind career paths"** — career models that align individual growth with organizational needs, fostering flexibility, technical excellence, and mentorship without sacrificing clarity or fairness.
Tailwind career paths reject the outdated notion that advancement requires climbing a managerial ladder. Instead, they create open landscapes for growth — where individuals deepen their expertise, broaden their contributions, and help others succeed. Organizations can foster cultures where technical excellence, collaboration, and mentorship thrive by focusing on multi-skilling, shared goals, and flexible structures. Real-world examples like Y Soft show that simplicity and transparency are key to success. Whether through peer-driven promotions, skill-mapping tools, or continuous mentorship, tailwind career paths create environments where employees feel empowered, valued, and inspired to grow.
> At the heart of a tailwind career path lies simplicity. Rather than fragmenting roles into granular job titles — front-end developer, back-end specialist, or UX expert — organizations can adopt broad, flexible roles.
For instance, Y Soft offers a compelling example of a streamlined and empowering career path within a [**manager-less R&D environment**](https://www.ysoft.com/careers/blog/managerless-rnd-promoting-people). Roles are kept simple, progressing through clear levels — *Junior → Intermediate → Senior → Principal* — while promotions are employee-driven, transparent, and feedback-oriented. This eliminates artificial managerial hierarchies and empowers individuals to take ownership of their growth.
## Core principles
For a tailwind career path to succeed, [multi-learning](/post/multi-learning-200-years-wrong-model) must be at its core. Teams that embrace skill mobility — where employees develop expertise in multiple areas — are far more resilient and adaptable. Implementing such frameworks may seem daunting, but organizations can follow core principles to design effective tailwind career paths:
- **Communicate the Vision Continuously**: Leadership must clearly articulate multi-skilling as a priority. Regularly reinforce this message through team events, company updates, and sprint reviews to create alignment and enthusiasm.
- **Simplify Roles and Levels**: Replace fragmented job titles with a broad role like *Product Developer*. Establish clear progression levels that emphasize skill depth, breadth, and influence — moving from team-level contributions to organizational leadership.
- **Make Promotions Transparent and Peer-Driven**: Implement a process where employees initiate promotions through self-evaluation and peer feedback, with reviews conducted by structured committees. At Y Soft, this ensures fairness while keeping employees accountable for their growth.
- **Encourage Multi-Skilling Through Mentorship**: Use tools like the *back-me-up table* to identify gaps in skills coverage. Every specialty should aim for a specialist, a backup, and an apprentice. Pairing specialists with apprentices fosters mentorship while broadening organizational knowledge.
- **Prioritize Team-Based Goals Over Individual Metrics**: Shift focus from individual targets to team-based goals. Shared performance objectives promote collaboration and reduce unhealthy competition. Celebrate achievements in retrospectives and sprint reviews to reinforce this approach.
- **Support Learning with Tools and Enablers**: Provide access to resources like AI tools (e.g., Cursor) to help employees navigate new codebases and reduce the friction of learning unfamiliar domains.
- **Facilitate Peer Learning and External Exposure**: Encourage employees to connect with peers from companies like Y Soft, where innovative approaches are already in place. These exchanges can provide invaluable insights and inspire solutions tailored to the organization's needs.
- **Separate Compensation from Career Levels Initially**: Avoid tying promotions to salary changes too early. Allow employees to experiment with the new model for at least a year before aligning it with formal HR compensation structures.
- **Try Gamification and Avoid Over-Gamifying**: Gamification can bring playfulness and ease when trying new ideas. It can help incentivize learning. So, it is a good idea to try some simple gamification techniques. It is important not to do more than necessary as gamification comes with risks, such as employees "gaming the system" rather than focusing on meaningful progress and intrinsic rewards — growth, mentorship, and collaboration.
These principles create a framework that aligns personal growth with team and organizational success. By prioritizing simplicity, transparency, and adaptability, companies can replace headwinds with systems that propel individuals forward.
## Encouraging experimentation
Encouraging experimentation during the early stages of implementing a career framework is equally important. By initially decoupling promotions from salary adjustments, organizations can allow employees to explore and adapt without fear of immediate consequences. Celebrating progress becomes a cultural cornerstone: sprint reviews, retrospectives, and peer recognition provide opportunities to highlight individuals who step outside their comfort zones. Over time, these celebrations reinforce the value of multi-skilling and cross-team contributions.
[Allan Cyment](https://www.linkedin.com/in/acyment/) shared an experiment with a "back-me-up" table used at one of his clients: a simple yet powerful tool for facilitating this growth. It allows teams to map out their skills, identify gaps, and ensure each area has a specialist, a backup, and an apprentice. Over time, employees broaden their expertise naturally, often through pairing or mob programming. Such practices encourage knowledge-sharing and mentorship, ensuring the team remains robust and flexible even as demands change.
Companies like [Y Soft](https://www.ysoft.com/) demonstrate that effective career paths need not be complicated. Their transparent promotion process removes barriers, while a clear structure enables individuals to understand expectations and chart their growth. Promotions are not dictated by managers but driven by employees themselves through peer-reviewed evaluations. Salaries are adjusted based on value and contributions rather than rigid timelines or hierarchies. This approach builds trust while aligning individual motivation with organizational goals.
The long-term success of tailwind career paths depends on clear communication and leadership commitment. Leaders must articulate the importance of multi-skilling as an organizational priority, ensuring employees understand how it benefits their personal growth and the company's goals.
For companies ready to embrace this model, the payoff is clear: resilient, innovative, and adaptable teams capable of navigating challenges and driving sustained success. The structural logic maps directly to the [scope of skills mandate](/post/teams-and-scope-of-skills-mandate) — the broader the mandate a team is authorized to hold, the less it depends on handoffs, coordination, and other people's calendars.
---
# Elevating Katas™ for Organizational Agility
**Date:** 2024-12-17 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevating-katas-structured-routines
**TL;DR:** Elevating Katas are repeatable routines that shift an organization toward higher adaptivity — not one-off workshops or transformation programs. Each kata targets a specific element: governance, roles, events, artifacts. Practiced consistently, they turn strategic intent into behavioral change and make culture evolve from action, not mandates.
“Kata” was popularized in management via Toyota, implying a disciplined and repeating pattern for improving. Each Elevating Kata is a repeatable, structured pattern or routine introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Each Kata targets a specific org design element (structure, policy, process, …) and aims to shift in ways that provide incremental and scalable improvements.
> When we speak of Elevating Katas we mean specific interventions or methods that guide an organization from its current level of maturity and flow towards more effective, systemic, and higher-order modes of working.
Each kata focuses on a particular area (such as governance, practices, roles, events, or artifacts) and is designed to shift mindsets, structures, or processes in a way that provides incremental, scalable benefits over time. By repeatedly practicing an Elevating Kata, organizations internalize more adaptive behaviors, enhance their management capabilities, and ultimately create a more responsive and learning-oriented culture.
**Key characteristics of Elevating Katas include:**
* **Purposeful Routine:**They are not one-off changes but ongoing practices that teams perform regularly.
* **Incremental Improvement:**Each iteration builds on the last, gradually increasing proficiency and confidence.
* **Systems-Level Focus:**They often address underlying organizational design elements—like governance models, role definitions, and multi-team events—to improve end-to-end product delivery.
* **Empowering Teams and Leaders:**By embedding these katas, organizations empower members at all levels to take ownership, adapt quickly, and focus on value.
* **Cultural Shift:**Over time, Elevating Katas influence not just processes, but also the culture, encouraging transparency, continuous learning, and a broader understanding of “product” and customer outcomes.
In short, Elevating Katas are deliberate, repeatable, systemic, and _strategic_ improvement routines that help organizations lift their practices to a higher, more impactful level.
## "STRATEGIC" IS THE KEY HERE
Below is the [method](https://www.orgtopologies.com/made-method) we've crystallized over the year that leads the way to **strategic org design**:
"Change MADE Real" method
You can[learn about the Change MADE Real](https://www.orgtopologies.com/made-method)method and its four steps, as it is essential to understand the MADE method to see the place of Elevating Katas in the landscape of Org Topologies.
Elevating Katas are principles, guidelines, and practices for systemic change. They are vehicles for the MADE method as they drive the _elevation_ of an org ecosystem towards the top right archetype group of the map:
Elevating Katas in the MADE method
Here's how to make sure that the application of Elevating Katas is systemic:
1. **Holistic Focus**The Star Model suggests that changes must work at the system level, not just tweak one element. Elevating Katas, by their nature, aren’t isolated improvements; they target multiple facets—governance, roles, events, practices, and artifacts—ensuring shifts in behavior permeate through structures, processes, and ultimately how people collaborate.
2. **Aligning Structures and Processes With Strategy**For an organization’s strategy to truly drive capabilities, the operational design must support it. Elevating Katas introduce routines (such as multi-team Product Backlog Refinement or vertical slicing of work) that bring strategic goals into daily practice. This ongoing, repeated alignment of work routines with strategic direction ensures that structure and processes consistently support the desired capabilities and outcomes.
3. **Enabling People and Role Evolution**
The Star Model emphasizes that people and their roles must be in sync with overall organizational design. Elevating Katas like “Elevate Product Ownership” push beyond conventional role definitions, helping individuals expand their influence and understanding. Over time, these repeated learning loops shape new competencies, reinforce role clarity, and ensure that teams operate in harmony with new structures and strategic objectives.
4. **Reinforcing Desired Behaviors and Culture**“Culture programs” on their own often fail because they focus on abstract values rather than tangible changes in working patterns. Elevating Katas bridge the gap between desired cultural traits (like collaboration, customer-centricity, or continuous improvement) and everyday actions. By practicing these Katas systemically, the organization hardwires new behaviors into its fabric, leading to a naturally evolving culture—rather than attempting top-down cultural mandates.
5. **Rewarding Continuous Improvement**
Because Katas are iterative and repeatable, they create a continuous feedback loop. Over time, as these new practices become second nature, the organization inherently “rewards” them through improved outcomes—faster cycle times, better product-market fit, and more engaged teams. This closes the loop between the “Rewards” element of the Star Model and the actual behaviors that drive performance and cultural evolution.
Elevating Katas serve as the micro-level routines that continuously align the various elements of organizational design. They turn strategic intent into actionable steps, align structures and processes, enhance roles and competencies, and reinforce behaviors—thereby making the entire system function cohesively, just as the Star Model prescribes.
## EXAMPLES OF ELEVATING KATAS
Elevating Katas are not one-off workshops or temporary campaigns. Instead, they are ongoing, disciplined practices that embed a new way of thinking and acting into the organization’s fabric. Each kata focuses on a particular dimension of how work is done—governance, roles, events, practices, or artifacts—offering a continuous improvement loop. By systematically revisiting and refining these routines, teams learn incrementally and develop deeper capabilities.
Below are some examples to give you a taste of what the Katas are.
### Kata: **Expand the “Product” Definition**
Teams regularly revisit and broaden their view of the “product” to include not just a single application or service, but the entire ecosystem of customer experience, business processes, and complementary offerings.
### Kata: **Elevate Product Ownership**
Product owners move beyond backlog management to become strategic influencers, actively connecting business goals with delivery teams. By consistently engaging in strategic alignment sessions and working closely with customers and stakeholders, product owners gradually learn to prioritize work that delivers the highest impact. [Read more](/post/elevate-product-management-for-business-agility).
#### Kata: **Hold Multi-Team Product Backlog Refinement (PBR)**
Multiple teams that share a product domain collaborate in joint refinement sessions. Practicing multi-team PBR regularly ensures alignment, surfaces dependencies early, and harmonizes priorities across different delivery groups. [Read more](/post/cross-team-collaboration-multi-team-pbr).
### Kata: **Slice Work Vertically**
Rather than building features layer by layer (e.g., back-end first, then front-end), teams deliver thin, vertical slices of functionality that span the user interface, business logic, and data layer. Repeatedly practicing vertical slicing enables the team to deliver incremental value faster and reduce the risk of late integration issues.
### Kata: **Merge Product Backlogs**
Instead of each team maintaining its own isolated backlog, organizations merge them into a single, shared product backlog. This practice, repeated regularly, leads to unified prioritization and improved transparency, ensuring that all teams work toward the same strategic objectives.
### Kata: **Define Shared "Done"**
Teams adopt and periodically refine a common set of quality criteria that must be met before work is considered complete. Repeated application of this kata drives consistent quality standards and reliability across teams. Read more about [DoD in LeSS](https://less.works/less/framework/definition-of-done).
### Kata: **Self-Select with Open Space and FAST**
One way to sustain a broader work mandate is to allow teams and individuals within the Team-of-Teams to self-select work and their peers with the necessary skills to create value together. Read more about [FAST](https://www.fastagile.io/), which stands for "Fluid Adaptive Scaling Technology". To facilitate self-selection at scale, this method combines 1) outcome-based product management, 2) open space technology, and 3) dynamic re-teaming.
### Kata: **Implement Beyond Budgeting**
Organizations abandon rigid, annual budgeting cycles in favor of rolling forecasts, dynamic resource allocation, and more decentralized decision-making. Over time, this kata helps the organization become more responsive, adjusting investments as market conditions evolve. [Read more on Beyond Budgeting](https://bogsnesadvisory.com/).
### Kata: **Lead with OBEYA Strategically**
Borrowed from lean management, “Obeya” involves creating a dedicated space (physical or virtual) where decision-makers convene regularly. By visually displaying strategic metrics, progress indicators, and customer feedback, leaders can make more informed, rapid decisions. Read more about [Leading with Obeya](https://leadingwithobeya.com/).
### Katas: **Design Tailwind Career Paths**
Instead of promoting through narrow, hierarchical ladders, individuals advance through capability growth and learning breadth. This kata involves regularly identifying new skill areas, setting capability-building goals, and providing supportive conditions—coaching, resources, and challenging projects—so individuals continuously gain new competencies. Over time, by repeating this practice, organizations cultivate multi-skilled, adaptable professionals whose career “tailwinds” come from developing a broad, flexible skill set aligned with strategic needs rather than climbing a predefined ladder. [Read more](/post/tailwind-career-paths).
### Kata: **Apply AI Strategically**
Any management approach that doesn’t include AI as a central part of the future workforce, is of the past. We are rapidly entering a world of AI agents and humanoid robots playing a role at work and home.Evolving rightward on the horizontal axis to broader skills mandate will become ever easier due to AI. And likewise upward on the vertical axis to a broader work mandate. So, top-right _Driving_ archetypes will become more feasible. [More on applying AI strategically](/post/elevate-org-with-strategic-ai-adoption).
### Kata: **Measure and Improve Value with EBM**
Org Topologies and Evidence-Based Management are distinct but highly complementary frameworks. **Org Topologies**provides the _“where and how to change”_ from a structural perspective, ensuring the organization’s form enables agility and aligns with its purpose. **EBM**provides the _“whether and why to change”_ from a value perspective, ensuring the organization’s operations remain focused on delivering measurable value and that any change is justified by evidence. [More on OT with EBM](/post/org-topologies-with-evidence-based-management).
## More Katas
We are collecting and documenting Elevating Katas. Browse our [Knowledge Base](https://www.orgtopologies.com/knowledge-base) to learn more.
Toward a Collection of Elevating Katas
## Conclusion
Leaders, rather than micromanaging or launching episodic “transformation programs,” can establish a handful of carefully chosen katas and ensure they are faithfully practiced. Over time, as people develop fluency in these routines, the organization’s agility and resilience increase. This approach to change is subtle but powerful, as it leverages the human capacity to learn by doing. Rather than relying solely on workshops or memos, it uses ritualized action to shape behavior and mindset.
Elevating Katas embody the principle that lasting organizational change arises from systemic coherence and incremental, behavioral shifts. By focusing on daily routines—how teams refine backlogs, how product definitions are broadened, how budgets are allocated, and how product owners engage with strategy—these katas directly influence the elements of Galbraith’s Star Model. The result is a more agile organization, one that continuously aligns its strategy, structure, processes, people, and rewards.
These katas do not offer a magic bullet; they demand patience, consistency, and intentional practice. Yet, this very requirement ensures authenticity. As habits form, culture evolves organically, and the organization’s capacity to learn and adapt deepens. In a world where the only constant is change, Elevating Katas serve as reliable instruments for shaping the future, guiding organizations toward sustained performance, relevance, and growth.
---
# Matrix, Functional, Project, and Product Structures vs. Scrum and LeSS
**Date:** 2024-12-13 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/matrix-functional-project-product-structures
**TL;DR:** Functional, project, and matrix structures all break Scrum in predictable ways: silos, dual reporting, resource-pool teams, disempowered delivery. LeSS addresses this by flattening hierarchy, forming cross-functional feature teams around a broad product definition, and optimizing for value flow over resource efficiency.
Organizational structures define how work, responsibilities, and decision-making are distributed. The four major types are functional, project, matrix, and product (divisional) structures. Each has strengths and weaknesses — especially in software-intensive environments that require agility.
Dysfunctional implementations of Scrum often occur when it is layered on top of outdated matrix or functional structures without addressing organizational design flaws — a pattern we call [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds). Large-Scale Scrum (LeSS) offers an alternative by advocating a product-centric structure optimized for delivering customer value through systems thinking and simplification.
## Organizational Structures and Their Challenges
### Functional Structure
In a functional structure, employees are grouped into departments based on specialized skills (e.g., engineering, marketing, finance).
- **Characteristics:** hierarchical reporting, deep specialization, and siloed work.
- **Strengths:** focus on technical expertise and skill development.
- **Weaknesses:**
- Limited collaboration across functions (silos).
- Delays caused by handoffs and lack of ownership.
- Difficult to adapt to changing priorities.
> Example: Developers write code but depend on a separate QA department for testing, leading to delays and misalignment.
### Project Structure
The project structure organizes work into temporary teams assembled to deliver specific projects. Teams disband once the project concludes.
- **Characteristics:** time-bound goals, project managers leading delivery, and multi-tasking across projects.
- **Strengths:** clear focus on project objectives and flexibility for one-off initiatives.
- **Weaknesses:**
- Team disruptions as employees shift between projects.
- Focus on short-term delivery over long-term sustainability.
- Context-switching reduces productivity.
> Example: A team is formed to build a new product version over six months. Once completed, team members are reassigned to unrelated projects.
### Matrix Structure
Matrix structures combine functional and project-based elements. Employees report to both functional managers and project managers.
- **Characteristics:** dual reporting lines, resource sharing across projects, and high coordination overhead.
- **Strengths:** efficient use of specialized resources and balancing functional expertise with delivery focus.
- **Weaknesses:**
- Conflicting priorities between functional and project managers.
- Increased overhead and delays from coordination.
- Multi-tasking and fragmented focus undermine team productivity.
> Example: A software engineer reports to a functional manager for career development while working on multiple projects under different project managers.
### Product (Divisional) Structure
A product structure, also called a divisional structure, organizes teams around specific products or product lines. Each division operates as a semi-autonomous unit.
- **Characteristics:** cross-functional teams focused on end-to-end delivery for a product.
- **Strengths:**
- Teams own end-to-end features, reducing handoffs and dependencies.
- Improved alignment with customer value and faster adaptability.
- Teams are stable and long-lived, improving efficiency and learning.
- **Weaknesses:**
- Requires significant reorganization to dismantle silos.
- Resistance from functional managers who lose control over specialized teams.
> Example: A cross-functional team focuses on the "shopping cart" product in an e-commerce platform, continuously iterating and improving it.
## Dysfunctional Scrum in Traditional Structures
When Scrum is implemented in functional, project, or matrix structures without addressing systemic design, it often leads to dysfunction:
- **Scrum Teams as Resource Pools:** teams remain specialists working on fragmented components instead of delivering end-to-end features.
- **High Coordination Costs:** dependencies across silos require layers of project management, reducing agility.
- **Lack of Ownership:** teams work on projects with shifting goals rather than focusing on product improvement.
- **Overarching Project Mentality:** Scrum is misused as a delivery framework in long-running projects, reinforcing phase-based workflows.
- **Disempowered Teams:** functional managers or project managers continue to dictate priorities and decisions, undermining team autonomy.
## Large-Scale Scrum (LeSS) as a Product-Centric Alternative
LeSS advocates for a product-centric organizational structure, addressing the limitations of functional, project, and matrix designs. Key aspects include:
**Broad product definition.** LeSS emphasizes defining the product broadly to include all teams working toward delivering customer value. Unlike fragmented project structures, LeSS ensures teams collaborate across the entire product, reducing silos and dependencies.
**Cross-functional feature teams.** LeSS eliminates functional silos by forming long-lived, cross-functional feature teams. These teams are equipped with all skills necessary to deliver end-to-end features, reducing handoffs and ensuring ownership.
**Flattened hierarchy.** LeSS removes matrix reporting lines, eliminating the dual authority of functional and project managers. Managers transition into roles focused on coaching and mentoring teams, not controlling their work.
**Focus on continuous product development.** Unlike project structures, LeSS emphasizes continuous product development over short-term projects. Teams iterate incrementally, delivering potentially shippable product increments each Sprint.
**Simplification through systems thinking.** LeSS simplifies organizational design by optimizing for value flow rather than resource efficiency. This reduces queues, delays, and coordination overhead, improving adaptability and delivery speed.
## Simplifying Org Structures with LeSS
Traditional organizational structures — functional, project, and matrix — were designed for efficiency, predictability, and control. However, in modern software-intensive environments these models create silos, dependencies, and coordination overhead, preventing organizations from delivering value quickly and adaptively. This complexity is further exacerbated when frameworks like Scrum are overlaid onto outdated structures without addressing systemic design issues.
Large-Scale Scrum (LeSS) offers a compelling alternative by advocating for product-centric simplicity.
By leveraging "More with LeSS" principles and focusing on simplifying organizational structures, LeSS enables organizations to optimize for delivering customer value. The seven principles for simplification include:
1. Transitioning from specialist roles to cross-functional teams that collaborate effectively and own end-to-end outcomes.
2. Shifting from resource-thinking to people-thinking, recognizing team members' full potential and creativity.
3. Organizing teams around customer value rather than technical components to enhance alignment and adaptability.
4. Replacing isolated efforts with continuous cross-team cooperation for shared learning and unified goals.
5. Reducing reliance on coordination mechanisms by fostering integration through collaboration.
6. Moving from project-based thinking to long-term product focus, ensuring sustainable value delivery.
7. Consolidating efforts into broad product definitions to streamline processes and maximize impact.
By embracing these principles, LeSS promotes a simpler, flatter, and more adaptive organizational design. This shift eliminates functional silos, minimizes dependencies, and empowers long-lived, cross-functional teams to deliver customer value sustainably and reliably.
Ultimately, transitioning from complex matrixed systems to a simplified product-centric structure requires systemic change and a commitment to learning.
Organizations that adopt LeSS principles gain the ability to respond quickly to change, focus on outcomes, and unlock innovation by reducing complexity and fostering alignment. The [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos) illustrates this transition from component teams to a whole-product focus in practice.
---
# The Myth of Conway's Law
**Date:** 2024-11-28 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/myth-of-conways-law
**TL;DR:** Conway's Law is treated as destiny — your org must mirror your architecture. Twenty years of LeSS adoptions prove otherwise. Cross-team code ownership works and is surprisingly easy once you actually try it. The common interpretation limits thinking; the original paper does not say what people think it says.
*Myth of Conways Law*
A big part of LeSS is to have teams work on entire customer problems, across the product, and that leads to cross-team code ownership (which we refer to as feature teams — what I'd call [whole product focus teams](/post/whole-product-focus-team)). I've been working in cross-team code ownership organisations now for more than 20 years and consider that to be hugely advantageous over mapping teams to part of the system. Of course, there are problems you'll need to figure out, such as code standards, dealing with production issues, regular maintenance upgrade, and more. Most of these problems have multiple known solutions. In fact, I'm always amused how relatively easy it is to have cross-team shared code ownership relative to the amount of arguments people, who never experienced it, have about it.
One of the consistent myths is the common interpretation of "Conways Law." Your organisation and your architecture must map/mirror. In LeSS adoption, this is just not happening, it is not true, not a law. It has been frustrating me for 20 years that people limit their thinking about problems in product development because they "must adhere to Conway's Law". Really, it doesn't have to be like that. If you free your mind from the limitations that Conway's Law gives you then you can find wonderful alternatives to structure product development. For a real example of this, see the [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos) — where component teams became feature teams working across the entire codebase.
The architecture-follows-org argument also fuels premature decisions like [splitting into microservices](/post/microservices-are-technical-debt) — which I argue is technical debt, not architectural progress. In recent LeSS Conference, Craig had a talk about Conway's Law itself and how people interpreted it. He dived into the original paper and point out that the common interpretations are not actually what it says in the original paper. The video of the talk is now online.
---
# No. Not Everything Is A Product
**Date:** 2024-11-17 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/no-not-everything-is-a-product
**TL;DR:** Calling everything a product — value streams, components, platforms — inflates complexity instead of reducing it. Each 'product' spawns its own strategy, roadmap, PO, and teams. The more narrow products you define, the harder it becomes to manage the whole. You end up with portfolio management overhead and near-zero adaptiveness.
I would like to reflect on a [webinar by Dave West on Product Definition](https://www.youtube.com/watch?v=ujPL7j02yVY). More than a thousand people watched on the spot — so, an important discussion.
First of all, I appreciate Dave's involvement in the field as a subject-matter contributor. Being a CEO, he doesn't need to do this. But he seems to be driven by true passion, and it is fantastic to see this energy. I wish other certification bodies had such a leader!
Secondly, Dave's definition of a product as an "abstraction of complexity" that contains multi-dimensional interests, investments, and opportunities is a useful one. The contrast of project vs. product model that he drew on his talk was well thought of.
But! Here comes my analysis of the key idea of the talk:
> I CANNOT AGREE THAT EVERYTHING IS A PRODUCT.
Just the other day I listened to [John Cutler](https://www.linkedin.com/in/johnpcutler/)'s podcast where he clearly articulated that "no, not everything is a product."
One can apply product thinking to a problem space — including seeing organizations and org change as a product.
But!
> IT IS DANGEROUS TO SEE EVERYTHING AS A PRODUCT INCLUDING VALUE STREAMS, INTERNAL COMPONENTS AND PLATFORM DEVELOPMENT.
Do I have a few more available characters in this post to explain?
If everything is a product, then:
- everything has its strategy, investments, roadmaps, product owners, teams…
- everything is a thing of its own
- everything is boxed with strict boundaries
- everything is siloed
- everything needs to be managed separately
As a result:
> THE MORE "PRODUCTS" ARE DEFINED, THE HARDER IT IS TO MANAGE "THE WHOLE."
This is not a black-and-white discussion. But we need to understand the dynamics of our decisions.
Such org design with many narrow products will inevitably lead to increased complexity, the need for portfolio and dependency management, an army of product owners, coordinators, specialized teams, scrum masters... A lot of self-inflicted complexity and a very low level of adaptiveness — the same dynamics behind [premature platformization](/post/avoid-premature-platformization).
Imagine what needs to happen when this org needs to be reconfigured to fit a change in the strategy or in the architectural approach? Difficult, expensive, slow. Low overall agility.
To conclude: it is vital to lead this discussion on product definition. And it is no less important to raise it beyond the industry status quo and easy solutions.
A product model is a good start but offers no perfection state. We need a holistic product model — what I'd call a [whole product focus](/post/whole-product-focus-team) approach. Something to strive toward and get constantly challenged in our human, local thinking.
These are just my thoughts. 💭 Happy to discuss.
*Originally posted on [LinkedIn](https://www.linkedin.com/posts/alexeykrivitsky_i-would-like-to-reflect-on-a-yesterdays-activity-7257718524393996288-iGMF?utm_source=share&utm_medium=member_desktop).*
---
# Microservices are Technical Debt
**Date:** 2024-11-17 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/microservices-are-technical-debt
**TL;DR:** Microservices are technical debt — a conscious trade-off, not shitty code. You gain short-term delivery speed in a narrow area. You pay with increased architectural complexity, fragmented team knowledge, and reduced long-term organizational adaptability. Like all debt, if you never pay it back, the accumulated entropy kills you.
Have you ever wondered that microservices are technical debt?
Just not in the way we're used to using the term: technical debt (TD) doesn't mean shitty code.
Shitty code is shitty code.
TD is when you decide to do something simpler and cut your quality standards to win at something else — getting some expected effect faster.
But since there are no free pies — after getting the temporary expected effect, you have to go back and redo it well — pay the TD. Otherwise the accumulated entropy will slowly kill you.
Notice the difference with shitty code. TD is a conscious decision.
Now back to microservices. They help teams kick out functionality in a narrow area of requirements faster without having to work on the entire product — an approach often justified by [the common misinterpretation of Conway's Law](/post/myth-of-conways-law). This yields a time gain.
A temporary gain. Just like TD.
But since nothing in this universe is free, the price of such an architecture is:
1. making it more complex,
2. fragmenting team knowledge and responsibility, and
3. reducing your organization's adaptability long-term — the same risk as [premature platformization](/post/avoid-premature-platformization).
> Microservices are a technical debt. Something to think about!
---
# Product Definition with Dave West
**Date:** 2024-10-31 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/product-definition-dave-west
**TL;DR:** Dave West's product-as-abstraction framing is useful, but 'everything is a product' is dangerous. Each new product boundary spawns its own strategy, PO, roadmap, and teams. The more narrow products you define, the harder it gets to manage the whole — self-inflicted complexity that kills adaptiveness.
I would like to reflect on a yesterday’s webinar by Dave West on Product Definition. More than a thousand people watched on spot — so, an important discussion.
First of all, I appreciate Dave’s involvement into the field as subject-matter. Being a CEO he doesn’t need to do this. But seems he is driven by true passion and it is fantastic to see this energy. I wish other certification bodies had such a leader!
Secondly, Dave’s definition of a product as an “abstraction of complexity” that contains multi-dimensional interests, investments and opportunities is a useful one. The contrast of project vs product model that he draw on his talk was well thought of.
But! Here comes my analysis of the key idea of the talk:
I CANNOT AGREE THAT EVERYTHING IS A PRODUCT.
Just the other day I listened to John Cutler’s podcast where he clearly articulated that “no, not everything is a product”.
One can apply product thinking to a problem space. Including also seeing organizations and org change as a product.
But!
IT IS DANGEROUS TO SEE EVERYTHING AS A PRODUCT INCLUDING VALUE STREAMS, INTERNAL COMPONENTS AND PLATFORM DEVELOPMENT.
Do I have few more available characters in this post to explain?
If everything is a product, then
- everything has its strategy, investments, roadmaps, product owners, teams …
- everything is a thing of its own
- everything is boxed with strict boundaries
- everything is siloed
- everything needs to be managed separately
As a result:
THE MORE “PRODUCTS” ARE DEFINIED, THE HARDER IT IS TO MANAGE “THE WHOLE”.
This is not a black and white discussion here. But we need to understand the dynamics of our decisions.
Such org design with many narrow products will inevitably lead to increased complexity, need of portfolio and dependency management, an army of product owners, coordinators, specialized teams, scrum masters... A lot of self-inflicted complexity and very low level of adaptiveness. This is exactly the kind of [premature platformization](/post/avoid-premature-platformization) that fragments ownership and kills agility.
Imagine what needs to happen when this org needs to be reconfigured to fit to a changes in the strategy or in the architectural approach? Difficult, expensive, slow. Low overall agility.
To conclude: it is vital to lead this discussion on product definition. And it is not less important to raise it beyond the industry status quo and easy solutions.
A product model is a good start but offers no perfection state. We need a holistic product model — what I explore further in [*No. Not Everything Is A Product*](/post/no-not-everything-is-a-product). Something to strive towards and get constantly challenged in our human’s local thinking.
These are just my thoughts. 💭 Happy to discuss.
---
# Individuals and Interactions = Relationship (the Blah-Blah-Blah Manifesto)
**Date:** 2024-10-16 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/individuals-and-interactions-relationship-the-blah-blah-blah-manifesto
**TL;DR:** Individuals and interactions is really just one word: relationships. Relationships are the root of any process improvement and any change. Before you induce change in a team or organization, build the relationship first. Don't do change on someone — do it with someone. Obvious, yet constantly forgotten.
## The image
The other day, I got reminded of this image I made somewhere in 2011:
What did I mean by this? Let's see:
Aha! Relationships!
> Relationships are the roots of any process improvement and any change.
Let's remember that. Before you decide to induce a change in a team, department, or organization — build relationships and bring the people along on the journey. This is also why [reactive-to-creative leadership](/post/reactive-to-creative-leadership) matters so much: you can't build real relationships from a place of fear.
> Don't do change on someone, do it with someone.
It's so obvious and so often forgotten. And when it is forgotten, [frameworks become the substitute for real agility](/post/agile-frameworks-not-what-makes-you-agile) — process replaces trust.
## The talk
The entire historical video from Agile Tour Vilnius, 2011:
Yesterday I got a chance to participate in an insightful webinar by Benedikt Stemmildt, *"Don't build features, build factories."*
Benedikt was very clear in the very beginning that he didn't like the term **feature factory**. I agree it carries a weight, as it is used to contrast intelligent value-adding to mechanically factory-like outputting of stuff.
I agree. And that got me thinking, so I had to reconceptualize the factory thing. Below is my take.
Agentic AI systems operate through **nested work-and-learning loops**.
## 1) Coding Factory
The innermost loop is the **Coding Loop**, where agents (AI and in older times human programmers) optimize implementation quality through rapid feedback cycles such as Red → Green → Refactor. This loop is excellent at producing working tested code. Yet having only one loop, such a Coding Factory can optimize toward technically correct irrelevance, as more code doesn't mean more value.
This is the same trap I described in [The Ferrari Trap](/post/the-ferrari-trap) — a faster engine doesn't help if it's pointed at a wall.
## 2) Feature Factory
The next level system is the **Feature Factory**, which adds a Feature Loop (on top of a Coding Loop): Refine → Specify → Verify. This is where behaviors, workflows, and executable specifications emerge.
As of mid year 2026 all current "agentic product development" systems describe this level of AI automation. They become highly efficient factories capable of generating and validating functionality at scale. However, obviously feature optimization alone does not guarantee meaningful outcomes either, so here **humans are required to operate the factories**, directing and ensuring the value. It's the same gap I keep circling in [Pair Programming in the AI Era](/post/pair-programming-in-the-ai-era) and [AI-Native vs. AI-Augmented](/post/ai-native-vs-ai-augmented).
## 3) Impact Factory
Adding the outermost **Impact Loop**: Opportunity → Hypothesis → Impact turns the system into a real Impact Factory.
The external loop continuously learns from real-world effects and redirects the lower loops toward meaningful goals.
Imagine three concentric feedback systems in motion: at the center, code rapidly iterates toward correctness; around it, features evolve toward usability and coherence; and at the outer edge, real-world signals continuously reshape priorities based on measurable impact. Each loop feeds constraints and learning inward, while insights from the inner loops propagate outward, creating a **living adaptive system** rather than a linear production pipeline.
In this model, a common "Feature Factory" is not the final stage of agentic AI maturity — **it is only the middle layer.** The progression from Coding Factory to Feature Factory to Impact Factory reflects an expansion in what the system is capable of learning from: first implementation correctness, then behavioral usefulness, and finally real-world impact. (I've written before about how [AI amplifies whatever trajectory your org was already on](/post/ai-native-startups-100x) — a Feature Factory with no Impact Loop is that amplification made literal.)
Each outer loop constrains and guides the inner loops, ensuring that local optimization contributes to broader objectives rather than drifting into isolated efficiency.
Truly adaptive agentic systems require all three nested loops: code optimization, behavioral optimization, and outcome optimization.
To learn more about building these levels with an 8-tier model for mastering agentic product engineering, see the [Agentic Engineering Guide](https://agentic-engineering.guide/).
---
# Specialization, Generalization, and Who Gets to Be Complete
**Date:** 2026-06-02 · **Reading time:** 5 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/specialization-generalization-demand
**TL;DR:** Specialize when demand is infinite and stable. Generalize when it's dynamic. AI is washing away the stable narrow demand in software — but the org chart decides who's allowed to be complete.
**Specialization makes perfect sense when you have close to infinite demand for that skill. Generalization makes sense when you want to serve a dynamic, broader demand.** It is that simple.
Should doctors operating on knees also do hips? No. Why would they? There is an infinite demand of misplaced meniscus and torn ACLs. Should a neurosurgeon also set broken bones? No need — there's more than enough demand to fill a career ten times over.
Must a classical pianist also learn to play other instruments? Not required. There are more piano tunes than she can ever play in her lifetime.
What about a backend Java developer? The one that is on a payment team? Should she stay in that narrow niche?
Well, it depends. Depends on the stability of the demand. And historically perhaps it used to be more or less stable. Or we thought it was — and we covered the fluctuations by making up work. But that worked well for a while.
As a result the ultimately holistic discipline of **software engineering** got artificially split over time into dozens upon dozens of micro-specializations.
Now I see the pendulum is accelerating the other way.
In the age of AI / agentic engineering almost anyone can open almost any repository, prompt an architectural diagram, figure out how to run tests, build, deploy, add missing coverage — and eventually make necessary changes. The stable narrow demand that justified "I only do payments in Java" is collapsing. The **sand castles of narrow career paths** are being washed away. (It's the same shift I traced in [AI Replaces Tasks, Not People](/post/ai-replaces-tasks-not-people) and [Routine vs. Adaptive Expertise](/post/routine-vs-adaptive-expertise).)
But here's the thing that bothers me the most: **the individual can't generalize if the organization won't let them.** A developer ready to work end-to-end hits a wall when the org chart still carves work into component teams, hands it through queues, and measures people by role, not outcome. **The structure — not the tooling — determines who gets to be complete.** I keep running into this same wall in [The Super IC Trap](/post/super-ic-trap-guild-hypothesis) and in the [Multi-Learning org design pattern](/post/multi-learning-org-design-pattern-ai).
For those few domains with genuinely infinite demand — designing and training LLMs, perhaps — specialization holds. For the vast majority of software engineers, radical broadening is already necessary.
Perhaps, you don't like the term "generalist"? Call it **broad specialist**. The label doesn't matter. What matters is: does your organization allow it?
We're entering a world where makers can finally be complete. The question is whether your org will let them — or keep slicing the work into pieces no one person is allowed to finish. You can hear the same tension in [why roles built on artificial scarcity are getting squeezed](/post/why-scrum-masters-are-getting-fired).
---
# Vibing or AI Engineering? A Spectrum for Personal Growth
**Date:** 2026-05-30 · **Reading time:** 3 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/vibing-or-engineering-spectrum
**TL;DR:** Vibing feels like a slot machine — drop a prompt and hope. But it's a spectrum, not two camps. Used right, AI isn't a slot machine but a gym with a coach.
There seem to be two camps. On one side, **vibing**: you treat the AI like a slot machine. Drop a coin — a prompt — pull the lever, and hope for magic. Sometimes the cherries line up; often they don't, so you feed it another coin.
On the other side, **agentic engineering** as a serious craft: design, guardrails, lifecycles, tests — things you can maintain and extend.
Most people read these as opposites. Black or white. You're either gambling or engineering.
I prefer to think of it as a **spectrum**. You can sit closer to either end, and the right place depends on the task — its complexity, and the maintainability and extensibility you actually want. A throwaway script and a system you'll live with for years don't deserve the same spot on the line.
And here's the part I find exciting and human-centric: even if you start by vibing (which I often do), you can ask the AI to explain what it just generated. Name its assumptions. Explain the technology. Drill deeper into the terms you don't know. Prompt it to sketch you a diagram.
So the random process of finding luck turns into an **intentional learning process**. And each prompt is now a step toward engineering.
So maybe that "spectrum from vibing to engineering" is just another word for depth of skill. And skill isn't binary — it's something we grow over time. Which flips the metaphor on its head. Used this way, the AI isn't a slot machine at all. It's a **training machine — a gym**.
So perhaps the real question isn't where you are on the spectrum at the very start, but whether you're using the machine to gamble, hoping for a sudden breakthrough — or to grow strength one step at a time. And to build on the sport metaphor: AI can be a [great coach with infinite patience](/post/ai-augmented-multi-team-pbrs).
---
# AI-Native, AI-Augmented, AI-Sprinkled: The Three AI Strategies That Explain the Performance Gap
**Date:** 2026-05-28 · **Reading time:** 4 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/ai-native-vs-ai-augmented
**TL;DR:** Three AI strategies: 100X (AI-native, clean-slate), 10X (AI-augmented, deliberately restructured), 1X (AI-sprinkled, same structure + tools). Most companies think they're at 10X. The performance gap is striking.
These terms aren't absolutely defined. They get redefined daily — by analysts, vendors, whoever is presenting the slides. In my consulting work, I use all three as distinct levels, because I see real differences between the organizations they describe. This is a short article to lay down those three definitions — the kind that are useful when a conversation needs to go somewhere concrete.
## The Three Levels
**100X — AI-native.** Built from scratch with AI as a first-class assumption. No legacy structure, no mandate pinning, no coordination overhead inherited from a pre-AI era. Anthropic's release cadence in Q1 2026 — major model improvements and new capabilities shipped consecutively across weeks — is a visible data point. A company structured for AI from the start moves at a pace that restructured organizations can observe but rarely match. These organizations are the [new performance benchmark](/post/ai-native-startups-100x) — not a future threat, a present competitive fact.
**10X — AI-augmented.** A legacy organization that has been deliberately restructured for AI. Not because it swapped tools, but because it changed structure: broader mandates, fewer handoffs, people following value instead of defending their assigned lane. This is what compound gain looks like in practice — AI tools multiplying across an expanded mandate rather than accelerating a narrow one. Getting here requires structural work. The [subsidized token era masked who had done that work](/post/subsidized-tokens-are-ending).
**1X — AI-sprinkled.** Same structure, same team formation, same coordination habits — with AI tools added on top. Copilot on every machine. AI-assisted PR reviews. Ticket summarization. Individual developers move faster. The system-level performance difference between this and 10X is striking — AI amplifying the [Ferrari Effect](/post/the-ferrari-trap), not dissolving it.
## The Practical Goal
100X is the benchmark. 10X is the goal.
Getting there is a structural question: mandate width, not skill levels. The org that compounds AI owns outcomes end-to-end — it isn't the one where everyone has Copilot. [That distinction was supposed to be what agile transformation achieved](/post/agile-was-homework-ai-is-assignment). Most organizations didn't get there. The urgency to get there is higher now.
## The Diagnostic Question
Not "are you using AI?" but "has your structure changed?"
If your teams still form around the same specializations, own the same narrow component, and hand off to the same downstream queues — you're at 1X. The tools sit on top of a structure that was never designed for them. That's the [Ferrari Trap](/post/the-ferrari-trap): local speed that doesn't add up to system-level performance.
If you've deliberately redesigned for the agentic AI age — not just accelerating old habits within legacy structures — you're building toward 10X. AI tools start to compound instead of just accelerate.
---
# AI Replaces Tasks, Not People — Unless Your Org Is Designed That Way
**Date:** 2026-05-20 · **Reading time:** 7 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/ai-replaces-tasks-not-people
**TL;DR:** When your job equals the task you do, AI finishes the task and you sit idle. The fix is organizational, not technological — broaden mandates or watch displacement happen by design.
I talked to a CEO recently. He runs a 70-person company — deep learning for manufacturing quality control, video cameras on factory lines. His developers had been writing the code that trains and deploys those models. Then AI got good enough to do most of that work.
So he made them an offer: transition from developer to consultant. When AI handles the implementation, what's left for humans is understanding customer problems and driving solutions end to end.
Some developers took the offer. Some didn't.
The ones who didn't are now in an uncomfortable position. The CEO is hiring consultants externally and figuring out what to do with developers whose daily output AI can match in a fraction of the time.
This CEO is an exception. He didn't treat his developers as costs to be reduced — he saw them as potential to be developed. New titles, new mandates, a deliberately redesigned organization that offers people an elevated path when their current tasks get automated. Most companies don't do this. Most companies see the automation and reach for the headcount spreadsheet.
This is not an AI story. This is an org design story.
## The Task Trap
Think about the roles in your organization. A database designer who only touches databases. A frontend developer who only writes React. A QA engineer who only runs test suites. Each role is scoped to a single task type, and each person's identity is wrapped around that scope.
When AI arrives, it doesn't evaluate whether you're a good database designer. It evaluates whether the task "design a database schema" still requires a human at all. If your job equals the task you do, and AI can do that task, the math is straightforward.
I worked with a database designer at a company I'll call DBN. Individually brilliant. With AI, his productivity on database work went through the roof — 100X by any reasonable measure. But the organization only allowed him to do database work. He was mandated to stay in his lane. When I ran the numbers, he had roughly 297 idle days per year. There simply wasn't enough pure database work to fill a calendar, even before AI made it faster.
AI didn't create his problem. It exposed it. Narrow specialization was already a fragile arrangement. AI just removed the ambiguity.
## 100X Individuals, 1X Organizations
Peter Steinberger runs 20 AI agents in parallel. Individual developers are hitting productivity numbers that would have been career-defining five years ago. The individual AI moment is real.
But organizations are still on their old trajectory. No tests, no documentation, mountains of tech debt, the same handoffs and queues and approval chains. Gary Hamel calls this the "crack of history" — powerful new technology wielded inside organizational structures designed for a different era. The mismatch, not the technology, is the problem.
Most companies respond to AI the way they responded to agile: layer it on top of the existing structure and hope the structure doesn't notice. The paradigm stays the same; only the speed changes. More code, faster. More designs, faster. More of exactly what you were doing before, at higher velocity, on the same trajectory.
That's the paradigm trap. You need to change the paradigm first, then amplify with AI. When you amplify first and change never, you're accelerating in the wrong direction. [The Ferrari Trap](/post/the-ferrari-trap) applies perfectly here: a faster car on the wrong road just gets you to the wrong place sooner.
## The Displacement Map
This is where the Org Topologies Displacement Map becomes useful. It has two axes: Scope of Work Mandate (narrow to broad) on the vertical, and Scope of Skills Mandate (narrow to broad) on the horizontal.
The bottom-left corner — narrow work, narrow skills — is the black zone. "Space Disappearing." That's where the DBN database designer sits. That's where every role scoped to a single repeatable task sits. AI compresses that space first.
The arrows on the map point up and to the right: from Outputs to Outcomes, from Incomplete to Complete. People who move in that direction own broader work (not just "write code" but "solve customer problems") and broader skills (not just databases but the full stack of understanding needed to deliver value). The top-right quadrant is where humans remain irreplaceable — not because AI can't do individual tasks there, but because the judgment, context-switching, and problem-framing required don't decompose into automatable units.
The CEO's offer to his developers was exactly this move. He was pointing at the top-right quadrant and saying: go there. Some made the shift. Others stayed put.
## Elevation of Human Intelligence
What the CEO was describing — whether he used these words or not — is the elevation of human intelligence. You stop being an execution resource and start owning the bigger picture. On the Org Topologies map, that's the driving quadrant, where people figure out what to build, not just build what they're told.
This isn't about becoming a manager. It's about broadening what you're responsible for and what you're allowed to know. A developer who understands the customer domain, participates in discovery, owns deployment and monitoring, and can switch between value areas when demand shifts — that person doesn't have a task that AI replaces. They have a role that AI amplifies.
But here's the catch that most AI optimists skip over: the organization has to allow this move. And most don't.
## The Organizational Ceiling
Most organizations are designed to prevent exactly the kind of broadening that makes humans resilient to AI displacement. The structure keeps people in narrow task boxes. Job descriptions define boundaries. Reporting lines enforce lanes. Performance reviews measure output within a specialty, not impact across a value cycle.
When AI finishes the narrow task faster, the person sits idle, and management sees rising costs with no matching improvement. Eventually it becomes a cost-cutting conversation, and engineers get associated with costs, not value. Not because AI replaced them, but because the organization was already designed to treat them as interchangeable task-executors. AI just made the price comparison unfavorable.
This is the ceiling. Individual developers can be 100X productive, but if the organization pins them to narrow streams and measures them on task throughput, the system absorbs none of that potential. 100X individual, 1X organization. The [DORA 2026 report](/post/dora-2026-developers-faster-teams-messier) quantified this exact gap: individual developer effectiveness up, software delivery instability up right alongside it. The gains evaporate into idle time, overproduction of the wrong things, and queues that existed long before the first token was generated.
## Two Wings
The structural fix maps to two organizational capabilities — what we call the Two Wings in *10X ORG*.
**Wing 1: Full value cycle mandate.** Give people and teams ownership of the complete flow from idea to production. Not "the backend part" or "the QA step" — the whole thing. Fast-flow teams, not functional silos. When a team owns the entire cycle, AI accelerates the whole arc, not just one phase of it.
**Wing 2: The ability to switch between value areas.** As I explored in [*Two Wings of a 10X Bird*](/post/two-wings-of-a-10x-bird), Wing 1 without Wing 2 is local optimization. A search team that owns its full value cycle is great — until search demand drops and that capacity sits unused. The organization needs people who can move between value areas as demand shifts. Unpin from streams.
Management has two dials to turn: grow multi-expertise (help people broaden their skills) and unpin from streams (stop assigning people permanently to one value area). These aren't binary switches. They're dials. You turn them gradually. But the point is that management must turn them, not leave them at zero and wonder why AI investments aren't paying off.
## AI Broadens, Not Just Accelerates
Here's what gets lost in the "AI replaces jobs" narrative: AI is a broadening tool, not just a speed tool. Developers can open repositories they've never touched and navigate them with AI assistance. They can learn new domains faster, co-own systems they'd previously needed months of ramp-up to understand, and modify things they were never supposed to modify.
AI doesn't just make the database designer faster at databases. It makes the database designer capable of doing frontend work, infrastructure work, customer analysis. AI is a teacher as much as a doer. Organizations that recognize this and deliberately use AI to broaden their people's capabilities — rather than just to accelerate their existing narrow tasks — will find themselves in a completely different position.
The [multi-learning](/post/multi-learning-200-years-wrong-model) idea isn't new, by the way. It was described in HBR in the late 1980s and was actually the core idea behind Scrum before the industry buried it under ceremonies and certifications. People are the real learning machines. AI makes that learning faster and cheaper than it has ever been. The question is whether your organization allows it.
## AI Is a Threat, and a Savior?
AI can do more than accelerate your current work. It can help you broaden — acquire new skills, work across domains, own bigger problems. But only if your organization lets you. When it doesn't, you're not being replaced by AI. You're being replaced by a job description that was already too small for any human.
## Keep People, Elevate the Work
AI automates tasks. It does not automate judgment, curiosity, or the ability to sit with a customer and hear what they're actually saying.
Humans are good at talking to customers, finding problems worth solving, connecting insights across domains, navigating ambiguity, and making decisions when the data is incomplete. These are the things that create value — and they don't decompose into prompts.
The question for every company isn't whether AI will automate tasks. It will. The question is what happens to the people who used to do those tasks. Do you broaden their mandates, invest in their growth, redesign the organization so they can take on bigger work? Or do you wait until the math catches up and the conversation turns to headcount?
The CEO in our story chose elevation. Most organizations haven't made that choice yet. The ones that do will find that AI doesn't reduce the need for people — it raises the bar for what people do.
Change the company — or change the company.
---
# DORA 2026: Developers Faster, Teams Messier
**Date:** 2026-05-12 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/dora-2026-developers-faster-teams-messier
**TL;DR:** DORA's 2026 data confirms it: individual developers are measurably faster with AI, but team-level delivery is flat or worse. The 280x inference cost drop removed the technology barrier. What remains is organizational design — and that is where the ROI actually lives.
[DORA's 2026 AI study](https://dora.dev/ai/roi/report/) just dropped. It puts a dollar figure on what many of us have been feeling.
39% first-year ROI. $8.4M invested, $11.6M returned. Google Cloud customers report 727% over three years. The financial case for AI-assisted development is now officially closed.
Except for the chart on page 20.
Individual developer effectiveness is the strongest measured effect. Right next to it — software delivery instability. Second strongest. Moving in the wrong direction. Team performance barely registers. Burnout unchanged.
Developers are getting faster. Teams are getting messier.
DORA introduces the J-Curve to explain this: learning curve, verification tax, pipeline adaptation. When organizations adopt AI tools, they slow down before they speed up. The dip is real, it's measurable, and most organizations are still in it.
The greenfield/brownfield split makes the pattern concrete. 35-40% productivity gain on new code. 10% on legacy systems. Most organizations run mostly on legacy. The productivity headlines describe a world most companies don't actually live in.
This is the central argument of 10X ORG book we published in February. AI amplifies whatever trajectory your organization was already on. Cross-functional teams with clear ownership and short feedback loops see AI gains compound across the value stream. Siloed components with handoff queues see faster developers producing more code into the same bottlenecks — what I call [the Ferrari Trap](/post/the-ferrari-trap).
DORA's five organizational keys — trust, platform thinking, accessible data, user-centric focus, automated guardrails — are all structural decisions. None of them are tooling decisions.
The 280x inference cost drop since late 2022 tells us the technology barrier is gone. What remains is organizational design — [redesign first, then AI](/post/redesign-for-ai-why-transformation-requires-organization-design). That's where the ROI actually lives. The fix requires [both wings](/post/two-wings-of-a-10x-bird): full value cycle ownership and the ability to redirect capacity when demand shifts.
---
# Multi-Learning: 200 Years of the Wrong Model
**Date:** 2026-05-09 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/multi-learning-200-years-wrong-model
**TL;DR:** For six million years our brains evolved to learn across domains. Two hundred years of factory logic pinned people to single tasks. AI is automating the repetitive work that justified that pinning. What remains is exactly what our brains were built for: multi-learning.
For millions of years, our brains evolved in environments that demanded everything at once. We hunted, gathered, raised children, fought, explored territories, developed languages, and sketched on cave walls. The same brain, the same day.
This is called "multi-learning" in scientific journals, but simply put, this is how humans naturally operate.
Then, about 200 years ago, someone realized you could make more money by putting a person on a single task. Cheaper to train. Easier to replace. The industrial revolution redesigned human activity around a principle that had nothing to do with the nature of our cognition.
That was a temporary optimization. A local maximum that lasted two centuries. But these are just a blink compared to the 6 million years of evolution of our species.
Now it's ending. As I argue in [*Redesign, Then AI*](/post/redesign-for-ai-why-transformation-requires-organization-design), AI collapses the cost of learning — which erodes the very advantage that narrow specialization was built on.
AI is taking over the repetitive, routine work that justified pinning people to single tasks in the first place. And what's left is exactly what our brains were built for: learning across domains, directing, reasoning, envisioning, orchestrating, making judgment calls that no single-purpose agent can make.
Look at the best practitioners today. They're not narrower — they're broader. They sit at the center of their own organization of agents, directing work across boundaries that used to require separate departments.
In the photo on the right, it is not an AI-generated person; it is Peter Steinberger, the creator of the famous OpenClaw, carefully driving this stack of dozens (hundreds?) of AI agents working for him.
We spent 200 years suppressing our strongest capability to make the factory floor more efficient. The factory floor is automated now. And when people stay pinned to narrow tasks in this new reality, [AI doesn't replace them — the org design does](/post/ai-replaces-tasks-not-people).
Time to go back to our strength. To multi-learning at work, which we know so well from non-office hours. Organizations that embrace this shift need [both wings](/post/two-wings-of-a-10x-bird) — full ownership of the value cycle and the ability to switch when value shifts.
---
# Two Wings of a 10X Bird
**Date:** 2026-05-02 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/two-wings-of-a-10x-bird
**TL;DR:** A 10X organization needs two wings: near-zero transaction costs (no handoffs slowing the learning loop) and near-zero switching costs (redirect when value shifts). Most AI adoptions only address one wing. That is why 100X individual gains fail to compound into system performance.
A two-person startup just redesigned a live publishing platform with AI. One prompt builds a working online shop in thirty minutes. The 100X is real.
But why? What makes a tiny team 100X while your organization — with better engineers, deeper pockets, and more data — barely moves the needle?
Two things. Two wings.
Wing one: transaction costs are near zero. A small team runs the full cycle — discovery, delivery, observability, operations and back to discovery— without handing anything off to anyone. No tickets across team boundaries. No three-week intake process. They outlearn everyone because nothing slows the loop.
Wing two: switching costs are near zero. When the data says pivot, they pivot by Tuesday. No sunk-cost roadmap. No six teams committed to last quarter's plan. They don't just run fast — they run the right direction, and they change direction the moment it stops being right.
Running fast isn't enough if you're running the wrong way. Running the right way isn't enough if every course correction takes a quarter.
Now look at how most organizations adopt AI.
The resource model: give every specialist an AI license. The database designer finishes in three days. Then waits. Transaction costs? Through the roof — every handoff, every "wait for the other team." Switching costs? Impossible — people are pinned to their specialty. Neither wing works. This is [the Ferrari Trap](/post/the-ferrari-trap) — faster cars on a jammed highway.
The delivery model: cross-functional teams with AI. Better — the BML (Build-Measure-Learn) loop runs fast inside each lane. But teams can't repoint to where the real value is. They're locked to their stream. One wing flaps. The other is pinned.
The adaptive model: teams that co-own broad customer problems, acquire skills across boundaries, and redirect when value shifts. Both wings work. That's where 100X individual gains compound into 10X organizational performance — what [multi-learning](/post/multi-learning-200-years-wrong-model) makes possible when the org structure allows it.
Most AI adoption conversations start with tools. The better question is: which wings does your organization have? As the [DORA 2026 data confirms](/post/dora-2026-developers-faster-teams-messier), individual developers are measurably faster — but team-level delivery is flat or worse when the structure hasn't changed.
---
Material from the 10X ORG book tour leanpub.com/10xorg — Amsterdam next week (LeSS meetup May 7, DevWorld May 8).
---
# Agile Was Homework, AI Is the Assignment
**Date:** 2026-05-01 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-was-homework-ai-is-assignment
**TL;DR:** You could fake agile for a decade — rename roles, run ceremonies, call it transformation. AI-native startups shipping at 100X just made faking visible. The gap is public now, and the structure of your organization determines which side of it you land on.
This is a digest from the ideas explored in [10X ORG](https://www.10xorg.com/) by Alexey Krivitsky, Roland Flemm, and Craig Larman — a book about what happens when AI meets organizational structure, and why the structure usually wins.
**Listen as a podcast:**
## You could fake agile...
Many did. You could rename your project managers to Scrum Masters, your status meetings to standups, your milestones to sprints. You could buy SAFe licenses, certify 200 people, hang a Kanban board in the hallway, and call the whole thing a transformation.
And it worked — in the sense that nobody called you out. The board saw the slide deck, the consultants got paid, the teams did their retros. Everyone played along. Change theater, done well, can run for a decade.
Your Scrum Master would have told you that's fine. "Agile is an adjective," they'd say. "What matters is that we're more agile this year than last year." And that sounded reasonable, because slow change was tolerable. The market moved at a pace where incremental improvement felt like enough, and nobody was keeping a public scoreboard of how fast your competitors shipped.
But here's the thing about slow change: in most organizations, it was cover for no change at all. The language got better. The ceremonies got smoother. The underlying structure — who decides what, who learns what, who is allowed to work on what — stayed exactly where it was.
That was survivable. Until now.
## You Are Now Being Compared to 100X
[AI-native startups are building full products](/post/ai-native-startups-100x) with one CEO and five Mac Minis. They don't need your org chart, your review cycles, your handoff protocols. They started clean, with no legacy structure and no historical management system weighing them down.
From now on, your organization will be benchmarked against what they can do. Not by you — by your board, your investors, your competitors, your customers who notice that someone else ships in days what you deliver in quarters. One hundred times faster, and not as a metaphor. As a measurable gap.
So your leadership will ask — if they haven't already — why can't we move like that? And why do we see only costs increasing with no visible gains?
The answer is uncomfortable. Your organization didn't start from scratch when AI arrived. It was already on a path — a management system, team structures, habits built up over years. AI found all of that in place, and it is very likely your org is on the same trajectory as before, now with AI spread like fairy dust. Increasing costs, not necessarily gains.
With agile, you could hide in the theater. Fake a transformation, skip the hard parts, and nobody benchmarked you against a fundamentally different kind of organization. With AI, the 100X baseline is public. The gap is visible, and faking it gets expensive fast.
## The Part That's Already Happening
Here's what makes this different from every previous technology wave: your developers already know.
They go home in the evening, open Claude or Codex, and build something in a few hours that would have taken their team two sprints. They pair with an AI agent and ship a working prototype before midnight. Then they come to the office at nine in the morning and sit down in the same org structure, the same approval chains, the same narrowly defined role boundaries that were designed for a world where building software was slow.
They feel the gap every single day. And the ones who are good — the ones you most want to keep — are already thinking about where they could work without that friction. You're not just competing with other employers anymore. You're competing with the experience your own people have at home, where they already operate at ten times the speed your organization allows.
This isn't a theoretical risk. It's a retention clock that's already ticking.
## The Uncomfortable Part
AI doesn't just speed things up. It pushes people away from single-skilling and toward orchestration and outcomes.
Take a database designer — there's an entire section in 10X ORG called "Nobody Needs 1,000X More Databases" that unpacks this example. If AI allows other people to handle much of that work, and allows the designer to do their traditional load in a few days instead of a month, then the question becomes obvious: what will the organization do with this person? Producing more of the same thing is not the answer. There is no customer demand for a thousand times more databases. There won't be enough demand for what they do.
The same goes for UI specialists, business analysts, frontend developers, and a growing list of roles defined by a single skill performed within a fixed boundary.
AI doesn't fire anyone. It just makes certain roles easy to not refill. The people with the narrowest mandates and the least leverage to negotiate are the ones who leave first, and they don't get replaced. This is the displacement pattern — not by job title, but by mandate. In 10X ORG (Chapter 3: Org Topologies), we call this the Scope of Skills Mandate: how many skills an organizational unit possesses and is authorized to apply. When that scope is narrow, the unit depends on handoffs, coordination, and other people's calendars. AI makes narrow units faster at what they do — but it doesn't give them anything else to do.
And here's where diminishing returns hit. If that database designer is kept pinned to the same work — structurally mandated to keep designing databases because "that's what database designers do" — then the acceleration has nowhere to go. The designer finishes in three days what used to take a month, and then sits in a system that has no mechanism for deploying their freed-up capacity elsewhere. The local gain doesn't compound. It dissipates. That's 1X dynamics: faster parts, same system, no global improvement.
The same pattern applies at the team level. Consider a Search team or a Payments Integration team — what 10X ORG describes as Delivery Topology (Chapter 3): units that "ship rapid improvements within a bounded area but are neither expected nor designed to contribute to other, perhaps higher-value work beyond it." If AI makes them ten or a hundred times faster at their bounded work, will there be enough valuable search or payments work to fill their capacity? Almost certainly not. But if they're structurally mandated to keep working on that thing — because "it's faster if a search team works on search" — there won't be any system-level gain. The team is optimizing locally while the organization stays flat.
This is [the Ferrari Trap](/post/the-ferrari-trap) (10X ORG, Chapter 2): adding faster engines to a jammed highway doesn't fix congestion. As Principle 3 of the book puts it, "mandates determine the maximum complexity the organization can handle. If mandates are narrow, the organization can only solve narrow problems, and anything broader turns into dependencies, coordination meetings, and delayed decisions."
[Multi-learning](/post/multi-learning-200-years-wrong-model) — people and teams expanding beyond their primary craft, building capabilities across domains — is no longer a nice principle to put on a slide. It's what Principle 8 of 10X ORG calls "Embed Multi-Learning": a structural requirement, not a training initiative. Without it, AI augmentation gives you a local efficiency gain, not a compound, org-wide one. You get 1X, not 10X.
## The Part Nobody Tells You
Here's the twist: multi-learning is not new.
In 1986, Takeuchi and Nonaka published "The New New Product Development Game" in Harvard Business Review — the paper that later inspired Scrum. They studied Honda, NEC, Canon, and others. The teams that produced breakthrough products weren't narrow specialists. They were multi-learning teams, people with depth who also developed capabilities across domains. They followed value and they learned while delivering.
That was forty years ago.
Most organizations ignored it, or paid lip service. They took the Scrum part — the ceremonies, the roles, the cadence — and left the multi-learning part on the table. Too hard, too expensive, too disruptive to career ladders and HR policies that reward growth within a single funnel. As 10X ORG puts it: "learning has traditionally been treated as a cost to minimize, not a capability to grow."
The agile homework was never about standups and sprints. It was about building organizations where people can learn, follow value, and contribute beyond their job description. The companies that did this homework — that embedded multi-learning as a structural principle, not a training initiative — those companies know how to handle AI. They already have the muscle: broader mandates, cross-boundary work, people who are allowed and expected to grow beyond their current role.
They don't need to panic. They need to accelerate.
### Must-Shaping
M-shaped people. Not T-shaped — that was the polite version. Multiple strokes of depth, connected by the ability to learn across boundaries and contribute wherever the value sits. This is not optional anymore. This is must-shaping.
AI democratizes knowledge and skills, making it easier for people to go beyond their primary craft. As Aiden — the AI character in 10X ORG — explains: "tutors, copilots, and research agents make multi-learning practical in weeks and days, not years. We are entering the new era of flattened learning curves."
But the organization has to allow it. Traditional HR policies and career paths still reward growth within a single clearly defined funnel, and that system is becoming outdated fast. The technology is ready. The structural permission is not.
So leaders need a sense of direction, and the direction is clear: broaden the definition of expertise. Allow people to learn, follow value, and use AI in ways that are still emerging. Not replacing people with AI — amplifying human intelligence with AI. 10X ORG calls this the move toward Adaptive Topology: "a network of interdependent units where adaptation doesn't require a reorganization — it is built into how these units work."
The organizations that did the agile homework know this direction. They've been walking it, slowly, for years. AI doesn't change the direction. It removes the excuses for not moving faster.
And the ones that faked it? They're about to discover that the AI assignment doesn't grade on a curve. The [DORA 2026 data](/post/dora-2026-developers-faster-teams-messier) already shows it: individual developers faster, team-level delivery flat or worse.
The ideas in this digest come from [10X ORG](https://www.10xorg.com/) — available now. If this resonated, the book goes deeper: nice principles, real case studies, and a diagnostic map to see where your organization actually sits.
---
# The Subsidized Tokens Are Ending
**Date:** 2026-04-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/subsidized-tokens-are-ending
**TL;DR:** Cheap AI tokens masked the difference between real restructuring and AI theater. When prices rise, companies that wove AI into their delivery lifecycle will justify the budget. Companies that sprinkled it on unchanged structures will face a CFO asking what they got.
## The Subsidized Tokens Are Ending. Did You Seize It — Or Just Sprinkle AI on a Dysfunctional Org?
Two things happened this week. GitHub Copilot — used by 4 million people weekly — moved to usage-based billing and paused new signups. Separately, Anthropic tested removing Claude Code from their $20/month plan. They reversed it within hours after backlash, but the signal was loud: flat-rate AI is becoming unsustainable.
The all-you-can-eat buffet can be closing soon.
If this trend holds over the next 3–6 months, it will expose a split that cheap tokens have been masking.
Some companies used the cheap-token window to actually restructure. Not just hand out Copilot seats — but rethink product development end to end. Discovery, delivery, observability, operations. AI woven into the lifecycle. These teams learned, measured, and got faster at building the right stuff rightly. They have the numbers to prove it.
Other companies sprinkled AI on top of what was already there. Same org chart, same handoffs, same processes — [the Ferrari Trap](/post/the-ferrari-trap) in action. A chatbot here, a coding assistant there. When leadership asks "what did we get for the AI spend?" — everyone speaks of local improvements without a clear compound effect.
Now imagine the price doubles.
The company that restructured goes to the CFO. Talk about the budget and the opportunities. Budget approved. They keep on learning and accelerating.
The company that sprinkled goes to the CFO: "We need more AI budget." The CFO asks: "What did the last one produce?" Here, AI became a cost center to be minimized. Not a value generator.
**Cheap tokens masked the difference between real transformation and AI theater. Expensive tokens will expose it.**
The gap between the best and rest will only grow. [AI-native startups are already moving at 100X](/post/ai-native-startups-100x) — your organization will be benchmarked against that baseline.
The subsidy window was your chance to [redesign, then AI](/post/redesign-for-ai-why-transformation-requires-organization-design). It is still there. So seize it. Spawn experiments. Allow the product engineering teams to do what they believe is right. Break some old rules here and there. Learn. Ship. Adapt.
There has never been and won't be a better time to try new things.
---
# AI-Native Startups Are Moving at 100X
**Date:** 2026-04-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-native-startups-100x
**TL;DR:** AI-native startups move at 100X with no legacy structure. Your organization will be benchmarked against that baseline. The org design choices of the last two decades — handoffs, queues, narrow mandates — now determine how much of that potential actually lands.
AI-native startups are moving at 100X. One CEO, five Mac Minis, a full product. They don't need org design consulting. They started clean, no legacy, no inherited structure. Good for them.
From now on, your organization will be benchmarked against what's now possible. And the question your leadership will face, if they haven't already, is: why can't we move like that? And why do we see only costs increasing (tokens and subscriptions) with no visible gains?
Your organization did not start from scratch when AI arrived. It was already on a path — a management system, team structures, habits built up over the years. AI found all of that already in place. And it is very likely your org is on the same trajectory as before, now with AI spread like fairy dust, increasing costs but not necessarily gains.
Your "Search" stream-aligned team is shipping features in its lane at a record pace. Your "Payment" component team produces more integrations than ever — but still depends on the same queues and hand-offs. Your DB designer outputs 100X more DB designs — [then sits idle for most of the year](/post/ai-replaces-tasks-not-people). Everyone now works according to an "AI SDLC". But has anything really changed? Is there real demand for this much of the same stuff? Are the old dependencies still in place?
**What if [agile was the homework, and AI adoption is the real assignment](/post/agile-was-homework-ai-is-assignment) now?**
The org design choices made (or not made) over the last two decades now determine how much of that 100X potential actually lands as system-wide improvement. 100X? 1X? 10X?
For agile practitioners, this is familiar ground but with new urgency. Broad co-ownership, cross-component work, [multi-learning](/post/multi-learning-200-years-wrong-model). AI is not just pushing harder in those directions, but it can also be used to challenge the historical beliefs about why that was never possible. When applied strategically, it can make the learning itself more feasible, and it can help change the historical organizational trajectory. Finally.
---
# Pair Programming in the AI Era
**Date:** 2026-04-16 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/pair-programming-in-the-ai-era
**TL;DR:** Pair programming is not dead in the AI era. The navigator's job was never reading code line-by-line — it was holding the broader frame: what test is missing, what feature next, do we need this at all. Treat AI-generated code like compiled binary and pair on high-level BDD tests instead.
Pair programming and AI-augmented engineering.
I hear people saying that the practice of pair programming is now dead because no human can read the code at the generation speed.
I agree. With the fact that one can’t read and understand code so fast.
But let me offer you a reframing.
First. The practice of pair programming assumes two distinct roles: navigator and driver. While the driver holds the keyboard and types, the navigator is welcome to read. But mainly the value from the addition pair of eyes and the navigator’s intelligence comes from holding a broader frame.
What is a missing test?
Which feature do we build next?
Do we need this at all?
These are navigator’s challenges.
In the AI age? Can still be (and I claim must be) performed by the human. As I explored in [*Agile in the Age of AI*](/post/agile-in-the-age-of-ai), developers are becoming mini-Product Owners — deciding what code needs to be written, not writing it.
And now for the more important reframing. Imagine the old-times pair programming with two humans. One clicks to compile. A binary is produced. The tests are run. Feedback is generated.
Will the programmers bother to read the binary code?..
Likely not. So why don’t we look at the code that is AI-generated at the speed of light as the binary code and instead focus on high-level tests (like BDD level) that still can be discussed and paired on. This shift from [routine to adaptive expertise](/post/routine-vs-adaptive-expertise) — from executing known procedures to navigating novelty — is exactly where human pairs add value that AI alone cannot.
---
# I Hired a Scrum Master AI
**Date:** 2026-03-21 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/hired-a-scrum-master-ai
**TL;DR:** An AI agent now coaches my team by reading session memories and surfacing recurring dysfunctions — approval gate violations, destructive ops without confirmation, plan-mode confusion. It catches patterns across sessions that humans forget. The role works because it observes relentlessly and never tires of pointing out drift.
While [Scrum Masters are getting fired](/post/why-scrum-masters-are-getting-fired) across the industry, I have just hired a Scrum Master!
In the interview, I asked:
What other issues have you observed in my recent sessions?
Then she replied without hesitation:
Here are the recurring issues I can see from the memories + today's session:
Issues observed
And she continued with a great level of detail:
1. Approval gate violation (repeated offense) — Memory says "NEVER jump to implementation without approval." Has its own memory file.
Still happened 3+ times today. The memory/CLAUDE.md approach isn't working — needs a structural fix, not another reminder.
2. Destructive data operations without confirmation — Cache version bump wiped 3.6MB of WA history. No warning, no backup, no confirmation
asked. This pattern (making irreversible changes silently) is the most dangerous.
3. Plan mode confusion — Plan mode's auto-"approved" message gets treated as user approval. This has happened before (it's explicitly in
the memory file) and happened again today.
4. Spec/plan location drift — Specs kept ending up in plan files instead of /specs. User had to say "MAKE A SPEC" and "follow OUR
WORKFLOW." The memory file for this exists too.
5. Testing against live resources — Previous incident with git e2e tests against working repo. Today: cache flush overwrote real data
file. Pattern: not isolating test/dev operations from production data.
6. Over-eagerness / not listening — When user says "stop", I often do one more thing before stopping. When user asks a question, I
sometimes start implementing instead of just answering.
-----
That's awesome, I said. You are hired! This is [AI as a teacher, not just a doer](/post/ai-augmented-multi-team-pbrs) — observing patterns humans miss and surfacing them relentlessly.
Welcome to the team of:
- product manager (me, for now)
- expert UX researcher + user interviewer
- elite BDD (Behavior-Driven Development) specialist
- and a good coder (Opus 4.6) — a setup that maps directly to how [agile teams work in the AI era](/post/agile-in-the-age-of-ai)
---
# The Gigantic Shift
**Date:** 2026-03-19 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/the-gigantic-shift
**TL;DR:** Companies are using AI as an excuse to cut headcount while single-person unicorns loom. Old recipes are expiring. Organizations cannot learn fast enough for you — install a coding agent, build something, play. 2026 is your window. Waiting for permission is the surest way to become irrelevant.
We are witnessing a gigantic shift in what is technically possible.
We are also witnessing companies using that as an excuse to cut its overstaffed organization loose.
These two things are appreciated by the stakeholders.
This affects many of us. All of us.
This is a very personal technological change.
I am committing myself to understanding how we can keep people relevant in these changing and challenging and exciting and scary times.
I see posts of Jeff Sutherland spawning an agentic Scrum team. And how this is the new new new game.
I hear Jensen Huang promoting agentic operating system. And first single-person unicorns are around the corner.
I read product managers of advanced organizations like Anthropic claiming that when their engineers turn to becoming real product developers, what remains is packaging and pricing. This is the shift from [routine to adaptive expertise](/post/routine-vs-adaptive-expertise) — and organizations that don't allow it will [displace people by design](/post/ai-replaces-tasks-not-people).
I hear many signals. This is the time to listen and absorb, do and try.
This is the time when old proven recipes might stop making sense. When new practices and skills emerge with an unprecedented speed.
I am committed to learn and try things first-hand. I encourage everyone to do the same.
Learning is a personal journey.
Most organizations won’t cope up with this speed of learning. And if you sit there and wait to be given permissions to try new things you will lose your precious time.
Don’t wait. Don’t stay in the past.
Go install your coding agent. Build a simple app. No matter what. Find a pet project to play with. As [Shopify's CEO put it](/post/shopify-ceo-reflexive-ai-usage), reflexive AI usage is now a baseline expectation.
2026 is your playing time. Our time.
---
# Redesign, Then AI: Why AI Transformation Requires a Multi-Learning Organization
**Date:** 2026-03-12 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/redesign-for-ai-why-transformation-requires-organization-design
**TL;DR:** AI tools without org redesign just amplify existing silos. AI collapses the cost of learning, which erodes the advantage of narrow specialization. The real unlock is broader skill mandates and cross-boundary work — multi-learning organizations. Redesign first, deploy AI second.
## The missing piece is organizational design
Organizations around the world are investing heavily in generative AI. Leaders are deploying copilots, automation tools, and AI agents across functions in the hope of dramatically improving productivity and innovation. Yet many executives are discovering that introducing AI tools does not automatically lead to meaningful transformation. Individual employees may become more efficient, but the organization itself often changes very little — the [DORA 2026 data](/post/dora-2026-developers-faster-teams-messier) confirms this exact pattern at scale.
The missing piece is organizational design.
Most organizations today are still structured around narrow roles and specialization. Teams are defined by functional expertise, ownership of components, or tightly bounded responsibilities. These structures were effective in an era when learning across domains was slow and costly. If acquiring new expertise required years of training, it made sense to organize work around specialized skills.
## AI lowers the cost of learning
Generative AI changes this assumption. With AI tutors, copilots, and agents, individuals can acquire new capabilities much faster than before. Developers can explore unfamiliar technologies, product managers can analyze complex data sets, and designers can prototype solutions beyond their traditional domains. In other words, AI dramatically lowers the cost of learning.
When learning becomes faster and cheaper, the advantage of narrow specialization begins to erode. What increasingly matters is the ability of people and teams to expand beyond their primary craft and recombine skills as work evolves. This capability can be described as **multi-learning**.
However, most organizations are not designed to support it. Rigid role definitions, siloed ownership of systems, and tightly bounded team responsibilities often discourage people from expanding their capabilities or contributing beyond their immediate domain. In such environments, AI simply amplifies productivity inside existing silos rather than transforming how the organization solves complex problems. This is [the Ferrari Trap](/post/the-ferrari-trap) — faster cars on a jammed highway.
## Redesign first, then deploy
To unlock the full potential of AI, leaders must therefore rethink how their organizations are structured. Instead of designing organizations primarily around specialization, they need to enable broader skill mandates, cross-boundary collaboration, and continuous learning across teams.
This shift also changes how AI itself should be applied. Rather than using AI primarily for task automation, organizations should integrate it into learning and capability development. In this sense, AI becomes a strategic amplifier of human adaptability.
> The most successful AI transformations may therefore begin not with technology deployment but with organizational redesign.
By creating environments where people and teams can continuously expand their skills and collaborate across domains — what requires [both wings of a 10X organization](/post/two-wings-of-a-10x-bird) — leaders can build organizations that are capable not only of adopting AI but of evolving with it.
## Further reading
These ideas are explored in more detail in the book [10X Org](https://www.10xorg.com/), which examines how organizations can elevate performance in the age of AI through intentional organizational design.
The book introduces the concept of multi-learning organizations and presents the Org Topologies approach for diagnosing and redesigning structures that limit adaptability and collaboration.
Since its release, *10X Org* has become a #1 Amazon bestseller in several strategic management and business categories. Leaders interested in understanding how organizational design can unlock the full potential of AI can explore these ideas further in the book.
---
# The Ferrari Trap
**Date:** 2026-02-20 · **Reading time:** 9 min · **Category:** AI X OD
**URL:** https://krivitsky.com/post/the-ferrari-trap
**TL;DR:** AI is an accelerator — but it accelerates whatever is. Developers expected 24% speedup from AI — actual result: 19% slower. The Ferrari Trap: faster cars on a jammed highway. Fix the road first.
[METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — a respected AI evaluation organization — ran a randomized controlled trial with sixteen experienced open-source developers across 246 real issues. Developers expected a 24% speedup from AI assistance. Actual result: 19% slower. And even after experiencing the slowdown, they still believed AI sped them up by 20%.
That perception gap is the Ferrari Trap in one sentence. The feeling of speed without the reality of progress.
Everyone's engine is revving louder. The cars are still stuck.
In [*10X ORG*](https://www.10xorg.com/), we call this the Ferrari Effect. But I've started calling it the Ferrari Trap, because "effect" sounds like something that happens to you. A trap is something you walk into — and most organizations are walking into it with their eyes open and their wallets out.
## The Metaphor
Aiden, the AI advisor in [*10X ORG*](https://www.10xorg.com/), explains it to Hanna, the Head of HR, after she asks why the roadmap is still slipping even though every developer is moving faster:
*"Think about car traffic. The goal is for cars to move fast and get where they're going. But what we often get are traffic jams. Now imagine swapping every car for a Ferrari. Although each one could now go much faster, that alone doesn't fix congestion."*
Hanna tries to absorb this. "So... if we've got AI super-specialists revving their engines... this is not helping?"
*"We're just flooding a blocked highway with faster cars. And more cars mean more traffic, more traffic means less flow."*
After a pause: *"Perhaps we should fix the road first — and only then let the AI-powered Ferraris fly."*
The metaphor lands because everyone has felt it. Your database designer finishes the month's workload in three days. Then waits. Your frontend team triples their output. Then waits — for the backend team, for the architect review, for the product manager who owns the intake queue. Individually, they're Ferrari-fast. Organizationally, the roads haven't changed since 2003.
## The Data
[Faros AI's research](https://www.faros.ai/ai-productivity-paradox) found the same pattern in delivery metrics: developers completed 21% more tasks and merged 98% more pull requests. But PR review time increased by 91%, and AI-generated code produced 1.7 times more issues than human-written code. Net organizational throughput: flat.
Meanwhile, an [NBER study](https://www.nber.org/papers/w34836) of six thousand CEOs and CFOs across the US, UK, Germany, and Australia found that 90% said AI has had no impact on productivity or employment — even though 70% actively use it. The modern Solow paradox. Executives average 1.5 hours per week of AI use. The cars are faster. The highway is still blocked.
## The Ferrari Trap in Siloed Specialists
The Ferrari Trap isn't a failure of intelligence. It's a failure of paradigm.
In [the book](https://www.10xorg.com/), Eric — the Director of Engineering — takes Paula, the newly hired Head of Product, on a tour of the development floor. Paula owns the roadmap. She sees execution performance across all teams — not one team's velocity, but whether the whole system delivers on its commitments. Devi, a frontend developer, is tripling her output with GenAI. Eric can barely contain himself: "What used to take days now takes hours. Sometimes minutes." Paula watches, then says quietly: "Everyone seems faster individually. But the whole? It's not getting any better."
Paula had spotted the jam. Eric was still admiring the Ferraris.
Eric isn't wrong about the individual gains. He's wrong about what they add up to. And that's the trap: the local evidence is overwhelmingly positive. Dashboards light up. Sprint velocity doubles. Every team demo is impressive. The data says faster. The roadmap says stuck.
The problem is structural. When specialists in silos all accelerate, they produce more work-in-progress that jams organizational queues. Dependencies between teams create bottlenecks that local speed can't resolve. Handoffs, waiting, and coordination overhead dominate total cycle time. You're not speeding up the constraint. You're speeding up everything except the constraint — which is the organizational structure itself.
Amdahl's Law, from computing, formalizes this: the speedup of a system is limited by the fraction of the system that can't be improved. If 80% of your end-to-end delivery time is spent in queues, handoffs, and coordination, then making the remaining 20% infinitely fast still only gives you a 25% improvement. AI tools can't fix the 80%. Only redesign can.
## The Ferrari Trap in Fast-Flow Teams
But what if your organization already did the transformation? What if you built autonomous, cross-functional teams — each owning their full value stream from idea to production?
You're still vulnerable.
Consider a typical post-transformation setup: a search team, a payments team, a recommendations team. Each cross-functional. Each empowered. Each fast inside its lane. They've got what [*10X ORG*](https://www.10xorg.com/) calls Wing One — [full ownership of the value cycle](/post/two-wings-of-a-10x-bird). No handoffs, no waiting, no review queues.
Now add AI. The search team accelerates search. The payments team accelerates payments. But demand for search stabilizes — the product doesn't need more search improvements. Meanwhile, a new AI-powered capability needs building urgently, and the people best suited for it are pinned to a payments lane that's already saturated.
These teams can't switch. They're autonomous inside their lanes but locked to them by design. When value shifts — and with AI, it shifts fast — they can't follow it. They hit what we call the demand ceiling: speed without scope.
This is the one-winged bird. [Wing One without Wing Two](/post/two-wings-of-a-10x-bird) — ownership without flexibility. AI hits the demand ceiling in each lane, and the organization has no mechanism to redirect capacity where it matters most. The Ferrari is fast on its road. But when the road ends, it can't change lanes.
## The Accelerator Problem
AI is an accelerator. But it accelerates whatever is. If you had a traffic jam before AI, you're going to have a faster one now — burning tokens, revving engines, but not moving value.
If your organization was building the wrong thing, it now builds the wrong thing faster. If your teams were producing untested code, they now produce more untested code. If your culture rewarded output over outcomes, AI turns that reward function into overdrive. If your org was into crap coding, it's now faster at crap coding.
This is what makes the Ferrari Trap especially dangerous: AI doesn't just amplify speed — it amplifies trajectory. Gary Hamel observed that we're running 21st-century technology on 19th-century management principles. AI walked into most organizations and found exactly that arrangement. It didn't disrupt the structure. It accelerated the structure. And an accelerated misfit is worse than a slow one, because it burns resources faster, creates more waste, and the gap between the organization's self-image ("We're an AI-powered company!") and its actual performance widens with every token purchased.
Sooner or later, leaders notice. "We rolled out copilots and GenAI licenses," they say, "but we saw no meaningful performance gain." What they do see is higher running costs — AI licenses, training budgets, consultants. These are symptoms of non-strategic AI adoption: naive, sporadic, ad hoc — spreading AI across existing silos and hoping it will do the trick.
## Fix the Road
Paula's line in [*10X ORG*](https://www.10xorg.com/) lands hard because it reverses the instinct: "First design, then AI."
Most organizations do the opposite. They buy the tool first, distribute it widely, measure individual adoption, and then wonder why the organizational needle didn't move. They're trying to solve a structural problem with a technology purchase.
The structural problem has a name in Org Topologies: narrow mandates. When a database designer is mandated to touch only databases, AI makes her finish the work in three days — then she sits idle for twenty-seven. Nobody needs a thousand times more databases. When a search team is mandated to own only search, AI makes them ship search improvements at record speed — then they hit what we call the demand ceiling. Speed without scope. The lane becomes the constraint, not the pace within it. The question isn't whether [AI replaces people](/post/ai-replaces-tasks-not-people) — it's whether your org structure turns displacement into elevation or just idle time.
The fix maps to two organizational capabilities — the Two Wings in [*10X ORG*](https://www.10xorg.com/). Wing One: give people and teams ownership of the full value cycle, from idea to production. Not "the backend part" or "the QA step" — the whole thing. Wing Two: enable switching between value areas. A team that can redirect its capacity when demand shifts, instead of sitting idle inside a lane that doesn't need more work.
Management has two dials to turn: grow multi-expertise (help people broaden their skills — AI makes this faster than ever) and unpin from streams (stop assigning people permanently to one value area).
These aren't binary switches. They're dials you turn gradually. But someone has to turn them. Leaving them at zero and distributing AI licenses is how you buy more Ferraris for the same jammed highway.
## Recognizing the Trap
You're in the Ferrari Trap if:
Your developers report feeling significantly faster while your roadmap timelines haven't meaningfully improved. Your AI spend is climbing but customer-facing outcomes are flat. Your teams are producing more pull requests, more code, more artifacts — and your cross-cutting initiatives still take quarters. Your sprint demos are impressive, and your annual planning conversation sounds the same as last year.
The uncomfortable question from [*10X ORG*](https://www.10xorg.com/) that I now ask in every workshop: "Where are you seeing local speed improvements that still don't show up in roadmap-level progress?"
Every hand goes up.
## Escaping
The sequence matters. Redesign, then AI. Not the other way around.
That doesn't mean stopping AI adoption. Try it everywhere — that's fine and necessary. Learn what it does to your system. Watch where the Ferrari Trap appears, where the demand ceiling hits, where faster workers produce longer queues. Use the evidence to diagnose where the structure, not the tooling, is the constraint.
AI is an accelerator. It will accelerate whatever is. So point it at the right thing. Use it to accelerate [improving your organizational design](/post/redesign-for-ai-why-transformation-requires-organization-design) — broadening mandates, compressing the [multi-learning](/post/routine-vs-adaptive-expertise) curve, dissolving the silos — instead of revving harder inside a jammed highway.
---
# Routine vs. Adaptive Expertise
**Date:** 2026-01-28 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/routine-vs-adaptive-expertise
**TL;DR:** Routine expertise executes known procedures well in stable conditions. Adaptive expertise handles novelty without freezing. Post-COVID research confirmed they are different capabilities — seniority alone offers no protection from disruption. Adaptive expertise must be deliberately built through broader mandates and continuous exposure to variation.
For decades, we have rewarded **deep specialization**.
A radiologist reads scans. A frontend developer writes UI code. A paralegal prepares contracts. These roles were seen as focused, professional, and trustworthy. We encouraged our kids to get an education that makes them experts—the go-to person for one well-defined kind of work.
The times are changing. As AI [takes over the repetitive work](/post/ai-replaces-tasks-not-people) that justified narrow specialization, success depends on more than executing well-learned domain and well-practiced tasks. Professionals are increasingly expected to learn as they go, apply knowledge in unfamiliar contexts, and respond when standard solutions no longer fit.
This is new in practice for most of us, but the theoretical distinction is not. In the 1980s, cognitive researchers Giyoo Hatano and Kayoko Inagaki introduced a useful concept to describe this phenomenon: **routine expertise**versus **adaptive expertise**.
_Routine_ expertise is the ability to perform known tasks efficiently and accurately by applying established procedures. Routine experts excel in stable conditions. They produce reliable, high-quality outcomes—as long as the situation remains familiar.
_Adaptive_ expertise goes further. Adaptive experts can extend, recombine, or reinvent their skills when conditions change. They handle novelty without freezing. They learn while acting.
The COVID-19 pandemic made this distinction painfully visible. Health professions educators around the world were forced to abandon standard training models almost overnight. One post-pandemic study showed that adaptive expertise did not correlate with age or years of experience. Instead, it emerged as a distinct capability that had to be deliberately developed. Those scoring higher in adaptive expertise also performed better during periods of disruption, while seniority alone offered little protection from disruption.
As it turns out, work experience does not automatically result in adaptive expertise.
Adaptive expertise is a different kind of mastery—one built through continuous learning, exposure to variation, and the embrace of new challenges. In other words: purposefully and with broader mandates. This is the foundation of [multi-learning](/post/multi-learning-200-years-wrong-model) — the organizing principle that makes teams genuinely versatile.
After the pandemic, the professionals who had demonstrated their surprising adaptive expertise were able to return to business as usual. But are there domains where such behavior is not a crisis response, but the daily norm? Organizations moving toward [AI-supported org design](/post/ai-supported-org-design) are making adaptive expertise the operating default, not the exception.
---
# Craig Larman on 10X and The Future of Jobs
**Date:** 2025-11-20 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/craig-larman-10x-future-of-jobs
**TL;DR:** Craig Larman's thesis: within years, AI will meaningfully replace entire job categories. A 10% improvement pitch won't save humans when AI is cheap, tireless, and good enough. The answer is 10X — dramatic business impact through adaptive organizations. The Org Topologies upper-right quadrant is our children's fighting chance.
> I am here to save jobs for our children.
Transcript of Craig Larman's keynote at LeSS Conference 2025. The ideas below became the foundation of [*Agile Was Homework, AI Is the Assignment*](/post/agile-was-homework-ai-is-assignment).
"This is my new professional mission for perhaps the next 10 or 20 years. And you can, those of you who have been at the previous conferences with me understand my motivation for this and our grandchildren. I have grandchildren. So my thesis is I've shared each year in these keynotes since 2020.
That within a few years, maybe by the, maybe by October, 2027, we'll see news of the first job category that's been meaningfully replaced by an AI. I think that could be possible within two years. I've got a sister and a daughter who work in the film industry and you should see what's happening there.
Things that currently take 1000 - 2000 people to do a production it's just, dramatically dropping and on. Of course, these are very early days, so I understand that it sounds like I am crying wolf or describing a situation that isn't going to happen. But I think this could be a boiling frog dynamic over the next 10 years.
And of course, these things are gonna be cheap as dirt. They work 24/7. They don't ask for vacation. They don't ask for time off. So the labor economics incentives to replace humans by AIs will be compelling, I suggest. And we humans won't compete. If the only thing that we can suggest is, please hire me, I'll make you 10% better.
It's just not gonna cut it. I suggest, because these AIs are going to be so economically desirable. Cheap as dirt, good enough, no vacations, that if humans want to be attractive in the future labor market, I suggest that 10% isn't gonna do it anymore. Now, if you've read the Book of "Secrets of Consulting" by Gerry Weinberg, what do you know?
One of Jerry's chapters is "never recommend more than a 10% improvement in business". And there's a whole bunch of interesting reasons for that. And I suggest that at this, what's going to be coming milestone or disruption in intelligence-as-a-service that we're going to have to suggest something more ambitious.
And I call this "10X Org". So the idea is, as in LeSS, one of the guides is more outcomes, less outputs, the focus is on some business impact or some meaningful impact, not just on creating outputs. And so when we say "10X Org", what I'm trying to suggest is 10 times the amount of business impact, 10 times the market share, 10 times the revenue.
Or whatever the business impact is. And I think that although before the age of AI, it would've been ludicrous to have these kinds of messages or suggestions, as a consultant. I think we're gonna be entering an age where aspirationally we need to make that pitch. And aspirationally, we humans will have to step up our game if we want to compete to actually achieve this goal.
And so I think we're at a point in the industry where actually we can be bold and suggest a much deeper improvement than would've seen ludicrous before.
And so with Roland and Alexey. Roland and Alexey! Over the last year, I've been starting to explore how to do this and the three of us are working on a book together, which we're gonna be releasing in not too long. And the basic idea, if you think of this from an Org Topologies point of view, this is Org Topologies as a 2x2, and quite simply where the scope of skills mandate is high and the scope of work mandate is high, that's the quadrant that is adaptive.
And this has always of course been the message of LeSS. But what we're trying to do with Roland and Alexey with the "10X Org" message is expand this to a far broader audience to all the different markets that are gonna be affected by AI. And I suggest that in many of these, moving to this quadrant — through [multi-learning](/post/multi-learning-200-years-wrong-model) and [broader mandates](/post/teams-and-scope-of-skills-mandate) — is the fighting chance for our children to have good jobs.
The adaptive quadrant. And it's also, I would suggest the perfection vision of where LeSS gets to as well. Thank you."
---
# Copenhagen: Flat Danish Management
**Date:** 2025-09-30 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/copenhagen-flat-danish-management
**TL;DR:** A memoir of joining a Danish company in 2004 — flat culture where sales and developers sat in a circle each morning without ceremony. Introduced CI, unit testing, incremental refactoring. The pattern repeating across assignments: arrive, revamp, make impact, move on when the adventure turns into business as usual.
Today watching the clouds as I am flying in to København, I remembered my first flight to Denmark 🇩🇰… year 2004.
I was just hired to lead an to-be development office of a Danish digital assets management software company. Pre-cloud era.
As a life-time skier, guess what was the first thing I did when learning about my assignment in this country? Right, go and check the map. The country appeared to be completely flat …
… as its management culture. Next morning in a small city of Odense, full of overrated H.C.Anderson’s portraits, I saw the first all-company meeting in my life. There were not doing Scrum yet (it would take me another 7-8 months to seed that idea), but in a style of a super-flat org, they just sat and talked each morning about their business.
What really shocked me is that they didn’t greet each other with their favorite “hej” before they got mugs with coffee and sat in that circle. In comparison to my previous assignment in Alcatel, en Bretagne, where you would literally need to go through the multi-level office building and kiss each other cheek to cheek before you open up your laptop. And then it is already time for lunch. And if Friday with wine.
Ok, so the Danish did say “hej” eventually to sit and talk about the business: sales people, developers, founders, and me…
And me? On my second day in the office, I was granted code access and dag into it. I wanted to quit right away…
But instead, ended up spending next a couple of years with great folks like Mykola Gurov on refactoring it.
That taught me a powerful lesson: you cannot (and should not) refactor everything. So we did it bit after bit. Smartly and safely. The kind of [adaptive expertise](/post/routine-vs-adaptive-expertise) that comes from doing, not from reading about it.
Trying to remember those times, 20 something years ago, I almost remember writing the first unit test and configuring the first build server with CI on it… I did that many times in other companies too during my employment career. Is there a pattern?
I quit ~3 years later (embarking on my Zurich journey) when my org revamping impact was declining and the wonderful adventure was slowly turning into a steady business as usual.
I ain’t no do usual. I do impact and move on. That’s probably a pattern too — a kind of [agile transformation that won’t be televised](/post/agile-transformation-televised), because it happens through doing, not through slide decks.
Happy to bring back to this country what I have been learning since then — the pain and pride, the ups and dows and the privilege
that goes with helping the orgs to improve.
Cheers to all my old friends from that era.
(The old Kastrup airport hasn’t changed a bit since then. That is an unfortunate find.)
---
# Why Scrum Masters Are Getting Fired
**Date:** 2025-09-27 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/why-scrum-masters-are-getting-fired
**TL;DR:** Scrum Masters get fired because org design locked them into team-level influence where they couldn't show real value. A vicious cycle: narrow mandate prevents impact, lack of impact prevents trust, lack of trust prevents broader mandate. Never stay where you are not allowed to perform. Your relevance is in your hands.
Another large company in my circle just fired a bunch of scrum masters and agile coaches.
That has been coming for almost a year with very strong signals, but now, that this happened, it came down as a “big surprise”.
This had nothing to do with the financial picture of the enterprise. (That was pure a managerial decision, weighted, strategic, and all that.)
So if you think your company is doing all right, and because of that you will be safe – you can be mistaken.
Most of the fired folks are skillful people, loving what they do and trying to get better at it. Others have given up over time but not because they wanted to.
In my analysis, there has been a very painful vicious cycle in motion (and I know it from other similar cases, so it is a generalization):
- the existing org design was made in a way that it limited the scope of influence of these people — what Org Topologies calls a narrow [scope of skills mandate](/post/teams-and-scope-of-skills-mandate)
- so the only thing they were mandated to do is making local improvements (eg at team level)
- but exactly because of that, they could not show real benefit over time or gain trust based on value delivered
- organizational performance improvements stagnated
- and because of the lack of trust and acceptance as significant party, these coaches could not influence the org design and get a broader mandate
Can you see how this reinforcing loop is making things only worse over time? Imagine it running for like 2 or 5 years.
My personal take from this: never allow yourself staying in a place where you are not allowed to show your true potential and make real impact.
Your relevance as valuable workforce is in your hands. And only in yours. No HR partner will save you when you have not been allowed to perform and just decided to hang in the comfortable limbo for years. The same pattern applies to developers — when [AI replaces the task and your mandate is narrow](/post/ai-replaces-tasks-not-people), you are exposed.
Get yourself going! (Or you will be gone.) The path forward is [multi-learning](/post/multi-learning-200-years-wrong-model) — broadening beyond a single craft so you have something to offer when the current task no longer needs a human.
(Sorry for this harsh truth. And all the best to the people who find themselves in a similar situation. There are companies that need your expertise and would be happy having you in.)
---
# Reactive to Creative Leadership
**Date:** 2025-09-02 · **Reading time:** 11 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/reactive-to-creative-leadership
**TL;DR:** Leadership style and organizational structure are inseparable. Reactive leaders — fear-driven, controlling — lock organizations into rigid designs. Creative leaders — purpose-driven, trusting — enable adaptive structures. You cannot shift your org topology without shifting your leadership first.
## TL;DR
In modern organizations, leadership style and organizational design are deeply interconnected.
When we talk about _Org Topologies_(Resource, Delivery, Adaptive), we usually think of structure. However, structure doesn’t shift without leadership shifting as well.
**The Leadership Circle gives us a useful lens here:**
* **Reactive** leadership is fear-driven. It leans on control, compliance, and protecting one’s image. It stabilizes, but it stifles learning.
* **Creative** leadership is purpose-driven. It emphasizes vision, trust, collaboration, and systemic improvement. It unlocks adaptability and innovation.
**Org Topologies show us the organizational side:**
* **Resource** Topology is siloed and efficiency-focused.
* **Delivery** Topology is cross-functional and output-focused.
* **Adaptive** Topology is versatile, outcome- and learning-focused.
**Now put them together:**
* Resource Topology runs on Reactive leadership– command, compliance, and tight control.
* Delivery Topology needs a blend– Creative “achieving” combined with just enough Reactive discipline to keep flow predictable.
* Adaptive Topology thrives only under Creative leadership– visionary, empowering, learning-oriented.
This article examines two frameworks – **The Leadership Circle**(which differentiates leadership styles, notably _Creative_ vs _Reactive_ orientations) and the **Org Topologies**model that describes different organizational design archetypes. We first summarize each framework’s core components, then map how various leadership styles align with each type of organizational topology.
Finally, we discuss how leadership development needs to evolve as an organization shifts from one topology to another.
## The Leadership Circle Framework: Creative vs. Reactive Leadership
The Leadership Circle framework (often delivered via a 360° Profile assessment) divides leadership behaviors into two primary categories: **Creative Competencies**and **Reactive Tendencies**.
The Leadership Circle is a model that maps leadership behaviors and mindsets into two overarching orientations – **Reactive**and **Creative**– each of which represents a distinct way of leading organizations and people. Like Org Topologies, it offers a map of different archetypal patterns.
Each half contains specific dimensions that capture a leader’s internal assumptions and outward behaviors:
* **Creative leadership**is characterized by effective, growth-oriented behaviors. Leaders high in Creative Competencies **“achieve results, bring out the best in others, lead with vision, act with integrity and courage, and improve organizational systems”**. For example, creative dimensions include _Relating_(building teams, developing others) and _Achieving_(setting vision and accomplishing strategic goals) . These competencies stem from inner confidence and a focus on purpose rather than fear. Notably, leaders who score high on the creative scale tend to be far more effective. High Creative leadership correlates strongly with better leadership performance and business outcomes.
* **Reactive leadership**is associated with self-limiting or fear-driven behaviors that can constrain effectiveness. The Reactive Tendencies reflect inner beliefs that **limit a leader’s authentic expression and impact**. Examples include _Controlling_(a tendency to micromanage, push for perfection, and derive self-worth from being in charge or “on top”) and _Complying_(a tendency to seek others’ approval and follow others’ expectations to feel secure). Such leaders often emphasize caution, control, or defending their image over innovation and engagement. In the Leadership Circle Profile, high reactive scores are **inversely correlated**with leadership effectiveness (often coinciding with low creative scores). In short, a predominantly reactive “command and control” style may undermine a leader’s impact, whereas a creative, empowering style enhances it.
**In summary:**
* _Reactive leadership_ optimizes for safety and control.
* _Creative leadership_ optimizes for trust, learning, and purpose.
## The Org Topologies Framework: Organizational Design Archetypes
Org Topologies is a framework for strategic organizational design that maps out archetypal ways to structure an organization. It introduces a **visual mapping technique**using two key dimensions of org design and defines multiple archetypal unit types.
Sixteen base archetypes (team or department patterns) are categorized into four groups, and, importantly, these are distilled into **three distinctive organizational “topologies”**– common overarching patterns of how work and authority are organized . Each topology represents a fundamentally different organizational ecosystem with particular characteristics and fit-for-purpose use cases . The three topologies are summarized below:
* **Resource Topology:**A siloed, efficiency-oriented design with frozen functional roles and high specialization. Here, work is divided among specialized units (e.g., separate functional departments), and _resources_ are managed to be 100% utilized. Leadership in this topology relies on **top-down coordination**– managers (or project management offices) plan work, allocate tasks, and monitor utilization across narrow skill silos. Because each group only performs a fragment of the process, extensive handoffs are needed for end-to-end delivery. Learning and innovation are limited; improvement tends to occur only within one’s specialization rather than through new discovery . _Use case:_ Resource Topology fits stable environments where maximizing resource efficiency and specialization is the primary goal (e.g., a project-based organization hiring specialists for defined tasks).
* **Delivery Topology:**A fast-flow, output-focused design that **upgrades to cross-functional teams**delivering value with fewer dependencies. Compared to Resource Topology, work in Delivery Topology is organized into independent _delivery units_(e.g., feature teams) that can produce “completely done” increments with minimal handoffs. This is often likened to a _“feature factory”_– teams churning out a steady stream of features for a product. There is a strong focus on **outputs and local efficiency**(throughput of features), and teams are kept **narrow in scope**so they can deliver quickly and predictably. High-level analysis or product decisions are still handled by “directing” roles or upstream units (product managers, analysts), meaning _discovery_ of _what_ to build remains somewhat separate from _delivery_. This topology excels when the challenge is not figuring out what to build (the requirements are known and of proven value) but rather delivering it rapidly at scale. _Use case:_ Delivery Topology is well-suited for environments where **predictable, speedy delivery**of features is critical and the market/problem is well-understood (for example, a software company rolling out frequent minor enhancements or a restaurant kitchen executing a set menu) .
* **Adaptive Topology:**A highly **adaptive and innovative**design that merges directing, doing, and delivering into unified, empowered teams. In Adaptive Topology, traditional functional boundaries are dissolved; instead of silos, the organization might form a _“team-of-teams”_ or network of multi-skilled teams that **work in unison across the entire value stream**. The goal of this topology is to maximize _adaptiveness_– enabling easy, continuous change based on learning, and true customer-centric innovation . Teams (and individuals) in an adaptive org are expected to collectively **discover**what customers need and **deliver**solutions rapidly, adjusting course as necessary. This requires a culture of continuous learning, high autonomy, and synchronous collaboration (often supported by real-time data and AI tools to inform decisions). The design makes it “cheap and easy” to pivot strategy because teams are broadly skilled and tightly aligned with the overall purpose, not confined to narrow tasks. _Use case:_ Adaptive Topology is fit for dynamic, uncertain environments where **innovation and agility**are paramount – for example, product R&D groups, startups, or market disruptors that must rapidly experiment, learn, and respond to change. It promotes long-term business resilience by enabling higher-impact outcomes and continuous adaptation.
**In summary**, each topology serves a different strategic goal and entails a distinct organizational structure: Resource topology optimizes for **resource utilization and specialization**, Delivery topology for **fast flow of outputs**, and Adaptive topology for **rapid learning and innovation (outcomes)**. These differences in structure and goal create different demands on leadership style, as we explore next.
## Mapping Leadership Styles to Organizational Topologies
The effectiveness of a leadership style is often context-dependent. A leadership approach that succeeds in a tightly controlled, efficiency-driven organization may falter in a fast-changing, innovative company, and vice versa. The Leadership Circle’s distinction between Reactive and Creative orientations provides a useful lens to map leadership styles onto the needs of each Org Topology.
Broadly, as an organization’s design shifts from **Resource**→ **Delivery**→ **Adaptive**, the leadership culture must shift from predominantly **Reactive**(command-and-control, cautious, task-focused) to increasingly **Creative**(visionary, empowering, collaborative) to support the organization’s purpose.
The table below summarizes this alignment:
**Organizational Topology****Best-Suited Leadership Style (Leadership Circle)****Organizational Needs & Rationale**
**Resource Topology**_Goal: maximize efficiency & specialization_**Predominantly Reactive**– directive, controlling style focused on stability and compliance.This topology’s siloed, plan-driven structure requires leaders who tightly coordinate and **enforce standard processes**. Reactive leadership tendencies (e.g., emphasizing control and risk-aversion) align with the need for predictability and utilization in a Resource topology, ensuring everyone follows the plan and stays “100% busy.” However, this can limit flexibility and innovation.
**Delivery Topology**_Goal: fast, predictable delivery of outputs_**Balanced/Transitional**– leaning Creative (achievement-oriented) but with some Reactive discipline.Delivery topology introduces **cross-functional teams and faster flow**, so leaders must **empower teams**to own delivery while still maintaining focus on output targets . A _Creative_ leadership approach that drives results and continuous improvement (high on the **“Achieving”**competency) suits this environment. Leaders foster collaboration and adaptiveness within teams, yet may retain **Reactive**elements like process control to ensure reliability and alignment with product requirements.
**Adaptive Topology**_Goal: continuous adaptation & innovation_**Predominantly Creative**– visionary, empowering, and facilitative style.An adaptive organization needs **leaders who inspire purpose, trust, and innovation**. Creative leaders excel here by providing vision and strategy while **empowering teams**to experiment, learn, and self-organize towards outcomes. In this high-change ecosystem, **reactive, control-oriented management would be counterproductive**– as research notes, truly adaptive/agile cultures _“require Creative Leadership”_, and reactive leadership cannot easily usher in the needed innovation and engagement. Leaders must cultivate a culture of trust, agility, and learning, embodying competencies like _Relating_, _Self-awareness_, and _Systems Thinking_ to enable the organization to thrive in uncertainty. At its core, [agile frameworks don't make you agile](/post/agile-frameworks-not-what-makes-you-agile) — treating people like adults does.
As the table illustrates, **leadership style and organizational topology need to be in sync**. A mismatch can create friction – for example, a purely reactive, micro-managing leader will likely stifle an Adaptive topology that demands empowerment and quick learning, while a purely visionary, hands-off leader may struggle in a Resource-focused bureaucracy that expects tight control. In practice, organizations often evolve through these topologies, and leadership mindsets must evolve in tandem.
## Evolving Leadership Development as Topologies Shift
Shifting an organization’s topology (e.g., moving from a Resource model to a more Adaptive model) is not just a structural change – it is a cultural and leadership transformation. Leaders must **develop new skills and mindsets**to support the new way of working. Below are some insights on how leadership development needs to evolve when an organization transitions from one topology to another:
* **From Resource to Delivery Topology:**Leaders need to **shift from micro-management to empowerment**as the organization moves toward cross-functional teams and faster delivery cycles. In a Resource topology, leaders were accustomed to detailed upfront planning, strict role boundaries, and ensuring compliance with plans. To succeed in a Delivery topology, they must _unlearn_ the overreliance on rigid plans and resource control. This means developing more Creative behaviors: trusting teams to self-organize within their scope, encouraging collaboration across functions, and focusing on outputs/outcomes rather than hours worked. Leaders should practice delegating decision-making to teams and fostering a culture of continuous improvement. In short, they transition from being task masters to being **enablers**– providing clarity and removing obstacles, while allowing teams more autonomy. This can be challenging, as it requires overcoming reactive impulses (e.g., the need to control every detail), but it is crucial for faster flow. By _“supporting testing of new approaches and learning from quick adjustments, instead of sticking strictly to preset plans,”_ leaders create an environment of trust and motivation in the Delivery context.
* **From Delivery to Adaptive Topology:**This shift demands an even deeper leadership transformation – from a results-oriented agile mindset to a truly **innovative and learning-focused**mindset. In moving to an Adaptive topology, leaders must fully embrace Creative leadership. They need to cultivate qualities like **visionary thinking, humility, curiosity, and systemic awareness**. Practically, this involves encouraging experimentation and accepting the risks of failure as opportunities to learn. Leaders must focus on _outcomes_ and customer impact over output, which means guiding teams with a compelling vision and then giving them freedom to discover solutions. Developing a **culture of empowerment and trust is paramount**: agile/adaptive leaders _“cultivate a culture of trust and empowerment, encouraging team members to take initiative and innovate,”_ which fosters an environment where experimentation thrives. Many traditional management habits (e.g., top-down decision making, extensive upfront analysis) must be shed in favor of facilitative leadership, coaching, and adaptation. According to Anderson and Adams (creators of the Leadership Circle), the _“innovative, agile, adaptive”_ organizational cultures of the future **require Creative leadership**– reactive, compliance-driven leadership **cannot**generate the level of engagement and innovation these organizations need. Thus, leadership development efforts should focus on building creative competencies (such as relationship building, strategic foresight, and self-awareness) and transforming leaders’ mindsets from controlling to **inspiring**. This often involves personal development work, coaching, and hands-on experience in agile ways of working. As leaders grow into this new mindset, they enable their organizations to fully realize the benefits of an Adaptive topology.
## Conclusion
Aligning leadership style with organizational topology isn’t optional — it’s decisive for performance.
Shifting from **Resource → Delivery → Adaptive**is never just about moving boxes on a chart. It also demands a parallel shift in leadership: **Reactive → Creative**. The two evolutions are inseparable.
Organizations that chase adaptability without Creative leadership will stall — this is exactly the [vicious cycle that gets Scrum Masters fired](/post/why-scrum-masters-are-getting-fired). Leaders who try to operate creatively inside a rigid Resource structure will suffocate. Both maps — the Leadership Circle and Org Topologies — point to the same truth: **you can’t elevate the system without elevating how you lead.**
The takeaway is clear: as companies push toward greater agility and innovation, they must invest in Creative, growth-oriented leadership at every level. Leaders who learn to act from **purpose and vision, not fear and control**, create the conditions for truly Adaptive organizations — ones capable of sustaining high performance in a world of constant change.
## Sources
* [The Leadership Circle –](https://leadershipcircle.com/leadership-assessment-tools/leadership-circle-profile/)[_Overview of Creative Competencies vs. Reactive Tendencies_](https://leadershipcircle.com/leadership-assessment-tools/leadership-circle-profile/)
* [Kestria Insights –](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)[_“Adaptable leaders: Embracing agility and lifelong learning”_](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)[(on empowering leadership in agile transformations)](https://kestria.com/insights/adaptable-leaders-embracing-agility-and-lifelong-l/)
---
# Remote Work: Synthesizing the Studies
**Date:** 2025-08-08 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/remote-work-synthesizing-the-studies
**TL;DR:** A synthesis of remote work studies reveals consistent themes: loss of spontaneous interaction weakens cohesion, informal learning collapses, onboarding suffers, and trust requires active effort. The hallway conversations we dismissed as waste actually drove both team bonding and cross-pollination of skills.
Working on synthesising multiple studies related to remote work and co-locations. More coming about that in the future — see also my earlier piece [*Agile Teams Working From Home, WTF?*](/post/agile-teams-working-from-home-wtf) for practical principles on building virtual offices. I did a ChatGPT 5 research on it so far and asked for the impact on teamwork and learning. The result:
Synthesis of Key Patterns Across Studies
Consistent Themes in Teamwork and Learning
Several clear patterns emerge regarding teamwork under remote work. Almost every study noted the loss of spontaneous, informal interactions, which in normal offices serve to build camaraderie, share quick updates, and solve problems on the fly. This led to weaker team cohesion and social connection in many cases, as people felt more isolated or siloed from their colleagues. Communication had to become more deliberate and structured, usually via digital tools and scheduled meetings, which kept work moving but often at the expense of creativity, agility, and the richness of face-to-face dialogue. A related theme is diminished trust and team spirit – without regular in-person contact, teams had to work harder to maintain a sense of trust and shared purpose.
On the learning front, many studies highlighted reduced informal learning opportunities. Mentoring, coaching, and on-the-spot feedback were harder to come by in remote settings, impacting newcomers and junior staff the most. Onboarding new employees became a notable challenge in several cases, as it’s tough to integrate someone into the team and culture purely over video calls. Likewise, knowledge sharing often suffered – without hallway conversations or overheard discussions, employees had fewer chances to pick up insights outside of formal meetings. Over and over, the research underscores that casual “water-cooler” exchanges play a big role in both team cohesion and learning; when those vanished, organizations saw hits to collaboration quality and the ease of skill transfer. This is especially damaging for [multi-learning](/post/multi-learning-org-design-pattern-ai) — the cross-boundary skill growth that organizations increasingly need to stay adaptive. Social isolation and a weaker sense of belonging were repeatedly mentioned, which not only hurts teamwork but also deprives people of the confidence and networking that fuel professional growth.
---
# Multi-Learning in the Age of AI
**Date:** 2025-05-16 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/multi-learning-org-design-pattern-ai
**TL;DR:** Three patterns for matching skills to work: Static Matching locks people in place, Dynamic Reteaming shuffles them reactively, Multi-Learning grows them continuously. AI changes the economics — it acts as teacher and mentor, making multi-learning viable where it was previously too expensive.
An essential part of organizational design is aligning demand (work) with skills (resources) effectively. What does the Age of AI change?
Let's study three patterns of skill-to-work matching first.
## STATIC MATCHING
Static Matching is the most popular approach within IT and R&D organizations. It establishes a fixed, pre-planned mapping of usually single-skilled parties to roles through clear team boundaries and responsibilities. Here, organizations set up teams with specific, narrowly defined roles. This approach is prevalent in Resource Topologies, where predictability and deep specialization drive efficiency.
Static Matching reduces uncertainty and minimizes cognitive overload by ensuring every team member knows exactly what is expected.
Static Matching tends to be inflexible. When market conditions or technology requirements change, these rigid structures can become bottlenecks, forcing the organization to suffer delays while teams struggle to adapt. This inflexibility is what produces [the Ferrari Trap](/post/the-ferrari-trap) — everyone is faster individually, but the system doesn't improve.
## DYNAMIC RETEAMING
The common answer to these drawbacks? Dynamic Reteaming is a reactive strategy wherein teams are reorganized on an as‑needed basis to address emerging gaps or mismatches between work and skills.
When a gap is detected—such as a critical skill deficiency or a new technology challenge—leaders may temporarily reassign or shuffle team members to patch the problem. The benefits are clear -- a short‑term quick fix that enables the organization to meet immediate demands, potentially speeding up problem resolution.
Dynamic reteaming comes at a significant cost. It disrupts team cohesion, creates knowledge discontinuity, and introduces coordination overhead.
Are there more strategic? Yes, thanks for asking!
## MULTI-LEARNING
Unlike Dynamic Reteaming, which can be seen as a quick fix, Multi-Learning (ML) is a continuous, cross-disciplinary learning culture where individuals and teams regularly expand their skills and knowledge across functional boundaries.
In this paradigm, teams are encouraged to go beyond narrow roles—integrating tasks like client onboarding, support, and cross‑departmental collaboration into their core responsibilities. This may involve stretching the team’s Definition of Done to incorporate outcomes that previously lay outside their remit.
Advantages? ML fosters true adaptability. By building broader skill sets, teams become more resilient and capable of addressing unforeseen challenges without the need for constant reconfiguration.
Limitations? Also known as ML requires a significant investment in training, cultural change, and often a rethinking of performance metrics. Without sufficient support, the burden of multi‑learning can lead to overload.
## AGE OF AI
But in the Age of AI, these limitations are quickly softening as AI can be used as a teacher, mentor, and advisor — making [routine expertise give way to adaptive expertise](/post/routine-vs-adaptive-expertise). A multi-learning, versatile team can open a code repository they have never yet worked in and ask their AI coding assistance to describe the architecture, explain conventions, run tests, generate missing ones, and then eventually, bit by bit, build new functionality. For a deeper look at how 200 years of narrow specialization led us here, see [*Multi-Learning: 200 Years of the Wrong Model*](/post/multi-learning-200-years-wrong-model).
---
# Learning Modes of Adaptive Topology
**Date:** 2025-05-02 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/learning-modes
**TL;DR:** Four deliberate learning patterns for adaptive teams: Scouting (sense early), Mirroring (build empathy), Weaving (integrate across teams), Synthesizing (codify insights). These are operating patterns, not transformation tools. AI makes each mode cheaper and faster — multi-learning becomes ambient rather than expensive.
> _How work units learn inside an Adaptive Topology._
### **What Are Learning Modes?**
**Learning Modes**are lightweight, deliberate patterns that help individuals and teams continuously learn across boundaries—**without reorganizing**.
They are to learning what interaction modes (from Team Topologies) are to coordination: **repeatable, intentional behaviors**that make learning systemic.
In an Adaptive Topology, learning is not a side activity—it’s the primary flow. **Learning Modes describe how that learning happens inside the structure.**
### **How They Differ from Elevating Katas**
* [**Elevating Katas**](/post/elevating-katas-structured-routines)are structured practices that help an organization **move from a Resource or Delivery Topology toward an Adaptive Topology**. They drive transformation—by shifting roles, rituals, responsibilities, or mindsets.
* **Learning Modes**describe **how work units operate once they’re inside an Adaptive Topology**, where **continuous learning is part of the work itself**.
Think of Elevating Katas as _change agents_, and Learning Modes as _operating patterns_ for evolved teams.
### **Why Learning Modes Matter**
Learning Modes offer a better alternative: **practices that support**[**multi-learning**](https://www.linkedin.com/posts/alexeykrivitsky_i-think-by-now-everyone-read-the-letter-from-activity-7316739319560388609-qzn2?utm_source=share&utm_medium=member_desktop&rcm=ACoAAACU2WIBRxv-fzfhRRzp_TnWRfGcaiV3tk0)**within long-lived teams**, enabling them to evolve from within.
### **The Four Learning Modes**
1. **Scouting**
2. **Mirroring**
3. **Weaving**
4. **Synthesizing**
Each mode enables learning across different dimensions: individuals, teams, roles, and systems.
#### **1.Scouting**
> _Explore the unknown. Sense early._
Small groups or individuals go outside their team to gather insight from other domains, users, or markets. Scouting brings early awareness of friction, trends, and ideas.
**Example:**
A backend developer joins customer support sessions to learn common complaints.
An AI agent might suggest, “Team X solved a similar problem—want a summary?”
#### **2.Mirroring**
> _Build empathy. Transfer tacit knowledge._
One person shadows another in a different role to understand their challenges, decision points, and context—not to replace them, but to see through their lens.
**Example:**
Developers sit with real users to observe how they work—learning what to improve or automate based on actual behavior and struggles.
#### **3.Weaving**
> _Learn across teams. Integrate perspectives._
Multiple teams work together—temporarily or regularly—on a shared challenge. This mode breaks silos and builds cross-team coherence.
**Example:**
Several teams collaborate to solve a major customer problem, combining technical, business, and support perspectives.
#### **4.Synthesizing**
> _Institutionalize the learning._
Insights from other modes are codified into shared tools, practices, or standards. This mode ensures learning sticks and scales.
**Example:**
After repeated Mirroring between QA and Dev, teams co-develop a shared onboarding template and update their Definition of Done.
### **What Learning Modes Enable**
* Cross-role learning without reteaming
* Capability growth inside stable teams
* Resilience without overload
* Continuous adaptability in a fast-moving context
### **What Learning Modes Are Not**
* **Not Elevating Katas**– which change the structure or culture to help reach an Adaptive state
* **Not interaction modes**– which focus on delivery coordination (like X-as-a-Service or Facilitation)
* **Not team reshuffling**– which breaks trust and momentum
### **How AI Accelerates Learning Modes**
Learning has always required time, trust, and exposure. But with AI agents now embedded in everyday tools, **learning can happen faster, just-in-time, and context-aware**.
Here’s how AI augments each learning mode:
#### **Scouting + AI**
* Agents can proactively surface relevant examples, documents, or team artifacts.
* AI copilots can “scout” across internal tools, Slack, Confluence, or code to find prior solutions.
**→ “This pattern was used in a similar case—want to see the code or talk to the team?”**
#### **Mirroring + AI**
* AI agents can track sessions, summarize insights, or suggest questions to deepen learning during a mirroring experience.
**→ “While observing the user workflow, notice how they hesitate on this step. Want to explore why?”**
#### **Weaving + AI**
* During cross-team problem-solving, AI tools can surface common dependencies, conflicting priorities, or shared risks.
* Agents can document shared learnings across teams automatically.
**→ “These 3 teams use different auth flows—would you like a synthesis report?”**
#### **Synthesizing + AI**
* AI can generate first drafts of shared artifacts—onboarding guides, updated playbooks, or code documentation—based on conversation logs and patterns.
**→ “Here’s a suggested update to the team’s Definition of Done based on what was discussed.”**
Without AI, learning across teams is expensive and slow. This is why [multi-learning has been misunderstood for 200 years](/post/multi-learning-200-years-wrong-model) — it was seen as prohibitively costly.
With AI, it becomes ambient and constant—**multi-learning becomes a background capability.** And as [strategic AI adoption](/post/elevate-org-with-strategic-ai-adoption) shows, the investment should target the specific archetype bottlenecks in your organization.
Learning Modes don’t change. But AI makes them **cheaper, faster, and easier to sustain and with manageable levels of cognitive load.**
### **In Summary**
> In an Adaptive Topology, learning is the work.
They help teams stretch, connect, and grow—**without needing to be rebuilt.**
Used consistently, they reduce the need for structural change and make adaptability scalable — the same adaptability that distinguishes [routine from adaptive expertise](/post/routine-vs-adaptive-expertise).
---
# AI-Augmented Multi-Team PBRs
**Date:** 2025-04-28 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-augmented-multi-team-pbrs
**TL;DR:** Multi-team PBRs are where teams learn together. AI applied during refinement — not before or after — lets teams interrogate knowledge directly, reducing dependency on expert preparation. The cognitive load criticism of LeSS dissolves when AI delivers information just-in-time in digestible chunks. AI is not just a doer; it is a teacher.
LeSS—an org design system for large-scale product development—describes Multi-Team Product Backlog Refinement as one of the key enablers of organization-wide adaptability.
Multi-team PBRs are where teams learn from customers, stakeholders, and each other. This is where all the involved teams dive into the problem space to come up with innovative and effective product experiments.
## Forward-Looking Orgs with AI-Augmentation
Today, AI augmentation offers a powerful and complementary capability: accelerating deep, multi-directional learning during PBRs without compromising the core LeSS design principle of simplicity.
We can think of many AI applications that can streamline the learning process, especially in product backlog refinement events.
Using my recent post on Never Read Alone, I explained how AI can enable teams to interrogate vast datasets, including user feedback, legal regulations, and competitor analysis, with just-in-time learning via AI-powered dialogs over any given corpus of knowledge. This amazing innovation must also be used during refinement.
And not before or after—a critical aspect.
A typical dysfunction of a PBR event is overpreparation by product managers and other expert roles who act as knowledge providers, turning the teams into students. Though it is essential for teams to learn, minimizing the associated process waste of knowledge transfer would be beneficial.
Namely, applying AI right in the PBRs to learn and structure knowledge, by the teams directly, can dramatically reduce the need for an expert or a special role to prepare for these meetings.
I predict that this will become increasingly common now, in the age of AI. For the broader organizational pattern, see [*Multi-Learning in the Age of AI*](/post/multi-learning-org-design-pattern-ai).
AIs (even before the hypothetical emergence of AGI) are already more knowledgeable than any average subject-matter expert and can easily cross-pollinate between domains. Teams that find ways to learn from AIs will no longer need to rely on and wait for part-time human experts. Thus, streamlining the learning process makes it way leaner than imaginable.
The main criticism of LeSS-inspired org design is the high cognitive load in teams, potentially caused by the constant need to learn and switch context — the same concern raised in discussions about [the scope of skills mandate](/post/teams-and-scope-of-skills-mandate). AI, when applied systemically and methodically, can reduce the burden of absorbing complexity by providing information in a clear structure, in smaller chunks, just in time, with runnable examples, etc.
These a few examples I'm bringing above are very different from how most people currently see and use AI.
Somehow, the whole narrative revolves around using AI agents as free labor. Although this is probably where many innovations will be made due to obvious economic reasons, AI is not limited to doing things. The broader story is [AI-supported org design](/post/ai-supported-org-design) — using AI strategically to evolve how organizations are structured and how people learn.
> AI is not (just) a doer, it is a great teacher.
---
# Shopify CEO: Reflexive AI Usage
**Date:** 2025-04-12 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/shopify-ceo-reflexive-ai-usage
**TL;DR:** Shopify's reflexive AI mandate is bold but insufficient. Amplifying a single skill with AI won't save you — single-skill jobs are the first to be automated away. The real move is becoming an M-shaped multi-learner with several deep specialisms. AI makes that feasible for the first time in history.
I think by now everyone read the letter from Shopify CEO on “Reflexive AI Usage as a Baseline”?
This reads like a mega-bold statement and very timely. We can now expect a wave of CEO letters to follow. Good. Everyone agrees that AI is something that cannot be ignored if your business aims to keep the market relevancy.
And I want to take this one level higher. Let me explain.
Yesterday I did a talk for our Org Topologies members titled “Versatile”. There I shared a premise that it is not just enough to amplify your current primary skill with AI.
Example: visual design, frontend coding, or alike. Such single-skill jobs will be the first ones to be taken away from humans by AI agents; already starting in 2025. When [AI replaces the task and your job equals the task](/post/ai-replaces-tasks-not-people), the math is straightforward.
If we want to stay relevant (a repeated keyword) we need to multi-learn. In other words: become M-shaped professionals with several deep specialisms. Scary? Difficult? Impossible?
[Multi-learning](/post/multi-learning-200-years-wrong-model) is not a new topic. For example it was referred to in HBR already in 1986. But it had been vastly seen as a myth and a trait of very rare high-IQ individuals. And fairly so.
But that was before 2025.
Now—is when the history branches off. Embrace versatile multi-learners.
Most who tried AI augmentation at work, realize that the AI facilitates and accelerated learning like nothing else. And the technological progress is still accelerating.
We are entering not just the era of AI and AI augmentation of work.
We are about to witness the rise of multi-learners that are 100x in value they can produce (that’s not some marginal step process improvement).
And on the personal level? What does it mean for all of us?
Our claim: m-shaping is an ultimate solution for staying relevant, preserving our jobs, and on top of that do amazing things for our customers, communities, and the whole world. The organizational structure must support this — as [*Tailwind Career Paths*](/post/tailwind-career-paths) explores, traditional career ladders reward narrow specialization and punish exactly the breadth that makes people resilient.
---
# AI-Supported Org Design
**Date:** 2025-04-10 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/ai-supported-org-design
**TL;DR:** AI OD is the strategic use of AI to evolve how organizations are structured and how people learn. Two anchoring principles: AI makes versatile teams viable by collapsing the cost of learning adjacent skills, and multi-learning becomes the engine of continuous adaptation. This is not a productivity story — it is an org design story.
## A larger landscape than individual productivity
AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025 — but as [the Ferrari Trap](/post/the-ferrari-trap) shows, faster individuals in unchanged structures produce no system-level gain. There is a much larger landscape. Let me share.
AI-Supported Org Design — *AI OD* for short — will become a hugely impactful topic affecting all of us and all the organizations in which we work.
AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.
It is not about replacing managers or employees. It is about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day.
Two principles anchor it:
- **The core organizing principle:** AI makes versatile teams viable.
- **The core operating principle:** With multi-learning as the engine.
How do these principles differ from applying AI for individual performance gains? Let me unpack.
## Organizing principle: AI makes versatile teams viable
Most organizations are still designed around narrow specialization — single-skill roles, component ownership, hand-offs between functions. That design made sense for [200 years of factory logic](/post/multi-learning-200-years-wrong-model), when learning a new craft was slow and expensive.
AI changes the economics of learning. When an AI agent can teach a backend developer the basics of customer support flow, or walk a support agent through writing a Python script, the cost of acquiring adjacent skills collapses. What used to require a re-org now becomes a learning act inside the team.
That is what unlocks *versatile teams* — teams broad enough to follow the work end-to-end, with AI as the always-available teacher and accelerator.
## Operating principle: with multi-learning as the engine
If we unpack this principle, it is all about applying AI to support the organization's development direction and accelerate its evolution to gain high performance and other competitive advantages.
That is strategic AI application.
Three sub-principles guide it:
### #1 — Multi-learning enables adaptivity
Especially in Adaptive Topologies (see the *Org Topologies* primer for details), learning — not just delivery — is the primary currency. AI enables this by making the unknown known and the unlearnable learnable, with ease.
Sample scenarios:
- A backend developer shadows a customer support session and begins contributing to onboarding scripts.
- A frontline support agent learns enough Python to automate common diagnostic steps, reducing ticket escalations and easing the load on developers.
- An end-to-end team includes privacy review and data protection steps in their regular sprint workflow — not because they were forced to, but because someone on the team got curious, shadowed legal, and brought that knowledge back in.
- A delivery manager starts using AI tools like Cursor or GitHub Copilot — not to replace anyone, but to better understand how her teams are using it, what it is good at, and the current limits.
### #2 — Matching work to skill in real time
Rather than static org charts or disruptive reshuffles, AI supports the continuous alignment of skills to work based on live data and evolving interests. When multi-learning is too expensive, AIs will suggest *micro-reteaming* without major upheaval as a temporary, quick-fix solution.
- **Static matching:** pre-analyze and pre-plan work.
- **Dynamic reteaming:** reallocate people when needed.
- **Multi-learning:** give people the mandate to learn.
When multi-learning is a part of work, managers do not need to waste time and energy preplanning or reteaming. People can follow the work and learn what is necessary to achieve the expected outcomes. This is the organizational capability that makes [both wings of a 10X organization](/post/two-wings-of-a-10x-bird) work.
### #3 — Learning becomes the flow
AI agents will surface relevant prior work and recommend five-minute learning prompts when patterns emerge.
> "Team X solved this two sprints ago."
>
> "Want to see how testing was solved in a similar sprint?"
That is learning embedded in the flow of work, not pulled out into a separate training program.
## Strategic AI in org design
AI-powered org design harnesses AI to make teams inherently versatile and learning deeply integrated — driving adaptable, resilient organizations without the need for constant structural upheaval.
This requires practicing a new mindset: seeing AI not as a tool to output more, but as a strategic lever that enables humans with easier multi-learning and higher outcomes.
> AI OD is not a productivity story. It is an organizational design story — with AI as the amplifier of human adaptability.
That is what [Org Topologies](https://orgtopologies.com/) offers as a field guide for leaders in this disruptive era of AI we all happen to live in, in collaboration with Roland Flemm and Craig Larman.
---
# Org Topologies meets EBM
**Date:** 2025-02-24 · **Reading time:** 10 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/org-topologies-with-evidence-based-management
**TL;DR:** OT tells you what to change in the structure; EBM tells you whether it worked. Together they close the loop: EBM identifies symptoms, OT treats root causes, EBM measures treatment effectiveness. Each structural change becomes a testable experiment with measurable outcomes — scientific org evolution.
This article starts by laying down the key principles of EBM applied within an OT-inspired org change. It opens with a crisp description of both methods and then dives into how they work together to reinforce a systemic org change with a strong focus on measuring value.
Org Topologies recognizes **Measure and Improve Value with EBM (for Enhanced Performance and Agility)** as one of the [Elevating Katas](https://www.orgtopologies.com/elevating-katas) — a set of principles, methods, and guides for moving an org design closer to the upper right on the Org Topologies map.
If you know both methods, jump to the later section where they are compared, contrasted, and integrated. For a complete guide on Evidence-Based Management, refer to the [Scrum.org EBM page](https://www.scrum.org/resources/evidence-based-management).
In this article, we claim the following to be true:
> OT provides the actionable changes and EBM provides the measure of success, enabling a *scientific approach* to organizational evolution.
> EBM identifies the symptoms, OT treats the *root cause*, and EBM then measures the treatment's *effectiveness*.
> EBM measures act as a *compass* ensuring Org Topologies changes truly lead to *agility*.
## Org Topologies: Principles and Methodology
**Org Topologies (OT)** is a framework for strategic organizational design and change. It is described as the first *"human-centric plus AI-friendly"* approach to organizational change. This means it emphasizes the human side of change (people need to *own* their change and find it engaging) while anticipating the integration of AI into the workforce.
Key principles and components of Org Topologies include:
- **Psychology of Change:** OT recognizes that lasting change occurs when people across the organization participate and take ownership, rather than having changes imposed top-down. It provides a *visual and collaborative mapping* process so everyone can *"visualize, discuss, understand, and shape the change"* together. This shared understanding creates a common language for organization design and engages everyone in the transformation.
- **Fit-for-Purpose Design:** Org Topologies aligns organizational structure with the organization's strategic goals or "North Star." Different business goals (e.g. rapid delivery, adaptability, resource efficiency, innovation) *require different tailored org designs*. OT helps leaders define the right target design to achieve their specific objectives and keep the organization *"fit for purpose"* as those objectives evolve. It works at any scale — entire enterprise or subdivisions — to ensure structure, strategy, and change process are all aligned.
- **Organization Mapping and Archetypes:** A core methodology in OT is mapping the current organization into **archetypes** on a two-dimensional grid. The two axes represent fundamental dimensions of org design, such as the growing **scope of skills mandate** (depth of cross-functional skills) and **scope of work mandate** (breadth of product/customer scope). OT defines a set of common patterns (archetypes) for how teams or units are structured and operate — a deeper look at how these archetypes emerge is in [*Determining Archetypes*](/post/determining-archetypes). In the latest version, there are 16 archetypes organized into four groups and positioned along the two axes. This **Org Topologies Map** is a visual tool to assess where the organization is today and identify mismatches between the current design and the capabilities needed to meet business objectives.
- **Topologies and Organizational Patterns:** The archetypes are further grouped into three broad **topologies** — often described as **Resource**, **Delivery**, and **Adaptive** topologies. Each topology represents a distinctive way the organization coordinates work:
1. *Resource Topology* (traditional model): characterized by specialized, siloed teams managed via centralized coordination (emphasis on resource utilization). *Directing* units (like PMOs or managers) decide work, and *Doing* units execute, often leading to hand-offs and dependencies. This can maximize local efficiency but often sacrifices adaptability and speed.
2. *Delivery Topology:* focuses on the fast flow of outputs by using cross-functional teams and removing inter-team dependencies. Teams are structured as "complete" delivery units (often called feature teams or *"feature factory"* style) that can produce a steady stream of features with short lead times. However, work definition (the *"what to build"*) is usually still driven by separate planning or analysis roles (discovery is handled apart from the delivery teams). This topology excels when the main challenge is **predictable, rapid delivery** of known features rather than exploring unknown market needs.
3. *Adaptive Topology:* aims for maximum *adaptiveness and innovation*. It **merges directing, doing, and delivering into one** unified unit. In this model, teams (or *"team-of-teams"* networks) are empowered to both discover and deliver value continuously, often working with a broad product scope and high synchrony across the organization. Humans, AI agents, and even robots collaborate in these *"Driving"* units to solve complex problems, learn, and adapt on the fly. The Adaptive topology's goal is to enable quick, cheap responses to change and to *"discover and deliver higher-impact customer outcomes"*, supporting long-term business resilience. This design is fit for organizations where growth, learning, and customer-centric innovation are paramount.
### Intended Application of OT
Org Topologies is intended for any industry or domain seeking to improve organizational agility and performance — from software product companies to farms or construction firms. It is especially useful in agile and digital transformations, where existing structures hinder fast delivery, adaptability, or innovation. By using OT, leaders gain a "critical managerial tool" to drive performance via org design. For example, OT can be overlaid with frameworks like SAFe, LeSS, or even non-tech models like Haier's Rendanheyi to map and enhance an Agile Release Train or a networked organization. (For a real-world case of this in action, see [*Studying Org Designs: Haier, RDHY, Bayer, DSO*](/post/studying-org-designs-haier-rdhy-bayer-dso).) Overall, Org Topologies helps organizations "align all the moving pieces" — structure, strategy, and change efforts — to achieve strategic goals in a sustainable way.
## Evidence-Based Management (EBM): Principles and Methodology
**Evidence-Based Management (EBM)** is a framework developed by Ken Schwaber and [Scrum.org](https://www.scrum.org/resources/evidence-based-management) to help organizations continuously improve by making decisions based on evidence and measurable outcomes. EBM is built on three core pillars: clearly defined **Goals**, targeted **Measures**, and the discipline of **Empiricism**. These pillars work together — our goals set the strategic direction, the measures (including KVAs) provide evidence, and empiricism drives continuous learning and adaptation. The method provides a disciplined, empirical approach for management and teams to achieve strategic goals in the face of uncertainty.
Key principles and components of EBM include:
- **Empiricism and Experimentation:** EBM advocates that organizations tackle complex, uncertain challenges through *intentional experimentation and frequent feedback*. Rather than making big up-front plans, teams and leaders set *incremental goals*, run experiments, and use data to decide the next steps. In practice, this means forming a hypothesis about how an improvement or change might move the organization closer to its goals, implementing that change on a small scale, and measuring the results against expected outcomes. Based on the evidence gathered, the organization adapts its tactics or even revises its goals. This iterative loop mirrors Scrum's empiricism at a management level, ensuring that *decisions are grounded in real-world data* rather than assumptions.
- **Value-Focused Goals:** In EBM, all efforts are oriented toward improving *outcomes* (value delivered), not just outputs. Organizations are encouraged to express their aspirations at multiple levels — a Vision (the ultimate change they seek to make in the world), a Mission (why they are uniquely positioned to achieve that vision), and concrete Goals that lead toward fulfilling them. However, EBM notes that many organizations struggle to create effective goals that drive real progress toward their mission and vision. EBM addresses this by helping organizations set **Strategic Goals** (long-term objectives connected to mission), break them into nearer-term **Intermediate Goals**, and then into very short-term **Immediate Goals** that teams can act on now. Crucially, each goal should have *measurable criteria* so the organization can inspect whether changes are actually moving the needle. This keeps goals outcome-oriented (e.g. improving customer satisfaction) rather than activity-oriented, and it ensures every level of goal is aligned with delivering real value.
- **Key Value Areas (KVAs):** A cornerstone of EBM is measuring value and capabilities in a **balanced way**. EBM defines four broad **Key Value Areas** which act as lenses on different aspects of organizational performance. These KVAs help teams and managers focus on what to improve and avoid blind spots.
The four KVAs are:
1. **Current Value (CV):** How much value the product or service delivers to customers *today* (e.g. customer satisfaction, revenue, market share).
2. **Unrealized Value (UV):** The potential future value that could be unlocked if the organization better met all possible customer or user needs — essentially the gap between current value and what *could* be achieved (e.g. untapped market segments, additional features that could attract new customers).
3. **Ability to Innovate (A2I):** How effectively the organization can deliver new capabilities or improvements (e.g. innovation rate, technical excellence, experiment frequency). This reflects the organization's capacity to adapt and innovate in response to market needs.
4. **Time to Market (T2M):** How quickly the organization can deliver a new idea or change and gather feedback on it (e.g. release frequency, lead time for changes).
### Intended Application of EBM
EBM was initially formulated in the context of software and product delivery organizations adopting Scrum, but it is broadly applicable to any enterprise seeking to improve its results under uncertainty. It is especially useful when an organization has adopted Agile practices but wants to ensure those translate into real business value. For example, a company might use Scrum for development; EBM provides the *management framework* to measure whether Scrum is delivering the expected improvements in customer value, time to market, etc., and to guide further changes. Typical applications of EBM include setting organizational OKRs or targets in terms of KVAs, assessing the impact of transformations (e.g., "Are we actually reducing time-to-market with this new process?"), and steering investments toward initiatives with evidence of high impact. Because it is framework-agnostic, EBM can overlay any process or structure, providing a way to *"measure, manage, and increase the value [an organization] derive[s] from their product delivery"*. Ultimately, it helps organizations *"improve outcomes, reduce risks, and optimize investments"* by empirically guiding decisions at all levels.
## How OT and EBM Complement and Contrast Each Other
Because Org Topologies and EBM operate in different yet related domains (structure vs. measurement), they can be used together in a complementary fashion.
### Complementary Use Cases
In an organizational transformation, one can use Org Topologies to *design the change* and EBM to *drive and verify the change*. For example, if a company's strategic goal is to improve innovation and adaptability, Org Topologies might suggest moving toward an Adaptive Topology — merging discovery and delivery functions into autonomous product units.
EBM would complement this by tracking **Ability to Innovate** and **Unrealized Value** metrics to see if the structural change actually increases innovation output or unlocks new market value. In fact, Scrum.org notes that their EBM framework is a good way to ensure *"rigorous experimentation and a balance between value indicators"* during change efforts.
Meanwhile, Org Topologies *"offers a powerful tool for assessing the [current] situation and outlining the changes needed"* to reach those objectives. Together, OT can tell you *what* to change in your org design, and EBM can tell you *whether those changes are producing the desired results*.
This closes the loop between design and outcome:
- **Strategy Alignment:** Org Topologies helps translate strategic objectives into an appropriate organization design (e.g. choose a topology that fits a strategy of rapid delivery or one that fits a strategy of innovation). EBM ensures that those strategic objectives are clearly articulated as measurable goals and provides feedback on progress toward them. The two together ensure that structure and strategy are continually aligned and validated. If strategy shifts, EBM will catch changes in outcomes, and OT provides a mechanism to adjust structure accordingly.
- **Navigating Change Safely:** Both frameworks stress incremental change, so used together they encourage a safe-to-fail approach. Org Topologies might implement a pilot re-organization in one product line (Elevate step with experiments), and EBM would measure the pilot's impact in terms of value (did customer outcomes improve? did time to market improve?). If the metrics show positive evidence, the new design can be rolled out wider; if not, the organization can iterate on the design. This complementary approach reduces the risk of large-scale changes — you're not "flying blind" with a new org structure because EBM is instrumenting the change with data.
- **Balancing People and Performance:** Org Topologies brings in the human element — making sure people understand the why of changes, and that roles and team boundaries are set up for collaboration rather than confusion. EBM brings in the performance focus — making sure the changes actually deliver business results, not just feel good. In some transformations, there's a risk of over-focusing on org charts and forgetting to measure outcomes (which EBM prevents), or conversely over-focusing on metrics and ignoring morale or clarity (which OT prevents by involving people in design). Together, they provide a more holistic transformation: *structural, cultural, and outcome-based* considerations are all addressed.
### Contrasting Considerations
On the other hand, using both requires understanding their different mindsets. Org Topologies might identify a **structural problem** (say, too many narrow-component teams causing slow integration). EBM might identify a **value problem** (say, low customer satisfaction). These may or may not point to the same solution initially — it takes skilled interpretation to connect the two.
For instance, EBM could reveal a problem (low Current Value) that is due to factors outside org structure (maybe a poor product-market fit or outdated technology). Org Topologies might propose structural changes that need careful justification via evidence (to avoid reorgs that don't pay off). In some cases, one framework might challenge the other: EBM's data might suggest that a recent structural change (inspired by OT) is not yielding results, which could mean re-thinking the change or giving it more time.
Conversely, an OT practitioner might caution that certain performance drops are expected short-term during re-structuring and that patience is needed. Therefore, while they complement each other, it's important to synchronize **cadence** and **perspective** — using EBM's evidence to inform Org Topologies decisions, but also using Org Topologies wisdom to interpret EBM data in context.
Another contrast is in **scope of impact**: Org Topologies changes can have far-reaching consequences on people's roles, team identity, and day-to-day work (which can be disruptive even if ultimately beneficial). EBM's introduction (measuring things, setting new goals) is usually less structurally disruptive but can change mindsets and accountability. An organization needs to manage both the structural change management and the cultural shift to evidence-driven management. Leaders might choose to introduce EBM practices first (to identify where change is needed and build a culture of empiricism), or introduce Org Topologies first (to fix glaring structural bottlenecks), or do both in tandem. There's no one right sequence, but it's wise to communicate how they interrelate so teams don't feel like "yet another initiative" piled on.
## Elevating Kata: Measure and Improve Value with EBM
When integrated thoughtfully, Org Topologies and Evidence-Based Management can reinforce each other to significantly enhance organizational performance and agility. Here are some ways an organization might combine the two frameworks:
- **Data-Driven Org Design:** Use EBM **metrics as diagnostics** to drive Org Topologies interventions. For example, suppose EBM reveals that *Time to Market* is too slow and *Current Value* is stagnating. This quantitative evidence can trigger a closer look at org structure: perhaps teams are organized in a Resource Topology with many dependencies causing delays. Org Topologies would then provide a method to redesign toward a Delivery or Adaptive Topology (e.g. introduce more cross-functional teams, reduce hand-offs) to address the problem. After making structural changes, the organization continues to track the relevant KVA metrics. If Time to Market improves and Current Value starts rising, it validates the structural approach; if not, further adjustments are made. In this way, **EBM identifies the symptoms, OT treats the root cause**, and EBM then measures the treatment's effectiveness.
- **Continuous Feedback into Structure:** Apply an **EBM loop within the OT "Elevate" phase**. As Org Topologies changes are implemented incrementally, each change can be treated as an EBM experiment. Define an expected outcome (e.g. "by merging Team A and B into a single value-stream team, we expect deployment frequency to double in that product line"), implement the change, and measure the outcome (deployment frequency is a proxy for Time to Market KVI). This creates a tight feedback loop: structural change → metric outcome → learn → next structural change. It prevents the organization from over-correcting or making broad changes without evidence. Essentially, OT provides the *actionable changes* and EBM provides the *measure of success*, enabling a **scientific approach to organizational evolution**.
- **Strategic Goal Alignment Workshops:** An integrated practice could be running a workshop where leadership uses EBM to set or refine strategic goals/KVAs, and simultaneously uses Org Topologies mapping to evaluate if the current org can meet those goals. For instance, leadership might set a goal to increase **Unrealized Value** (capturing a new market segment). In the same session, using Org Topologies maps, they might discover that the current structure has no dedicated product team exploring that new market (perhaps all teams are tied up delivering current features). This insight leads to an Org Topologies design solution (e.g. create a new "Explore" team archetype or reassign an existing team's mandate to include the new segment). They would then implement that and use EBM to monitor if Unrealized Value (e.g. percentage of market captured or new customer adoption) starts to go down, indicating value is being realized. This illustrates how strategy → structure → metric integration can happen in a seamless flow.
- **Combining Language and Measures:** Org Topologies provides a **common language** for org structure (with terms like CAPS, WHOLE, topologies, etc.), and EBM provides a common language for value and improvement (CV, UV, etc.). Together, they can help different parts of the organization communicate. For example, an agile coach might say *"We need to elevate from a CAPS-1 to a CAPS-3 team to reduce dependencies,"* and a product manager might add *"Yes, that should improve our Time to Market."* When both the structural change and the expected outcome are clearly expressed, it creates alignment between organizational development efforts and business results. This integration of lexicon — structural terms coupled with value metrics — ensures everyone understands not just *what* change is happening, but *why* (what outcome is expected). It ties the abstract concepts of org design to concrete business metrics that people care about.
- **Ensuring Balanced Change:** EBM's four KVAs ensure that while pursuing one improvement, you don't hurt another. An organization integrating OT and EBM will use those metrics to check that a structural change aimed at one dimension doesn't inadvertently damage another. For example, moving to a Delivery Topology might speed up delivery (better T2M) but, if done in isolation, could lead to feature factory syndrome where lots of output doesn't increase customer value (CV). By keeping an eye on Current Value and Unrealized Value, leaders can detect if they are churning out features with no outcome — and then course-correct by incorporating more "Adaptive" elements (e.g. ensure teams also have discovery capability, not just output focus). Thus, the **EBM measures act as a compass** ensuring Org Topologies changes truly lead to agility (ability to respond) *and* real value creation, not one without the other.
- **Scaling and Sustaining Gains:** Over time, as an organization iterates between OT-driven changes and EBM-driven measurements, it can develop a capability for **self-tuning**. The structural changes (OT) solve immediate bottlenecks, and the measurement (EBM) ensures new bottlenecks or opportunities are quickly identified. This synergy can accelerate an agile transformation or any continuous improvement initiative. Org Topologies changes might happen at a slower cadence (since structural moves take planning), while EBM cycles can happen very frequently. An integrated approach might use EBM continuously (say, quarterly outcome reviews, monthly metric check-ups) and use Org Topologies periodically (say, an annual structural review or on-demand when EBM indicates a plateau). When both are embedded into the management practices, the organization is equipped to *adapt both its strategy execution and its structure in concert*. This leads to what we might call **organizational agility** in the truest sense: the organization can reconfigure itself (structure, teams, processes) and redirect itself (goals, investments) with relative ease, based on evidence, to seize opportunities or avoid threats.
## Key Metrics Aligned to Organizational Topologies
The **Evidence-Based Management (EBM) Guide (2024)** Appendix provides example Key Value Measures (KVMs) that organizations can use to gauge value and improvements. Each organizational topology — **Resource**, **Delivery**, and **Adaptive** — emphasizes different goals, so certain metrics from the EBM examples will be more suited to each.
Below are three exemplary key metrics fit for each topology, along with explanations of how each metric aligns with that topology's characteristics and goals.
### Resource Topology
*Org Goal: maximizing resource utilization and specialization*
| Metric (Key Value Area) | Alignment with Resource Topology |
|---|---|
| **Product Cost Ratio** *(Current Value)* | Measures total product expenses relative to revenue. A lower cost-to-revenue ratio reflects greater efficiency in resource utilization, supporting a Resource-focused organization's aim to optimize costs and maximize the output from each resource. |
| **Revenue per Employee** *(Current Value)* | Indicates how efficiently each employee (resource) generates value. A higher revenue per employee means the organization gets more output per resource, aligning with the Resource Topology's goal of maximizing resource use and efficiency. |
| **On-Product Index** *(Ability to Innovate)* | The percentage of time teams spend working directly on product value (vs. overhead). A high on-product index means most of the workforce's time is spent on productive, value-adding work, which aligns with maximizing resource productivity in a Resource Topology (minimizing idle time or context-switching). |
### Delivery Topology
*Org Goal: maximizing output and predictability of delivery*
| Metric (Key Value Area) | Alignment with Delivery Topology |
|---|---|
| **Release Frequency** *(Time to Market)* | Measures how often the product is released (e.g. daily, weekly, etc.). Frequent releases indicate a high throughput of features to customers, matching the Delivery Topology's emphasis on steady output and regular delivery of value. This metric shows the capability to deliver predictably and often. |
| **Lead Time (to Value)** *(Time to Market)* | The time from an idea or requirement being proposed to it being delivered and benefiting the customer. Short lead times demonstrate fast turn-around from concept to delivery, reflecting the Delivery Topology's goal of rapid, predictable delivery of proven value. |
| **Change Failure Rate** *(Ability to Innovate)* | The percentage of releases that result in failures (e.g. require hotfixes or rollbacks). A low change failure rate means releases are generally stable and successful, supporting the Delivery Topology's focus on predictability and quality in output. This ensures that increasing release speed doesn't come at the cost of reliability. |
### Adaptive Topology
*Org Goal: maximizing outcomes and innovation through fast adaptation*
| Metric (Key Value Area) | Alignment with Adaptive Topology |
|---|---|
| **Customer Satisfaction** *(Current Value)* | Gauges how happy customers/users are with the product (e.g. via surveys or NPS). High customer satisfaction indicates the organization is delivering valuable outcomes, not just outputs. This aligns with the Adaptive Topology's goal of maximizing customer-centric outcomes (delighting customers through continual learning and adaptation). |
| **Time To Pivot** *(Time to Market)* | Measures how quickly the organization can change direction in response to feedback or market changes. A short time to pivot reflects true business agility — the hallmark of an Adaptive Topology — demonstrating easy, cheap change based on learning and a capacity to rapidly adapt strategy. |
| **Innovation Rate** *(Ability to Innovate)* | The percentage of effort spent on developing new product capabilities (versus maintenance). A higher innovation rate means the organization dedicates more of its resources to creating new value. This supports the Adaptive Topology's focus on innovation and exploration, ensuring the organization can continuously evolve and deliver novel solutions. |
## Summary
In summary, Org Topologies and Evidence-Based Management are distinct but highly complementary frameworks. **Org Topologies** provides the *"where and how to change"* from a structural perspective, ensuring the organization's form enables agility and aligns with its purpose. **EBM** provides the *"whether and why to change"* from a value perspective, ensuring the organization's operations remain focused on delivering measurable value and that any change is justified by evidence.
Their key principles differ — one is about *designing the system*, the other about *measuring and steering the system* — yet they share a foundation in agile, empirical thinking and can mutually reinforce success. By integrating the two, organizations can avoid the pitfalls of structure-blind improvement or improvement-blind structure. Instead, they gain a powerful combined approach to become both well-organized and continuously learning — ultimately enhancing performance, adaptability, and agility in a sustainable way.
For a broader look at what "adaptive" means in practice, see [*In Search of Adaptivity and Fit*](/post/in-search-of-adaptivity-fit). This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous.
---
# Strategic AI Adoption
**Date:** 2025-02-15 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevate-org-with-strategic-ai-adoption
**TL;DR:** AI makes specialization cheap — broader skill mandates and higher archetypes become feasible. Don't spray AI generically. Three strategic questions: Where are you elevating? What archetype bottlenecks can AI break? Do the AIs need human monitoring? Focus investment where it unblocks the specific move you're making on the OT map.
> **Any management approach that doesn’t include AI as a central part of the future workforce is of the past. We are rapidly entering a world of AI agents and humanoid robots playing a role at work and home.**Org Topologies Primer 2025
A key insight when designing with OT: _Specialization and expertise are vanishing as limited resources, due to intelligence as a service_. This is the practical consequence of what I describe in [*Multi-Learning: 200 Years of the Wrong Model*](/post/multi-learning-200-years-wrong-model). That makes it _much_ easier to elevate an organization! So when you are deciding on new teams requiring new expert knowledge, shed the old assumptions, “We don’t have enough experts, therefore…”. Spin up another 10,000 agents.
Evolving rightward on the horizontal axis to broader skills mandate will become ever easier due to AI. And likewise upward on the vertical axis to a broader work mandate. So, top-right _Driving_ archetypes will become more feasible.
Obviously, “adopt AI everywhere you can” will be the general guidance — but as [the Ferrari Trap](/post/the-ferrari-trap) shows, generic AI adoption without structural change produces no system-level gain. Given the limited resources of money, time, and attention, in strategic org design with OT we recommend that you ask and answer these questions:
> 1. What parts of the organization are the focus of development with OT?
Focus your AI investment in the area you are elevating, where competitive advantage may come from early _adoption of new technology._
> 2. What archetypes are part of your target, and what are the major bottlenecks or constraints limiting their rapid adoption?
Find the early points where AI can make an outsized impact.
> 3. Do the AIs need monitoring by humans?
That implies new responsibilities and processes in your organization. We predict that _monitoring_ will become an important responsibility for human workers.
For example, a pet-supply company creates e-commerce software in a Resource topology. It’s a mature, uncomplicated market. Competition has delivered a better website and app that customers love. Leadership has decided on a business objective of retaining customers, with an org goal of fast flow to parity, by targeting a Delivery topology with CAPS-3 teams.
Now let's evaluate this set-up with the three questions:
_Q> What parts of the company are the focus of org development?_ The Product Management and R&D departments, so focus on AI investment there.
_Q> What archetypes are part of the target? What’s a dominant constraint from one to the other?_
The R&D department has mostly TASKS-1 individuals, and the target is CAPS-3 teams. On investigation, it’s a lack of front-end design and coding skilled people. Focus time, money, and management attention on AIs, especially on that big bottleneck, over a generic “adopt AI.”
_Q> Do the AIs need monitoring by humans?_
Yes, because people have decided on AI agents that autonomously design and code front ends, independently creating and iterating on variations that they deploy and measure. The small number of existing front-end designers and developers joining the new CAPS-3 teams will be trained in agent monitoring and take on that responsibility.
As a part of the Org Topologies Primer 2025 — a table of how AI adoption can be strategized in each of the four archetype groups:
## More on AI Implications on Org Design
---
# Haier's RDHY vs. Bayer's DSO
**Date:** 2025-02-04 · **Reading time:** 10 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/studying-org-designs-haier-rdhy-bayer-dso
**TL;DR:** Haier and Bayer both dismantled hierarchies but took different paths. Haier's micro-enterprises are independent P&L centers with digital contracting; Bayer's squads are cross-functional but still lean on centralized coordination. Mapped on Org Topologies, Haier reaches higher on both axes. Both prove decentralization works — the question is how far you push autonomy.
## What This Article Covers
Two of the most ambitious organizational redesigns in modern industry — Haier's **Rendanheyi (RDHY)** and Bayer's **Dynamic Shared Ownership (DSO)** — share a common ambition: dismantle the traditional pyramid and push decisions to the frontline. They also differ in almost every respect that matters: origin, structure, age, cultural drivers.
This piece walks through both models, maps their work units on the [Org Topologies](https://www.orgtopologies.com/) two-axis grid, and shows what each gets right — and where each is, in different ways, still incomplete.
Sections, in order:
1. Haier's transformation
2. Bayer's transformation
3. Similarities and differences: RDHY and DSO
4. Studying org designs of RDHY
5. Studying org designs of DSO
6. Comparing and contrasting the two models
7. Putting it all together
## 1. Haier's Transformation
The Haier **Rendanheyi** model (**RDHY**) is a management philosophy developed under the leadership of Haier's founder, Zhang Ruimin. It is a radical departure from traditional hierarchical structures — built on the idea that every employee's effort should align directly with customer (or user) value creation.
Haier's journey toward a decentralized, customer-centric organization began in earnest around **2005** — a sharp break from conventional hierarchy. Over the following years, and especially around **2012**, Haier refined the approach by breaking its operations into thousands of micro-enterprises that interact directly with users, institutionalizing entrepreneurial autonomy and customer-focused value creation.
Reported outcomes include: hierarchical layers reduced from 12 to 3 across subsidiaries, a 67% faster decision-making cycle compared to 2021 benchmarks, and a target — by 2025 — to derive 60% of revenue from ecosystem services through AI integration and cross-industry partnerships.
## 2. Bayer's Transformation
Bayer's **Dynamic Shared Ownership** (**DSO**) is a sweeping transformation of a traditional hierarchical structure into a more agile, decentralized system — one that shifts decision-making and ownership closer to the frontline. Much like Haier's RDHY, DSO is designed to empower employees and create a more responsive, customer-centric organization. But it emerges from a very different corporate context and set of challenges.
Bayer began restructuring its traditional pyramid-shaped organization into small, empowered squads around **2018–2019**. The initiative accelerated significantly around **2020** in response to performance challenges and the need for faster, market-responsive decision-making. The creation of agile, cross-functional squads is a more recent development of the model. The goal: shift power to frontline teams while maintaining interdependent coordination through digital platforms and agile processes.
It is still early to judge the success of the DSO implementation — Bayer is only a few years into the change (compared to Haier, who started almost two decades ago). As of February 2025, Bayer's CEO Bill Anderson, who was appointed in 2023, continues to lead Bayer through a major restructuring program aimed at reducing hierarchy and cutting costs by €2 billion by 2026. Bayer's recovery toward a shinier future is likely still ahead.
## 3. Similarities and Differences: RDHY and DSO
Both models share similar ambitions — decentralize decision-making, empower frontline employees, focus on customer value. The contexts and drivers, however, differ:
- **Origin.** Haier's model was born out of the need to transform a manufacturing company in a rapidly evolving Chinese market. Bayer's DSO is a response to internal performance challenges and the demands of a global pharmaceutical and life sciences conglomerate.
- **Structure.** Haier's approach breaks the organization into thousands of micro-enterprises and ecosystem micro-communities. Bayer is reconfiguring its structure into autonomous, cross-functional squads within a "flat army."
- **Cultural drivers.** Both require a significant cultural shift. Haier's journey is about aligning every employee's value with customer value. Bayer's DSO is similarly designed to transform mindsets from hierarchical control to shared, mission-driven ownership.
In summary:
- **Haier.** Most employees are reorganized into micro-enterprises (and aggregated into ecosystem micro-communities), but some functions — especially centralized support — remain outside the direct micro-enterprise structure.
- **Bayer.** A significant portion of the workforce is restructured into agile, cross-functional squads, yet certain central functions and corporate support roles are not organized this way.
## 4. Studying Org Designs of RDHY
### Core Principles of RDHY
**1. Human-centric value creation.** At its heart, the model is built on the idea that "Ren" (人, meaning "people" or "employees") and "Dan" (单, "orders" or customer demands) should be "HeYi" (合一, "integrated"). In other words, the personal value of every employee is directly tied to the value they create for users. This "win-win" concept drives a culture where **every individual is seen as an entrepreneur**, with incentives and rewards linked to how well they serve customer needs.
**2. Decentralization and self-organization.** Traditional middle management and rigid bureaucracies are replaced with a **network of micro-enterprises (MEs)** — autonomous units. Each small unit (often around 10 people) operates almost like an independent startup within the larger organization. This decentralization enables rapid decision-making and agile responses to customer feedback — what Haier calls "zero distance" between the employee and the end-user.
**3. Entrepreneurial autonomy.** Rather than a top-down, command-and-control system, the Rendanheyi model delegates authority to the lowest levels. Employees are given decision-making power and a share in the success of their projects. The entrepreneurial spirit is encouraged through systems that reward innovation and accountability, making every micro-enterprise **responsible for its own profit and loss**.
### Work Units of RDHY
Haier's RDHY isn't limited to autonomous micro-enterprises (MEs). Over time, the model has evolved to include several complementary unit types:
1. **Micro-enterprises (MEs).** Small, autonomous business units — typically 10 to 15 employees — that operate as independent profit-and-loss centers within the larger corporate structure. They are empowered to make critical decisions, hire and manage talent, and directly engage with customers to identify and meet their needs, fostering an entrepreneurial culture where every employee acts as a mini-entrepreneur. MEs are the foundational building blocks of Haier's decentralized organization, and they often collaborate and interconnect through ecosystem micro-communities (EMCs) to share resources and co-create value.
2. **Ecosystem Micro-Communities (EMCs).** MEs are not isolated; they are designed to interconnect. Groups of MEs come together to form EMCs — clusters or communities that collaborate to address more complex user scenarios. In practice, EMCs are often divided into subtypes (for example, "solution EMCs" and "experience EMCs"), with one set focusing on developing solutions (R&D or manufacturing) and the other on user engagement and experience. The grouping helps the organization tackle larger market challenges while still maintaining the agility of small entrepreneurial units.
3. **Supporting shared services and platforms.** In addition to MEs and EMCs, Haier has built internal service platforms that function as support units. These manage essential services — HR, procurement, logistics — reducing the need for traditional middle management and allowing the MEs to focus on value creation and customer engagement. Platforms like COSMOPlat serve as internal marketplaces where units can interact, bid for services, or share resources in a transparent, market-based manner.
Together, these three layers create a dynamic ecosystem in which individual entrepreneurial units drive rapid innovation and customer-centricity, while centralized platforms and inter-unit communities ensure coordination and resource sharing across the whole enterprise.
### Disclaimer
Below are publicly available real-life examples. These are probably some of Haier's most advanced and successful cases — that's why they have been promoted. They are great for illustrating the power of the model.
When we later map these teams with Org Topologies, it is worth remembering that those assessments are likely the outliers — in the positive direction. We predict that not all teams at Haier are this advanced and would probably be assessed lower on the map. The same applies to Bayer's example teams further below.
Our intention is not to create a statistically correct assessment — we simply lack the data for such a study. Our goal is to show the qualitative (not quantitative) potential of these two very different models. Our mission is to inspire other organizations to *get the change going*. (For another case study using Org Topologies mapping, see [*LeSS Adoption at Poster POS*](/post/less-adoption-at-poster-pos).)
### Real-Life Examples of MEs
**Mask Supply Microenterprise.** During the COVID-19 pandemic, a small group of Haier employees recognized a critical shortage of protective masks. They quickly formed an ME to source raw materials, organize production, and distribute masks at scale. While it emerged to solve a specific crisis, it evolved to manage the entire supply chain for the product line, leveraging external suppliers and digital tools for smart contracting.
**Smart Home Appliance Microenterprise.** One of Haier's flagship MEs focuses on the development of integrated smart home solutions. This unit designs, produces, and continuously refines products like refrigerators, washing machines, and air conditioners by directly engaging with customers. Its work spans the entire value chain — from R&D and manufacturing to marketing and service — and it often collaborates with other MEs within an EMC to address complex user scenarios.
**GE Appliances Microenterprise (global adaptation example).** Following Haier's acquisition of GE Appliances, parts of the U.S. business were reorganized into autonomous micro-enterprises. Each ME targets a distinct product line (for example, air conditioners or washing machines) and is empowered to handle everything from product innovation to market launch, tailoring solutions to local customer needs. The structure has allowed the unit to operate with startup-like agility while contributing to overall brand performance.
### Mapping Haier's Org Design with Org Topologies
The Org Topologies map offers a visual aid to make sense of org design, beyond frameworks and ambiguous terminology.
The horizontal axis represents the **[Scope of Skills Mandate](/post/teams-and-scope-of-skills-mandate)**: the levels of skill composition that work units are allowed to apply doing certain work — from Functional, to End-to-End, and even Expanding beyond that.
The vertical axis represents the **Scope of Work Mandate**: the levels of work that units are expected to perform — from the lowest Task level, to Partial, and even Whole Business.
**Below are the assessments of the sample value-creating units of Haier's RDHY model.**
**Mask Supply Microenterprise**
- **Horizontal:** Expanding — although this unit initially formed with a functional/multi-skill base to address a crisis, it rapidly integrated external partners and digital contracting, continuously acquiring new capabilities.
- **Vertical:** The unit is responsible for a specific product line (protective masks) and manages a substantial portion of the supply chain without covering a fully diversified business — Partial-Business Focus.
**Smart Home Appliance Microenterprise**
- **Horizontal:** This flagship unit covers the entire value chain (from R&D and manufacturing to marketing and service), operating independently to deliver complete End-to-End smart home solutions.
- **Vertical:** It functions as an independent profit-and-loss center with Partial-Business Focus, managing a complete business segment that delivers end-to-end value to customers within Haier's broader product landscape.
**GE Appliances Microenterprise**
- **Horizontal:** Following Haier's acquisition, this unit was reorganized to handle an entire product line with full End-to-End autonomy, mirroring a startup-like approach.
- **Vertical:** Structured as a standalone profit center responsible for delivering a complete business solution in its segment — Partial-Business. Each unit is dedicated to a distinct product line (for example, air conditioners or washing machines) and is empowered to manage everything from product innovation to market launch.
The visual representation of the assessment:
**Now let's assess the supporting shared services and platforms.**
- **Horizontal:** Typically mapped between the Multi-Skill and Expanding levels — they are capable of building internal service platforms. We don't have the exact details of their composition or dependencies on other units, so we assume they are mostly complete units.
- **Vertical:** Positioned in the Task Focus to Capabilities Focus range. Their responsibility is narrowly defined — manage critical support tasks and provide operational capabilities. They do not handle complete business outcomes; they ensure that processes and resources are in place for the MEs and EMCs to function efficiently.
On the map:
We did not assess Ecosystem Micro-Communities (as clusters of MEs) because our focus is on fine-grained work units. Evaluating larger groups, such as ecosystems or business divisions, does not accurately reflect workers' mandates and usually creates a misleading picture.
## 5. Studying Org Designs of DSO
### Core Principles of DSO
**1. Mission-driven value creation.** Bayer is shifting the focus from traditional quarterly KPIs to **outcomes aligned with its long-term mission** — "Health for all, Hunger for none." Decisions and rewards are now tied directly to how well teams create real, tangible value for customers.
**2. Network of autonomous, cross-functional teams.** Instead of a rigid, top-down hierarchy, Bayer is restructuring into a "flat army" of **multidisciplinary, self-governing teams** (often called "squads"). These teams are empowered to make decisions independently, drawing on diverse skills that span functions such as R&D, marketing, and supply chain management. The decentralized model encourages faster, more informed decisions at the point of customer contact.
**3. Shared ownership and empowerment.** DSO replaces conventional management control with shared ownership. Frontline employees — from field sales reps to technical advisors — are given real **decision-making authority and held accountable for outcomes**. Their performance and compensation become directly linked to the value they deliver to customers, fostering a strong entrepreneurial spirit across the organization.
### Work Units of DSO
Bayer's DSO reconfigures the organization into several types of work units that work both autonomously and collaboratively. Although detailed internal information is not fully disclosed publicly, industry reports and management insights suggest the new structure includes the following key units:
1. **Agile squads.** Small, cross-functional teams (typically 5–15 members) composed of employees from various disciplines — R&D, marketing, sales, supply chain — who are empowered to make quick, autonomous decisions. Squads execute on specific projects or market opportunities and are oriented toward rapid innovation and customer responsiveness.
2. **Cross-functional cells.** In certain strategic areas, Bayer has set up specialized cells that bring together experts from multiple functions to tackle complex, integrated challenges. These cells often work on end-to-end value creation projects, such as new product development or digital transformation initiatives, ensuring every aspect from conception to market delivery is coordinated.
3. **Centralized support platforms.** Although the aim is decentralization, Bayer maintains certain central service units that provide standardized functions and services (IT, HR, procurement, finance) underpinning the agile squads. These platforms support the squads by delivering standardized tools, resources, and process frameworks that enable faster decision-making and smoother inter-team collaboration. Rather than engaging directly in market-facing innovation, they streamline operations, reduce overhead, and enable faster decisions by automating routine tasks and ensuring consistent processes across the organization.
4. **Integration and coordination forums.** These forums — regular "scrum-of-scrums" meetings, digital collaboration platforms, designated liaison roles — exist to synchronize the work of Bayer's agile squads. They facilitate the sharing of progress, resolution of inter-squad dependencies, and alignment of outputs with overall corporate strategy. They are the glue connecting autonomous teams while ensuring collective efforts drive toward shared business outcomes.
Each of these work units contributes to the overall DSO approach by combining decentralized autonomy with the mechanisms for coordination and shared value creation. This blend of independence and interdependence is central to Bayer's effort to transform into a more responsive and innovative organization in today's fast-paced market environment.
### Disclaimer
There is much less information publicly available on DSO compared to RDHY. For one, DSO is much younger. Secondly, its power is yet to be seen. Lastly, all the information we are basing our assessment on has been pushed out by Bayer's marketing itself, which is likely the best-case scenario plus some early, hard wins.
So, we hardly know anything about the model's downsides or how broadly the model has been adopted in the enterprise.
Yet, even without quantitative accuracy, we believe our analysis can be useful to see the potential of the DSO model — not its particular implementation at Bayer, which is yet to be studied thoroughly in the years to come.
In any case, DSO is by far the boldest change model that we know of in the pharma and chemical industry. If it proves successful, we will see it spread across the industry. Then we will get more data and insights to perform a more thorough study.
### Real-Life Examples of Squads
**Bayer Crop Science Squad (Southern Iowa).** Led by Barry Jacobson in Bayer Crop Science, this squad is composed of field sales representatives, technical agronomists, and customer business advisors. The team rapidly develops proposals based on direct interactions with farmers and local ag retailers. They identify specific challenges in the field, collaboratively design solutions, and implement them without the delays of traditional approval hierarchies. Their work has led to faster decision-making and improved responsiveness to market needs, directly aligning with Bayer's push for frontline empowerment.
**Bayer Italian Innovation Squad (healthcare/pharma).** In Bayer's European operations, an agile squad was formed to address a pressing healthcare challenge. The team — drawing talent from R&D, design, and operations — collaborated to develop a tool designed to make injections easier for hemophiliac patients. By rapidly iterating their solution over a period of just 2–3 months, the squad demonstrated high responsiveness and creativity. Their cross-functional collaboration allowed them to innovate swiftly while directly addressing user pain points — a critical aspect of Bayer's transformation.
**Bayer Global Design Teams.** Bayer has instituted around 70 design teams globally, which operate as agile work units responsible for redesigning key corporate processes — from supply chain management to digital transformation initiatives. These teams work cross-functionally to reengineer and optimize processes across the organization. Their efforts are critical for aligning disparate parts of the business under the new DSO model, ensuring that innovation and efficiency improvements are integrated throughout Bayer's operations.
### Mapping Bayer's Org Design with Org Topologies
**Similar to Haier's assessments above, below are the Org Topologies mappings for Bayer's sample value-creating units.**
**Bayer Crop Science Squad**
- **Horizontal:** This cross-functional Multi-Skill squad (field sales reps, technical agronomists, customer advisors) combines diverse expertise to develop and execute market-specific solutions.
- **Vertical:** Focused on a specific segment within the crop science division (Partial-Business Focus), delivering targeted outcomes rather than managing an entire business.
**Bayer Italian Innovation Squad**
- **Horizontal:** This agile squad — drawing talent from R&D, design, and operations — was able to take a healthcare innovation (a tool for easier injections) from concept to market in 2–3 months, delivering a complete End-to-End solution.
- **Vertical:** The mandate is centered on a specific innovation project within the healthcare/pharma segment (Partial-Business) rather than an entire business vertical.
**Bayer Global Design Teams**
- **Horizontal:** Composed of multidisciplinary experts, these teams work on comprehensive process redesign and digital transformation, integrating a wide array of skills to deliver full solutions (End-to-End).
- **Vertical:** Their primary focus is on enhancing and optimizing operational processes (e.g., supply chain, digital workflows) rather than managing a complete business line — assessed as Capabilities Focus.
The visual representation:
**Below is the Org Topologies mapping of the sample supporting units of Bayer.**
**Centralized support platforms**
- **Horizontal:** These platforms support the agile squads by delivering standardized tools, resources, and process frameworks that enable faster decision-making and smoother inter-team collaboration. That spans the whole range from Functional to End-to-End.
- **Vertical:** Placed in the Task Focus to Capabilities Focus range. Their work mandate is narrowly defined — they are responsible for specific support tasks or developing certain operational capabilities, not for managing a complete business or customer value chain.
**Integration and coordination forums**
- These are merely events and virtual teams, so we won't assess them.
And on the map:
## 6. Comparing and Contrasting the Two Models
Both Haier's micro-enterprises (MEs) and Bayer's agile squads are advanced work units — but they excel in different dimensions of organizational transformation.
**Haier's micro-enterprises (MEs).** These units are highly advanced in terms of decentralization and entrepreneurial empowerment. Each ME functions as an independent profit-and-loss center with full decision-making authority and direct customer engagement. Their structure not only dissolves traditional hierarchical boundaries but also integrates deeply into larger Ecosystem Micro-Communities (EMCs), enabling a near-seamless alignment between employee incentives and user value creation. This radical shift — where nearly all operating staff are treated as mini-entrepreneurs — is a breakthrough in dismantling bureaucracy and fostering sustained innovation.
**Bayer's agile squads.** Bayer's squads are advanced in adopting agile, cross-functional collaboration within a traditionally hierarchical, large multinational context. These squads (typically 5–15 members) are empowered to work rapidly and iteratively, leveraging digital collaboration tools to shorten decision cycles and respond to market demands quickly. Although they enjoy significant autonomy on project-specific tasks, they still operate within a framework that includes centralized support functions for strategic alignment and resource sharing. This approach excels in creating rapid, flexible responses but may not be as radically decentralized as Haier's MEs.
Both models rely on **shared supporting units** that enable the work units by offering standardized commodity services and platforms.
### Managing Interdependency with Digital Contracting and Agile Coordination
MEs and squads can do a lot independently, yet they are interdependent and should not function as broader silos. They have to find ways to collaborate with each other. Here, Haier and Bayer apply different strategies.
**Digital contracting** is a cornerstone of Haier's RDHY, enabling its vast network of MEs to function as an integrated, agile ecosystem. Rather than relying on traditional, paper-based agreements, Haier employs digital contracting through platforms like COSMOPlat and the Workbench. These systems utilize **smart contracts and blockchain** technology to automate and secure agreements between MEs and their external partners.
When an ME issues a **digital tender** for a service or resource, competing units bid for the work; once agreed upon, the contract is automatically executed and recorded on a blockchain. This streamlines negotiations, minimizes errors, and ensures payment is directly linked to the value created for customers — embodying Haier's "paid by users" principle. In essence, while each ME operates with significant autonomy, digital contracting ensures they remain interdependent, sharing resources and expertise across EMCs.
In contrast, Bayer's DSO — which effectively operates as a [Delivery Topology pushing toward Adaptive](/post/three-ecosystems) — addresses alignment and coordination among its agile squads through a set of complementary **digital and procedural tools**.
To manage dependencies across squads, Bayer employs **agile ceremonies** such as "scrum-of-scrums," where representatives from different squads meet regularly to synchronize efforts, resolve conflicts, and ensure alignment with the company's broader strategy.
Additionally, Bayer relies on **digital collaboration platforms** that provide real-time transparency through shared dashboards, performance metrics, and project updates. Dedicated liaison roles further facilitate coordination by managing inter-squad dependencies, ensuring overlapping resources and joint initiatives are effectively integrated.
In summary: Haier's digital contracting transforms micro-enterprises into semi-independent, entrepreneurial nodes that operate through automated, transparent agreements — ensuring that autonomy is balanced with ecosystem collaboration. Bayer's DSO emphasizes agile alignment among its squads through structured coordination mechanisms, digital tools, and dedicated liaison roles. Both approaches aim to dismantle traditional hierarchies, yet Haier's model focuses on creating a tightly integrated digital marketplace for value exchange, while Bayer's strategy is centered on aligning and coordinating autonomous teams within a larger corporate framework.
## 7. Putting It All Together
> Haier's Rendanheyi, initiated around 2005 and refined by 2012, dismantles traditional hierarchies by reorganizing most employees into small, autonomous micro-enterprises that operate within an interconnected ecosystem. It decentralizes the organization into MEs that are integrated into a broader ecosystem through digital contracting and Ecosystem Micro-Communities.
On the horizontal axis (scope of skills mandate), these units are positioned as End-to-End to Expanding — they begin as end-to-end units but continuously acquire new skills and external capabilities via digital tools.
Vertically (scope of work mandate), some MEs (e.g., Smart Home Appliance or GE Appliances units) are mapped as Partial-Business because they manage the full value chain for a given product line, while others — like the Mask Supply Microenterprise — operate at a Partial-Business level, focusing on a specific product segment with some dependency on shared services.
> In contrast, Bayer's Dynamic Shared Ownership — an ongoing roll-out started in 2018 — restructures the organization into agile, cross-functional squads that work rapidly on specific projects. Bayer's squads, supported by centralized platforms and coordination forums, are generally positioned as Multi-Skill units with a Partial-Business mandate.
On the horizontal axis, these squads generally fall within the Multi-Skill to End-to-End range, reflecting their integration of diverse expertise to rapidly deliver innovations and adapt to market feedback.
Vertically, the squads are mostly positioned in the Capabilities to Partial-Business zone, as they are tasked with delivering specific projects or capabilities rather than running an entire, standalone business. Bayer reinforces alignment and coordination through centralized support platforms and integration forums that help manage interdependencies among squads.
This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous.
---
# Teams and Scope of Skills Mandate
**Date:** 2025-01-15 · **Reading time:** 7 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/teams-and-scope-of-skills-mandate
**TL;DR:** The difference between functional and multi-function teams is not individual skills — it is the team's organizational mandate. What scope of customer problems is the team authorized to solve end-to-end, without handoffs? That mandate is an org design decision, not a staffing one.
The key question this article addresses is:
> How do we tell if a team is truly multi-function or just functional, and why does it matter for delivering end-to-end value?
There has been a high-volume discussion exploring this and skill-related questions in our [Slack community](https://www.orgtopologies.com/community) with great input from Aimé Flemm, Steve Alexander, Sven Müller, and Zoltán Dósa. I decided to summarize key discoveries in this article.
**TL;DR**: Functional teams specialize in one domain—even if they have multiple subskills—while multi-function teams span multiple domains, letting them deliver end-to-end value without handoffs. The big difference is the _team's mandate_ (an org design decision), which shapes how quickly and efficiently they can respond to customer needs.
## Embracing the Spectrum: From Functional to Multi-Function Teams (Updated)
Organizations often struggle to explain the difference between **functional**(“single-function”) and **multi-function**(or “multi-skilled”) teams. On the surface, one might assume “functional” means a person can only do a narrow set of tasks, whereas “multi-function” means having a broad skill set. But what if individuals in a so-called “functional” team already use multiple subskills—like an Ops engineer proficient in networking, security, and disk management?
The crux is not whether a person can do multiple things. Rather, **Org Topologies**emphasizes the **organizational mandate**: what scope of customer problems is the team authorized and expected to solve, _end to end_, without formal handoffs?
## Functional vs. Multi-Function: The Scope of Mandate
In **functional**teams, members share a single overarching role or domain—e.g., front-end development, Ops, product management, or marketing.
* Yes, they might each have “subskills” in that domain (a front-end developer who knows React, Angular, CSS, etc.), but they remain in _one function_.
* To deliver new features involving other domains, they typically coordinate with separate teams (e.g., a back-end or product design group).
A **multi-function**team, by contrast, includes roles spanning multiple domains under one shared purpose—e.g., front-end, back-end, product management, UX design, marketing, and sometimes operations (DevOps).
* They can handle various tasks, from discovering customer needs to coding, testing, and promoting a feature.
* They reduce external handoffs because they already have the necessary expertise in-house.
**Why use “functional” instead of “single-skilled”?**Because “single-skilled” suggests someone only knows one tool or framework, which is rarely true. In reality, it’s about how the organization structures the team’s mandate, not the total number of frameworks each individual can handle.
## Why This Matters
Below is a quick summary illustrating why the difference between **functional**and **multi-function**matters for delivering value:
* **If a functional unit tries to build a truly new product feature and ensure customer adoption,**it typically lacks the product management, design, and marketing expertise to guarantee it’s desirable, user-friendly, and effectively promoted. They must hand off tasks to other functional teams or departments.
* **On the other hand, a multi-function team**includes (or has access to) those complementary skills—so they can easily iterate, test with real users, market, and refine solutions without waiting in line for another team. This often leads to faster feedback loops and more holistic product outcomes.
When the time to market and adaptation to change is critical, these distinctions can become make-or-break. The [whole product focus team](/post/whole-product-focus-team) — capable of working on any feature end-to-end — is the natural endpoint of this evolution. A purely functional structure can bottleneck innovation if teams struggle to collaborate across organizational silos. By contrast, a well-supported multi-function team can operate like a mini-startup within the enterprise: they discover, design, develop, and launch features under one roof.
## An “Outside-In” Example
One simple way to explain this concept to leadership is to focus on **what the customer can expect**from a team rather than the internal skill sets:
* **Functional Team**: If the team can solve only one type of problem—for instance, handling front-end UI—then it’s functional (or single-function). Even though each member might know multiple frameworks, all of those subskills remain under “front-end work.” If the customer also needs changes to the back-end or advanced user research, that functional team has to reach outside for help.
* **Multi-Function Team**: If the team can solve a wide variety of problems across the stack—front-end, back-end, testing, infrastructure, UX—then it’s multi-function. They have the authority and ability to manage all key tasks end to end, meaning fewer handoffs and faster delivery.
From an **executive viewpoint**, this outside-in framing underscores how quickly and effectively a team can satisfy customers. A multi-function team can deliver a “one-stop shop” experience, improving responsiveness and overall accountability.
## It’s About Organizational Design—Not Just Skills
A major misconception arises when a functional team argues: “We’re already multi-skilled because we combine various tasks within our domain.” For instance, a front-end specialist might also do design tweaks and user testing. In reality, if the team’s **formal organizational mandate**remains the front-end, they’re still considered “functional.” They have multiple subskills within one primary function but must hand off anything beyond that function.
This distinction highlights an **environmental**aspect: even if individuals possess overlapping abilities, does the **organization**encourage them to apply those abilities collaboratively, or does it enforce silos through strict role definitions? Multi-function teams need **organizational support**—clear goals, decision-making authority, and a culture that fosters collaboration.
## Less Handoff, More Ownership
Imagine you have:
* **Team A**: front-end
* **Team B**: back-end
* **Team C**: design and user research
In a functional setup, a new feature request might bounce between these specialized teams, each handling their part. This can work if requirements are stable but slow iteration and discovery if the feature’s final shape is uncertain.
In a **multi-function setup**, a cross-domain team includes front-end, back-end, and design expertise. They can talk to the customer, sketch a design, code it, and test reactions without waiting for separate teams. They have **end-to-end ownership**, boosting adaptability and speed of learning.
## Addressing Executive Concerns
When explaining Org Topologies to executives, focus on:
1. **Reduced coordination overhead**: Multi-function teams minimize handoffs by integrating key roles in one group.
2. **Faster innovation**: They can swiftly adapt to user feedback because discovery, design, and delivery happen together.
3. **Contextual choices**: Functional teams still excel in stable or compliance-heavy environments where deep specialization is needed. If rapid learning is crucial, multi-function teams often thrive.
Forming multi-function teams requires a supportive environment: leadership support, psychologically safe collaboration, and well-defined missions unifying diverse roles. It’s not enough to place cross-domain experts in the same Slack channel—there must be a shared commitment to work as a single unit. Career structures matter here too — [tailwind career paths](/post/tailwind-career-paths) reward breadth rather than punishing it.
## Evolution and “Scope of Skills Mandate”
Teams can **expand**their scope over time, gradually incorporating product discovery, UX, or marketing capabilities. A front-end team might learn how to validate user needs. An infrastructure group might add DevOps or QA tasks to reduce external dependencies. As they grow their **scope of skills mandate**, they move along the spectrum toward multi-functionality.
This is why **functional vs. multi-function**isn’t strictly binary. It’s a continuum anchored by how many domains a single team is empowered to address. Org Topologies helps visualize these evolutions and clarifies how structural decisions align with organizational goals.
## My Key Takeaways
* **Functional (single-function) teams**specialize in one domain. Members often have multiple subskills, but their **mandate**is still narrow; they rely on handoffs to cover other domains.
* **Multi-function (multi-skilled) teams**span multiple domains—front-end, back-end, design, product, and marketing—so they can build and deliver end-to-end solutions in-house.
**Why This Matters**:
* When tasked with new features and adoption, functional teams may lack product, design, or marketing expertise. They must coordinate externally.
* Multi-function teams have these skills under one roof, enabling quicker iteration, testing, marketing, and refinement.
**An “Outside-In” Example**:
* A team that can solve only one category of problems (e.g., front-end UI) is functional.
* A team that can tackle multiple parts of the stack (front-end, back-end, infra, etc.) is multi-function.
* Organizational **culture**and **authority**matter. Even if individuals have overlapping skill sets, they need an environment and mandate that allows them to perform cross-functional work seamlessly.
Ultimately, choosing between functional and multi-function structures depends on your **strategic goals**and related **market context**.
Functional teams can be ideal in stable, specialized settings, while multi-function teams shine in fast-evolving markets where quick learning and customer responsiveness are essential. In the age of AI, the economics tip further toward broad mandates — [multi-learning](/post/multi-learning-org-design-pattern-ai) becomes viable when AI collapses the cost of acquiring adjacent skills. Understanding the difference—focusing on what the team can deliver _end to end_—is key to designing modern, adaptive organizations.
---
# Tailwind Career Paths
**Date:** 2024-12-17 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/tailwind-career-paths
**TL;DR:** Traditional career ladders reward narrow specialization and punish breadth. Tailwind career paths flip this: broad roles like Product Developer, peer-driven promotions, back-me-up skill tables, and mentorship baked into the structure. Y Soft's manager-less R&D shows the model works — simplicity and transparency over HR theater.
In today's rapidly evolving technological landscape, organizations face increasing pressure to build adaptive, multi-skilled teams.
Traditional career paths, however, often act as barriers rather than enablers, rewarding narrow specialization and promoting hierarchical roles as the only path to success. In the age of AI, this rigidity is especially dangerous — [narrow-mandate roles are the first to be displaced](/post/ai-replaces-tasks-not-people). For those attempting to adopt frameworks like [**Large-Scale Scrum (LeSS)**](https://less.works/) or operate in dynamic environments, these outdated systems quickly become obstacles. Instead, organizations need **"tailwind career paths"** — career models that align individual growth with organizational needs, fostering flexibility, technical excellence, and mentorship without sacrificing clarity or fairness.
Tailwind career paths reject the outdated notion that advancement requires climbing a managerial ladder. Instead, they create open landscapes for growth — where individuals deepen their expertise, broaden their contributions, and help others succeed. Organizations can foster cultures where technical excellence, collaboration, and mentorship thrive by focusing on multi-skilling, shared goals, and flexible structures. Real-world examples like Y Soft show that simplicity and transparency are key to success. Whether through peer-driven promotions, skill-mapping tools, or continuous mentorship, tailwind career paths create environments where employees feel empowered, valued, and inspired to grow.
> At the heart of a tailwind career path lies simplicity. Rather than fragmenting roles into granular job titles — front-end developer, back-end specialist, or UX expert — organizations can adopt broad, flexible roles.
For instance, Y Soft offers a compelling example of a streamlined and empowering career path within a [**manager-less R&D environment**](https://www.ysoft.com/careers/blog/managerless-rnd-promoting-people). Roles are kept simple, progressing through clear levels — *Junior → Intermediate → Senior → Principal* — while promotions are employee-driven, transparent, and feedback-oriented. This eliminates artificial managerial hierarchies and empowers individuals to take ownership of their growth.
## Core principles
For a tailwind career path to succeed, [multi-learning](/post/multi-learning-200-years-wrong-model) must be at its core. Teams that embrace skill mobility — where employees develop expertise in multiple areas — are far more resilient and adaptable. Implementing such frameworks may seem daunting, but organizations can follow core principles to design effective tailwind career paths:
- **Communicate the Vision Continuously**: Leadership must clearly articulate multi-skilling as a priority. Regularly reinforce this message through team events, company updates, and sprint reviews to create alignment and enthusiasm.
- **Simplify Roles and Levels**: Replace fragmented job titles with a broad role like *Product Developer*. Establish clear progression levels that emphasize skill depth, breadth, and influence — moving from team-level contributions to organizational leadership.
- **Make Promotions Transparent and Peer-Driven**: Implement a process where employees initiate promotions through self-evaluation and peer feedback, with reviews conducted by structured committees. At Y Soft, this ensures fairness while keeping employees accountable for their growth.
- **Encourage Multi-Skilling Through Mentorship**: Use tools like the *back-me-up table* to identify gaps in skills coverage. Every specialty should aim for a specialist, a backup, and an apprentice. Pairing specialists with apprentices fosters mentorship while broadening organizational knowledge.
- **Prioritize Team-Based Goals Over Individual Metrics**: Shift focus from individual targets to team-based goals. Shared performance objectives promote collaboration and reduce unhealthy competition. Celebrate achievements in retrospectives and sprint reviews to reinforce this approach.
- **Support Learning with Tools and Enablers**: Provide access to resources like AI tools (e.g., Cursor) to help employees navigate new codebases and reduce the friction of learning unfamiliar domains.
- **Facilitate Peer Learning and External Exposure**: Encourage employees to connect with peers from companies like Y Soft, where innovative approaches are already in place. These exchanges can provide invaluable insights and inspire solutions tailored to the organization's needs.
- **Separate Compensation from Career Levels Initially**: Avoid tying promotions to salary changes too early. Allow employees to experiment with the new model for at least a year before aligning it with formal HR compensation structures.
- **Try Gamification and Avoid Over-Gamifying**: Gamification can bring playfulness and ease when trying new ideas. It can help incentivize learning. So, it is a good idea to try some simple gamification techniques. It is important not to do more than necessary as gamification comes with risks, such as employees "gaming the system" rather than focusing on meaningful progress and intrinsic rewards — growth, mentorship, and collaboration.
These principles create a framework that aligns personal growth with team and organizational success. By prioritizing simplicity, transparency, and adaptability, companies can replace headwinds with systems that propel individuals forward.
## Encouraging experimentation
Encouraging experimentation during the early stages of implementing a career framework is equally important. By initially decoupling promotions from salary adjustments, organizations can allow employees to explore and adapt without fear of immediate consequences. Celebrating progress becomes a cultural cornerstone: sprint reviews, retrospectives, and peer recognition provide opportunities to highlight individuals who step outside their comfort zones. Over time, these celebrations reinforce the value of multi-skilling and cross-team contributions.
[Allan Cyment](https://www.linkedin.com/in/acyment/) shared an experiment with a "back-me-up" table used at one of his clients: a simple yet powerful tool for facilitating this growth. It allows teams to map out their skills, identify gaps, and ensure each area has a specialist, a backup, and an apprentice. Over time, employees broaden their expertise naturally, often through pairing or mob programming. Such practices encourage knowledge-sharing and mentorship, ensuring the team remains robust and flexible even as demands change.
Companies like [Y Soft](https://www.ysoft.com/) demonstrate that effective career paths need not be complicated. Their transparent promotion process removes barriers, while a clear structure enables individuals to understand expectations and chart their growth. Promotions are not dictated by managers but driven by employees themselves through peer-reviewed evaluations. Salaries are adjusted based on value and contributions rather than rigid timelines or hierarchies. This approach builds trust while aligning individual motivation with organizational goals.
The long-term success of tailwind career paths depends on clear communication and leadership commitment. Leaders must articulate the importance of multi-skilling as an organizational priority, ensuring employees understand how it benefits their personal growth and the company's goals.
For companies ready to embrace this model, the payoff is clear: resilient, innovative, and adaptable teams capable of navigating challenges and driving sustained success. The structural logic maps directly to the [scope of skills mandate](/post/teams-and-scope-of-skills-mandate) — the broader the mandate a team is authorized to hold, the less it depends on handoffs, coordination, and other people's calendars.
---
# Elevating Katas™ for Organizational Agility
**Date:** 2024-12-17 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevating-katas-structured-routines
**TL;DR:** Elevating Katas are repeatable routines that shift an organization toward higher adaptivity — not one-off workshops or transformation programs. Each kata targets a specific element: governance, roles, events, artifacts. Practiced consistently, they turn strategic intent into behavioral change and make culture evolve from action, not mandates.
“Kata” was popularized in management via Toyota, implying a disciplined and repeating pattern for improving. Each Elevating Kata is a repeatable, structured pattern or routine introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Each Kata targets a specific org design element (structure, policy, process, …) and aims to shift in ways that provide incremental and scalable improvements.
> When we speak of Elevating Katas we mean specific interventions or methods that guide an organization from its current level of maturity and flow towards more effective, systemic, and higher-order modes of working.
Each kata focuses on a particular area (such as governance, practices, roles, events, or artifacts) and is designed to shift mindsets, structures, or processes in a way that provides incremental, scalable benefits over time. By repeatedly practicing an Elevating Kata, organizations internalize more adaptive behaviors, enhance their management capabilities, and ultimately create a more responsive and learning-oriented culture.
**Key characteristics of Elevating Katas include:**
* **Purposeful Routine:**They are not one-off changes but ongoing practices that teams perform regularly.
* **Incremental Improvement:**Each iteration builds on the last, gradually increasing proficiency and confidence.
* **Systems-Level Focus:**They often address underlying organizational design elements—like governance models, role definitions, and multi-team events—to improve end-to-end product delivery.
* **Empowering Teams and Leaders:**By embedding these katas, organizations empower members at all levels to take ownership, adapt quickly, and focus on value.
* **Cultural Shift:**Over time, Elevating Katas influence not just processes, but also the culture, encouraging transparency, continuous learning, and a broader understanding of “product” and customer outcomes.
In short, Elevating Katas are deliberate, repeatable, systemic, and _strategic_ improvement routines that help organizations lift their practices to a higher, more impactful level.
## "STRATEGIC" IS THE KEY HERE
Below is the [method](https://www.orgtopologies.com/made-method) we've crystallized over the year that leads the way to **strategic org design**:
"Change MADE Real" method
You can[learn about the Change MADE Real](https://www.orgtopologies.com/made-method)method and its four steps, as it is essential to understand the MADE method to see the place of Elevating Katas in the landscape of Org Topologies.
Elevating Katas are principles, guidelines, and practices for systemic change. They are vehicles for the MADE method as they drive the _elevation_ of an org ecosystem towards the top right archetype group of the map:
Elevating Katas in the MADE method
Here's how to make sure that the application of Elevating Katas is systemic:
1. **Holistic Focus**The Star Model suggests that changes must work at the system level, not just tweak one element. Elevating Katas, by their nature, aren’t isolated improvements; they target multiple facets—governance, roles, events, practices, and artifacts—ensuring shifts in behavior permeate through structures, processes, and ultimately how people collaborate.
2. **Aligning Structures and Processes With Strategy**For an organization’s strategy to truly drive capabilities, the operational design must support it. Elevating Katas introduce routines (such as multi-team Product Backlog Refinement or vertical slicing of work) that bring strategic goals into daily practice. This ongoing, repeated alignment of work routines with strategic direction ensures that structure and processes consistently support the desired capabilities and outcomes.
3. **Enabling People and Role Evolution**
The Star Model emphasizes that people and their roles must be in sync with overall organizational design. Elevating Katas like “Elevate Product Ownership” push beyond conventional role definitions, helping individuals expand their influence and understanding. Over time, these repeated learning loops shape new competencies, reinforce role clarity, and ensure that teams operate in harmony with new structures and strategic objectives.
4. **Reinforcing Desired Behaviors and Culture**“Culture programs” on their own often fail because they focus on abstract values rather than tangible changes in working patterns. Elevating Katas bridge the gap between desired cultural traits (like collaboration, customer-centricity, or continuous improvement) and everyday actions. By practicing these Katas systemically, the organization hardwires new behaviors into its fabric, leading to a naturally evolving culture—rather than attempting top-down cultural mandates.
5. **Rewarding Continuous Improvement**
Because Katas are iterative and repeatable, they create a continuous feedback loop. Over time, as these new practices become second nature, the organization inherently “rewards” them through improved outcomes—faster cycle times, better product-market fit, and more engaged teams. This closes the loop between the “Rewards” element of the Star Model and the actual behaviors that drive performance and cultural evolution.
Elevating Katas serve as the micro-level routines that continuously align the various elements of organizational design. They turn strategic intent into actionable steps, align structures and processes, enhance roles and competencies, and reinforce behaviors—thereby making the entire system function cohesively, just as the Star Model prescribes.
## EXAMPLES OF ELEVATING KATAS
Elevating Katas are not one-off workshops or temporary campaigns. Instead, they are ongoing, disciplined practices that embed a new way of thinking and acting into the organization’s fabric. Each kata focuses on a particular dimension of how work is done—governance, roles, events, practices, or artifacts—offering a continuous improvement loop. By systematically revisiting and refining these routines, teams learn incrementally and develop deeper capabilities.
Below are some examples to give you a taste of what the Katas are.
### Kata: **Expand the “Product” Definition**
Teams regularly revisit and broaden their view of the “product” to include not just a single application or service, but the entire ecosystem of customer experience, business processes, and complementary offerings.
### Kata: **Elevate Product Ownership**
Product owners move beyond backlog management to become strategic influencers, actively connecting business goals with delivery teams. By consistently engaging in strategic alignment sessions and working closely with customers and stakeholders, product owners gradually learn to prioritize work that delivers the highest impact. [Read more](/post/elevate-product-management-for-business-agility).
#### Kata: **Hold Multi-Team Product Backlog Refinement (PBR)**
Multiple teams that share a product domain collaborate in joint refinement sessions. Practicing multi-team PBR regularly ensures alignment, surfaces dependencies early, and harmonizes priorities across different delivery groups. [Read more](/post/cross-team-collaboration-multi-team-pbr).
### Kata: **Slice Work Vertically**
Rather than building features layer by layer (e.g., back-end first, then front-end), teams deliver thin, vertical slices of functionality that span the user interface, business logic, and data layer. Repeatedly practicing vertical slicing enables the team to deliver incremental value faster and reduce the risk of late integration issues.
### Kata: **Merge Product Backlogs**
Instead of each team maintaining its own isolated backlog, organizations merge them into a single, shared product backlog. This practice, repeated regularly, leads to unified prioritization and improved transparency, ensuring that all teams work toward the same strategic objectives.
### Kata: **Define Shared "Done"**
Teams adopt and periodically refine a common set of quality criteria that must be met before work is considered complete. Repeated application of this kata drives consistent quality standards and reliability across teams. Read more about [DoD in LeSS](https://less.works/less/framework/definition-of-done).
### Kata: **Self-Select with Open Space and FAST**
One way to sustain a broader work mandate is to allow teams and individuals within the Team-of-Teams to self-select work and their peers with the necessary skills to create value together. Read more about [FAST](https://www.fastagile.io/), which stands for "Fluid Adaptive Scaling Technology". To facilitate self-selection at scale, this method combines 1) outcome-based product management, 2) open space technology, and 3) dynamic re-teaming.
### Kata: **Implement Beyond Budgeting**
Organizations abandon rigid, annual budgeting cycles in favor of rolling forecasts, dynamic resource allocation, and more decentralized decision-making. Over time, this kata helps the organization become more responsive, adjusting investments as market conditions evolve. [Read more on Beyond Budgeting](https://bogsnesadvisory.com/).
### Kata: **Lead with OBEYA Strategically**
Borrowed from lean management, “Obeya” involves creating a dedicated space (physical or virtual) where decision-makers convene regularly. By visually displaying strategic metrics, progress indicators, and customer feedback, leaders can make more informed, rapid decisions. Read more about [Leading with Obeya](https://leadingwithobeya.com/).
### Katas: **Design Tailwind Career Paths**
Instead of promoting through narrow, hierarchical ladders, individuals advance through capability growth and learning breadth. This kata involves regularly identifying new skill areas, setting capability-building goals, and providing supportive conditions—coaching, resources, and challenging projects—so individuals continuously gain new competencies. Over time, by repeating this practice, organizations cultivate multi-skilled, adaptable professionals whose career “tailwinds” come from developing a broad, flexible skill set aligned with strategic needs rather than climbing a predefined ladder. [Read more](/post/tailwind-career-paths).
### Kata: **Apply AI Strategically**
Any management approach that doesn’t include AI as a central part of the future workforce, is of the past. We are rapidly entering a world of AI agents and humanoid robots playing a role at work and home.Evolving rightward on the horizontal axis to broader skills mandate will become ever easier due to AI. And likewise upward on the vertical axis to a broader work mandate. So, top-right _Driving_ archetypes will become more feasible. [More on applying AI strategically](/post/elevate-org-with-strategic-ai-adoption).
### Kata: **Measure and Improve Value with EBM**
Org Topologies and Evidence-Based Management are distinct but highly complementary frameworks. **Org Topologies**provides the _“where and how to change”_ from a structural perspective, ensuring the organization’s form enables agility and aligns with its purpose. **EBM**provides the _“whether and why to change”_ from a value perspective, ensuring the organization’s operations remain focused on delivering measurable value and that any change is justified by evidence. [More on OT with EBM](/post/org-topologies-with-evidence-based-management).
## More Katas
We are collecting and documenting Elevating Katas. Browse our [Knowledge Base](https://www.orgtopologies.com/knowledge-base) to learn more.
Toward a Collection of Elevating Katas
## Conclusion
Leaders, rather than micromanaging or launching episodic “transformation programs,” can establish a handful of carefully chosen katas and ensure they are faithfully practiced. Over time, as people develop fluency in these routines, the organization’s agility and resilience increase. This approach to change is subtle but powerful, as it leverages the human capacity to learn by doing. Rather than relying solely on workshops or memos, it uses ritualized action to shape behavior and mindset.
Elevating Katas embody the principle that lasting organizational change arises from systemic coherence and incremental, behavioral shifts. By focusing on daily routines—how teams refine backlogs, how product definitions are broadened, how budgets are allocated, and how product owners engage with strategy—these katas directly influence the elements of Galbraith’s Star Model. The result is a more agile organization, one that continuously aligns its strategy, structure, processes, people, and rewards.
These katas do not offer a magic bullet; they demand patience, consistency, and intentional practice. Yet, this very requirement ensures authenticity. As habits form, culture evolves organically, and the organization’s capacity to learn and adapt deepens. In a world where the only constant is change, Elevating Katas serve as reliable instruments for shaping the future, guiding organizations toward sustained performance, relevance, and growth.
---
# Matrix, Functional, Project, and Product Structures vs. Scrum and LeSS
**Date:** 2024-12-13 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/matrix-functional-project-product-structures
**TL;DR:** Functional, project, and matrix structures all break Scrum in predictable ways: silos, dual reporting, resource-pool teams, disempowered delivery. LeSS addresses this by flattening hierarchy, forming cross-functional feature teams around a broad product definition, and optimizing for value flow over resource efficiency.
Organizational structures define how work, responsibilities, and decision-making are distributed. The four major types are functional, project, matrix, and product (divisional) structures. Each has strengths and weaknesses — especially in software-intensive environments that require agility.
Dysfunctional implementations of Scrum often occur when it is layered on top of outdated matrix or functional structures without addressing organizational design flaws — a pattern we call [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds). Large-Scale Scrum (LeSS) offers an alternative by advocating a product-centric structure optimized for delivering customer value through systems thinking and simplification.
## Organizational Structures and Their Challenges
### Functional Structure
In a functional structure, employees are grouped into departments based on specialized skills (e.g., engineering, marketing, finance).
- **Characteristics:** hierarchical reporting, deep specialization, and siloed work.
- **Strengths:** focus on technical expertise and skill development.
- **Weaknesses:**
- Limited collaboration across functions (silos).
- Delays caused by handoffs and lack of ownership.
- Difficult to adapt to changing priorities.
> Example: Developers write code but depend on a separate QA department for testing, leading to delays and misalignment.
### Project Structure
The project structure organizes work into temporary teams assembled to deliver specific projects. Teams disband once the project concludes.
- **Characteristics:** time-bound goals, project managers leading delivery, and multi-tasking across projects.
- **Strengths:** clear focus on project objectives and flexibility for one-off initiatives.
- **Weaknesses:**
- Team disruptions as employees shift between projects.
- Focus on short-term delivery over long-term sustainability.
- Context-switching reduces productivity.
> Example: A team is formed to build a new product version over six months. Once completed, team members are reassigned to unrelated projects.
### Matrix Structure
Matrix structures combine functional and project-based elements. Employees report to both functional managers and project managers.
- **Characteristics:** dual reporting lines, resource sharing across projects, and high coordination overhead.
- **Strengths:** efficient use of specialized resources and balancing functional expertise with delivery focus.
- **Weaknesses:**
- Conflicting priorities between functional and project managers.
- Increased overhead and delays from coordination.
- Multi-tasking and fragmented focus undermine team productivity.
> Example: A software engineer reports to a functional manager for career development while working on multiple projects under different project managers.
### Product (Divisional) Structure
A product structure, also called a divisional structure, organizes teams around specific products or product lines. Each division operates as a semi-autonomous unit.
- **Characteristics:** cross-functional teams focused on end-to-end delivery for a product.
- **Strengths:**
- Teams own end-to-end features, reducing handoffs and dependencies.
- Improved alignment with customer value and faster adaptability.
- Teams are stable and long-lived, improving efficiency and learning.
- **Weaknesses:**
- Requires significant reorganization to dismantle silos.
- Resistance from functional managers who lose control over specialized teams.
> Example: A cross-functional team focuses on the "shopping cart" product in an e-commerce platform, continuously iterating and improving it.
## Dysfunctional Scrum in Traditional Structures
When Scrum is implemented in functional, project, or matrix structures without addressing systemic design, it often leads to dysfunction:
- **Scrum Teams as Resource Pools:** teams remain specialists working on fragmented components instead of delivering end-to-end features.
- **High Coordination Costs:** dependencies across silos require layers of project management, reducing agility.
- **Lack of Ownership:** teams work on projects with shifting goals rather than focusing on product improvement.
- **Overarching Project Mentality:** Scrum is misused as a delivery framework in long-running projects, reinforcing phase-based workflows.
- **Disempowered Teams:** functional managers or project managers continue to dictate priorities and decisions, undermining team autonomy.
## Large-Scale Scrum (LeSS) as a Product-Centric Alternative
LeSS advocates for a product-centric organizational structure, addressing the limitations of functional, project, and matrix designs. Key aspects include:
**Broad product definition.** LeSS emphasizes defining the product broadly to include all teams working toward delivering customer value. Unlike fragmented project structures, LeSS ensures teams collaborate across the entire product, reducing silos and dependencies.
**Cross-functional feature teams.** LeSS eliminates functional silos by forming long-lived, cross-functional feature teams. These teams are equipped with all skills necessary to deliver end-to-end features, reducing handoffs and ensuring ownership.
**Flattened hierarchy.** LeSS removes matrix reporting lines, eliminating the dual authority of functional and project managers. Managers transition into roles focused on coaching and mentoring teams, not controlling their work.
**Focus on continuous product development.** Unlike project structures, LeSS emphasizes continuous product development over short-term projects. Teams iterate incrementally, delivering potentially shippable product increments each Sprint.
**Simplification through systems thinking.** LeSS simplifies organizational design by optimizing for value flow rather than resource efficiency. This reduces queues, delays, and coordination overhead, improving adaptability and delivery speed.
## Simplifying Org Structures with LeSS
Traditional organizational structures — functional, project, and matrix — were designed for efficiency, predictability, and control. However, in modern software-intensive environments these models create silos, dependencies, and coordination overhead, preventing organizations from delivering value quickly and adaptively. This complexity is further exacerbated when frameworks like Scrum are overlaid onto outdated structures without addressing systemic design issues.
Large-Scale Scrum (LeSS) offers a compelling alternative by advocating for product-centric simplicity.
By leveraging "More with LeSS" principles and focusing on simplifying organizational structures, LeSS enables organizations to optimize for delivering customer value. The seven principles for simplification include:
1. Transitioning from specialist roles to cross-functional teams that collaborate effectively and own end-to-end outcomes.
2. Shifting from resource-thinking to people-thinking, recognizing team members' full potential and creativity.
3. Organizing teams around customer value rather than technical components to enhance alignment and adaptability.
4. Replacing isolated efforts with continuous cross-team cooperation for shared learning and unified goals.
5. Reducing reliance on coordination mechanisms by fostering integration through collaboration.
6. Moving from project-based thinking to long-term product focus, ensuring sustainable value delivery.
7. Consolidating efforts into broad product definitions to streamline processes and maximize impact.
By embracing these principles, LeSS promotes a simpler, flatter, and more adaptive organizational design. This shift eliminates functional silos, minimizes dependencies, and empowers long-lived, cross-functional teams to deliver customer value sustainably and reliably.
Ultimately, transitioning from complex matrixed systems to a simplified product-centric structure requires systemic change and a commitment to learning.
Organizations that adopt LeSS principles gain the ability to respond quickly to change, focus on outcomes, and unlock innovation by reducing complexity and fostering alignment. The [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos) illustrates this transition from component teams to a whole-product focus in practice.
---
# The Myth of Conway's Law
**Date:** 2024-11-28 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/myth-of-conways-law
**TL;DR:** Conway's Law is treated as destiny — your org must mirror your architecture. Twenty years of LeSS adoptions prove otherwise. Cross-team code ownership works and is surprisingly easy once you actually try it. The common interpretation limits thinking; the original paper does not say what people think it says.
*Myth of Conways Law*
A big part of LeSS is to have teams work on entire customer problems, across the product, and that leads to cross-team code ownership (which we refer to as feature teams — what I'd call [whole product focus teams](/post/whole-product-focus-team)). I've been working in cross-team code ownership organisations now for more than 20 years and consider that to be hugely advantageous over mapping teams to part of the system. Of course, there are problems you'll need to figure out, such as code standards, dealing with production issues, regular maintenance upgrade, and more. Most of these problems have multiple known solutions. In fact, I'm always amused how relatively easy it is to have cross-team shared code ownership relative to the amount of arguments people, who never experienced it, have about it.
One of the consistent myths is the common interpretation of "Conways Law." Your organisation and your architecture must map/mirror. In LeSS adoption, this is just not happening, it is not true, not a law. It has been frustrating me for 20 years that people limit their thinking about problems in product development because they "must adhere to Conway's Law". Really, it doesn't have to be like that. If you free your mind from the limitations that Conway's Law gives you then you can find wonderful alternatives to structure product development. For a real example of this, see the [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos) — where component teams became feature teams working across the entire codebase.
The architecture-follows-org argument also fuels premature decisions like [splitting into microservices](/post/microservices-are-technical-debt) — which I argue is technical debt, not architectural progress. In recent LeSS Conference, Craig had a talk about Conway's Law itself and how people interpreted it. He dived into the original paper and point out that the common interpretations are not actually what it says in the original paper. The video of the talk is now online.
---
# No. Not Everything Is A Product
**Date:** 2024-11-17 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/no-not-everything-is-a-product
**TL;DR:** Calling everything a product — value streams, components, platforms — inflates complexity instead of reducing it. Each 'product' spawns its own strategy, roadmap, PO, and teams. The more narrow products you define, the harder it becomes to manage the whole. You end up with portfolio management overhead and near-zero adaptiveness.
I would like to reflect on a [webinar by Dave West on Product Definition](https://www.youtube.com/watch?v=ujPL7j02yVY). More than a thousand people watched on the spot — so, an important discussion.
First of all, I appreciate Dave's involvement in the field as a subject-matter contributor. Being a CEO, he doesn't need to do this. But he seems to be driven by true passion, and it is fantastic to see this energy. I wish other certification bodies had such a leader!
Secondly, Dave's definition of a product as an "abstraction of complexity" that contains multi-dimensional interests, investments, and opportunities is a useful one. The contrast of project vs. product model that he drew on his talk was well thought of.
But! Here comes my analysis of the key idea of the talk:
> I CANNOT AGREE THAT EVERYTHING IS A PRODUCT.
Just the other day I listened to [John Cutler](https://www.linkedin.com/in/johnpcutler/)'s podcast where he clearly articulated that "no, not everything is a product."
One can apply product thinking to a problem space — including seeing organizations and org change as a product.
But!
> IT IS DANGEROUS TO SEE EVERYTHING AS A PRODUCT INCLUDING VALUE STREAMS, INTERNAL COMPONENTS AND PLATFORM DEVELOPMENT.
Do I have a few more available characters in this post to explain?
If everything is a product, then:
- everything has its strategy, investments, roadmaps, product owners, teams…
- everything is a thing of its own
- everything is boxed with strict boundaries
- everything is siloed
- everything needs to be managed separately
As a result:
> THE MORE "PRODUCTS" ARE DEFINED, THE HARDER IT IS TO MANAGE "THE WHOLE."
This is not a black-and-white discussion. But we need to understand the dynamics of our decisions.
Such org design with many narrow products will inevitably lead to increased complexity, the need for portfolio and dependency management, an army of product owners, coordinators, specialized teams, scrum masters... A lot of self-inflicted complexity and a very low level of adaptiveness — the same dynamics behind [premature platformization](/post/avoid-premature-platformization).
Imagine what needs to happen when this org needs to be reconfigured to fit a change in the strategy or in the architectural approach? Difficult, expensive, slow. Low overall agility.
To conclude: it is vital to lead this discussion on product definition. And it is no less important to raise it beyond the industry status quo and easy solutions.
A product model is a good start but offers no perfection state. We need a holistic product model — what I'd call a [whole product focus](/post/whole-product-focus-team) approach. Something to strive toward and get constantly challenged in our human, local thinking.
These are just my thoughts. 💭 Happy to discuss.
*Originally posted on [LinkedIn](https://www.linkedin.com/posts/alexeykrivitsky_i-would-like-to-reflect-on-a-yesterdays-activity-7257718524393996288-iGMF?utm_source=share&utm_medium=member_desktop).*
---
# Microservices are Technical Debt
**Date:** 2024-11-17 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/microservices-are-technical-debt
**TL;DR:** Microservices are technical debt — a conscious trade-off, not shitty code. You gain short-term delivery speed in a narrow area. You pay with increased architectural complexity, fragmented team knowledge, and reduced long-term organizational adaptability. Like all debt, if you never pay it back, the accumulated entropy kills you.
Have you ever wondered that microservices are technical debt?
Just not in the way we're used to using the term: technical debt (TD) doesn't mean shitty code.
Shitty code is shitty code.
TD is when you decide to do something simpler and cut your quality standards to win at something else — getting some expected effect faster.
But since there are no free pies — after getting the temporary expected effect, you have to go back and redo it well — pay the TD. Otherwise the accumulated entropy will slowly kill you.
Notice the difference with shitty code. TD is a conscious decision.
Now back to microservices. They help teams kick out functionality in a narrow area of requirements faster without having to work on the entire product — an approach often justified by [the common misinterpretation of Conway's Law](/post/myth-of-conways-law). This yields a time gain.
A temporary gain. Just like TD.
But since nothing in this universe is free, the price of such an architecture is:
1. making it more complex,
2. fragmenting team knowledge and responsibility, and
3. reducing your organization's adaptability long-term — the same risk as [premature platformization](/post/avoid-premature-platformization).
> Microservices are a technical debt. Something to think about!
---
# Product Definition with Dave West
**Date:** 2024-10-31 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/product-definition-dave-west
**TL;DR:** Dave West's product-as-abstraction framing is useful, but 'everything is a product' is dangerous. Each new product boundary spawns its own strategy, PO, roadmap, and teams. The more narrow products you define, the harder it gets to manage the whole — self-inflicted complexity that kills adaptiveness.
I would like to reflect on a yesterday’s webinar by Dave West on Product Definition. More than a thousand people watched on spot — so, an important discussion.
First of all, I appreciate Dave’s involvement into the field as subject-matter. Being a CEO he doesn’t need to do this. But seems he is driven by true passion and it is fantastic to see this energy. I wish other certification bodies had such a leader!
Secondly, Dave’s definition of a product as an “abstraction of complexity” that contains multi-dimensional interests, investments and opportunities is a useful one. The contrast of project vs product model that he draw on his talk was well thought of.
But! Here comes my analysis of the key idea of the talk:
I CANNOT AGREE THAT EVERYTHING IS A PRODUCT.
Just the other day I listened to John Cutler’s podcast where he clearly articulated that “no, not everything is a product”.
One can apply product thinking to a problem space. Including also seeing organizations and org change as a product.
But!
IT IS DANGEROUS TO SEE EVERYTHING AS A PRODUCT INCLUDING VALUE STREAMS, INTERNAL COMPONENTS AND PLATFORM DEVELOPMENT.
Do I have few more available characters in this post to explain?
If everything is a product, then
- everything has its strategy, investments, roadmaps, product owners, teams …
- everything is a thing of its own
- everything is boxed with strict boundaries
- everything is siloed
- everything needs to be managed separately
As a result:
THE MORE “PRODUCTS” ARE DEFINIED, THE HARDER IT IS TO MANAGE “THE WHOLE”.
This is not a black and white discussion here. But we need to understand the dynamics of our decisions.
Such org design with many narrow products will inevitably lead to increased complexity, need of portfolio and dependency management, an army of product owners, coordinators, specialized teams, scrum masters... A lot of self-inflicted complexity and very low level of adaptiveness. This is exactly the kind of [premature platformization](/post/avoid-premature-platformization) that fragments ownership and kills agility.
Imagine what needs to happen when this org needs to be reconfigured to fit to a changes in the strategy or in the architectural approach? Difficult, expensive, slow. Low overall agility.
To conclude: it is vital to lead this discussion on product definition. And it is not less important to raise it beyond the industry status quo and easy solutions.
A product model is a good start but offers no perfection state. We need a holistic product model — what I explore further in [*No. Not Everything Is A Product*](/post/no-not-everything-is-a-product). Something to strive towards and get constantly challenged in our human’s local thinking.
These are just my thoughts. 💭 Happy to discuss.
---
# Individuals and Interactions = Relationship (the Blah-Blah-Blah Manifesto)
**Date:** 2024-10-16 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/individuals-and-interactions-relationship-the-blah-blah-blah-manifesto
**TL;DR:** Individuals and interactions is really just one word: relationships. Relationships are the root of any process improvement and any change. Before you induce change in a team or organization, build the relationship first. Don't do change on someone — do it with someone. Obvious, yet constantly forgotten.
## The image
The other day, I got reminded of this image I made somewhere in 2011:
What did I mean by this? Let's see:
Aha! Relationships!
> Relationships are the roots of any process improvement and any change.
Let's remember that. Before you decide to induce a change in a team, department, or organization — build relationships and bring the people along on the journey. This is also why [reactive-to-creative leadership](/post/reactive-to-creative-leadership) matters so much: you can't build real relationships from a place of fear.
> Don't do change on someone, do it with someone.
It's so obvious and so often forgotten. And when it is forgotten, [frameworks become the substitute for real agility](/post/agile-frameworks-not-what-makes-you-agile) — process replaces trust.
## The talk
The entire historical video from Agile Tour Vilnius, 2011:
Sources:
- [youtube.com/watch?v=OPup-kMzYEg](https://www.youtube.com/watch?v=OPup-kMzYEg)
- [slideshare.net/slideshow/offshore-agile-agiletour/9574708](https://www.slideshare.net/slideshow/offshore-agile-agiletour/9574708)
References that helped to preserve the idea:
- [slideshare.net/michael.sahota/5-practices-for-an-agile-mindset](https://www.slideshare.net/michael.sahota/5-practices-for-an-agile-mindset)
- [blog.vincent-tietz.de/2015/08/24/alles-super-die-agile-2015-in-washington-dc/](https://blog.vincent-tietz.de/2015/08/24/alles-super-die-agile-2015-in-washington-dc/)
---
# Fads Do Not Last
**Date:** 2024-10-16 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/fads-do-not-last
**TL;DR:** Management fads rise and fall on a 5-7 year cycle. Spotify Model is generating consulting work from failed adoptions. SAFe has a long tail because of sunk training costs. Team Topologies will fail fast — it just renames existing teams and justifies the status quo without changing underlying dynamics.
These days, most of my org consulting work comes from failed adoptions of the so-called "Spotify Model" — [how adaptive is that model, really?](/post/tribes-and-squads-how-adaptive) It seems it takes 5 to 7 years for a management fad to rise and fall unless it solves underlying organizational problems and changes the negative dynamics. Most fads don't.
SAFe has been falling already for quite some time. Yet it has a slightly different trend of a very long tail. That is due to the high investments in trainings and licenses companies were told they needed to purchase to "become agile". But it is failing nevertheless, and it will generate enough work for most of us for the next 10 years to dismantle those constructs.
Team Topologies is on the rise. But I don't think it will have a long tail on decline. It will fail drastically. Why do I think so? Unlike Spotify and SAFe, TT doesn't really change much — it just gives fancy names to existing teams and justifies whatever there is. As I argue in [*How Adaptive are Team Topologies?*](/post/how-adaptive-are-team-topologies), it also [misses a crucial team type](/post/whole-product-focus-team) entirely.
Save this post.
Discuss on LinkedIn: [linkedin.com/posts/alexeykrivitsky_these-days-most-of-my-org-consulting-work-activity-7245706749448536064-I1RX](https://www.linkedin.com/posts/alexeykrivitsky_these-days-most-of-my-org-consulting-work-activity-7245706749448536064-I1RX).
---
# Elevate Product Management
**Date:** 2024-07-19 · **Reading time:** 15 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevate-product-management-for-business-agility
**TL;DR:** Most product owners own parts, not Products. Parts cannot demonstrate business impact — only costs. So POs become team-level business analysts, and business stays uninvolved. Fix: close the Product Gap by elevating POs to strategic Product level, forming teams-of-teams, sharing code ownership, and working in a unified sprint cadence.
Business Agility is similar to the agility we observe at the team level—it helps a work unit deliver faster, learn faster, and adapt more quickly to change, but as the name suggests, it extends across the business.
Most companies aim to outperform their competitors and remain relevant to their customers and stakeholders for as long as possible. The promise of Business Agility is like an **elixir of life**, essential for preventing stagnation and fostering rejuvenation.
> When obtained, Business Agility allows organizations to fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost -- _be agile_ in the broadest sense of this word.
This blog describes how Business Agility can be achieved in relation to the work of Product Managers and Product Owners. The Org Topologies™ map helps us understand this concept and guides us on the path.
If you are unfamiliar with Org Topologies™, the tool for strategic organizational development, [you can get started here](https://www.orgtopologies.com/essentials).
## **The Difference between “Product” and “products”?**
Large, complex Products are ... large and complex. We want to split them into smaller parts because managing smaller products _appears_ to be easier. So, usually, what large organizations identify as products are steps in the funnel, parts of a customer journey, features, applications, or components... They are parts of a larger Product.
Those smaller products are typically poorly understood by the customer and business stakeholders. The sub-products are parts of a bigger whole. Only when that _whole_ is put together can we address customer needs, enable a business model, make a true impact, and get a return on investments.
> "Dividing an elephant in half does not produce two small elephants." -- Peter Senge, "The Laws of Systems Thinking"
Note the distinction between “Product” with a capital “P” and lowercase “products” in the paragraph above. We will apply this capitalization throughout this article. The difference between Product and product is essential. Org Topologies™ defines that difference as the **“Product Gap”**:
Product Gap
It usually comes as a surprise, but the size of the Product Gap in an organization profoundly affects the whole organization, its design, and its operating model. In other words:
> **A Product Gap is an essential characteristic of an org design.**
The idea that every piece of the whole (each sub-product) needs an “owner” is common in the industry. This is probably due to the popularity of Scrum terminology. Let us paraphrase that slightly differently:
> **Most organizations have far too many product owners!**
Now, what do those product owners (in lowercase) exactly “own”?
## **What is Ownership?**
When ownership means owning the whole Product, the impact a Product Owner can make can be measured by the improvements to that Product over time. As discussed above, a Product is developed to solve customer needs and enable a business model. As a consequence, the impact of a Product Owner must be measured in those terms as well. The results of their work are visible to the business stakeholders and customers and can be measured and optimized.
But what happens when the whole Product is broken down into parts, and it is the parts that are owned but not the whole? Then, the impact of the work of the product owners (lowercase) becomes less connected to what business stakeholders and customers understand and care for. Results become harder to observe, the impact becomes harder to measure, and efforts and investments become harder to justify.
Working on the parts does not guarantee a meaningful positive impact on the whole. Therefore, predicting and measuring _returns_ and _profits_ is difficult or even impossible when owning only a part.
What is easier to observe and measure when individual parts are owned separately are _the efforts_ and _costs_. And this is more dangerous than it sounds.
Large organizations distinguish between “profit centers” and **“cost centers”**. Sadly, business stakeholders and accounting see many product owners and their teams as mere “cost centers”.
> If you are the costs, you will be minimized.
Sad but true.
In the absence of working towards something outer-focused (e.g., the impact of the Product on customer needs, a business model), owning a product part (lowercase) usually boils down to a sequence of inner-focused activities: preparing work, slicing work, detailing work, assigning work, tracking work, coordinating work... Work, work, work. Output, output, output. The [three ecosystems](/post/three-ecosystems) model shows why this inner focus is structurally inevitable in fragmented orgs.
This is an obvious downfall of product management. The noble goal of Product Management is to **maximize outcomes and minimize outputs**, and that is challenging when the parts are owned separately.
To make matters worse, teams quickly get used to their “helpful” and “available” product owners. Teams start to expect and rely on them to do all this preparation and coordination work. This inevitably only makes the downward spiral more vicious. In such environments, the true ownership of impact is replaced by managing work and output.
Product owners (lowercase) become synonyms for project managers, requirement engineers, and team coordinators.
They are **team output owners**, really.
## **Levels of Ownership**
In the Scrum-dot-Org Professional Product Owner class, there is an exercise where a picture (displayed below) is shown, and the students are asked to plot themselves according to the different ownership levels.
Most product owners who attend such classes plot themselves on the left side of this image as 'scribes' and 'proxies'.
Ownership of the parts is rooted deep into how we do things these days (at least in the software industry). Typically, such product owners have either task- or feature-focus and are given a single development team to work with.
With Org Topologies, we map this level of Product Ownership in the lower part of the map (Y—and A-levels). They are output-driven.
Output vs Outcome
Ownership levels
## **Business Agility Cannot Be Attained ...**
### **... When There is No Business Involvement**
The “Product Owner” role was invented some 30 years ago as a response to a common problem - business in most organizations has been separated from Product Development (IT, R&D). Business people were neither involved nor controlled investments in software product development at the right level of granularity.
That created a huge swamp for organizational dysfunctions such as internal fixed-scope projects, annual budgeting for IT, and countless orphaned products that someone once requested but no one really wanted.
By giving a Product Owner's role to a business stakeholder, we bring Business and IT closer together and teach them to collaborate in a win-win game. In this setup, Business and IT work together daily to maximize value (more outcome) and minimize the amount of work not done (less output).
And here lies the first impediment to Business Agility: the role of product owners (lowercase) is unlikely to look sexy to someone from the Business. Remember: a product owner owns a part of the Product: a step in the funnel, a part of a customer journey, a feature, an application, a component. And business people are not interested in tactical management of the parts but in strategic management of the whole. Hence, in many organizations, the role of product owners will be fulfilled by IT folks, not business representatives.
> Essentially, product owners in most orgs are team-level business analysts who take care of details so the teams don't get distracted from coding.
Now we have just returned to square one: Business stays outside, not taking an active part in creating products, is uninvolved, and is not controlling investments.
Eventually, in such an environment, the only way to control anything for Business is to fall back to the old-and-tested management practices of _threats_ and _bribes_ (deadlines and bonuses).
Goodbye, Business Agility!
### **... When There is No Whole Product Focus**
Meet Billy, a product owner of the Billing Engine, and she works with a Billing Engine Team.
Billy can optimize her team’s output when there is work regarding the Billing Engine. It is her focus. She scans the organization for useful work in the Billing Engine and brings it to her team. And when there is no work coming from the outside? She has a list of things that need to be improved in the Billing Engine.
(Isn't she sometimes making up the work to keep her team busy? She would never agree to this statement. So, let's assume this never happens...)
The trio: Billy, the Billing Engine and the Billing Engine Team are a tight knot. Billy owns the Billing Engine. The Billing Engine Team specializes in the Billing Engine. They all need each other. Their world is small but comfy. They can focus and specialize. They can be _super-efficient_ when it comes to the changes of the Billing Engine.
Note: These are not just some universal laws: no one is born owning and knowing a Billing Engine. This is an org decision someone made some time ago. These are the principles of how that org is set up. “Efficiency Through Specialization” and “Focus Equals Efficiency” are the company's values that are written in the hallway.
Billy can even try to make her team more efficient and achieve a nearly hundred percent resource utilization. But will it make the _whole company_ agile? Agile as to “fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost”? That is a rhetorical question.
How many product owners with dedicated teams are in the org? Five, ten, twenty-five, a hundred?... All the product owners are strongly focused on their product parts, as Billy is. All the teams are deeply specialized in their product part.
“Efficiency Through Specialization”. “Focus Equals Efficiency”.
Imagine that Billy and her colleague product owners all need to contribute to larger business initiatives, bets, objectives, programs, projects, and epics (whatever they are called in that organization). These initiatives are usually created and prioritized by business stakeholders.
And this quarter, there are five big company-level bets.[](http://bets.one/)One is a “Customer Retention” project on top of the other things. In the scope of that objective, customer retention needs to be increased, and those changes affect the Catalog (and the Catalog Team), the Product Search Engine (and the Product Search Engine team), the Billing Engine (and the Billing Engine Team), ...
Which team will handle that epic?
Before anyone can take it, it needs to be decomposed into work tasks according to the specialization and focus of the teams and their product owners.
For instance, the Billing Engine Team must receive the tasks for the changes in the Billing Engine for the “Customer Retention” epic. The same goes for the Product Search Team and other teams.
Again, why? Because “Efficiency Through Specialization” and “Focus Equals Efficiency”. Because someone has designed a company like that.
And that's not the only project there is. How many other projects are the teams juggling simultaneously in that company? Five, ten, twenty-five, a hundred?...
In that context: what are the odds that the “Customer Retention” project-epic-initiative-bet will be started and done in the next sprint by all the team working on it together? That probability is close to zero. Such organizations cannot work as one, they are fragmented and look more like a group of small sales boats than a well-build nice-looking cruise ship.
> Everyone is busy, everything is slow.
Business Agility cannot be achieved through specialization and focus. Those things can even harm it.
Business Agility requires stronger cohesiveness between the teams: a _shared focus_ and _broader specialization_. This is the [whole-product focus](/post/whole-product-focus-team) principle in action.
## **Elevating to Close The Product Gap**
In case you missed it, the latest hype in the agile space is about Product. Many people are talking about Product Management, Product Managers, Product Leads, Empowered Product Teams, etc. The so-called “[Product Operating Model](https://www.svpg.com/the-product-operating-model/)” is the latest promise to solve our digital product development problems.
This is a promising model, and we want to subscribe to the hopes it brings. However, we also believe that **culture follows structure** and that specific organizational design changes will make the application of the model more successful. Without the right structure, even "empowered" teams end up caught in [the Ferrari Trap](/post/ferrari-trap) — fast parts in a slow system.
Org Topologies™ offers a set of guides and practices called [Elevating Structures](https://www.orgtopologies.com/elevating-structures). In this context, we discuss _elevating_ the product owners and the teams.
### **Elevating The Product Owner Role**
Many organizations that recognize that they are in the field of product development have an established position called a Product Manager (PM).
PMs have a rather holistic view and speak the customer and business language. We can say they live on the Business side of the company. They must be visionary and responsible for delivering a Product that addresses a real need and represents a viable business opportunity. They implement the company's strategy through the Product and work on product-related tasks such as pricing, packaging, releasing, innovating, branding, advertising, etc.
As per the Org Topologies™ map, the Product Manager is located in the upper left part of (C0/C1) the map - they oversee a large scope.
However, because of the dysfunction of the product owners (lowercase) described above, those PMs were structurally separated from real ongoing product development. They are not driving features. They are not collaborating with the teams. The product owners take the space between the PMs and teams.
It's time to change that.
> To close the Product Gap, we need to connect those PM directly to the teams. In other words, remove the product owners, and make the PMs the Product Owners.
They shall act like mini-CEOs and manage a strategic Product Backlog. In many companies, such a Backlog already exists but has different names (a Product Portfolio, a List of Company Bets, OKRs).
Instead of playing the role of a tactical business analyst, the Product Owner is a strategist. They will spend most of their time managing stakeholders and prioritizing for value.Teams then can learn to work directly with the customers and stakeholders to collect the details they need.
### **Elevating the Teams**
Elevated Product Owners will own the Products, not the teams. That means Product Owners must embrace working directly with many teams.
To move the teams within the reach of the Product Owners, we must elevate the teams by creating **Teams of Teams** with a business problem scope.
Each business problem scope needs a single Product Owner and a Team of Teams. Such an organizational constellation can be called a Product Group. It is a holistic unit that has an end-to-end responsibility for a certain business impact.
Creating a Team of Teams is similar to creating a cross-functional team with individuals but at a higher level of abstraction. Instead of combining individuals to solve problems at the feature level, we combine teams to solve problems at the business level. Each Team of Teams must have all the capabilities to solve any problem within their sphere of shared ownership.
### **Elevating the Sprints**
Having a single business-level Product Backlog with Teams of Teams creates the opportunity for teams to abandon the isolation of their team-level sprints. The business-level Product Backlog contains big and important items that are best addressed through the collaboration of multiple teams. They study and do the work in a shared cadence - a Product Sprint.
We all know that a common goal makes the difference between a group of people and a team. By working in sync, dependencies between isolated teams turn from interruptions into opportunities for collaboration within the Team of Teams.
In addition, the value delivered in each Sprint will be a business-level outcome. Stakeholders will benefit from attending an overall Sprint Review to inspect the return on their investment.
Elevated System
### **Elevating Engineering Practices**
An important prerequisite to getting the best out of this approach is shared multi-team code ownership.
This implies we need to break the team-feature coupling and broaden the team's scope of work from tasks or features to the whole company domain. (If a company is too big, we define parts of the business domain that are independent of each other).
The goal is for all developers to work on many components, and ideally, they can change all the code. Most people say this is impossible and undesirable because this will create chaos. On the other hand, the results of private code ownership aren’t great either: complex code and standardization problems. So why not give it a try?
Shared code ownership can be achieved gradually and thoughtfully. How about opening those repositories that need to be changed most of the time for most of the developers?
Many approaches are available to make this prerequisite less scary (shared standards, stack simplification, automation, to name but a few).
### **And What About the Team Output Owners?**
There are many options depending on what those people are skilled in and what they want to do in the new org.
But in most cases, product owners (lowercase) possess great knowledge about some given product parts, they understand certain aspects of business processes, know how to analyze and split large requirements, some even still can code...
That would make them great team members, no?
## **Summary**
Business Agility means that a company can decide to work on what is most important at any given moment at no additional cost.
Business Agility can be structurally enabled by:
1. **Closing the “Product Gap”**
2. **Elevating Product Owners to the level of the Product**
3. **Elevating teams and forming Team of Teams**
4. **Elevating the Sprint**
5. **Elevating the Engineering Practices**
6. **Forming Product Groups where people collaborate jointly on the challenges of the Product**
Learn more about the [Elevating Structures™](https://www.orgtopologies.com/design-and-adopt-elevated-ecosystems)to discover more ways to elevate your ecosystem and gain the true benefits of agility.
_© 2024, Roland Flemm and Alexey Krivitsky_
---
# Avoid Premature Platformization
**Date:** 2024-07-16 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/avoid-premature-platformization
**TL;DR:** Premature platformization creates a chasm between platform teams and customer-facing delivery. It fragments ownership, stifles adaptability, and produces overengineered solutions nobody asked for. Validate the business model first. Let the platform emerge from real usage. Use shared code libraries, not dedicated platform teams.
## Mind The Gap Between The Train And The Platform!
In the rush to platformization, organizations often create a chasm between the platform and its customer-centric parts. This divide can lead to misaligned priorities, inefficiencies, and stifled innovation. Mind the gap!
## Caution
This topic is highly contradictive as many consultants advice for exactly the opposite — to focus on platform development. That is probably why recent [LinkedIn post on avoiding platformization](https://www.linkedin.com/posts/alexeykrivitsky_platformengineering-teamtopologies-devex-activity-7217610626620133376-1Gwk) has triggered a lot of attention.
In this detail article I’m going beyond this false dichotomy (i.e. to platform or no to platform) and aim to advise for a balanced view on this subject with a preference to focus on the whole product.
## Problem Statement
Imagine an architect who discovers that several stream-aligned teams share a common concern that could be extracted and reused. Thrilled by the opportunity, the architect identifies an important task ahead. The default reflex is to design a platform to address this shared concern. However, each stream-aligned team has its own roadmap and is busy with their tasks. The proposed solution seems simple: create a new team dedicated to this platform. Thus, a platform team is born.
The architect collaborates with this platform team, spending weeks meticulously designing and implementing a platform solution, complete with beautifully published APIs. The next step? Mandate that all the stream-aligned teams integrate and utilize this new platform. This seemingly straightforward approach, however, is fraught with challenges and often leads to unforeseen issues. This modus operandi assumes that all variables can be anticipated through extensive analysis and design, a notion that often proves unrealistic in the dynamic environment of software development and organizational operations.
## The Pitfalls of Platformization in Software Development and Its Effects on Org Design
Platformization, particularly in software development and organizational design, often stems from misguided priorities and expectations.
While platformization aims to achieve economies of scale by standardizing processes and creating reusable components, it can paradoxically lead to inefficiencies if not approached correctly. The key is to balance the pursuit of economies of scale with the need for flexibility and customer focus.
Viewing the "platform" as a separate product or value stream can lead to prioritizing internal efficiencies over delivering tangible customer value. Instead of focusing on what customers truly need, organizations may fall into the trap of building elaborate platforms that do not align with actual market demands.
Despite the broad spread of populist ideas that promote platformization and the need for dedicated "platform teams", the long-lasting undesired effects of premature platformization cannot be overstated:
1. Hindering Adaptability and Innovation
2. Leading to Lower-Level Org Topologies Archetypes
3. Overengineering and Waste
4. Creating Internal Silos and Dependencies
### 1. Hindering Adaptability and Innovation
Emphasizing platformization can stifle organizational adaptability and innovation by creating monolithic structures resistant to change. This contrasts sharply with higher-level archetypes within the Org Topologies model, such as B2, B3, and C3, which champion adaptability, cross-functionality, and a shared focus on customer outcomes.
### 2. Leading to Lower-Level Org Topologies Archetypes
For instance, dedicating separate teams to platform development can lead to a "not our job" mentality and hinder value flow — one of the [three contagious organizational diseases](/post/three-common-and-contagious-organizational-diseases) I've diagnosed. This issue aligns with lower-level archetypes like Y2 ("component development with narrow-specialized teams") and A2 ("hopeful yet entangled teams"), known for their siloed nature and struggles with dependencies. These archetypes often lack the fluidity to adapt quickly to changing market needs, which is critical for innovation.
### 3. Overengineering and Waste
Premature platformization frequently results in overengineered solutions. Without a validated business model or clear customer demand, organizations risk investing heavily in features and functionalities that are not actively sought after. This approach can lead to significant waste of resources and effort.
### 4. Creating Internal Silos and Dependencies
Dedicating separate teams solely to platform development can create unwanted silos within an organization. This isolation often leads to misaligned priorities, communication breakdowns, and a "not our job" mentality, ultimately hindering the overall flow of value creation. Such internal silos can disrupt collaboration and efficiency.
## Alternative Approaches to Mitigate Platformization Risks
To mitigate the risks associated with platformization, several alternative strategies are recommended:
1. **Validate Your Business Model**: Prioritize building successful, customer-facing products first. Only consider platform development when a genuine need for shared services emerges from these validated products.
2. **Promote Shared Ownership**: Avoid dedicated platform teams. Instead, encourage a collaborative approach where product teams contribute to platform development as a shared effort. This fosters a sense of collective ownership and ensures the platform evolves in alignment with real-world needs. This resonates with higher-level archetypes like B3 ("interdependent teams collaborating on business value") and C3 ("holistic product development"), which prioritize shared ownership and cross-functional collaboration to deliver customer value.
3. **Focus on Emergent Architecture**: Allow the platform to emerge organically based on actual usage patterns and requirements. This iterative approach supports adaptability and prevents overengineering by ensuring development remains closely aligned with real-time needs.
4. **Consider Shared Code Libraries/Services**: Instead of building a full-fledged platform, start with reusable code libraries or services that any team can create, co-own, and co-develop.
5. **[Whole Product Focus](/post/whole-product-focus-team)**: Avoid creating "value streams" dedicated to internal non-customer-facing concerns, such as platform or infrastructure development. Concentrate on delivering a complete product or its vertical slice that meets customer needs comprehensively. This involves integrating various components and services seamlessly, ensuring that the final product provides a coherent and valuable experience for the end-user. By focusing on the whole product, teams can avoid fragmented efforts and ensure that platform developments align with broader business goals and customer expectations.
## Key Takeaway
Approaching platformization as a primary goal is ill-advised. Instead, a more customer-centric, adaptable, and collaborative approach to organizational design and software development is recommended.
By prioritizing validated business models, shared ownership, emergent architecture, reusable code libraries, and a whole product focus, organizations can mitigate the risks associated with platformization and create a more agile and responsive environment for delivering customer value.
Additionally, this approach allows for the realization of economies of scale in a lean manner without sacrificing adaptability and innovation. Architecture decisions like [premature microservices](/post/microservices-are-technical-debt) carry the same risk — buying short-term speed at the cost of long-term organizational adaptivity.
This approach doesn't say imply that platforms are not necessary or wasteful in general. This is just a just caution that premature platformization can harm organizational adaptability, innovation and resilience due to the gap between the platform-creating and customer-focused parts of the organization.
---
# Elevate a SAFe Adoption
**Date:** 2024-07-15 · **Reading time:** 8 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevate-safe-adoption-with-org-topologies
**TL;DR:** A typical SAFe adoption lives in Resource or Delivery Topology — managing dependencies instead of eliminating them. Elevate one ART at a time into a true team-of-teams: shared business-level backlog, synchronous cross-team work, self-managed dependencies. The framework should heal the system and become less needed, not provide a permanent crutch.
## What is Elevation by Org Topologies?
Elevation by Org Topologies refers to the process of enhancing an organization’s design and functioning to achieve higher levels of adaptability, innovation, and resilience. This method involves a structured approach to understanding the current state of an organization, identifying capability and value gaps, and designing a visionary path forward. By utilizing Org Topologies’ mapping and assessment techniques, organizations can navigate their transformation journey systematically.
This elevation process fosters a more holistic understanding of organizational systems, allowing for continuous improvement and alignment with strategic goals. The ultimate aim is to create sustainable, high-performing _Topologies_ that can effectively respond to changing market conditions and drive long-term success.
According to the theory, there are three types of topologies. A traditional SAFe adoption is either [a Resource Topology or a Delivery Topology](/post/three-ecosystems). Both of these ecosystems are characterized by reliance on lower-level archetypes (Incomplete Tasks and Capabilities level) that are not aligned with business stakeholder needs and customers' journeys. Thus, to yield expected results, such archetypes require extra management capabilities, roles and processes.
Note that the Adaptive Topology requires a completely different set of archetypes residing in the top right quadrant of the map:
Three Topologies
## Reasons Why SAFe Adoption Needs to Be Elevated*
_* The reasoning below is based on numerous observed SAFe adoptions of various sizes. If your SAFe adoption avoids many of these drawbacks, you are an exemplary exception—_
_keep up the great work!_
1.**Lack of True Agility**: Many organizations implementing SAFe do not achieve the level of agility intended. They often get stuck in lower archetypes (e.g., TASKS-1, or CAPS-2) with significant dependencies that slow down the development process and reduce overall responsiveness to change.
2.**Dependency Management**: SAFe tends to manage rather than eliminate dependencies. This management approach consumes time and resources, reducing the system’s efficiency and effectiveness in delivering value.
3.**Push System Pitfalls**: Although SAFe is designed to operate as a pull system, it often functions as a push system. This misalignment leads to decreased adaptability and responsiveness to customer needs, ultimately impairing the system’s performance.
4.**Siloed Teams and Fragmented Backlogs**: Teams often work in silos with their own backlogs, resulting in local optimizations that do not align with the broader organizational goals. This fragmentation complicates prioritization and reduces transparency and predictability in delivering customer value.
5.**Inadequate Organizational Design**: The typical SAFe implementation does not address the root causes of organizational inefficiencies. It often fails to align with strategic goals, resulting in suboptimal configurations that need continuous adjustments and elevation.
6.**Slow Feedback Loops**: SAFe’s dependency on program increments (PIs) with 8-12 week cycles limits the frequency of customer feedback, making it difficult to quickly adapt to changing market conditions and customer requirements.
7.**Suboptimal Use of Agile Release Trains (ARTs)**: ARTs frequently operate as loosely connected teams rather than cohesive units focused on common goals. Elevating ARTs to function as high-performing, integrated teams of teams can significantly enhance their agility and value delivery.
8.**Misalignment with Business Needs**: SAFe’s structure often separates product management from teams, leading to designs that are difficult to implement and creating waste. Integrating product management and development teams can help align solutions more closely with business needs.
By addressing these issues and elevating SAFe adoption, organizations can improve their adaptability, enhance customer value delivery, and create more cohesive and responsive development ecosystems. Without this elevation, SAFe risks becoming yet another case of [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds) — implementing a framework as the goal instead of the means.
## A "Team of Teams" Concept from Org Topologies
A "team of teams" is an advanced organizational concept where multiple specialized teams are integrated to work collaboratively on broader business problems, creating a larger, cohesive unit. This approach enhances scalability and adaptability by leveraging the combined skills and expertise of different teams to address complex challenges that span their individual scopes.
### Key Features of a Team of Teams:
1. **Business Problem Focus**: Teams are combined to address business problems at a higher level, often encompassing entire customer journeys or significant business areas.
2. **Self-coordination**: The integrated teams coordinate among themselves, eliminating the need for external coordinators.
3. **Shared Backlog**: A single business-level backlog is used, ensuring all teams work towards common goals in synchronization.
4. **Higher Adaptability**: By working in a shared cadence (e.g., synchronized sprints), teams can adapt quickly to changes and dependencies that arise during the development process.
5. **Simpler Org Design**: by allowing your stakeholders and product managers to work with the cohesive unit – a "team of teams" and now pre-cut and pre-assign for the individuals and individual teams.
6. **Synchronous Work on Business Objectives:** In contrast with traditional sequential work, which is planned upfront, the teams within the "team of teams" are able to work synchronously, contributing together to the shared business objectives. This is similar to a great Scrum team, where the whole team works as one to complete an end-to-end single piece of customer-facing functionality before moving to the next one.
The last point is critical: it gives us an observable differentiator whether your teams are working as asynchronously (individually) or together as a true "team of teams".
Not how a traditional ART is not a "team of teams". And the fact that the dependencies between different teams in an ART are being analyzed upfront and managed externally to the teams, deprives the teams of the ability to collaborate just-in-time, share work, and thus work synchronously. This is so by design: in SAFe because it is given that they are blocking dependencies between the teams, the goal of the framework and its method is to _save_ the team from dealing with the dependencies.
From the systems thinking perspective, such an over-management is a _quick fix_ -- it will not make the system better over time, and the system will always require such an intervention (i.e., PI Planning and Upfront Dependency Management) for the system to work.
> Our core belief: a framework (or any management system that we apply) should 1) improve that ecosystem, not merely provide a crutch and 2) become less needed in a long run as the system has healed, improve and acquired new capabilities to deal with those historical problems in an inherent way.
## Towards Elevated ARTs, one eARTs at a time:
**1. Pick an ART to get elevated.**
SAFe adoption is usually advised as a big bang, a "one size fits all" transformation. But once you are ready for a SAFe adoption, nothing stops you from experimenting independently on the ART level. Not all the ARTs need to undergo the same transformation and at the same time. The context matters. Size matters. Steady acquisition of new skills and capabilities matters. The willingness of people to participate voluntarily in experiments matters. So go an ART at a time, provided they can deliver value understood by the business (if not - consider merging the ARTs or pick the ones that do). Pick in ART that has more intrinsic chances of being converted into a "team of teams". Make sure all the members of an ART understand the ultimate goal and the challenges of the journey. Make sure they want to solve those challenges. The challenge must be accepted first before addressed.
**2.Elevated an ART's Backlog to Business Objectives.**
In practice, an ART often functions as a collection of individual teams rather than a cohesive unit. To achieve a higher level of organizational agility, aim for an ART to reach the B-level archetype (a "team of teams"), characterized by a focus on business value and a higher degree of adaptability. This requires all the teams in an ART to share the same context. They should stop seeing individual features or tasks being fed to them as their work. Bigger, challenging business objectives should be used to unite them and help them see they need each other to work together on those. So, present a united backlog formulated on the level of business objectives to all teams in the ART. You don't need to create special roles to do this work. The existing group of product managers, Product Owners plus selected team members and stakeholders shall become up with a list of prioritized business objectives. In most cases, such a list already exists.
**3.Contain the dependencies and allow for synchronous work of multiple teams.**
SAFe tends to manage dependencies rather than addressing the root causes of their existence (i.e. focus on component development rather than end-to-end customer-facing functionality). To elevate an ART to be able to self-manage cross-team dependencies is the goal here. This can be achieved by minimizing WIP and allowing the teams to work together on a single business objective and in a shared cadence. In most cases, some form of technical coaching will be needed to teach the teams to integrate across the teams continuously. Dispersing the teams or lighting up the team boundaries is usually very helpful in this period. It's absolutely OK (and must be taught and appreciated) for the team members from different teams to work together on some core pieces of functionality. The "team of teams" should be more important than the individual teams within.
**4. Improve an ART at a time.**
The goal here is to shift from reactive, control-oriented management to [creative leadership](/post/reactive-to-creative-leadership) that empowers teams to self-organize. Don't cancel any existing SAFe rituals, but first add processes that will allow the teams to have a shared context and a cadence. Postpone your judgments about the speed or performance of your Elevated ART (eART). Remind yourselves and the others of the goal: creating a cohesive unit which can act together as one -- jumping on bigger problems and learning and working in sync. Work as one and learn as one: apply inspection and adaptation as well as managers' support to solve raised impediments via overall retrospectives, joint backlog refinements, cross-team mobbing sessions, collecting multi-team architectural workshops, and joint increment reviews.
Elevating SAFe Adoption with Org Topologies™
---
# Elevate Scrum!
**Date:** 2024-07-13 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/elevate-scrum
**TL;DR:** Team-level Scrum creates silos, not business agility. Elevate by merging backlogs to business-level objectives, empowering Product Owners beyond team scope, forming teams-of-teams with shared cadence, and promoting cross-team code ownership. This is an org design change — management must own it, not merely bless it.
Scrum is often implemented at the team level, which can limit achieving business agility at scale. Moving beyond this "team-level agility" to a more holistic approach fosters in-team and inter-team collaboration, aligning with the "[second wave of Agile](/post/second-wave-of-agile-revolution)":
[](/post/second-wave-of-agile-revolution)
Drive the Second Agile Wave
## Five Reasons To Elevate Scrum
1. **Overcome Limitations of Team-Level Scrum**: Solely implementing Scrum at the team level can create silos and hinder cross-team collaboration, leading to dependencies, integration issues, and slower delivery.
2. **Achieve Business Agility**: Elevating Scrum enables organizations to respond to changing customer needs and market demands more effectively by fostering collaboration and alignment across multiple teams working towards shared business goals.
3. **Enable Innovation**: By breaking down silos and promoting a holistic view of product development, elevating Scrum empowers teams to experiment, learn, and adapt more quickly, leading to increased innovation and better customer outcomes.
4. **Optimize for Flow and Learning**: Elevating Scrum involves optimizing for both flow efficiency (delivering value quickly) and outcome orientation (focusing on business results), resulting in a more adaptable and resilient organization.
5. **Enhance Human Potential**: Moving from task-focused work to a more collaborative and outcome-oriented approach, elevating Scrum enables individuals to contribute their full potential and derive greater satisfaction from their work.
## How to Elevate Scrum?
1. **Establish a Single Product Backlog**: Instead of separate backlogs for each team, create a single product backlog reflecting the organization's strategic priorities and customer needs (OKRs work nicely here), aligning all teams towards shared goals and reducing dependencies.
2. **Empower Product Owners**: Ensure Product Owners understand customer needs and business objectives, and are empowered to make decisions that optimize value delivery. [Elevate their role from managing team-level backlogs to owning a broader scope](/post/elevate-product-management-for-business-agility) that aligns with business outcomes.
3. **Foster Cross-Team Collaboration** Implement practices such as [multi-team product backlog refinement](/post/cross-team-collaboration-multi-team-pbr), shared sprint goals, and joint sprint reviews to facilitate knowledge sharing, collaboration, and alignment across teams.
4. **Promote Shared Ownership**: Encourage teams to take ownership of a broader scope of work that extends beyond their immediate areas of expertise. This involves cross-training team members, promoting a culture of learning, and breaking down silos between development, testing, operations, and other functions.
5. **Focus on Business Value Delivery**: Define and track metrics that measure the organization's ability to deliver business value, such as customer satisfaction, revenue growth, and time to market. Use these metrics to guide decision-making and continuous improvement efforts.
6. **Continuously Adapt and Improve**: Regularly [assess the organization's product development maturity](https://www.orgtopologies.com/assess-business-agility-with-org-topologies-mapping) and identify areas for improvement. Experiment with new practices and tools, using data and feedback to drive continuous adaptation and optimization.
By implementing these steps, organizations can elevate their Scrum practices from team-level implementations to a more holistic approach that unlocks the full potential of agility and enables them to thrive in today's rapidly changing business environment.
## Contrasting Team-Level Scrum and Elevated Scrum
**Team Level Scrum****Elevated Scrum**
**Mapping per Org Topologies**Typically: A2 or A3 Moving Towards B3 or C3
**Focus**Primarily on feature delivery within a defined scope Shifting from a feature-centric to a holistic product or business area focus
**Structure**Multiple Scrum teams, often structured around specific technologies, components, or feature sets Moving away from rigid team structures towards more fluid and adaptable models, such as a "team of teams" working collaboratively on a shared business area
**Product Backlog**Teams maintain separate product backlogs, leading to potential dependencies and coordination challenges Transitioning to a single, elevated Product Backlog encompassing a broader scope of work and fostering a unified product vision
**Product Owner**Each team has a dedicated Product Owner focused on maximizing value within their team's scope Ideally, a single, senior Product Owner with a strategic perspective and authority to make decisions across the elevated scope
Top challenges of Team-Level Scrum:
1. **Siloed Work**: Teams may operate in isolation, hindering cross-team collaboration and leading to a fragmented product vision.
2. **Limited Adaptability**: Responding to shifting priorities or emerging opportunities may require significant effort due to static team structures and backlogs.
3. **Dependency Management**: Reliance on other teams for specific skills or components can introduce bottlenecks and slow down value flow
Key benefits of Elevated Scrum:
1. **Enhanced Adaptability**: Teams can easily adjust their focus based on evolving priorities reflected in the unified backlog.
2. **Improved Flow of Value**: Breaking down silos enables smoother collaboration, reducing dependencies, and accelerating value delivery.
3. **Greater Business Alignment**: Aligning all teams to a shared backlog and strategic goals increases the impact and relevance of their work.
4. **Increased Learning and Innovation**: Teams are encouraged to acquire new skills and collaborate across disciplines, fostering a culture of continuous learning and innovation.
## Key Considerations When Elevating Scrum
* **Leadership Buy-in and Support**: Elevating Scrum requires a significant shift in mindset and organizational culture, necessitating strong leadership support to overcome resistance and drive transformation.
* **Shared Understanding and Alignment**: Establish a shared understanding of the target operating model, the rationale for change, and the implications for different roles and teams within the organization.
* **Gradual and Iterative Approach**: Transforming to an elevated Scrum model is best approached iteratively, starting with smaller pilots or experiments to validate assumptions and refine the approach based on learnings.
Key thing to note: elevating Scrum is an org design change. Hence, your management must be involved in this activity, their mere blessing and delegation won't make it a successful transformation. They need to own it and be elevated in their thinking as well.
(C) 2024, Flemm & Krivitsky
---
# Systemic Reduction of Cognitive Load
**Date:** 2024-04-28 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/systemic-reduction-of-cognitive-load
**TL;DR:** Limiting code ownership is the popular fix for cognitive load, but it trades individual relief for systemic complexity: queues, long lead times, us-vs-them culture. The primary concern is customer value; cognitive load is secondary. Eleven alternative approaches — from TDD to mob programming to GenAI — reduce load without fragmenting the product.
## Why Cognitive Load Matters
Have you ever tried collaborating with an overloaded person? In my experience, it is impossible to tell whether a person is overloaded or lacking professional attitude and skills. In other words, overloading makes us incapable of producing work of the expected quality.
The[](https://www.stress.org/workplace-stress)[American Institute of Stress](https://www.stress.org/workplace-stress)reports that workers' daily stress (measured in the US and Canada) increases by roughly 5% yearly. 83% of US workers suffer from work-related stress, with 25% saying their job is the number one stressor in their lives. A stressed worker gets, on average, 41% less productive and 33% less engaged.
I found no numbers specifically in our high-tech knowledge work field, i.e., digital product development. But we can be sure that the ever-increasing complexity and speed at which companies are forced to push new value onto the market doesn't make us less stressed.
_Quite the opposite!_
So, it shouldn't surprise us that reducing cognitive load has been gaining increasing traction in our field over recent years. For five years, it has become one of the most quoted factors managers consider when making organizational design decisions in their R&D organizations.
The most common treatment for the cognitive load problem is limiting the scope of ownership of software teams. This argument is easy to agree with (hence its popularity): the less code the team needs to manage, the less would be the cognitive load of the team members.
_Problem solved!_
Yet, such organizational design decisions that seem correct when analyzed without proper scrutiny (fast thinking) have unexpected side effects rippling throughout the entire product development organization. It doesn't take a rocket scientist to see how private code ownership policy (applied to fight high cognitive load) quickly creates problems in other parts of the organizational system. Queues of pull requests, longer lead times of time-to-value, the “us vs. them” culture between different teams owning different parts of what a customer would call a “single product.”
For at least several years, the industry is familiar with these ramifications, which spread almost uncontrollably within the larger product development system, making it slow to deliver, unresponsive to learning, and essentially non-agile. This is exactly how [the Ferrari Trap](/post/ferrari-trap) manifests — optimizing one dimension while the whole system degrades.
_Are these the trade-offs that your organization is willing to make?_
This book you are about to read goes several layers deeper than the popular materials on reducing the cognitive load you can find online and on bookshelves. The world is not black and white. There are no one-size-fits-all solutions out there. There is no quick fix to complex dilemmas.
Reducing cognitive load is so important that we must keep _uncovering better ways_ to deal with it. One such way is [multi-learning](/post/multi-learning-200) — teams gradually expanding skills through practice rather than through narrowing ownership. But without dualistic ideas of either-or, we need to fight the work-related stress of our workforce and simultaneously learn to tap into the unlimited potential of our organizational intelligence.
We must go beyond curing just the symptoms and applying fast, sloppy thinking to complex issues.
## Reduction of Cognitive Load is Critical!
And it is also important to understand that cognitive load has nothing to do with storing of information in our brains: those limits have not been found by the research, so we can assume that our inner hard drives are unlimited. Hence, point #1: cognitive load has nothing to do with knowing different things, we can keep acquiring new information almost forever.
But what is limited, in fact, is our immediate temporary memory (i.e., RAM) - we cannot stay productive by being focused on more than a handful of things, and we cannot be engaged simultaneously in several unrelated complex activities. E.g. did you notice when driving a car that when the traffic situation worsens, then for those few moments we stop paying attention to the news on the radio? Hence, point #2: cognitive load is essential for maintaining our productivity.
Now, how to approach this in our workplace? How to design organizations that take that into account? The art and science of org design is not to mix primary and secondary concerns.
What do we mean by that? Organizations are NOT created to reduce cognitive load. In fact, the best way to reduce it would be NOT to start a company and NOT to engage in product development. So, in fact, not delivering value is not an option. Hence, point #3: the primary concern of an organization is to discover and deliver customer value.
Now, now we agree that the customer value is our primary concern, we must find ways how to do that in the most effective and productive manners by maintaining adequate levels of cognitive load. This work becomes our secondary concern in org design.
Customer value in most cases is a thing that spans different components, modules, microservices, applications ... it is a cross-cutting thing. Therefore, in order to solve customer problems and provide the best customer experience, we need to keep this wholistic view. Hence, point #4: we need to find ways to stay productive and reduce cognitive load without jeopardizing customer value and customer experience.
So point #5: divide and conquer (i.e., split the product into parts and give away those parts to be owned by individual teams) is not always the best option. In fact, that must be our last resort. As I argue in [*How Adaptive are Team Topologies?*](/post/how-adaptive-are-team-topologies), narrow code ownership trades individual comfort for systemic slowness.
## There Is More Than One Way To Manage Cognitive Load
Hence, this list below is ways to reduce cognitive load by maintaining a systemic view on the customer problems:
**#1 Simplify, Automate and Standardize (Reduce Switching Costs)**
**#2 Apply Test-Driven Development**
**#3 Share Work and Mob (Avoid Individual Tickets)**
**#4 Use GenAI**
**#5 Minimize the Distance to Customers**
**#6 Avoid Separating Discovery and Delivery (Continuous Discovery Habits)**
**#7 Embed Business Analysis into the Teams**
**#8 Minimize General Organizational Complexity**
**#9 Use Modeling Techniques to Grasp the Bigger Picture**
**#10 Minimize WIP**
**#11 Develop Learning Skills by Making Learning a Habit**
... and the list goes on and on.
## Get the free e-book!
[](https://learnhow.simplification.works/p/cognitive-load)
---
# Agile in the Age of AI
**Date:** 2024-04-08 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-in-the-age-of-ai
**TL;DR:** AI breaks core Agile assumptions. Cross-functional teams matter less when AI fills knowledge gaps — teams shrink to 2 humans plus AI. Coding stops being the bottleneck, so sprints shorten to days. More small teams means coordination moves up a level. Developers become mini-POs deciding what to build, not writing every line.
Scrum is over 30 years old, the Agile principles are over 20 years old, and we are now entering the Age of AI — a strange new world where intelligence is available as a service. How does AI impact Agile?
Most Agile practices and principles are based on assumptions about human behavior and team productivity. Some of these assumptions still hold true, but some need to be challenged and reevaluated — and this will impact the practices.
This article is a mix of observation and prediction: what I've seen happen already, and some speculation about what I think is going to happen in the near future. The main takeaway for the reader is simple — *be ready for change*. I don't know exactly how things will change, but I'm confident that Agile in the Age of AI looks different from before. Take a step back, look carefully at how you work today, and start questioning everything.
## Cross-functional teams
Agile development is normally done by small, self-organizing, cross-functional teams. Cross-functional means the team members have different skills that complement each other — overlapping circles of knowledge.
But why do we actually need cross-functional teams? The underlying assumption is that the team needs a mix of complementary skills, otherwise they can't build whatever they are supposed to build. A cross-functional team has all the skills it needs to autonomously build a shippable product increment with minimum dependencies on other teams.
With generative AI, every person effectively has an AI colleague who is blazingly fast and knows every programming language, every popular framework, every design pattern. The AI's "knowledge circle" is vastly bigger than any human circle (although there is still some human knowledge the model doesn't have).
The models aren't perfect yet — they need human oversight. But one or two people with strong prompt-engineering skills and access to a top-notch GenAI model will outperform a traditional cross-functional team — in both speed and quality. I experience this regularly: with an AI colleague I can build things in hours that would have taken days, and in days what would have taken weeks.
So cross-functional teams are great, but not as important as in the past, since knowledge isn't really the bottleneck any more. A team of 1–2 people + AI has access to most of the knowledge they need. Why 2 people, not 1? Because it's nice to have another human to talk to, and easier to deal with vacations and sick leave.
What happens when team size shrinks to 2 people? Do we fire everyone else? No — smart companies will AI-empower everyone, instead of AI-empowering a few and firing the rest. The question is whether the org structure [elevates people or displaces them](/post/ai-replaces-tasks-not-people). Firing a bunch of people creates a culture of fear and kills innovation: people won't explore the technology further if improved effectiveness means more people getting fired.
So let's say we originally had 2 cross-functional teams of 5 each. This might now be split into 5 teams of 2 + AI. What do they work on? Depends on context. It's a luxury problem: *we now have increased development capacity — what shall we do with it?*
## Smaller teams = more teams
One consequence of AI-empowered teams: smaller teams, and more of them.
Smaller teams need less internal coordination. If they sit next to each other (physical or digital) and talk informally whenever needed, they hardly need formal meetings — for example, less need for a daily standup when they can just talk. (Although they might do it anyway for social reasons.)
On the other hand, more teams means more cross-team coordination — at least if they're working on the same product and share dependencies. Each team can be seen as a single team-member in a larger "super team", and the rituals (retrospectives, planning) happen at the team-of-teams level.
Most companies will end up with some kind of daily sync and some kind of planning session every few weeks. But the structure changes: cross-team meetings rather than team-internal, planning sessions that focus on the big picture rather than backlog items.
## Software engineers (mostly) don't write code
A clear trend: AI models are getting really good at writing code. Not perfect yet, but good enough that it makes sense to have your AI colleague write most of the code. This fundamentally changes the role.
As a software engineer you still need to be in charge — think about the architecture, write the prompts, review the results, take responsibility for code quality. But the actual craft of writing the code — AI will, for the most part, do that faster and better than you. This is partly true already today. Within a year it will likely be true 90% of the time. A developer who insists on manually writing all code in the Age of AI is likely to become a bottleneck and a source of bugs.
Developers essentially become *mini-Product Owners*: their job is to decide what code needs to be written, not to write it. Comparable to how you write high-level code in a modern language and the compiler turns it into machine code — except now we raise it one level and the AI writes the high-level code too.
Your AI colleague can even work in the background. Imagine this conversation between Bob, Lisa, and their AI colleague MrFixit over morning coffee:
- MrFixit: "Good morning folks! A couple of bug reports came in last night, two of them were pretty straightforward so I fixed them and put up PRs."
- Lisa: "Great, I'll review in a moment. Any risky stuff there?"
- MrFixit: "I needed to change the login a bit. I added more tests so it's probably fine, but that part might be worth some extra reviewing."
- Lisa: "OK, will do."
- Bob: "Hey MrFixit, did you see that Slack discussion on security holes?"
- MrFixit: "Yeah, want me to look into it? I have some ideas."
- Bob: "Yes please."
- MrFixit: "OK, hold on... Done! I put up three PRs with three different approaches. See the PR descriptions for details. Ping me if you want to discuss."
- Bob: "Awesome!"
Sounds exotic now — within a year I think this will be the norm for many teams.
The result: coding is no longer the bottleneck. So what does this mean for Scrum Sprints — a timeboxed period (usually 2–3 weeks) to let the team focus on development? If work that took a week now takes a day, and work that took a day now takes an hour — do we need sprints?
## 1-day sprints?
My guess: sprints will gradually become a lot shorter, or disappear entirely. Maybe 1-day sprints. Start the day with a quick sync with your human and AI colleagues, decide what to focus on, finish it up and release by the end of the day, do a quick review before going home. Daily Standup and Sprint Planning become essentially the same thing.
With multiple teams working together, there's still a need for a higher-level sync — maybe weekly — to keep alignment. This is true with or without AI, but it gets stronger as we shift to more small teams instead of a few large ones.
There's still a human need for some kind of sync and planning every few weeks. But its purpose and structure will change when development cycles shorten and there's no longer a need to batch weeks of work just because coding takes time.
## Roaming or shared specialists?
What about specialists? Say our teams need to deal with databases and persistency, and need specialist knowledge.
Traditionally we'd put a DB person on each cross-functional team. In a 2-person AI-empowered team, the humans lack some skills and rely on the AI colleague. Enough for routine tasks. For advanced tasks, a human specialist is still needed — to formulate the prompt, evaluate the result, build tools, decide which AI models and tools fit, or fine-tune the models to make them better at that specialized knowledge.
My guess: we'll have either roaming or shared specialists. Some agile teams do that anyway — it will become more common. The broader pattern here is [multi-learning](/post/multi-learning-org-design-pattern-ai) — people expanding beyond their primary craft with AI as a teacher. For example with 5 teams, maybe one or two have a DB specialist (the teams that do most DB work), and they're shared specialists who sometimes help other teams. An alternative: roaming specialists who don't belong to any specific team and go to whatever team needs them most.
## The job of the Scrum Master or Agile Coach
Traditionally the Scrum Master / Agile Coach teaches and mentors the team — how to effectively split a user story, run a retrospective, work as a team.
An AI-empowered team has all this knowledge already, if it chooses to seek it. So the role becomes more *coach* and less *mentor*. If the team wants to know how to split a story, sit with them and write a prompt to ChatGPT. There's the old edict: *give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime*. Now that teams can catch their own fish, you have time to coach more teams and help them figure out how to use those fishing rods.
## User feedback loop
User feedback remains a critical part of agile development, even in the Age of AI. But the practicalities change. We release more often, so customers and users should be ready to receive small updates often instead of large updates seldom. Users take a more active part. Some appreciate this; some don't.
If the user isn't available as often as needed, we can create *mock users* by asking an AI model to role-play a particular type of user — mock user research, mock interviews, eventually mock users trying our system directly and giving feedback. Mock users won't be as useful as real users, but they're faster and more frequent — a useful complement that surfaces the most obvious design issues.
## Additional points to consider
Just for fun, I gave this article to Claude Opus and asked it to suggest additional points. Here is the unedited response, which I thought was quite good:
- **Impact on product backlog and prioritization:** With AI-empowered teams delivering faster, the backlog may need updating more frequently. The Product Owner role might evolve toward strategic prioritization and stakeholder management.
- **Changes in estimation and planning:** Story points and ideal days become less relevant when AI accelerates development. Teams might need new approaches to planning and forecasting.
- **Adaptations in Agile frameworks:** Scrum, Kanban, SAFe may need to be adapted. Sprint Planning, Daily Scrum, Sprint Review frequencies and durations will likely shift.
- **Impact on team dynamics and collaboration:** AI enhances productivity, but consider its impact on team dynamics. Teams will need new ways to foster human connection, creativity, and innovation in an AI-driven environment.
- **Continuous learning and skill development:** As AI takes over certain tasks, members need new skills — prompt engineering, AI model selection, result evaluation. Continuous learning becomes more crucial.
- **Ethical considerations and transparency:** Teams will navigate AI ethics — bias, fairness, transparency. Agile practices may need to evolve to ensure responsible AI development.
## Recalibrate
My friend Kent Beck tweeted something that captures the essence of what we are facing in all roles and professions: we need to recalibrate what we spend our time on. What does it mean to be an Engineer, a Scrum Master, a Product Owner, an Engineering Manager?
Same goes for Agile. We need to recalibrate our practices. That starts with self-reflection. What do we spend time on? What are our rituals, roles, artifacts? What needs to be challenged, changed, or reevaluated as we enter the Age of AI? If you want the structural version of this argument, [*Agile Was Homework, AI Is the Assignment*](/post/agile-was-homework-ai-is-assignment) goes deeper into why the org design — not the framework — determines whether AI adoption actually lands.
---
# How Adaptive are Team Topologies?
**Date:** 2024-04-05 · **Reading time:** 19 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/how-adaptive-are-team-topologies
**TL;DR:** Team Topologies promises fast flow through narrow code ownership, but this reinforces blocking dependencies between teams and hinders customer-focused agility. Optimizing cognitive load at the individual team level comes at the cost of whole-product collaboration.
## TL;DR
The article takes a predominantly critical stance toward the Team Topologies approach. It systematically debunks several of its key claims, arguing that while the model promises fast change at a component level, it may inadvertently reinforce negative dynamics — such as strict code ownership and inter-team blocking dependencies — that ultimately hinder true customer-focused agility.
In essence, the tone is analytical and cautionary, highlighting potential pitfalls and serious side effects if the model is applied too rigidly.
The key idea from Team Topologies:
- Team Topologies' promise is to optimize for the fast flow of change.
- For the flow of change to grow, the teams' Cognitive Load ought to be minimized.
- And for this, it is suggested that teams go with narrow service code ownership.
- Team Topologies claim that with such a strong focus on architectural concerns, the negative effects of Conway's Law will be reduced.
We conclude (with the analysis of this article):
- To make a change for a customer feature, typically several services and components need to change.
- So despite the fast flow of change at the component level (as promised by Team Topologies), the flow of change at the feature level might not improve or even get slow.
- The slowness of the R&D and due to narrow code ownership policies, Conway's Law might get reinforced by Team Topologies.
- The idea of a developer's Cognitive Load is overplayed and analyzed very one-sidedly in Team Topologies.
- Instead of introducing narrow service code ownership, one could as an alternative work to decrease product and engineering complexity by applying modern engineering ideas from companies like Google.
- Team Topologies don't seem to offer a strong vision to improve an engineering organization, but instead might let leaders accept mediocrity.
In general, applying ideas from Team Topologies might have serious negative side effects that leaders need to be aware of. And even without those side effects, we find there is too much talk about teams and too little about customer value and how to make the whole organization more adaptive and innovative.
## Towards Detailed Analysis of Team Topologies
> In today's fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential.
This is a quote from an article dated back to 1986. Since that time, things haven't slowed down, instead speed and flexibility became a standard, a norm to expect from any business.
The concept of Team Topologies has been on quite a rise over recent years. Despite its popularity, there are some essential things in the approach that seriously bother us. In short, we believe Team Topologies done by the book might create a suboptimal inner-focused R&D organization that is optimizing wrong things. For instance, instead of their growth and culture of continuous improvement, the concepts from Team Topologies are likely to optimize peace of mind of development teams.
But is it the right thing to put as a primary optimization concern in product development? In other words: will the application of ideas from Team Topologies help create better business results?
The book talks vastly of Conway's Law and the Cognitive Load of teams. Below, you'll find our detailed analysis debunking these overused terms. We believe those phenomena are somewhat true, but their effect is overplayed and exaggerated. Those things should be accounted for, but should not be your key driving factors in the organizational design decisions.
What can be better primary goals for system optimization and organizational design? For instance, how about long-term speed and flexibility? Or adaptivity and innovation?
But how well are the ideas from Team Topologies consistent with these optimization goals? In short, not much. But we encourage you not to take our word for it — read on and decide for yourself. That is our sole goal with Org Topologies™ — to help organizational leaders (like yourself) make rational, informed, well-thought decisions.
## Team Topologies Are About … Team Topologies
Let me start with a little consulting story. Not so long ago, I had a phone call with a potential client. They asked for some training, and I asked them in return how they currently work and why they need the education.
They said they were about to roll out team topologies in the organization. Stream-aligned teams, mainly. I logically asked what those teams will be formed around, and what they will be working on.
The answer I heard back was somewhat obscure. "We have some available product managers to manage some independent product parts, each of them will get a stream-aligned team." — was the answer. "And then once the first six teams work", they continued, "we will add more teams, and then more".
A quick check with the client six months later confirmed my fear — they were still forming teams and were not ready (in their words) to discuss value areas and coaching for product managers.
And it is not a single case in my practice. Now, what do you read between the lines?
## Teams, Teams Everywhere
There has always been a lot of buzz in the agile space about teams. Teams are at the heart of any agile-friendly method, so you can't underestimate their value. I spent years working in and coaching agile teams. It is a vibrant space. You never stop learning and getting surprised.
But what makes teams so crucial in complex product work?
Teams are able to absorb certain levels of complexity, uncertainty and fluctuations, especially when being cross-functional and cross-component. That makes the job of management way easier.
In other words, teams allow the management representatives to stop wasting their precious time and attention on task assignment and task coordination — and engage instead in some significant high-value work. For instance, developing a company's strategy, making internal investment decisions, clarifying and communicating product visioning, and so forth.
Ironically, it is because of the importance of teams in complex product work, we somehow forgot about other aspects. For instance, what to form a team around. A team can do any sort of thing, but the outcome of those efforts depends on the value of that work. That is obvious, theoretically. But we keep seeing company after company that go ballistic on forming and spawning new teams for every new piece of functionality.
That is why the non-team-based organizational archetypes reside at the very bottom of the Org Topologies map. They are at the very beginning of the transformation journey.
## Teams 101
Imagine a developer who knows a backend component B1. And another developer who is familiar with a frontend component, F1. When put together as a team, they already know B1+F1.
And if there is a requirement on the product backlog that requires work to be done only in those two components, that small team of two is already capable of doing more than the individual developers separately. They can implement that requirement completely, end-to-end, with no hand-off or delays. That speaks for a short feedback cycle and learning. They ship faster, they learn quicker, and they adapt sooner. Everyone wins. That speaks for agility in its essence.
If a third person with test automation skills joins in, then these three would not just create a working feature, but make sure it will always be working with automated tests. That's significant.
A typical product team has more than two or three developers. So it is not hard to imagine a team knowing collectively 3, 5 or 10 different system components and tech stacks. And it is possible to foresee how such a team volunteers for a custom item of high priority and learns a new component that they hadn't worked with before. Now, they as a team have a plus one skill. And can do even better than before. And the more they learn, the better they learn. As learning is a skill too, a meta-skill.
To conclude, another reason why teams are so crucial in the process of product creation is that:
> Team can learn faster than the individuals (the sum of the parts). But more importantly — they are able to accumulate knowledge at the rate no single individual can (they are more than the sum of the parts).
## PDE = f (TEC, VD)
**Product Development Efficacy = function(Team Engineering Capabilities, Value Definition)**
By this non-scientific equation, we mean that it is not enough to consider just how great the teams are in delivering work (Team Engineering Capabilities). But also what those efforts are focused on (Value Definition). That is trivial yet not common to see. If the value is defined wrongly or too narrow, teams will be running at their full speed with little to no contribution to the goals, a measure of the organizational Product Development Efficacy.
In other words:
> Value of teams can be only measured by value of their work.
This has been one of the key reasons why we came up with the Org Topologies™. Our mission is to shift the industry into thinking of both aspects: great teamwork on high value.
But what is the promise of Team Topologies from this perspective?
## Fast Flow
The entire concept of Team Topologies, as the name implies, is around the teams: the kinds of teams, collaboration styles, team ownership, etc. But what is it for?
One of the authors clarified that goal in a series of tweets:
So, the goal is fast flow (at a team level). Now we need to see if that results in building greater products and serving business objectives better.
In order to know that, we'll have to debug and debunk Team Topologies piece by piece. So we will have to go a bit technical. After reading the book several times (yes, we are masochists) we got a strong impression that the authors build all their arguments mainly on these two overused concepts:
- Fighting Conway's Law (168 references in the book)
- Minimizing the Cognitive Load (115 references)
We find these ideas easy to sell to tech-savvy managers. Some sort of IT management bingo. But it doesn't require an in-depth analysis to see how these concepts (being referred to so many times in the book) are got wrong and basically misused by the authors for the sake of supporting their questionable beliefs.
### Conway's Law?
Mel Conway's Law states:
> … the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.
In simple language, Mel Conway formulated an observation that organizational design clearly has an influence on systems design (architecture). So, the way developers, delivery teams, and production departments communicate will have some sort of footprint on the product.
This is a mere observation. Not a law. Conway's paper was not accepted by the HBR due to a lack of data. It is more or less an anecdote we share in our field. Though, he had some clues.
Fred Brooks confirmed Conway's observation and introduced an important corollary to it:
> Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
We find this logical statement of Brooks way more important to the topic of the org design, than the law itself. In other words, to make sure the architecture can be improved and evolved as necessary, an organization shall be kept flexible.
In contrast, if an organization is not flexible (it is fixed and static), then it will not be able to produce a different (improved and evolved) architecture, as a result of Conway's Law. And therefore might not sustain its product over a longer time. We need evolving architectures that can be improved; hence we need to create flexible organizations. But what are the key pieces of advice the Team Topologies book gives?
Literally, the opposite! The book's authors insist on a strict approach to code ownership. They claim that components/services must be owned by teams:
Few points here. First, Team Topologies suggest that the team design must map to the architecture with narrow service ownership. Does that fight or reinforce Conway's Law? (For a deeper look at this question, see [*Myth of Conway's Law*](/post/myth-of-conways-law).)
Secondly, in the tweet above, Matthew agrees that shared code ownership requires engineering maturity. So, is it a bad thing to grow maturity? Isn't that a goal of any engineering leader? It seems so to us. But instead, it looks as if Team Topologies provide a safe harbour to cultivate mediocrity with narrow code ownership discouraging sharing as a concept:
### Fast Flow of Change?
Customers don't want changes in components/services. They want product features to get their job done. And how do features typically relate to components and services? They are orthogonal to each other: meaning, to develop a customer feature, it typically requires making changes in several components and services.
This is a profound consequence of org design with narrow code ownership at the component/service level. It will almost automatically create asynchronous blocking dependencies between teams. That means delays and waiting.
> Inter-team blocking dependencies between teams with narrow code ownership inevitably result in bigger delays, longer cycle times, slower feedback loops and worse time to market of value. That is lower adaptivity. Fewer innovations.
Wasn't the idea of Team Topologies to improve the fast flow of change as an enabler for customer value and agility?
Team Topologies does promise a fast flow of change. But at the component and service level (because of narrow code ownership) — not at the customer feature level! Can such a well-selling book provide such questionable suggestions?
Implementing Team Topologies will unlikely be your enabler for customer value. And it won't be just the flow of change for features that is slow. But also the flow of changing architecture (which is by definition a cross-component and cross-service concern). And when an organization is unable to adapt its architecture fast enough, isn't that the opposite of agility?
Such dynamics can't be solved fast by throwing money and resources into it and applying fancy architectural techniques (e.g., microservices). See the detailed article [Dependencies, Teams, and Microservices](https://blog.odd-e.com/dependencies-teams-and-microservices/) by Viktor Grgic analyzing this and related points in greater detail.
We are confident that the authors of Team Topologies might have thought of these consequences. We are not certain why they decided not to point them out. There are now organizations out there that are trying to adopt Team Topologies. And maybe with little awareness of those significant side effects. As you are reading this, your organization might also be on that path. Think slower.
### Alternatives?
What are the alternatives? Does the industry know any better?
Yes. We suggest investing in continuously learning feature teams with whole product focus that are working on the most important items from the global viewpoint. That is a fast flow of change and agility if you really care for it.
Feature teams learn to be fluid over time — a process I describe as [multi-learning](/post/multi-learning-200) — accumulating cross-component skills sprint by sprint. This creates the necessary flexibility in the organization. And eventually, it elegantly fights Conway's Law. This is because feature teams don't just build customer features faster, but with the constant cross-component work, they also constantly evolve the architecture.
It is not that easy to build such an organization. It has its challenges. For instance, shared code ownership and cross-component work are getting harder with scale. But such an organization learns to solve problems over time. Things will be improving. There will be hope.
### Cognitive Load?
Finally, why do Team Topologies advise narrow service/component ownership? The key argument (as we understood from the materials) is to minimize what they call developers' "cognitive load" (this has been mentioned 115 times in the book).
For a more nuanced treatment of cognitive load in org design, see [*Systemic Reduction of Cognitive Load*](/post/systemic-reduction-of-cognitive-load). But this concept, as it seems, is also misinterpreted by the authors. Reading this thread on LinkedIn:
It sounds like the authors of Team Topologies got so focused on minimizing what they thought of as the 'Cognitive Load' (they actually meant complexity to working with code) then they seemed to forget to explore other options to minimise it. That is an example of what is known as a false dichotomy — and offered false choice to impress and convince the readers. It implies that either you have a high 'cognitive load' or you need to limit the scope of the team's ownership.
It is hard to argue that the smaller the scope of a team's ownership is, the lower the need and effort for learning, less uncertainty in their work, less stress, shorter lead time to make changes in those known lines. But see how inner-facing those concerns are.
Let ask you: is it the primary concern of your business to make your teams' work easier? Being developers ourselves and working a lot with development teams, we understand that it is the improving the developer experience (DX) is the right thing to do. But this is not what your customers are buying, and the investors are investing into, is it? If you go real extreme on this thinking, you will give each developer a single line of code to own. Individual lead time for change will be extremely "effective", but what about the feature level, the customer journey level, and the whole product level?
It appears to us that we are confusing the means with the ends here by focusing too much on optimizing the developers' comfort zone? Point one. (Again: we love developers! But we really adore the ones who learned different programming languages and frameworks and keep learning.)
Point two. Narrow boundaries of team ownership (e.g., at the service level as advised by Team Topologies) will inevitably result in more complex inter-team dependencies. Imagine a business requirement that need to be delivered. It is not formulated in the language of services or teams. It goes across several services; hence, several teams will have to do some service-related work to implement it. Do they understand the business requirement or just given tasks to code within their scope of ownership?
> Narrow code ownership makes planning and and delivering customer value more complex and less certain. It also distantiates teams from customer problems.
You can't remove systemic complexity by policies. You can only shift it around. And by implementing the ill-advised component/service level-team ownership model, complexity will be moved from the teams' small worlds into the space of requirements and planning. Hence, creating more work for managers, coordinators, analysts, etc. Won't it make the product development process more complex, as well as the entire organization? We are afraid so. This will mean less transparency. So less agility, by nature. Is that what you really-really want?
We doubt that. And we are surprised that Team Topologies provide basically only a single option on minimizing (shifting) the engineering complexity by limiting team's ownership scope.
But as Viktor Grgic mentions above, there is at least one more option on how to systemically minimize the complexity of the engineering work — it is by investing in and improving your engineering practices. Learn from the best with this book.
So let's not ignore the progress our industry has been making to come up with such brilliant ideas to systemically fight the complexity of engineering, to name a few:
- monorepo
- trunk-based development
- continuous integration
- automated testing
- and many more
## Book Review
To sum it all up, we are providing below a screenshot of a detailed review of this book by Bas Vodde, who is an experienced developer and an organizational consultant.
## Unexpected Long-Term Negative Impacts When Applying Team Topologies
Despite everything said above, our main complaint on Team Topologies is not their misunderstanding of Cognitive Load or the self-inflicted Conway's Law (discussed above), but these two things:
- Legitimization of component development with no perfection vision.
- Inward view on organizational design.
Let us elaborate.
### Legitimization of Component Development
Imagine an engineering director who has just finished the first few chapters of the Team Topologies book. He takes a look at his org chart and proclaims: "Oh! We have all the team types described in the book! Great!".
And nothing gets improved in the organization: the existing component work and its negative dynamics remain as it has been. Anyone leading the R&D must understand how the component teams (no matter how modern their names are: "platform teams", "complicated sub-system team", "service owning teams") will promote sequential life cycle:
> Value can be delivered only when the work of multiple component teams is integrated and tested. Component teams promote sequential life cycle.
So what? With a component team organization, the work-in-progress (WIP) from a team usually waits several iterations before it can be combined into a valuable feature.
Because of these dynamics, the R&D work is slow, expensive, and unreliable. Business people are unhappy and always pushing for more to get at least something. This creates immense pressure and stress on the developers (and this despite the narrow code ownership policies that were to create less stress!). The developers have to cut quality corners to be on time and yet are always behind the unrealistic plans. A blame game kicks in. More work pushers are got hired (we mean 'delivery managers', 'release train engineers', and other representatives of the 'modern professions'). Managers need to be managed, so more managers are hired — more hierarchies and less face-to-face work of the business people and the developers. More misunderstandings, less empathy, tighter deadlines, and more blame. The organization is entering a vicious cycle. Things will be only get worse over time in there. Then later the best developers quit because they are not learning anything and don't grow.
So to change these dynamics and make a U-turn, component team structure and component development need to be minimized. And when it has to be applied, it has to be well thought through, done temporarily as a step towards a greater good.
### You Need Perfection Vision to Guide Transformation
When might you need a temporary "complicated subsystem team" from Team Topologies? The answer is obvious: when you have a complicated subsystem!
But isn't this a self-fulfilling prophecy? Will a permanent complicated subsystem team be motivated to reduce complications from the subsystem it owns? Is that true that making the subsystem less complicated might go against the idea of the existence of this team? Will people be working full-heartedly to put themselves out of their job? Complex questions.
In light of such a dilemma, having a clear long-term perfection vision for the organization will help a big deal. So, what that vision can be? For instance, you might want ideally all the teams will be self-sufficient, so-called end-to-end teams. Meaning that they will be able to volunteer for an important piece of work (a feature) and implement it throughout the needed architectural layers, fast and with high quality. And all the teams will be like that. Won't that be cool?
That will imply that the teams will have to know how to work cross-functionally and cross-components, making changes in any parts of the codebase when necessary. Such a mode of work will imply a policy of shared code ownership. This might sound like a dream. Because it is one! But before you start criticizing this vision for its impracticality, will you not agree that this "dreamed" R&D would be great?
Let's imagine that you've settled on such perfection vision (your big, bold dream). It doesn't have to be real just yet. But it has to be set as a long-term target. If made so, it will be pulling you towards a better state of affairs. When the vision is set and communicated, you can start working to make it real (in that order: envision, then work towards the vision). Then your temporary solutions (e.g., forming a temporarily complicated subsystem team) can't be criticized if they take you a step further on that dreamed path. And what now be the mission of that complicated subsystem team — of course, to make that subsystem less complicated! So that other stream-aligned teams could work on it, when needed. Now there is no contradiction. And is always a clear direction and progress.
It is worth noting, and we do appreciate this — the Team Topologies book does state that the stream-aligned teams is a preferred team type, on page 64:
> Generally speaking, we need to optimize for fast flow, so stream-aligned teams are preferred.
Then on page 135:
> The stream-aligned team is the primary team type in an organization, and the purpose of the other fundamental team topologies is to reduce the burden on the stream-aligned teams.
And finally on page 136:
> In a modern software organization, we expect most teams to be stream aligned. The flow of work is clear, and each stream has a steady, expectable flow of work for the stream-aligned team to prioritize.
But are these statements enough to make organizational leaders work hard to avoid other team types? Because Team Topologies list all the team types, we fear that might create a belief in some leaders that those teams should be present permanently. Unless there is big clear perfection vision in the organization in which such teams don't exist.
What we are definitely missing when reading the book is the definition of the true north — a perfection state organizations are to strive for. Instead, we see legitimization and excuses for having different kinds of specialist groups and component teams. That is a good recipe for no real change in organizations implementing Team Topologies.
> With no direction, there is no change.
### Inward View on Organizational Design
Finally, our claim above describes our fears on how companies might adopt new terminology (from Team Topologies) but without real change that brings you closer to perfection.
Another concern we share is that Team Topologies drive a very inward-focused view of the organization. That can't drive higher customer centricity.
I have heard of another company adopting Team Topologies with a serious intention. What the leaders did in the first place, looked at the product architecture diagram (blocks of services and components) and started defining corresponding teams owning those boxes. That became their transformation roadmap.
Can't you see how wrong that is? That's when organizational design is made dependent on legacy architecture. Can't that be a good recipe for creating great products customers love?
We find that the whole discussion of Team Topologies is very much inward-focused. There is no customer in the middle of the picture, no business objectives on the line. That goes against Lean Thinking when a customer is put in the middle.
'Product Backlog' is mentioned 0 (zero) times in the Team Topologies book. 'Backlog' is mentioned four times, one of those as a 'team backlog'. The authors of Team Topologies seem to be intentionally avoiding the discussion about the business side of things. Here is a public comment made by one of the book authors as a reply to my attempt to clarify this question:
See [this thread on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6980799654103818241). We have no further comments.
## The Summary
With all said above, we believe organizations implementing Team Topologies "by the book" represent archetypes spanning mainly from Y1 and up to A2 and A3.
We have covered the Y1 box because we feel some implementations of "enabling teams" can be mere reincarnations of functional groups doing the work teams (also known as undone departments). And "platform teams" and "complicated subsystem teams" will univocally trigger dynamics of component development (with blocking dependencies and delays described above).
Those component teams can't be working on customer features end-to-end, so their lists (backlogs) will be full of technical tasks to implement in that piece of code they own. That's the lowest scope level on the map — the "task scope".
A2 will be likely a place for stream-aligned teams with blocking skill- and process-based dependencies on other team types. With component teams being legitimized by the Team Topologies, we can't see how to avoid this.
A3 is the best place Team Topologies can target — a modus operandi for standalone stream-aligned teams with zero blocking dependencies. We want to believe the idea behind the book is to get there. But if it is the goal, it is somewhat watered down by all other team classes and collaboration types defined in the book. So, the goal of having all those teams will be very much decided by individual organizations without clear guidelines from the method authors.
Why Team Topologies don't go higher on the map, like up to B or C? That's because Team Topologies prefer "single team service ownership" as a preferred way of operating. This almost certainly guarantees team-level backlogs (with team-level product owners). And it doesn't matter if Manuel Pais or someone else likes the concept of the backlogs or not — there will be backlogs (lists and queues) at the team level. And if the model doesn't define them explicitly on higher levels (B and C row of the Org Topologies™), they will be defined where the managers find it suitable — likely at the team level. That's how organizations behave and support their status quo.
### Towards Better Organizations
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for yet another maturity assessment model. No, at all.
The mission of Org Topologies™ is to help you, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation and therefore overall organizational resilience is a great place to grow towards.
So, how to improve your org design if you are considering applying the ideas from Team Topologies:
**If you have up to 7 teams (around 50 people):**
- Consider organizing all them around a common shared objective-oriented product backlog, forming a group of teams, working together. We like calling it a "team of teams". And try to make all those teams in the group end-to-end, cross-functional, cross-component, customer-facing and long-living teams.
- Pitch the long-term vision of the customer value to your "team of teams". The people need to see themselves sharing the work and needing each other to deliver on that vision.
- All the teams in the 'team of teams' group should together receive training and coaching.
- And they should be guided by a cohesive overarching strategy defined for that customer value area. Ideally, from an aligned group of product leaders or a single vocal leader.
- Apply advanced multi-team facilitation techniques to enable high collaboration between the teams. Ideally, a pair/group of senior Scrum Masters / Agile Coaches to work with the entire group (not a coach per team).
**If you have more than 50 people in development, you need to go incrementally** (big-bang transformations are … too big and risky):
- Try to define a broad-enough customer value area for the first 50 people to start in. It needs to have a clear, long-lasting value to your business stakeholders.
- Invite people to form the first team for the group to work in a holistic permanent work unit.
- Once the first group settles and functions (in 3-6 months), you can spawn a new group if needed.
- At mid-time intervals (quarters, half-years, or just-in-time) engage high-level business stakeholders to reconsider the structure. You can merge groups or move teams between them to better match your portfolio-level investment targets. This way, the organization can be managed and optimized as a whole.
---
# 75% of those using Scrum will not succeed
**Date:** 2024-04-03 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/75-of-those-using-scrum-will-not-succeed
**TL;DR:** Ken Schwaber predicted 75% of Scrum adoptions would fail. The real number is likely higher. The structural change most organizations never finish: merging decision-making power with frontline information in a single Product Owner role — a product CEO at Gemba. That role rarely exists before Scrum, and rarely gets created after.
## A revolutionary method most organizations never finish adopting
Ken Schwaber, a co-creator of Scrum, predicted back in the days that only 25% of companies would be able to get the promised benefits of the method. After more than 10 years of organizational consulting, I estimate this number to be much lower.
Why? Because Scrum is a revolutionary method that is based on several structural changes that need to be put in place. Many organizations skip these hard parts and end up with what I call [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds) — hoping a slide deck will solve the problems.
One of them is the introduction of the Product Owner's role. This role has been invented around 30 years ago to highlight a radical structural change that needs to happen.
It is to merge power with information that are usually separated on a classical org chart. This is a decision-making capability at Gemba. A powerful move!
## Why true Product Owners are so rare
It is very rare actually that such a role already exists in a given organization before the adoption of Scrum. Yes, there are people with power and others with information, plus many different committees and work groups trying to make all sorts of decisions.
See how those classical dynamics are different from the single "product CEO" who makes informed decisions just-in-time by being involved in the act of product development with quick learning cycles being assisted by a group of committed, knowledgeable people. Without this structural change, Scrum contracts to the team level while management layers multiply above — what I diagnose as [Scrum Shrinkingitis](/post/three-common-and-contagious-organizational-diseases).
That's why it is so rare.
The challenge of [elevating product management](/post/elevate-product-management-for-business-agility) is at the heart of this gap. I am re-watching interviews with Brian Chesky, the AirBnB CEO. He is just fantastic. And, although, he does NOT call himself a product owner (who in the Silicon Valley does?), he's very much describing the same dynamics that I would expect from the true PO in Scrum.
[Join a LinkedIn discussion on this topic.](https://www.linkedin.com/posts/alexeykrivitsky_ken-schwaber-a-co-creator-of-scrum-predicted-activity-7180981237656801282-9wZZ)
---
# A missing team type in Team Topologies?
**Date:** 2024-03-23 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/whole-product-focus-team
**TL;DR:** Team Topologies names four team types but skips the most important one: a broad, cross-product team capable of working on any feature end-to-end. LeSS calls them feature teams. Stream-aligned teams are not the same — they are bound to a narrow scope by definition. The missing type is the one that drives real adaptivity.
## A fifth team type?
Are [#teamtopologies](https://www.linkedin.com/feed/hashtag/?keywords=teamtopologies&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7176905728090071041) ignoring an important team type?
I've worked with high-performing organizations that thoughtfully crafted teams that are capable of working across the whole business/customer domain — as broad as it gets.
Such teams had to do a lot of cross-team learning — what we now call [multi-learning](/post/multi-learning-org-design-pattern-ai) — to stay relevant and keep adding real value. Such teams avoided locking themselves into a predefined narrow scope of work to show local efficiency that is easy to measure and brag about.
I saw such teams in highly-adaptive organizations such as [PandaDoc](https://www.linkedin.com/company/pandadoc/), [Poster POS](https://www.linkedin.com/company/poster/), [Y Soft](https://www.linkedin.com/company/y-soft/) and other places.
In LeSS such teams are called "feature teams". A bad choice of a name, if you ask me. (I also know the historical context and understand why it is so. The story goes to the 90s and to how Microsoft was calling those great teams.)
Such teams differ from other team types as they aim at being able to work on any feature end-to-end; across the whole customer/business domain. That's going up the vertical axis of Org Topologies. Not just improving the flow of known value; but exploring the unknown.
That does not mean such teams in the reality of complex legacy products can actually work on any feature right from day one. No. In reality such teams have their preferences and temporary limitations. But that's a great perfection vision to push us forward and keep improving, isn't it?
## What to call them
If I were to choose a new name for that team type I would think along these lines:
- whole product focus team
- cross-product teams
- omni-component teams
- versatile teams
- omnipotent teams
- …
It is not about the name, really. But the meaning.
## Aren't these just stream-aligned teams?
Aren't stream-aligned teams exactly the same as this 5th team type?
No. As per the definition:
> Stream-aligned teams focus on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona.
SATs are by definition bound to their context, affixed to their value stream that is likely defined quite narrowly to fight the cognitive load challenge (the key premise/promise of the TT method). For a deeper critique of this approach, see [*How Adaptive are Team Topologies?*](/post/how-adaptive-are-team-topologies) and the broader question of [reducing cognitive load systemically](/post/systemic-reduction-of-cognitive-load).
Thoughts? Criticism?
Join [this LinkedIn discussion](https://www.linkedin.com/posts/alexeykrivitsky_teamtopologies-activity-7176905728090071041-Lh2O?utm_source=share&utm_medium=member_desktop) with hundreds of comments to express your thinking.
---
# Extract Team Leads
**Date:** 2024-03-23 · **Reading time:** 6 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/extract-team-leads
**TL;DR:** The Team Lead role always starts with good intentions but culture follows structure: the power figure prevails, the team stops acting, and a vicious cycle of micromanagement takes hold. Extract leads out. Replace with Engineering Managers across several teams — people who grow capacity, code with teams via pairing, and cannot micromanage because their scope is too wide.
Those who know me know that I have never been in favor of the Team Lead role. Though before, I used to think that the negative connotation of this role was more of a leadership style and that it can be trained and adapted.
We all know that the style of leadership can vary. But my current belief is that if you have a built-in role of a Team Lead within a team, then the culture will eventually follow the structure. Meaning, that the power figure of a Team Lead will likely prevail over the other team members, leaving them powerless and victimized.
## Me as a Team Lead
I remember being assigned a Team Lead role at my first paid job, back in 2001-2003. That happened because I had been earlier in that project and I had learned some things about the domain, the clients and the code. So I was given several developers to lead.
Some decisions I made were not too bad, actually. I did introduce Continuous Integration and Unit Testing. But looking back, I can totally see how limiting for the team and too controlling I was.
I can feel nothing but shame now when I remember telling off a bright developer for doing refactoring that had been long overdue. Why did I do that? Not because I didn't want better code. Neither because I wanted to do it myself. No. But I felt scared with the changes he was introducing. I thought they could break the code badly and delay the delivery, which I felt solely responsible for.
I felt insecure and helpless. I felt an urge to control what the other developer was doing for otherwise, he would ruin everything and my career too. The level of responsibility that was put on me (or did I worsen it myself over time?) was too much — I was unable to act proactively and openly.
I was preventing the necessary changes. I was not leading — I was blocking.
... 20 years later, I know I was probably a bit too young for that role. But on the other hand — doesn't my behavior as a Team Lead form a recognizable pattern that we can see in numerous places these days? Do you recognize yourself or your Team Lead in that story?
Responsibility put on a single person eventually leads to that person becoming overloaded and stressed. And that can result in various dysfunctions. Playing safe and [reactive](/post/reactive-to-creative-leadership) is just one of those possibilities that I, personally, experienced. Others can exert different behaviors under the stress of too many expectations from them. But one pattern stands above all — the level of command and control of other increases over time. Thus sucking out responsibility out of the team.
And this becomes a vicious cycle, a self-fulfilling prophecy. The team stops acting, waiting for its leader to act, and the leader has nothing to do but to act because (s)he sees no proactivity from the team. Months and years pass and all you've got is an overly exhausted individual trying to micromanage a bunch of demotivated individuals. That's a tough job and a sad way of being.
It doesn't have to be this way. We can do so much better! But first, we need to understand how we created these dynamics.
## Good Intentions. Bad Dynamics
Note how introducing a Team Lead (or a similar role within a team) always starts with good intentions:
- "Let's have someone senior in the team to make sure the team makes the right decisions."
- "Instead of having the entire team spend their time on clarifying that requirement, let's just have the Team Lead look at that."
- "We need to make sure that junior developers don't contribute with bad code, so let's have the Team Lead review the pull requests."
No one has ever been fired for stating these or similar proposals. They make sense. They are logical. Furthermore, they also resemble other companies that we saw or worked in.
And yet, these are these proposals that lead to the negative dynamics we've just discussed above. Introduction of a special senior role (no matter how you call it) will likely lead to limiting the flow of work and the growth of the team. That's just how the system's bottlenecks function.
> "Show me a specialist and I show you a bottleneck!" — as my fellow LeSS coach and a good friend, [Greg Hutchings](https://www.linkedin.com/in/greghutchings/) puts it. And a Team Lead becomes a hell of a specialist over time.
## Introduce Engineering Managers Instead
The more I work with great companies these days, the more I observe this pattern: a Team Lead role got abandoned, and an Engineering Manager is introduced instead with a focus on long-term engineering prosperity. In practice, meaning that an Engineering Manager works with several teams and in a cross-functional way.
One can say that this is just "scaling" of the Team Lead role. But no. This creates entirely different dynamics:
### #1 Your teams are free from the dictatorship of any kind
Teams are now just teams. No roles, no power games. Flat and proactive as defined in Scrum. All decisions that require the entire team will be made by the entire team. And if some processes require just a team representative (or two), those representatives likely will rotate and never result in forming "special" people. There are no special people. There are just brilliantly equal team members radiating with the potential to act freely when needed.
### #2 Product Management leads the teams
We want people to be led, not told what to do. The presence of a business-minded person (e.g. Product Owner in Scrum) who works with a team on a daily basis can raise enough awareness for everyone to know the direction and act accordingly. We don't need another leader to digest, simplify and fence the team from the real world. We can finally start treating people as adults.
### #3 Focus on long-term growth
An Engineering Manager should work with several teams, not just one. This way, we minimize the ability of this person to know all the details and then try to micromanage. This person can still be involved in development activities and short-term goals. But not full-time. And not for the sake of deliveries.
The mission of an Engineering Manager shall be to grow the capacity of teams. To make engineering great again.
Below is an example of a job description of an Engineering Manager at Gusto:
- Hire, lead and grow a team of diverse engineering talent
- Build and foster an inclusive, collaborative, and high-performance culture
- Collaborate with our data science, operations, product management and design teams to lead and own developing end to end product experiences for complex customer needs from initial planning, execution, to final delivery
- Work closely with Leadership to help set priorities for both short-term and long-term roadmaps
This is the company where [Kent Beck](https://www.linkedin.com/in/kentbeck/) works as an Engineering Manager (as of 2022). And he writes a lot about this role, his mission, and leadership duties.
### #4 Code with the Teams
We want Engineering Managers to be ... engineers. Not HR specialists or life coaches.
We always wanted more experience engineers to pass their knowledge to others. Team Leads were an attempt to achieve that, but with bad consequences. Now, the Engineering Managers, devoid of these shortcomings, can do the right thing right.
Engineering Managers shall be following the "Go Gemba" approach of Lean Managers and code with teams, from time to time, joining feature development. But never alone! Rather, with pair programming or yet better with (remote) mob programming techniques.
### #5 Engineering Managers as Scrum Masters?
I might sound heretical to some people now... But if you follow this article's line of thinking, then the Engineering Managers' mission and scope of work will somewhat overlap with the ones of a Scrum Master. My experience shows 80% overlap or more.
So, do we need both? An Engineering Manager and a Scrum Master for a group of teams? You can choose. Those two can form a powerful leadership team to coach and grow the engineering processes in an organization.
[Poster POS](/post/less-adoption-at-poster-pos) (a Ukrainian SaaS for food services and retail businesses) made this change in the summer of 2021. They removed the role of a Team Lead from the teams and picked a few most trusted engineers who were also interested in improving the production system long-term by mentoring others. Back then, I played the role of a Large-Scale Scrum Coach and a temporary Scrum Master in Poster. Together with the Engineering Managers, we formed a team and lead the changes.
Once I moved out of the company, the Scrum Master position was not filled in. And instead, the Engineering Managers became the Scrum Masters.
What also helped was that quite a few team members were trained in facilitation. So they could run the events without relying solely on the Scrum Masters. That made the job of an Engineering Manager / Scrum Master slightly easier.
## Extract Leads out of the Teams
There are options. You will see what works better... But what you need to do first is to extract the leads out of your teams!
---
*See also a related earlier piece: [Why Scrum is Silent on Team Leads](/post/why-scrum-silent-team-leads).*
---
# LeSS Adoption at Poster POS
**Date:** 2024-03-16 · **Reading time:** 4 min · **Category:** Case Studies
**URL:** https://krivitsky.com/post/less-adoption-at-poster-pos
**TL;DR:** A deep LeSS adoption at a Ukrainian SaaS company — started during COVID lockdowns, continued through full-scale war. Component teams became feature teams in a single flip event. Documents not just the design moves but the reasoning, failures, and what people felt at each step. Most adoptions die in the first two months; this one survived bombardment.
This is a short reading guide to a long, honest case study. The full version lives on **[less.works/case-studies/poster](https://less.works/case-studies/poster)** — a few hours of reading, but worth every minute if you care about how real product organizations are designed and re-designed under pressure.
Poster POS is a Ukrainian SaaS company building cloud POS for hospitality (HoReCa). The case study covers a deep [LeSS](https://less.works/) adoption that began during COVID-19 lockdowns and continued through the full-scale Russian invasion in 2022. Co-authored with the Poster team, it documents not just the design moves, but the reasoning, the failures, and what the people inside felt at each step.
Below is what you'll find, chapter by chapter, and why each part is worth your time.
## Preamble (by Candlelight)
A short, raw opener: training Poster's engineers in air-raid shelters and during blackouts, presenting org-design slides by candlelight in Kyiv winter 2022.
**Why it matters:** the rest of the case study sits on top of this context. Most "transformation" stories are told from comfortable rooms — this one is told from a country at war, and that changes both what's possible and what's required.
## About Poster and This Case Study
Topics: scope of the case, inspirations, company history, business model (B2B SaaS for cafes/restaurants/retail), product surface (POS apps, back office, ecosystem), team size at the time of adoption, COVID-19 and the sudden full-remote setup.
**Why it matters:** Poster is a *real* mid-sized product company, not a Fortune 500 thought-experiment. The constraints (people, money, dependencies, technical debt, time pressure) are the constraints most readers actually face.
## Product Development Before LeSS
Topics: component teams; per-team Product Owners; OKRs cascaded down + the *Contract Game*; rising defect rates; internal product complexity; weak engineering practices; multi-week stabilization "periods"; UX degradation; flat-lining development capacity. Closes with raw quotes from employees.
**Why it matters:** this chapter is a mirror. If you recognize three or more symptoms here in your own org, the rest of the case study is your roadmap. The "before" picture is also documented as systems diagrams — useful as a diagnostic template you can copy.
## Designing the New Organization
Topics: defining the optimizing goal; *owning* the change (vs. delegating it to a consultant); educating everyone — leaders, managers, engineers, PMs; the role of the Product Owner at Poster; the initial organizational blueprint; perfection vision.
**Why it matters:** the most copied — and most failed — part of LeSS adoptions is the org redesign. As I argue in [*Human Framework Dependency Syndrome*](/post/human-framework-dependency-syndrome-hfds), solutions must come from within. Poster shows what it actually looks like to *do the design work*: who's in the room, what artifacts they produce, and how the leaders avoid offloading the decision to outside experts.
## LeSS Flip Event
Topics: format and agenda of the all-hands switchover event; the Feature Team Self-Design Workshop (engineers picking their own teams against constraints); initial Product Backlog Refinement across the new teams; Sprint Planning I and II run end-to-end; closing rituals.
**Why it matters:** a "Flip" is the moment a component-based org becomes a feature-team org in one big-bang event. Poster's playbook is concrete and reusable: the agendas, the workshop instructions, and the constraints used for team self-design are reproducible at other companies.
## First Twenty LeSS Sprints — Observations and Lessons Learned
Topics: perceived speed (and why it feels slower at first); product backlog management; the difference between a *wrong* product backlog and a *true* one; product support process; the changing role of engineering managers; the engineering community as a pull mechanism for practice improvement; the evolution of the Definition of Done.
**Why it matters:** most adoptions die in the first two months — the [agile transformation will not be televised](/post/agile-transformation-televised). This chapter is the survival guide — what to look for, what to ignore, and what to fix urgently. It's also where the case study gets most counter-intuitive (e.g. why team velocity is a misleading signal in the first quarter).
## The Path is the Goal
Topics: short reflective closing; the postscript "Russian warship, go f… yourself!" placing the adoption back into its wartime context.
**Why it matters:** LeSS adoption is presented not as a project with an end date but as a continuous direction of travel — closer to a *kata* than to a *deliverable*. For a detailed look at the Poster journey mapped on Org Topologies, see [*Case Study: Studying LeSS Adoption at Poster POS Inc.*](/post/case-study-poster-pos-org-topologies). This framing is critical for leaders who're shopping for a one-quarter transformation.
## References
The case study closes with a small set of references — books, talks, and prior LeSS case studies that shaped Poster's adoption.
---
Read the full case study at **[less.works/case-studies/poster](https://less.works/case-studies/poster)**. Allow a few hours — it rewards slow reading.
---
# The Three Ecosystems
**Date:** 2024-02-23 · **Reading time:** 8 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/three-ecosystems
**TL;DR:** Beyond the waterfall-vs-agile binary, adding a 'scope of work' vertical axis reveals three distinct organizational ecosystems. This two-dimensional view expands your org design options and clarifies the path toward business-wide agility far better than any single-axis model.
## TL;DR
Many people still see the challenge of creating a better value-creating organization as black-and-white: it is either waterfall or agile.
But in fact, when the second dimension is added (the vertical axis “scope of work”) we suddenly have more options. That makes the path toward true business-wide agility much clearer.
This article explores three fundamentally different organizational ecosystems through the lens of Org Topologies™. This understanding will expand your organizational design options by providing you with a shared visual language that you can use to define the long-term vector of your organizational development. For a deeper look at the specific [team archetypes](/post/determining-archetypes-and-opportunities-for-coaching) that populate each ecosystem, see the archetypes guide.
## Not Yet Another Team Maturity Model
The mission of the Org Topologies™ is not to develop another team maturity and assessment model but to expand our systemic view on the entire value-creating landscape.
The essential questions that the Org Topologies™ explores are:
1. **How can we build an organization where the synergy of all the teams equals the performance of the organization itself?**This means elevating the collaboration of the teams to the highest level by eliminating all unnecessary levels of indirection and management.
2. **How can we create a team of teams that is capable of discovering and delivering value to the customers?**Meaning, expanding the collaboration of the teams on all fronts (which is referred to as 'left-shifting' - blending discovery & delivery) and getting to zero distance to the customers.
3. **Which org archetypes need to be put in place to realize the maximum potential of the people in the organization?**This means uplifting people to the most humanistic and human-centered organizational design that helps people grow.
All these questions are not about individual teams and their solo performance. The scope is rather on designing organizations for tight collaboration as a holistic value-creating ecosystem. This article explores some of them.
## Ecosystems Thinking
[Org Topologies Mapping](https://www.orgtopologies.com/assess-business-agility-with-org-topologies-mapping)'s most prominent benefit is to provide a visual language to model ecosystems - groups of work units cooperating to get things done. Comparing and contrasting such models might serve as a powerful source of insights on finding the true-north vector for the long-term development of your organization.
Let's look at three very recognizable yet distinctive ecosystems that prevail in the digital product development space.
### Ecosystem Type 1: Pre-Agile (Matrix Organization)
As depicted in the image above, such an ecosystem consists of the low-level delivery-oriented archetypes (Y0-A1) which are either task-focused single-skill individuals or feature-focused functional groups.
Because none of these archetypes can produce end-to-end customer value independently, they require each other plus the special higher-level archetypes to perform upfront analysis and discovery work.
Such a setup typically results in analysis work being handed over for implementation in the form of thorough requirement specifications followed by heavyweight upfront planning and estimating, followed by identifying and then tracking the numerous dependencies.
From the lean thinking perspective, such a process results in overcomplicated big batch processing that contributes to all kinds of [inefficiencies and waste](https://en.wikipedia.org/wiki/Muda_%28Japanese_term%29). From the process perspective, such an ecosystem will have to master the sequential staged development process, also known as waterfall.
To manage this excess complexity, organizations that are organized in such a pre-agile ecosystem need to rely heavily on the practices of traditional project management. The presence of a dedicated project management office (PMO) is not rare. It would act as an intermediary between the business-oriented and delivery units of the ecosystem, thus contributing to the inherent lack of transparency and effective business-to-IT collaboration.
With such a strong focus on inner concerns (i.e., managing projects), these ecosystems would have to optimize for what they can measure and manage: that is, utilization of existing skills instead of customer value impact. This creates a strong focus on resource utilization and prescribed process culture.
So no surprise, Ecosystem 1 is usually contrasted with "agile". But is it so black and white?
### Ecosystem Type 2: Agile Teams (Fast Local Flow)
This ecosystem upgraded its delivery units to 'agile teams', essentially forming cross-functional units with a focus on fast flow. That is a great improvement compared to the pre-agile setup (see Ecosystem 1 above). Such teams (Y2-A3) are better fit for fast delivery and reacting to feedback - fast flow of change within a narrow scope of ownership.
This kind of transformation we call "the first wave of agile" - moving the delivery box to the right. Getting faster with better flow. Creating such an ecosystem has been the main focus of many agile change agents for the last few decades. A series of [frameworks and methodologies](https://www.orgtopologies.com/scaling-frameworks)have emerged to provide practices and tooling for creating and sustaining such constructs, with a strong focus on increasing the 'flow of change'.
Discovery and delivery are separated. Resulting in what some people call a "dual track agile". That is a half-measure, a half-baked agility. Thinkers and doers are separated. That is the same old Taylorism. Unchanged paradigms. Sloppy thinking.
Maybe some things have slightly improved compared to the matrix world of Ecosystem 1, but in general, it is naïve to expect a drastic organizational improvement with such an org design. So, no surprise:
> Last year [2022], over seven in ten respondents (72%) said they were satisfied with the Agile practices in their company, while this year, that has dropped to three in five (59%). – [17th Annual State of Agile Report](https://digital.ai/resource-center/analyst-reports/state-of-agile-report/)
In such ecosystems, the so-called 'agile practices' mainly affect how delivery is being run, but they failed to introduce systemic changes to the power structures and the way delivery learns what to work on.
Traditional top-down analysis with dedicated 'discovery groups' is a very prevalent way of managing requirements engineering in such ecosystems.
> Separating Dreaming, Thinking, and Doing is the deadly sin of large organizations. It will lead to Coordination Chaos: fragmentation, waste, and underperformance.– [Ari Tikka from](https://gosei.eu/blog/others-dream-others-think-others-do/)[gosei.fi](http://gosei.fi/)
Result? Big batch processing, hand-offs, queues, waiting... No surprise, countless organizations that invested in creating so-called "agile teams" still have to fall back on traditional project management practices to deal with dependency management and execution concerns. That's why there is still a "projects" box in the illustration above, the same as in the pre-agile ecosystem.
Unless you elevate the whole ecosystem (simplifying and integrating it), some notion of projects will still need to happen to provide some even illusionary understanding of control. In this ecosystem, projects have to support the need for scoping agreements between business and IT, plus decent dependency management. The more teams are added, the more dependencies will emerge, and the more efforts need to be spent on managing such a system.
Because of the above: such an ecosystem scales badly. Thus creating a fruitful market for so-called "agile scaling solutions". Aiming at streamlining the complexity of management at scale. But the root causes that create that complexity and difficulty of scaling remain unsolved.
Long-term effect? Unsatisfied business stakeholders (things are still slow from their global perspective), and demotivated members of the agile teams due to lack of empowerment and constant micromanagement. More investments into such an ecosystem won't necessarily result in more impact. ROI is problematic. We should see how organizations that have been creating such ecosystems will deal with the ongoing light financial crisis. Unfortunately, we will see more layoffs but as a result, hopefully, more systems thinking.
### Ecosystem Type 3: Business Agility (Team of Teams with Co-Ownership)
This last ecosystem that we are discussing in this article merges "dreaming, thinking, and doing" into one holistic workflow. This is what we call "the second wave of agile". This is a true upgrade, uplifting of the whole ecosystem.
This is the shift from Delivery to Adaptive — the same elevation described in [*The Two Wings of a 10X Bird*](/post/two-wings-of-a-10x-bird). Such change is to enable the "cooperative game of invention and communication" as the co-creator of the Agile manifesto, Alistair Cockburn, nicely put it in his industry-changing book ["Agile Software Development: The Cooperative Game"](https://www.oreilly.com/library/view/agile-software-development/0321482751/ch04.html).
Structurally, to create the preconditions for such rich collaboration, an organization needs to introduce the notion of a team or teams. This is a scaled concept - where a collective of agile teams work together with each other and with the customers, business stakeholders, and subject-matter experts to **outlearn**the competition.
In the Org Topologies language, we call this an elevated ecosystem - a true enabler of business agility. This can be made possible by investing in both directions: flow and learning.
While growing teams horizontally is common practice, making the teams move up is not. This can be achieved by allowing the agile teams to co-own the business/customer domain, by growing their "scope of work", on the Y-axis of the Org Topologies map. (See [*Teams and the Scope of Skills Mandate*](/post/teams-and-scope-of-skills-mandate) for a detailed treatment of horizontal growth.)
Making teams co-own and thus truly co-create, requires removing all artificial boundaries that would otherwise cause the "us-them" mentality and result in a "not our job" culture.
The B2-C3 archetypes of the Org Topologies are gaining the best of the two worlds by combining **flow efficiency**with **outcome orientation** (see the illustrations above). This is the space of Business Agility.
## The Elevating Terminology.
**Elevating an Organization**in the context of Org Topologies™ refers to the ongoing process of improving the organizational ecosystem to close capability and value gaps. This involves adopting new mindsets and structures to enhance business agility and overall adaptability. The goal of elevating is continuous improvement and innovation across the organization.
****
**Elevating Structures™**are the guides (tools, templates, workshops, patterns, examples) developed and collected by Org Topologies™ to help organizations implement practices of higher archetypes, promoting systemic changes rather than local optimizations. This approach helps organizations become more adaptable, innovative, and resilient.
Learn about the [Elevating Structures™](https://www.orgtopologies.com/elevating-structures)to discover the ways to elevate your ecosystem and gain the true benefits of agility.
---
# Three Contagious Organizational Diseases
**Date:** 2024-02-10 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/three-common-and-contagious-organizational-diseases
**TL;DR:** Three org diseases: Silosis Multiplicatum (silos needing project management as pain relief), Scrum Shrinkingitis (Scrum contracted to team level while management layers multiply above), and Autonomitis Blockadus (independent teams that paradoxically create inter-team blockages and cold wars). Each maps to a specific region on the OT map.
## A short field guide to org pathologies
Below are three widespread organizational syndromes I keep running into — half tongue-in-cheek diagnoses, half serious patterns. Each one is mapped to a region on the Org Topologies™ map, so you can spot where in your transformation journey the symptoms are likely to flare up.
## 1. Silosis Multiplicatum
A widespread syndrome of operating in silos, where departments or teams do not communicate or cooperate, leading to inefficiencies, missed opportunities, and a constant need for project management — symptomatic pain management. That is why this disease is also known as **Projectitis Acutus**.
In the Org Topologies™ mapping, this illness is most seen in the low-level ecosystems: the **Y0–A1** area, where the prevailing management paradigm is resource utilization — matching work to people's skills. This is a very much pre-agile way of thinking and working. For a deeper look at these archetype levels, see [*Archetypes and Coaching Levers*](/post/determining-archetypes-and-opportunities-for-coaching).
## 2. Scrum Shrinkingitis
A baffling condition where the contraction of Scrum to the team level mysteriously multiplies management layers, leading to an inflamed organizational structure and severe agility impairment.
This is very common in organizations that use SAFe-inspired adoptions — one of the [management fads that do not last](/post/fads-do-not-last) — where Scrum is downplayed and seen as a low-level mechanical process at the lowest organizational level. As a result of this severe disease the **Bureaucracy Mass Index** — which measures **Corporate Obesity** — grows, and over time, if not cured, such organizations become less and less capable of performing their essential functions.
In the Org Topologies™ mapping, this is common in the **Y2–A2** area of the map, where the so-called agile teams are structurally incomplete and hence ought to be managed from outside to get shovel-ready, preprocessed work.
## 3. Autonomitis Blockadus
A perplexing disorder where pursuing team independence paradoxically leads to a maze of inter-team blockages, collaboration deficiency, and team cold wars.
Such widespread sickness results in a lack of systemic view with too much focus on local efficiency in chasing the fast flow at individual team/repository/feature level — the same pattern that produces [the Ferrari Trap](/post/the-ferrari-trap) when AI enters the picture. This disease is often not noticed by patients because the parts of the organism (organization), studied in isolation, appear perfectly healthy. These local optima come at the cost of global efficiency and synergy.
As a result, despite all the efforts to create fast and independent teams, the whole organization displays characteristics of a slow and bureaucratic one. With the Org Topologies™ mapping, such organizations reside in the **Y3–A3** area.
---
Know more diseases, syndromes and cures? [Discuss in a LinkedIn post](https://www.linkedin.com/posts/alexeykrivitsky_orgtopologies-organizational-healthcheck-activity-7162003298990985216-7xHU).
---
# Agile Frameworks Don't Make You Agile
**Date:** 2024-01-25 · **Reading time:** 1 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-frameworks-not-what-makes-you-agile
**TL;DR:** You can have System Demos and Scrum Masters everywhere and still not be agile. You can use no framework and be insanely agile. At the core is treating people like adults — trusting them, allowing mistakes, not micromanaging what, how, when, and where. That goes further than any framework ever could.
🤫 Let me tell you a secret:
Agile frameworks are great, but they're NOT what makes you agile.
You can have System Demos and Scrum Masters all over the place and still not be a tiny bit agile. And you can use no agile framework at all and be insanely agile.
So what makes agility work?
👉 At the core of agility is treating people like adults!
Trust them, allow mistakes to happen, respect them, don't always try to tell them what to do, how to do it, when and where to do it. This is also why [reactive leadership corrodes organizations](/post/reactive-to-creative-leadership) — fear-driven control is the opposite of treating people as capable adults.
That goes a longer way in becoming agile than implementing any framework ever could. And yet organizations keep chasing the next methodology as if the [framework itself is the answer](/post/human-framework-dependency-syndrome-hfds). It never is. As I have argued before, [management fads do not last](/post/fads-do-not-last) — what lasts is a culture of genuine trust and respect.
---
# The Second Wave of Agile Revolution
**Date:** 2023-11-05 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/second-wave-of-agile-revolution
**TL;DR:** Team-level agile failed because organizations focused on local ways of working instead of systemic improvements. The second wave shifts emphasis to inter-team collaboration, shared product ownership, and global optimization — not just individual team performance.
## TL;DR
Is Agile dead? It depends on what you mean by 'Agile'. If you mean that the organizations are not getting the promised benefits because they were focusing too much on the team-level agile "ways of working" instead of systemic global improvements -- then we are in agreement. It is a misunderstanding of Agility that led us down a dead-end.
At [Org Topologies](https://www.linkedin.com/company/orgtopologies/), we see bright sparks -- the signs of the 'second wave of Agile' as we call
it. The emphasis is shifting towards both in-team and inter-team collaboration. Team autonomy and broad product ownership — what we describe as [the two wings](/post/two-wings-of-a-10x-bird) of a high-performing organization. And we want to support and amplify this movement.
And we still are!
## The discourse is on
We hear constant whispers and loud voices saying: "Agile is dead!" While such statements could be dismissed as mere hyperbole, they open up a fascinating discourse. Is the Agile movement truly dead? Or has its meaning been relegated merely to represent team-level agility?
We've discussed this topic on LinkedIn, and [the quoted below post](https://www.linkedin.com/posts/alexeykrivitsky_orgtopologies-activity-7056315635080802304--Eb9) attracted thousands of views and hundreds of reactions:
[](https://www.linkedin.com/feed/update/urn:li:activity:7056315635080802304/)
## What's the buzz?
**Understanding the Shift**
The essence of agile for many of us, practitioners has always been centered around teamwork and creating great teams. The scrum boards, stand-up meetings, and constant feedback loops were crafted to propel teams into a state of perpetual productivity. However, as solutions evolve, they often give birth to newer problems. The very emphasis on team-level agility has inadvertently spawned the necessity for scaling. This is one of the [three common and contagious organizational diseases](/post/three-common-and-contagious-organizational-diseases) we see across the industry.
**Scaling: A Self-Inflicted Conundrum**
By concentrating predominantly on micro, team-level agility, we've managed to sidestep a crucial aspect – system thinking. The inevitable need to scale becomes a challenge rather than a solution, a self-afflicted issue born from a tunnel-vision focus on the immediate team.
**The Emergence of Business Agility**
In this chaotic scenario, a new buzzword has gained traction: 'business agility'. The concept posits that agility should not be confined to development teams but should envelop the entire business entity.
But this raises a question - hasn't agility always been meant for everyone: developers, customers, and other stakeholders?
> **"Business people and developers must work together daily ..." -**claims the Agile Manifesto signed more than 20 years agoo.
The fact that we've reached a point where we need a term like 'business agility' is a stark indicator of a systemic failure.
**Org Topologies: Charting a New Course**
At Org Topologies, we hold a different view. We staunchly believe that agile is neither dead nor confined to business agility. What we need is a rejuvenation, a second wave of the agile revolution.
Our emphasis should not just be on in-team dynamics but also on inter-team collaboration. Merely focusing on team-level metrics like the flow of change isn't sufficient. It's time to expand our horizons and appreciate **value-creating ecosystems**.
Org Topologies serves as an excellent tool in this context. It provides a comprehensive mapping of different organizational archetypes in their relationships to organizational adaptability, acting as a catalyst for introspection and path determination.
**Navigating the Journey with Org Topologies**
Using Org Topologies, organizations can identify their current position in the agile journey. It becomes a catalyst for conversations about where the organization aspires to be, thereby allowing organizations to chart their path towards perfection.
**Conclusion: Sparkling the Second Wave by Creating Space for Collaboration**
In conclusion, agile is far from dead. But we need to broaden our perspective. We must start understanding "agile" beyond team-level agility and embracing a holistic view encapsulating in-team and inter-team collaboration, then we can truly ride the second wave of agile.
Let's not see business agility as a separate entity but as an inherent part of a much-needed agile revolution. With tools like Org Topologies, we can strategically navigate our journey — as demonstrated by the [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos) — ensuring that agile principles remain vibrant, relevant, and, most importantly, value-driven for everyone involved.
**We are uncovering better ways... Let's keep learning and improving beyond dualistic ideas. Let's keep creating adaptive organizations that bring resilience to business and fun to work.**
---
# Case Study: from Component Teams to Team Topologies to FaST Agile
**Date:** 2023-10-26 · **Reading time:** 14 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/case-study-component-teams-to-fast-agile
**TL;DR:** A company with 42 component teams had 97% waste or wait time. They moved through three paradigms — component teams, stream-aligned teams (Team Topologies), then FaST Agile — each mapped on Org Topologies to show what actually changed. Component teams are sticky because developers live in an illusion of independence while dependencies hide between backlogs.
We're looking at this case study from the viewpoint of Org Topologies™ to understand better the chain of transformations he is describing in this talk. The story he is sharing spans several years while he was helping a company to move away from a rigid multi-team constellation of component teams to an org design based on mainly stream-aligned teams of [Team Topologies](https://teamtopologies.com/)® and later on to a more fluid [FaST](https://www.fastagile.io/)-ecosystem.
The meta-level goal of this article is to demonstrate the power of Org Topologies™ as an approach to visualizing and communicating org design and org change ideas. Thus, this article contrasts three different organizational designs showing their significant differences.
## First Org Design: Component Teams
In the video, James Shore first shares his definition of component teams:
In the Org Topologies™ language, we are trying to avoid the black-and-white definitions like 'component teams'. That's why we have a map of 16 archetypes, with [7 of them being the most recognizable](/post/org-topologies-key-archetypes).
If we map the 'component teams' as James describes them, they will be represented by the orange post-its on the map below as Y2 and Y3 archetypes. The exact classification will depend on how incomplete or complete those work units are in terms of their technical capabilities:
In James' words:
> "Component Teams ... is the most common thing I used to see and actuallty the most common thing I _still_ see today....
> This is where each team is focused on a particular technical part of the system... A front-end team and a back-end team... The database team... Or the Ops team... People who are focused on specific technical areas.
James was hired to help that organization with component teams because "the work was grinding to a halt." This is not surprising if we analyze an ecosystem of such teams:
* structurally, such teams cannot independently ship customer features or work on business objectives end-to-end (that's why they are mapped at the Y-level, the task focus level. They can't complete user features);
* they cannot see the bigger picture, simply because that is not their focus;
* therefore, such teams require external specialists and functional groups to provide them with detailed requirements and task breakdowns and help them coordinate and integrate their tasks into a shippable valuable piece of software.
An organization that has such an organizational design will have many blocking dependencies, hand-offs, queues, coordinating roles, upfront plans, dependency boards, and integration issues to manage. Such an organization will be too busy dealing with its world of self-imposed complexity. Rather than being customer-focused, outcome-oriented, and product-centric.
The mapping below depicts all the overhead archetypes that are needed to complement the Y-level archetypes for the whole system to deliver a working product (individuals and groups dealing with analysis, design, coordination, integration, operation, etc.):
No surprise such organizations would want to improve, eventually. But in our experience, the required _management awakening_ can take years. Why is it so hard to change?
> An org design with component teams is very sticky. (This stickiness is also what makes [the Ferrari Trap](/post/the-ferrari-trap) so dangerous — faster individuals inside a broken structure produce no system-level gain.)
First of all, the developers in component teams might not see a problem at all! They strongly focus on what they are good at (and everyone likes to have focus). They feel a strong sense of ownership (of components). All the excessive complexity such a component organization needs is handled by people external to the developers. So, the developers usually don't feel the burden.
Sometimes, when you talk to the developers of component teams and ask whether they know of many cross-team dependencies, they might surprisingly respond: "No, not at all!". Component teams might not see the dependencies, as each team has its task-level backlog that someone external to the team populates and manages. They live in an illusion of independence. "We can do those tasks without any other team," they'd say. And they would be correct. But from the value flow viewpoint, a feature touching multiple components that are owned by different teams has to be broken down into separate tasks. And those separate parts of the feature sit in many different team-level backlogs. Will they be picked up by different teams simultaneously and worked on in a single cadence? Very unlikely. So there are dependencies and asynchronous work that slows down the delivery of value, but one needs to see the bigger picture to see that.
This can be summarized by this famous definition of a cognitive bias described by Daniel Kahneman in his book "Thinking, Fast and Slow":
> **What You See is All There Is** (WYSIATI) says that when presented with evidence, especially those that confirm your mental model, you do not question what evidence might be missing.
The dependencies are between the backlogs, not within them. But these dependencies are not what the teams are looking at... That's why component teams might linger in sweet ignorance of being 'efficient' and 'productive'.
This can be illustrated with the following map overlay:
See how this illusion of independence and the focus on internal concerns (better developers' focus, stronger developers' ownership) create a dysfunctional organization where rich collaboration and joint work of multiple teams becomes almost impossible. James reports that the company had 200 engineers, 300 people in the R&D, and 42 teams. And based on his value-stream mapping analysis, it had 97% of waste or wait time! So they were spending months on something that would take just 2–3 days of work. That was caused by all that waiting and asynchronous, unaligned work of the component teams.
James wonderfully describes in one passage the dynamics and culture such an organization exhibits, showing how such companies "get killed by their cross-team dependencies":
> A team would start working on something, but they would need another team to do something, so they would hand off and then they would wait. And while waiting they would take on other work. So when another team came to them saying "we need something from you", they said "sorry, we're in the middle of something" and now that team would wait...
They created what James calls "the spaghetti diagram". Each card represents a team and every line represents a blocking dependency:
## Second Org Design: Stream-Aligned Teams
James has helped the organization of 42 component teams to move away from the spaghetti state by redefining the responsibilities and making, what he calls, "full ownership teams.", which is very similar to the "stream-aligned teams" popularized by Team Topologies:
Looking at this organizational redesign through the lens of Org Topologies™, this was a move from a Y-level team setup of entangled component teams to an A-level setup with the majority of teams being able to work on customer features end-to-end. And that is a great improvement!
That organizational improvement helped the company to grow and got up to about 67 teams.
However, with the new design and increased number of teams, the company started running into new problems, which were mostly around _product management_. And this is not surprising:
> Every new solution will create new (better) problems.
So the "product management" problems referred to in the story by James are caused by the fact that the stream-aligned teams are focusing mainly on what they are good at already. They build and deliver features that lie within their field of expertise. And that is not a coincidence, That’s intentional.
In the language of Team Topologies: "The goal is to optimize for fast flow of change". Because of this optimizing goal, stream-aligned teams will be given work that is in their field of expertise because that is the fastest way to get that work done. They will be given some set of features in which they can develop deep expertise to be fast at shipping those changes. That's why the steam-aligned teams are mapped at the A-level, the feature focus level. Because of the relatively narrow scope of work, stream-aligned teams "_did not truly own a significant portion of the final product_" (a direct quote from James in the video). A rhetorical question: what happens when you have work units that are fixed to work only on given parts of the whole (components or feature sets)? **You will have dependencies between the teams!**But we agree such dependencies are less strong than between the pure component teams. So the new setup is an improvement compared to the previous state.
According to the storyline, the new org design with stream-aligned teams was significantly better than the initial one with component teams. With the stream-aligned teams, you can focus more on external concerns such as shipping features to serve known user needs, getting fast feedback thanks to the fast flow of change, and then improving the product features. That feedback cycle is the essence of agility.
Yet, James also mentions issues related to this design. One issue had to do with not having enough "specialties" such as UX, Security, and SREs (site reliability engineers) in each team. In other words, the teams were incomplete (A2 as per Org Topologies™).
In this phase they had to deal with two different kinds of dependencies:
* product-level dependencies, due to the narrow scope of work (features) in teams
* specialization dependencies, due to the incompleteness of skills in teams
The second issue mentioned is of greater importance. It had to do with the architects (likely a C1 archetype, as per Org Topologies™) not being able to constantly match the team structure to the changing business and architectural needs. This is substantial: the "essential agile" team archetypes, as per the illustration above, cannot sustain business-level agility. By design, such teams tend to be stuck at whatever they are already good at (they have a feature focus). Thus, they are not fluent and unresponsive when it comes to changes in the product strategy or changes in the architecture. They can't adapt quickly and easily. They are stuck to build and ship fast what they know how to build and ship (remember: the fast flow of change is the goal for stream-aligned teams).
To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult. James concluded in his story that the architect group failed at that task. But our view on that is that the task of realigning the team structure to the strategy is too complex to be performed by anyone regularly. And the scale they had (40+ teams) was also not making it less of a challenge.
So the next step the company was heading toward was to craft an organizational design that would enable true (business-centric) agility. This should be a design where the structure is in constant re-alignment to the business needs. A fluid structure.
## Third Org Design: Towards True Agility with FaST
James got excited about the [FaST](https://www.fastagile.io/). He learned it from [Quinton (Ron) Quartel](https://www.linkedin.com/in/qrq/) and [Paige Watson](https://www.linkedin.com/in/paige-is-xp/) around 2019. FaST stands for Fluid Scaling Technology, and is about combining open space technology (a tool for self-organization) with a frequent opportunity to change team compositions.
The reason FaST appealed so much to James, in his own words:
> What we were doing in the Team Topologies approach is that we were _scaling horizontally_. We're adding people by adding new teams... That requires careful design... Ultimately we're talking about making a big design change to the organization and potentially reflecting that also in the architecture... Sort of a top-down approach ... and to be done in kind of a big bang way.
The broadening of team skills described here is exactly the [multi-learning](/post/multi-learning-200-years-wrong-model) dynamic — teams acquiring capabilities beyond their initial specialization. So the self-managed, bottom-up, and incremental approach offered by FaST was appealing to James, being much more in the spirit of agile:
> In the FaST approach we're _scaling vertically_. We're adding people by having more people participating in one virtual team (a Collective), having more people act as a single team.
Essentially, James ran an experiment in that company with a subset of seven very tightly coupled stream-aligned teams (around 50 developers) and turned them into a FaST Collective. This essentially is a single large team that regularly self-organizes into temporary small teams based on the work at hand.
James concludes with these five key takeaways:
We conclude that FaST has helped to design and sustain a high-level product-centric ecosystem in that company. James also talked a lot about the high transparency such an ecosystem created for its business stakeholders. And we know in empirical process control, transparency is a prerequisite for proper inspection and adaptation. Hence, it is an enabler for better steering and governing. So the third organizational design was displaying better manageability and higher adaptability than the other two options (component teams and stream-aligned teams).
This positions FaST in the top-right corner of the Org Topologies™ map, potentially spanning the area from B2 and B3 up to C2 and C3.
And where does a FaST collective as described in the video live, exactly in the land of FaST?
**The vertical aspect:**
* It depends on the size of an organization: with only 50 people in R&D, all developers would belong to a single Collective. And by definition, that Collective would own the whole product. Therefore, that would be a C-level ecosystem.
* We cannot imagine the constant creation of temporary teams with hundreds of developers in an open space every other day (we are open to learning that this is possible, so we need more case studies, experience reports, or invitations to implement this). However, for now, with the facts that we have, we believe that with hundreds of developers, there will be a need for several Collectives. And likely each Collective will own its product part. Therefore, this would be a B-level ecosystem.
* The Collective described in the video was formed from seven tightly coupled teams, while the rest of the organization remained unchanged. Although it was not clear in the video whether the Collective worked on the whole product or just its part, it is safe to assume that they worked on a product part. Therefore, the case presented in the video would be classified as a B-level archetype.
**The horizontal aspect:**
* For a work unit (a team, a team of teams) to qualify for a multi learning unit (Y3, A3, B3, or C3) it needs to exhibit a unique observable behavior: over time people in that unit are acquiring new skills, hence they 'multi-learn' (we borrowed this term from an [HBD article](https://hbr.org/1986/01/the-new-new-product-development-game)).
* Multilearning is very much different from multi-skill work. In the latter case, people with existing skills work closely together, utilizing their existing skills. In a long-living stable team with a broad product scope, it is simply not possible to keep utilizing one's existing skills forever without being constantly under or overloaded. That's because a constant match between the existing skills and the demand for skills is highly unlikely in a complex work environment (i.e., product development). That means, the fewer skills you have, the bigger the chance you won't be able to utilize them all the time when working on the business priorities. So, in a long-living stable team, to stay relevant, one will have to _acquire new skills_ that are currently in higher demand, hence: multi-learn. That's the dynamics expected in [LeSS with feature teams](https://less.works/less/structure/feature-teams) (as a side note: in the video James is misusing the term 'feature teams' equating them to 'stream-aligned teams'; which is a big misunderstanding).
* In FaST, people have a chance to change work and with whom they work every few days (for the next FaST cycle) because of the built-in fluidity. Will the people be acquiring new broad skills in such a fluid environment? Or will they follow the work and maximize utilization of their existing skills? Will a back-end developer self-volunteer to work (and multi-learn) a front-end task for the next cycle, or will she be pulled in to contribute with her existing back-end skills? That is very contextual and will depend on many things, including personal motivation, stress, level of engineering practices, code-sharing policies, coaching by the managers, the existing reward systems, HR policies...
* So we can't say that FaST will always be fostering the creation of multi-learning work units, though, we believe it is not impossible, but FaST alone (as a process) won't suffice.
Hence, it is safe to assess the target org design in James' story at B2-level Collective.
## Summary
This case study illustrates the power of the Org Topologies™ approach in assessing different organizational designs and organizational change ideas from the viewpoint of structural facts and observed inter-team dynamics.
We encourage you to apply it at your workplace and report back.
_This experience report presents a personal view of the change story based on the provided references. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing._
---
# Archetypes & Coaching Levers
**Date:** 2023-10-24 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/determining-archetypes-and-opportunities-for-coaching
**TL;DR:** Classify a work unit by what it receives as input: tasks (Y-level), feature requests (A-level), or business objectives (B/C-level). Then look inside the box — a team classified A2 externally may operate as Y0 internally if a team lead distributes tasks. That gap between external archetype and internal dynamics is your coaching lever.
## Determining the Vertical Archetype by Inputs
The big determining factor on the vertical axis is the type of input a given unit receives:
- Does the unit receive **tasks**?
- ...**feature requests**?
- ...**business objectives**?
- ...**product goals** and **customer challenges**?
**Tasks** provided as inputs to the unit would classify the unit as the **Y-level**.
Constant **feature requests** (and nothing else) would classify the unit as an **A-level** archetype.
**Business objectives, product goals,** and **customer challenges** — **B** or **C** (the higher archetypes), depending on how broad the scope of work and ownership is.
This very simple logic will help you determine the vertical level of a given work unit (individual, functional group, or team). This is an outside, black-box view from the mere viewpoint of the inputs a work unit receives.
The input levels a unit receives are not random in a given context but are a function of:
- org and power structures
- work breakdown and work integration processes
- beliefs of the management
- cultural aspects
Therefore, the correct determination of the vertical a unit belongs to says a lot about the organization structure, process maturity, and culture.
## But What if We Look Inside the Box?
> There is a whole universe within a universe.
Looking inside a team might reveal a completely different picture of how the work is received, perceived, and gets done.
In the theory of networking there are six different types of networking topologies possible to perform a (networking, routing) operation:
And if we consider an org work unit (i.e., a team) as a graph of connections and relationships between its members, we can assume some of these classical networking topologies have their place.
Consider the **star topology** above — one person (i.e., a team lead) decides who works on what, then divides and distributes the work accordingly. This connects directly to [why Scrum is silent on team leads](/post/why-scrum-silent-team-leads) — the issue isn't the title, it's the leadership style. This central hub of a network might receive feature requests (an A-level per Org Topologies) but then break down the work into tasks to be fed to teammates (almost like a Y0 level — individualistic task work). That creates a conflict. From the outside, the work unit acts like an A-level (let's say an A2) archetype that doesn't require external micromanagement and can convert a feature request into a working feature. But once we unwrap the black box, we see that most of the team members exhibit the Y-level dynamics: they work on tasks, don't see the bigger picture, don't speak the customer's language, and require a task coordinator.
The same logic can be applied to at least one more networking topology — the **line topology**. At a team level, it will result in sequential work with hand-offs between single-skilled individuals, a mini-waterfall.
The **mesh topology** is probably the best representation of how any team coach would want an agile team to operate — but also with dynamic relationships. There, people work with whoever they need to at any given moment, without any central hub responsible for overall coordination.
## Coaching Opportunities
> Give me a lever and a place to stand and I will move the earth.
If you uncover a mismatch between an external view (e.g., A2) of an archetype and how it operates inside (Y0 with individualistic work, or maybe Y1 with a mini-waterfall), this means that a given team doesn't live up to its full potential yet.
Hence, you've found your coaching opportunity — a lever. This can be visualized with the sub-levels as illustrated below:
Imagine every box of the Org Topologies map has a smaller map inside. As described above, with the help of networking topologies, an A2 archetype can be different when studied from the inside. This is what you typically see when coaching A2 teams:
- some A2s will have a team lead and be more like a Y0 inside
- some A2s will have mini-waterfalls and act inside like a Y1
- others, more perfect A2s, will be more like real A2s
So, by putting a map inside a box, you can find the internal gap — a coaching opportunity:
## Summary
Applying Org Topologies to coach organizations requires observing the system as a whole as well as its parts. Studying the whole system or its parts are two different approaches, both valuable in understanding the whole ecosystem.
### Working with the whole
When we observe the whole, we assess which elements are in the ecosystem and study the interactions between them. We are not zooming in to improve the performance of a single part. We design and sustain the org design by working at the level of the organizational building blocks — the archetypes. Once we understand how the parts are interacting and what level of adaptivity this produces for the whole system (i.e., the development organization), we can formulate actions to redesign it to obtain higher adaptivity at the whole level — the direction described in [*The Three Ecosystems*](/post/three-ecosystems). An example of such a systemic change is moving a collection of teams that work independently from each other with feature ownership towards a team of teams that work as one on a business objective.
### Coaching the parts
We can also deliberately zoom in and study the parts internally. In other words, we consider the organizational element under examination to be the boundary of our system. Inside that system, the mapping of Org Topologies can be equally applied to study the interactions of individuals inside an org unit. We will find many coaching opportunities by going to Gemba to coach the teams. We can help them unleash their true potential by leveraging their inter- and in-team collaboration skills.
This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous. Co-authored with Roland Flemm.
---
# Multi-Team Product Backlog Refinement
**Date:** 2023-09-23 · **Reading time:** 10 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/cross-team-collaboration-multi-team-pbr
**TL;DR:** Multi-team PBR brings all teams into one refinement session instead of separate ones. The goal: shared understanding of the whole product, reduced coordination overhead, fewer integration issues. Requires a single product backlog and one Product Owner. Teams focus on the whole problem together rather than receiving pre-cut slices in isolation.
**Multi-team PBR is one of the**[**Elevating Structures**](https://www.orgtopologies.com/design-and-adopt-elevated-ecosystems)**that help to uplift your ecosystem up the levels of the Org Topologies™ mapping:**
This article focuses on refining the Product Backlog with multiple teams at the same time: **multi-team Product Backlog Refinement (aka mt-PBR)**. The goal of mt-PBR is to maximize information sharing and collaboration during Product Backlog Refinement. We bring all development teams together in one refinement session instead of having teams conducting separate refinements. (For how AI tools can augment these sessions, see [*AI-Augmented Multi-Team PBRs*](/post/ai-augmented-multi-team-pbrs).)
## Refinement in Scrum
The Scrum guide mentions refinement, but does not elaborate much on how to do it:
> _“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” (Scrum Guide)_
When we develop a product with more than one team, the Scrum guide suggests to have one single Product Owner and One single Product Backlog:
> _If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner. (Scrum Guide)_
This suggests a move towards the [higher archetypes](/post/org-topologies-key-archetypes) (B and C levels) as per Org Topologies™. Maybe that is too scary or simply not what you want. However, even without transforming your organisation, you might want to explore and benefit from Scrum events such as Product Backlog Refinement with a team of teams.
## Why would you want to do a mt-PBR?
It makes sense to try out mt-PBR when:
* You want to create a shared understanding of the work. In other words, you want the teams to focus on the whole product or problem at the same time rather than splitting the work into smaller items per team upfront.
* You want to reduce the coordination effort that is needed to reduce dependencies between the teams when they work asynchronously from each other in isolation.
* You want to minimize integration issues that will occur if the teams do not integrate during the Sprint.
* You have the opportunity of dealing with a challenge that affects multiple teams. This could be a shared problem or a Product that is been developed by multiple teams and you want the teams to collaborate on that challenge to increase the chances of success.
* You think it is important that team members learn from each other and you want to give everybody the opportunity to contribute to creating the best possible value.
## Preconditions
* In order to get the anticipated benefits of mt-PBR, you will need a single product backlog and one Product Owner. It’s okay if you have many POs running around the teams, as long as there is one single person who takes responsibility for the whole product (or the cross-team problem you are addressing).
* There is a restriction on the number of people involved. I have used this practice with up to 70 development team members, say about eight teams. I know there are colleagues who have run successful mt_PBRs with up to 150 attendees.
* At every customer where I introduced this practice, the teams were cross-functional (archetypes A2 or A3). Meaning that every team can design, test, and build software — what we call a [whole product focus team](/post/whole-product-focus-team). I suspect this practice will not work very well with single-function teams of Y2 level (analysis, test, development in separate teams).
* You need a cross-team Definition of Done (DoD) so all teams have a shared understanding of what needs to be done to be Done.
## Preparations
Before we can start the mt-PBR sessions, the Product Owner (PO) and Scrum Master (SM) need to prepare the session.
### **The Product owner:**
* Needs to shape the top of the backlog by identifying the Product Backlog Items (PBIs) that need to be refined. Let’s say 10 or 15 (larger) items, enough work that will take one or more Sprints to complete with the whole group.
* Needs to describe the PBIs as goals, not as outputs.
* Needs to provide customer-centric acceptance criteria for each PBI.
* Needs to prepare the product vision and shorter-term Product goal (let’s say for the current quarter or less). Consider impact maps as practice.
* Sends an invitation to the whole group, relevant stakeholders, and Subject Matter Experts (SMEs).
### **The Scrum Master:**
* Needs to book a space that is large enough for the group to work in and with sufficient wall space to work on.
* Needs to ensure there are flip-overs, brown papers, stickies, markers, etc.
* Needs to ensure there are “stations” or desks where groups of people can work.
* Needs to arrange a beamer and possibly a loudspeaker system.
* If there is no common understanding of “Done” across the teams, the Scrum Master needs to establish a minimal DOD that applies to all teams. While refining, this will create transparency on the work that needs to be done for each item.
* Often the work is estimated while refining. The Scrum Master should ensure the unit of estimation (possibly story points or t-shirt sizing) is calibrated across teams. This will prevent wasteful discussions between members of different teams when estimating.
## **mt-PBR session process**
The mt-PBR consists of two parts:
part 1: Overall Refinement part 2: Detailed (multi-team) Refinement
The two parts are planned directly after each other.
### **Part 1: Overall Refinement**
This is a session that prepares for the detailed refinement session (part 2). If you have never worked with large groups in sessions, you will be happy to learn that the overall refinement session is done with a small group of delegates from the teams. It is a meeting that has a size you will be familiar with: no more than around 10 people. The attendees are team delegates (development team members) Subject Matter Experts (SMEs) and possibly Product Managers. The session takes 30 minutes to an hour. The input of the session is the top of the Backlog as prepared by the PO. The output of the session is a set of PBIs for one Sprint that has been discussed briefly, with a rough (t-shirt-sized) estimate, acceptance criteria, and known dependencies.
#### **Session details**
The PO briefly iterates the product vision and mission (the Product goal). This provides context, “the Why” for the work that we are about to pick up. This helps everybody to understand why the PO has chosen to prioritize the Product Backlog the way he or she did. The team delegates form heterogeneous groups of 3 to 5 people to discuss one PBI each. This is important. They do not work on the problem with their teammates. They estimate PBIs and split them if they seem to be bigger than one sprint. They also identify dependencies, which are indicators for possible team collaboration during the Sprint. Note that probably not all of the selected PBIs require multiple teams to work on.
A great benefit of the Overall Refinement is that the team delegates will later be able to guide the rest of the group during the upcoming Detailed Refinement. They will share their insights with the rest of the group. To increase the value of the detailed refinement, we close the overall refinement by the attendees doing a teach-back to each other of what they learned and what is decided regarding the selected PBIs.
### **Part 2: Detailed multi-team Refinement**
Immediately after the Overall Refinement, the detailed multi-team refinement starts. This session requires strong facilitation. Ask your Scrum Master to help out! All development team members must attend. This is not an optional meeting. Anybody who holds relevant knowledge of the PBIs (such as SMEs, architects, domain model experts, etc.) should attend too. This session can take two to four hours. You will need to experiment to learn what works best in your context.
The group gets informed about the PBIs by a Subject Matter Expert.
#### **Session details**
The session starts centrally with the PO briefly (re)sharing the product vision, mission and the current Product goal. The SMEs or Team delegates who were present at the Overall Refinement introduced the selected PBIs. They also share which teams are likely to collaborate during the Sprint. There is no need for much technology, the items are on large sticky notes and visible on the wall.
the Product Backlog
When all PBI’s are introduced there is usually a short Q&A. When that’s done, the PO picks up one PBI at a time and asks the people who will refine that item. Guided by the team delegates, the people will self-organize in heterogeneous groups to further refine the PBI’s. Note that we deliberately break up the existing teams to stimulate learning and knowledge sharing. Sometimes multiple groups refine the same PBI.
You can make this a hybrid meeting by creating “numbered Stations” with a room in zoom or teams. A group that picks up an item calls the station number, so the remote attendees know which (virtual) room they will be working in.
Members of different teams collaborate in refining.
The PO, PMs, SM, and SMEs walk around and support the groups when needed. They contribute to the refinement by asking powerful questions.
Each group clarifies the acceptance criteria by creating initial designs, examples, or scenarios that describe how the PBI can be tested. Any question and input that is a prerequisite to taking the PBI into the Sprint needs to be addressed. People verify existing code if needed. The groups use the DOD here to verify if everything we need to do to meet our quality standards is addressed.
#### **Iterations**
When the groups have worked on their item for about 15 to 20 minutes, we rotate the groups across the items to continue refining the PBIs with different people. We iterate and rotate because our goal is to use the full potential of the whole group. By ensuring everybody knows most of all PBIs to some extent we create flexibility: it will make decisions easier, multiple teams can collaborate on an item as all teams will have (some) knowledge about the item, it mitigates integration issues and increases self-organization.
#### There are a number of iteration techniques:
**Partial roulette:** each group works on an item. When the time box expires, one person stays behind at the station, the other people move to the next station to contribute to the refinement of another item.
**Full roulette:**each group works on an item. When the time-box expires, all people move to the next station to continue refinement.
**Diverge and merge:**Our favorite! Each group works on an item. When the time-box expires, one person (SME) stays behind at the station, all other people split and go to a random other station. They get taught about the other PBI for 5 minutes, give feedback and suggestions and then return to their station to discuss learnings. Each group then continues refining their initial PBI.
**Teach-back:** each group works on an item. When the time-box expires, all people gather around one station where the SME explains the findings. All stations are visited sequentially. This is time-consuming with large groups.
We iterate the refinement rounds as many times as needed. Mostly two to three times is enough. Also, we stop when the time box expires. Before we end the meeting we record the results by taking pictures or otherwise. The session is concluded centrally by the PO going over the PBIs, asking for open ends, which teams are involved in doing what, etc.
During, but mostly after the session, people create items in their work management tool (Jira, TFS, or the likes) as needed.
### **The complete schedule in a nutshell**
**9:30–10:30 Prepare and set up the room**
**10:30–11:30 overall PBR****–** intro 20 min. – refine 20 min – closing 20 min
**10:30 -10:45 break**
**10:45–12:30 detailed PBR (longer if needed)** – intro 15 min – Multi-team PBR 60 min (3x 20 min diverge/merge
12:15 -12:30 closing – done (time for lunch)!
Alexey Krivitsky and Roland Flemm
---
# A practical approach to improve the performance of your agile teams
**Date:** 2023-07-17 · **Reading time:** 8 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/practical-approach-improve-agile-teams
**TL;DR:** An A-level ecosystem has teams working on features but not business objectives. Information scatters across many backlogs, work runs asynchronously, local optimization flourishes, and coordination overhead grows over time. Adding more teams makes it worse. The systemic fix is horizontal scaling — broadening team capabilities toward end-to-end delivery.
_Part 1, improving an A-level ecosystem with horizontal scaling._
The [organizational archetypes](/post/org-topologies-key-archetypes) of the Org Topologies™ map can be used to plot organization designs that we refer to as **ecosystems**. This article describes an **A-type ecosystem** for (software) product development, the prevalent dynamics in it, and the solutions to improve performance using Org Topologies™ mapping.
## Example of an A-type Ecosystem
The A-level ecosystem is a combination of organizational archetypes where the A-level archetype is most prominent. At the A-level, as per the Org Topologies™ map, the work is done by the teams at the feature level. This means that their Product Backlog contains features, rather than tasks or business initiatives. (For a broader view of why ecosystems get stuck at this level, see [*The Three Ecosystems*](/post/three-ecosystems).) However, customers do not think about application features, they have a “job to be done”, a need to be met. For example, a user might need to find the best option to travel from A to B. We can help the user by offering a product that will allow them to select a mode of transport based on relevant selection criteria (time of itinerary, cost, scheduled departure or arrival times, etc). This product consists of a series of features: set selection criteria, search, show travel options, select travel options, see itinerary details, manage profile, price alerts, etc). In the A-level ecosystem, there will be one or more teams assigned to build and maintain (a set of) features. In our example, the A-level teams are of type A2, which means not all capabilities are available in the teams to deliver a Done product. They depend on other organizational elements for shipping value to the customer. In other words, to provide a fully operational solution to the customer, we need multiple organizational elements to collaborate. This is a common situation in software development groups.
In our example, this is an enterprise business analyst group (which can be mapped to archetype C0, an individual with a whole product focus). After decomposition, the feature-level work is further refined by the analyst group before the work is picked up by the A2-level teams. Each of the teams is responsible for building a certain feature(set). There is a travel team, travel feed-engine team, customer data team, and itineraries team. These teams work with Scrum. The analysts are not organized as a (Scrum) team. They are grouped into a department based on their expertise. (This is a Y1 archetype). After the features have been tested, we need an integration team to assemble the features into one working product, the user experience team will test the integrated product for consistency, and the performance and security team will need to verify the product before handing it off to the maintenance team for going live. These teams have a whole product focus but they have a single skill as they perform only a step of the complete product development process. Below is a visual representation (an Org Topologies™ mapping) of the ecosystem.
## Dynamics of this Ecosystem
Each A2 team has its own Product Owner and Product Backlog. The specifications of the customer needs are prepared by the analysts and spread across multiple Product Backlogs. The development of features will be performed asynchronously. This is because each Product Owner can individually decide on priorities. Also, there are variations in team speed. And asynchrony is inevitable because the amount of work for each team varies. The Customer team might have little work creating a login screen and a customer profile page, while the Travel Feed team might take much more time to disclose information from a large number of external sources.
Another interesting observation is that teams will not stay idle after delivering the required functionality for a certain customer journey. They will remain busy by adding functionality to their feature that their Product Owner deems valuable (face recognition maybe?). Also, the team might propose to upgrade their code to the latest frameworks and software patterns. Strictly speaking, this does not necessarily add value from the customer's perspective, nor might this be beneficial for the other teams. Doing work that is not adding value at the whole product level is also known as ”local optimization”.
Before a working product can be shipped, the work has to pass through the C1 groups and maintenance department. There is a lot of information going back and forth (round-robin) between the elements of the ecosystem that needs to be coordinated. The dynamics can be summarized as follows:
* Information scattered across many backlogs
* Asynchronous dependencies
* Local optimization
* High-frequency round-robin of work
* Need for coordination roles
Looking at the performance of this system, we see that there is low predictability on the delivery at the business initiative level (or customer need level). Also, we see that over time, there is a growing need for coordination due to the growing asynchronicity of the work. Transaction costs are increasing due to increasing lead times.
## Resolving problems the fast way
The company’s leaders want to have clarity on the possible delivery dates of new initiatives. This is difficult due to the high number of handoffs, round robins for rework, and isolated feature focus of the teams. Which such an organizational design, the likeliness of not meeting anticipated delivery dates is high. Once this happens, a common procedure is for the leadership to summon the coordinators to report on possible causes for the delay and present plans for improvement. To speed up, it is not unlikely managers will propose to add more teams. However, there is ample evidence this does not work:
> “Adding human resources to a late software project makes it later.”
This is Brooks’ Law which teaches us that adding teams will make the system perform worse. As a result, managers will push harder on the teams, team members will get frustrated, and leadership will be aggravated because the increased cost of additional teams does not give better results. These dynamics might be familiar to you.
## Resolving problems in a systemic way with horizontal scaling
We should address this problem by looking at how the elements of the whole ecosystem interact. Managers should not waste energy trying to optimize the existing system. They can invest their time and energy more wisely in understanding the system, discovering the root causes, and considering options to redesign the system.
All ecosystems are sticky. Its elements will try to stay in equilibrium and maintain the status quo, even when it is under pressure. How does this work? First of all, people want painless and fast solutions, as opposed to finding and implementing a deeper solution which will take more time and effort. Secondly, the coordinators will be tasked by higher management to improve the system. But what if the coordinators are a part of the problem? They will most likely not see themselves as a cause for the poor performance, as this implies self-sacrifice.
In our example, we see a large amount of dependencies between teams. This problem was addressed by appointing coordinators to handle them. But was that the right solution? Did we address the root causes for having dependencies? No, we did not, because the fix did not make the dependencies disappear. Instead, we institutionalized them by appointing dependency managers, aka coordinators.
We need to think deeper and look for a solution that results in a system without dependencies, or at least reduces the most important ones. For this, we must study how information flows go back and forth when developing a product. We need to understand why these information flows are a problem. We should start by looking at the dependencies of the A2-level teams because they are at the core of delivering customer value.
The analysts, A2 teams, integration, security and performance, and maintenance groups are tightly coupled. The information between the groups round robins at high frequency: A development team hands off their work to the integration group, they raise bugs that need to be fixed by the developers, and so on. This kind of dependency often occurs and is also known as “Reciprocal dependency”. We want to reduce them as much as we can. We don’t care too much about dependencies that only pop up every so often. After all, we do not want to optimize the org design for exceptions.
We need to contain the reciprocal dependencies inside a single team or (product) group. Possible solutions to achieve this are:
* Existing team members learn the missing skill (obtain knowledge)
* We give the mandate to the team to perform the missing skill (obtain permissions)
* Automate and create a self-service solution (self-service, no-code/low-code solutions)
* We add someone with the missing skill/knowledge to the team
* We create new teams by mixing the existing single-skilled teams into teams that contain the reciprocal dependencies
The result:
In the given example, we choose to change the organizational design by recreating teams that are better set up to deliver a Done increment every Sprint. This means that each A2 development team should be expanded with the missing skills to deliver a working product. . This will dissolve most of the other groups. By doing this, we will have contained a large number of unwanted dependencies in the teams. The teams will become A3-type teams ([multi-learning](/post/multi-learning-200-years-wrong-model) with flow) and will lower the need for coordination drastically. After all, the teams do not work at the customer problem level.
## Learn More
© Alexey Krivitsky and Roland Flemm
---
# Don't Scale Agile. Descale Your Org.
**Date:** 2023-03-10 · **Reading time:** 7 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/don-t-scale-agile-descale-your-organization
**TL;DR:** Scaling agile means adding complexity to fit a broken org. Descaling means simplifying the org until agility emerges naturally. Ask: how would a single-team company solve this? Too many branches — use trunk. Too many objectives — pick two. Unclear requirements — talk directly to customers. The simpler the structure, the more transparency, inspection, and adaptation.
## Wrong questions, wrongly framed
- How can we scale agile to fit in our organization?
- How do we adapt agile practices for our complex operation?
- Which processes and roles must we add to make agile work for us?
Important, frequent and likely wrong questions. Let's explore.
## Avoid Faux-agile
Do you have one of the following in your organization?
- A PMO department responsible for resource allocation to projects?
- Regular complex multiple-day increment planning events for all the teams to ensure alignment and dependency management?
- A group of project managers responsible for removing blocking intergroup coordination issues to ensure the planned timing, budget and scope?
- A group of scrum masters, agile coaches, architects, team leads responsible for the success of agile adoption and release plans?
- Quarterly product releases that require long quality control cycles?
- "Agile release trains" with thorough agile testing at the end?
The pairs above mix pre-agile and faux-agile practices.
Take the first pair. Pre-agile practices (e.g. 'PMO') rely on upfront detailed planning to ensure smoother and cheaper execution by assigning different narrow specialists to different tasks. Faux-agile practices (e.g. 'increment planning events') add a flavor of agile — usually just the terminology — to the pre-agile way of working, without changing much.
## Avoid Scaling Agile
Consider these questions:
- How to make our PMO agile?
- How to convert the architects group into the agile way of working?
- How to ensure post-production quality control in an agile-friendly way?
These questions are based on thinking that the way things are is the way they ought to be.
Agile thinking — built a lot on top of Lean thinking — has never been about adding anything. The big idea is understanding the sources of the complexity and then rigorously and thoughtfully keep simplifying and improving.
This is why "scaling agile to fit in your organization" is accurately the opposite of what you should be striving for. The question should rather be: how do we change, simplify and descale to make our organization agile — or better yet, adaptive? This is the same trap I described in [*The Ferrari Trap*](/post/ferrari-trap) — bolting on process to a structure that needs simplification.
## Think Like a Single-Team Company
Your organization is complex and requires advanced methods to manage everything that is happening in there. That's given.
Or is it *accepted* as given? Isn't it a sum of all previously made organizational decisions?
A big idea here is to stop accepting whatever levels of complexity you have in place. And instead ask yourself and your colleagues:
> How will the problem X be solved in a single-team company?
Thinking about this question is a recipe for simplification. And it can be applied to a broad variety of situations:
- We have too many feature branches with partially done work, how do we manage them?
- We have numerous important objectives to reach this year, how do we manage them?
- We have a lot of unclarity in the upcoming customer requirements, how do we manage them?
Each of such questions offers a cross-road: either towards adding more processes and structures (more added complexity) or towards simplifying by understanding and removing the sources of the issues.
Let's use the three questions above as examples to apply this powerful simplification method: *what will a single-team company do?*
- **Too many feature branches with partially done work — how do we manage them?** Feature branches add complexity and hence ought to be minimized — or, better yet, avoided altogether. What will a single-team company do? It likely won't have any long-lived feature branches, and instead will make all the developers work on the trunk and talk to each other face-to-face to address conflicts in real time. Managing very few (or no) branches creates a simpler, more transparent production system with fast feedback. Win-win.
- **Numerous important objectives to reach this year — how do we manage them?** Focus on too many things equals a lack of focus. What will a single-team company do? It likely won't have too many objectives — maybe just one or two that are vital for overall success and painfully clear to everyone. Managing one or two objectives requires no objective-management-and-tracking system (not even OKRs). A smaller number of objectives creates more focus, opportunities for joint work, and a simpler organization. Win-win.
- **A lot of unclarity in upcoming customer requirements — how do we manage them?** Unclarity of upcoming customer requirements is expected and rather normal. What will a single-team company do? It likely will talk directly to its customers, using quick prototypes and regular small releases to clarify customer needs and the product implementation. A continuous process of getting feedback doesn't require extra roles of middlemen and makes the organization faster and simpler. Win-win.
The simpler the processes and the structures, the more transparency there is. And transparency, in its turn, enables inspection and adaptation. These are the key ingredients for continuous improvements — getting better over time.
## Simplification: Principles and Practices
### Principle #1: Broaden the view (fighting bounded rationality)
With every built fence comes a limited view. In other words, people make decisions based on the information at hand. And the narrower their understanding, the more local and suboptimal their decisions will be. The Stanford Encyclopedia of Philosophy defines this phenomenon as ['bounded rationality'](https://plato.stanford.edu/entries/bounded-rationality/).
So, how to fight non-systemic, locally optimized decisions?
What stays in the way of broadening the view to see the whole:
- Backlogs and other task-lists defined at the level of individuals or individual teams.
- Limited ownership of a technology, component, module, or feature by an individual or an individual team.
- Managers who bring the work to individuals or individual teams.
What helps:
- Defining a broader customer-centric value area (aka 'product', 'ecosystem') that includes many teams, customers and stakeholders — what I call the [three ecosystems](/post/three-ecosystems) of product development.
- Treating the value area as a whole by making all involved teams share common objectives and work as much as possible.
### Principle #2: Minimize the distance (avoiding middlemen and proxies)
*Zero distance* — a concept introduced by the Haier Group. It emphasizes the connection between the business and the end-user or customer. This has become central to the management model of the Internet of Things era. *"Business people and developers must work together daily throughout the project"* is one of the [twelve principles of the Agile Manifesto](https://agilemanifesto.org/principles.html).
So, no matter how you frame this principle, the organizations that enable their teams to learn to work directly with the customer make a difference.
Have you heard of teams claiming that they suffer from requirements changing often? Such nonsense can occur only in organizations where middlemen gather and formulate requirements — and the teams are sitting and waiting for the specs to be delivered. Then every update to the spec is seen as an irritating requirements change, a scope creep.
Once the teams start working directly with the customers, they realize that it is the *understanding* that changes — and requirements really don't exist. So, the focus shifts from preventing change by fixing requirements, to improving shared understanding constantly.
What prevents zero distance and shared understanding:
- lack of direct collaboration between customers and teams
- lack of knowledge of the customer/domain language
- lack of focus on improving communication skills
- too much focus on internal concerns (e.g. architectural view)
- too much focus on resource thinking: *"developers need to develop, not talk"*
- stereotypes such as *"developers are introverts and won't talk to customers"*
How do people get good at anything? Especially talking to others? Right — by talking to others. This comes with practice. And nothing can replace it.
To enable zero distance and improved shared understanding:
- focus on the importance of zero distance and shared understanding (making people understand how important this is, makes learning possible)
- removal of all middlemen — turning them into match-makers and facilitators
- making an effort in learning and speaking customer/domain language
- having enough time spent together regularly (developers can visit customers or invite them in for workshops)
### Principle #3: Shorten the feedback (doing more often what hurts)
Each principle here supports the others. And this principle goes hand in hand with the previous one. One of the best ways to engage with the clients is to show them how you understand things. In Scrum, for example, this is achieved with a practice of Sprint Reviews. But formal reviews must not be the only time and place where the teams meet with the customers to get somewhat delayed feedback.
Going down the learning path of Continuous Delivery is the best way we know in software development of shortening feedback loops. The [HFDS model](/post/hfds) captures this dynamic — how structural simplification enables faster feedback.
What impedes shortening feedback loops:
- planning cycles that are in lock with shipping cycles
- shipping cycles that are in lock with releasing cycles
In other words:
- Software shipments should happen as often as possible, even if your organization does big upfront planning (e.g. on a quarterly basis).
- Releasing of individual features should be done on a per-user basis, not per shipment. This can be achieved by using feature flags.
This way you won't have any excuse not to integrate and release as often as possible, even if the plans are done quarterly and not all the features are ready for all the users yet.
### Principle #4: Employ the managers (bringing them to Gemba)
Why is this important at all for descaling?
The fact is, managers will be trying to improve the system, even if they understand only a part of it. We discussed the phenomenon of bounded rationality above.
A rhetorical question. Which type of manager will be able to see the whole and improve the whole better:
- the ones who sit in their ivory towers looking at the spreadsheets,
- or the others who spend a lot of time with the teams and customers — seeing and understanding how the value is being produced, shipped and used?
The idea of a 'Gemba Sprint' takes this to an extreme by inviting managers to join the teams for several weeks and more. A truly powerful method. But you don't have to implement it in such an extreme manner. Find what works for you.
### Principle #5: Simplify relentlessly (jointly and continuously)
This principle glues the other four together:
- when the view on the problem and solution space is broadened,
- where the teams work together with the customers to improve their understanding,
- that is being constantly verified and improved with powerful fast feedback loops,
- and the ones who have most of the influence on organizational design (formal leaders and managers) deeply understand how things really are,
then true systemic improvements are possible.
And what is a true systemic improvement? The one that is not symptomatic, but cuts away the root cause.
Thus, removing — not adding. Therefore, simplifying.
> Don't scale agile. Descale your organization.
---
# Cat Paw Management (Meets Recession)
**Date:** 2023-02-16 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/cat-paw-management-meets-recession
**TL;DR:** Teams narrowly specialized in low-priority features — the 'cat paw' teams — get cut first when recession hits. Narrow specialization creates overproduction: teams keep polishing their corner because that is all they can do. In a downturn, if your team's work is not a top business priority, you are exposed. Broader skills are job insurance.
## The cat paw feature
Did you see this Google feature yet? Type 'cat' or 'dog' and watch the search results page erupt in an expensive paw-prints animation:
I never knew of this feature, before I encountered this tweet:
Although this tweet appears to be a joke, it highlights an important issue of the software product development industry that can't be ignored — in the face of the recession, the time of cat paw development is over.
Below are my thoughts on what's making this a real issue (for product development companies and their employees) and what needs to change to overcome it.
## Overproduction and running costs
First, some essential definitions.
> Overproduction (producing more goods than customers need) is one of the essential wastes classified in lean thinking, together with defects, inventory, hand-offs, over-processing and others.
It is a clear sign of process inefficiency. And overproduction itself causes other wastes: inventory of unsold goods grows, as well as the number of hidden defects in unused products.
We don't really know if the discovered 'cat paw' Google feature is more of a pet project. Or if there is a 'cat paw feature team' standing behind this piece of creativity.
What we know is that any live product feature draws maintenance costs, and this must be managed in some way. So eventually, it must be an organizational decision at Google to have cat paws built and kept running.
We like humor. And the cat paws are a good one. It also shows the customer how rich Google is and how much slack time it can afford. Following this logic, every company should want to have some form of cat paws in their products.
## Narrow specialization and unwanted cat paws
Imagine there is a team in your organization that is specializing in some sort of customer feature. Something serious and not pet-related. For instance, cross-website search and product recommendations.
A long time ago, there was no search and no recommendations, and then the company recognized the potential in increasing customer activation, retention and life-time value with these features. So to have a laser-sharp focus on this development, a 'search-and-reco' team was created. And since then, they have been keeping these functions alive and modernized.
Five years later, that team is still there. Polishing the feature, fixing rare bugs, timely upgrading the technology, adding bells and whistles — keeping themselves busy and staying narrow-specializing. This is what happens when [the scope of skills mandate](/post/teams-and-scope-of-skills-mandate) is too narrow — the team can only do one thing, so that's what they do.
To follow today's wide-spread misinterpretation of Scrum, that team is likely to have a dedicated 'search-and-reco' backlog owner who makes sure that the team has things to do. Interestingly, when such a constellation is set, that team will always believe that they are working according to the priorities. So, all Scrum checks are green.
But wait a minute, are they? And how is this really different from the cat paw feature that seems rather important for someone at Google to invest in it? But at the same time, from the viewpoint of the company's global priorities, it practically adds no value (but just draws costs):
- [Google shares lose $100 billion after company's AI chatbot makes an error during demo](https://www.theguardian.com/technology/2023/feb/09/google-ai-chatbot-bard-error-sends-shares-plummeting-in-battle-with-microsoft)
- [Some shareholders are concerned that Google's parent company is falling behind Microsoft in the AI race](https://www.theguardian.com/technology/2023/feb/09/google-ai-chatbot-bard-error-sends-shares-plummeting-in-battle-with-microsoft)
What would be the best way for the cat paw developers at Google to stay relevant? Can they get retrained to help their company in the AI survival challenge?
And can the developers from our imaginary 'search-and-reco' team learn to work on something of higher value to stay relevant for their company?
## Staying relevant (as a company and an employee)
> On Friday, January 20, 2023, Alphabet, the parent company of Google, sent a [memo written by chief executive Sundar Pichai](https://blog.google/inside-google/message-ceo/january-update/) announcing that 12,000 employees would be laid off.
Google is not the only company that lays off massively these days. We are clearly feeling an early wave of the upcoming recession. We can only hope it won't be deep and long. But hope is a poor strategy.
And companies found a way to deal with it — laying off their employees. OK, Google! That's your strategy to decrease cash burn rate and keep staying relevant. We got it.
A rhetorical question here is: who will Google fire first — a cat paw team or an AI search team? The answer is painfully clear.
So, what about us — employees of software product firms and other businesses? How can we stay relevant in the face of the crisis today and in general? (Crisis just makes societal and economic problems more tangible; the issue has been here for a long time.)
Well, our advice is to watch for the cat paws. Meaning: if you believe that you are working on something of a low priority from the global viewpoint — don't wait. Those times of relaxed feature polishing are over. We are sorry, but you can be the next one out. And this is not a threat, but a reality.
So, what can you do? Raise your concerns: don't hide, show that you care about the company's future. Raise your head and see around: stop developing the next version of the improved cat paws and start learning what's relevant for your company's business today and tomorrow. The answer is [multi-learning](/post/multi-learning-200-years-wrong-model) — broadening beyond a single craft. With AI, this has [never been more feasible](/post/shopify-ceo-reflexive-ai-usage).
---
# Human Framework Dependency Syndrome
**Date:** 2023-02-08 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/human-framework-dependency-syndrome-hfds
**TL;DR:** Implementing a framework cannot be the goal of an org transformation. HFDS — Human Framework Dependency Syndrome — is hoping a slide deck will solve your problems. Solutions must come from within. Own your change: know the gains, the starting point, the desired state, the direction, and make a conscious decision to embark.
## Frameworks are not the Problem
Recently, we recorded an episode for Zuzi Sochova's podcast. I can tell, this was the most precise and crispiest explanation of #OrgTopologies that we've done up to now. One particular aspect of the podcast that I'd like to elaborate here is what I humorously called a "Human Framework Dependency Syndrome", or HFDS. So, what is that?
Let me start from the beginning. #OrgTopologies is a visual thinking and mapping tool that helps describe, analyze, discuss and improve org designs. It is a great helper for leaders and change agents in planning and executing more sustainable and deeper org changes.
#OrgTopologies is not a framework. But rather a field (or simply a "schema" as per Dave Snowden's suggestion) on which other frameworks and org design ideas can be mapped, and then compared and contrasted.
It is important to stress this: we at #OrgTopologies are not against frameworks. In fact, we believe they can be quite useful, provided some other conditions are true. Let's see.
## "Framework Thinking" is the Problem
We are up against, what we call, framework thinking — being dependent upon a framework and hoping that it will solve all the issues at hand. This especially becomes true when an organization hires an expensive consultancy firm that comes with a slide deck that recommends a specific framework. It is when the "Framework Dependency Syndrome" hits hard.
We say this at every conference talk that we do (and it's why [management fads do not last](/post/fads-do-not-last)):
> "Implementing a framework cannot be the goal of an org transformation."
The goal of an org change is to create a different (better) organization that produces different (better) results. And frameworks (as well as other org design ideas) can be helpful tools on the journey. But they are just the means to an end.
## Unique Journey
What is an "org change"? It is a unique challenge that is specific to a given organization. It is a risky journey out to the unknown with a hope of arriving at a better state of affairs. There is no book on how to improve your organization (unless you write one after the journey is done). And there are no consultants on this planet who have done exactly the same transformation (unless you become one afterward).
We are not against any frameworks, consultants or good solutions. But what happens when an organization doesn't own its transformation? The research results are clear:
> "I know what I wouldn't have done, and that is outsourcing the problem to McKinsey… and have them find a solution. The research results are clear. The solutions must come from within the organization." — John Kotter
To put it in other words: to be successful at a change is to own it. And what does it take to own a journey? It is to know 1) the gains of the journey, 2) the starting point, 3) the desired end state and, hence, 4) the direction. Plus having 5) an idea on what it takes to get there and then make 6) a conscious strategical decision to embark on the journey.
These are the six minimal ingredients of preparing for an org change.
Is it all it takes? Of course not. The reality of the change will be different from the plans. So, continuous adjustments are vital for course correcting and staying on track towards the desired end-state.
Thus, having freedom to change the approach (framework) when it doesn't yield the expected results is essential for a successful change. And on the contrary, being dependent upon a fixed approach (framework) is a good recipe for failure.
## Own the Change
That's where #OrgTopologies become handy by helping you visualize, analyze and keep discussing the change journey: from an A to a B, from one particular org state to the other, with not so much focus on a chosen framework but on the journey itself and the goal.
Below is an illustration of one of such journeys done by a Ukrainian-based company Poster in 2021, going from Y1 to C3 — as per the map below:
Poster chose LeSS (Large-Scale Scrum) as an inspiration and a framework, but was not locked by it. (For the full story, see [*LeSS Adoption at Poster POS*](/post/less-adoption-at-poster-pos).) The desired target state of "being able to work with all the teams on anything that is important for the business" (also known as a system optimizing goal towards high organizational adaptability) was much more important than following some prescribed ideas or dogmas.
So stay sane, stay healthy and own your change. Because [the agile transformation will not be televised](/post/agile-transformation-televised) — it happens through real decisions, not through frameworks.
---
# Case Study: Studying LeSS Adoption at Poster POS Inc. with Org Topologies
**Date:** 2023-01-12 · **Reading time:** 13 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/case-study-poster-pos-org-topologies
**TL;DR:** Poster POS's LeSS adoption mapped through three Org Topologies scans: the pre-LeSS component setup (TASKS-2/CAPS-2), the initial blueprint with its flaws caught early, and the improved design actually implemented. Shows how org scanning prevented a bad intermediate design from being deployed — the assessment caught problems before the flip.
[Poster POS Inc. (or Poster)](https://joinposter.com/en) is a cloud-based SaaS automation for small-to-midsize businesses in the hospitality industry, also known as HoReCa (Hotels-Restaurant-Catering).
The business was founded in Ukraine around 2013 and has shown a very high level of resilience since then. The HoReCa industry has been severely affected by Covid-19 and by the Russian war on Ukraine in 2022. Still, the company restored its profitability and even grew its B2B clientele in Ukraine during the wartimes.
In 2021, the company has undergone serious reorganization, striving to increase its adaptability. Poster was inspired by the ideas from [Large-Scale Scrum (LeSS)](https://less.works/), such as global optimization with a whole-product focus and delivery of high-value work with customer-facing feature teams.
This case study analyzes that transformation journey using Org Topology Scans (org scans). It covers three distinguishable organizational designs:
1. Org scan of the **status quo** in Poster before the LeSS adoption, "Team-level Scrum"
2. Org scan of the **envisioned initial LeSS-Inspired blueprint** (which drawbacks we timely rethought and eliminated)
3. Org scan of the **improved LeSS-Like org design** implemented in 2021 as the scope of this LeSS adoption.
The following chapters describe these three OT™ scans in detail.
## Heads-up! Video is Available
There is also a talk by Alexey Krivitsky from the LeSS Conference 2023 featuring some of the ideas from this article:
## 1. Org Scan of the Pre-LeSS Structure "Team-Level Scrum"
Before the LeSS Adoption started in the summer of 2021, Poster had around 50 engineers in the R&D department that were structured as:
* **a dozen of development teams** varying from 2 to 6 people; teams were built around a specific technology, a component, or a feature set;
* **one separate infrastructure/operations team** of several people;
* **one small designer group**, whose members mainly worked on individual task lists to support the development teams with visuals and UI sketches.
According to the [Archetypes of Org Topologies](/post/org-topologies-key-archetypes)™, the development teams in this setup can be seen as a mix of **task-focused, component-oriented teams (TASKS-2)**and **capabilities-focused teams working on a narrow capabilities set (CAPS-2)**. What is typical for these designs is that every team had an individual team-level backlog (task/capabilities list) that was managed by a team-level "PO". Most of the teams, especially the bigger ones, also had a team lead - an interface person for the team and the ultimate solution-oriented decision-maker. The designer group can be seen as **individual task-focused work (TASKS-1)**.
Two more departments, tightly coupled with the R&D were the "client onboarding" (3 people) and "1st & 2nd-line support" (25 people). This case study doesn't go into the details of those departments, keeping a focus on R&D and its radical transformation.
The illustration below shows an org scan of Poster product department as of the summer of 2021 with TASKS-2 and CAPS-2 archetypes.
### Analyzing the "Team-Level Scrum" Org Design
According to the Org Topologies™ mapping, all the archetypes of Team-Level Scrum provide close to no organizational adaptability, as they are narrowly specialized in tasks and individual features. That was why Poster wanted to improve its org design and planned the restructuring.
The "Team-Level Scrum" org design is typical for many product development organizations of any size. It grows naturally as a company hires more people and forms new teams. It is also known as the "copy-paste Scrum adoption" antipattern — a classic case of [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds) — where Scrum is implemented as a cookie-cutter for each newly formed team. Scrum in such an organization is seen as a team-level way of working, where each team gets its own backlog and a backlog owner and starts working with iterations that are typically non-synchronized among the teams. Such an approach allows the teams to run a Scrum-like process individually. And from the team perspective, this is an efficient way of working, as it allows teams to keep focus and ownership on given product components or some narrow feature sets.
This org design is also relatively easy to implement, which is why it is so widely adopted in the industry. But as the number of teams grows, additional complexity caused by inter-team dependencies increasingly slows everyone down. Hiring professional managers and applying project management tricks just make things worse. These practices add communication layers with hand-offs, bureaucracy, and processes to an already poorly designed engine.
In such a model, even though each team has a sharp focus and might even have an illusion of progress by ticking off items from its individual backlog, the performance at the organizational level tells a whole different story. At the level of the R&D department (not just individual teams) in such organizations, we see slow delivery and low adaptability. This is a systemic view: paying attention to the interaction between the parts is as important as studying the parts.
The lack of maneuverability (teams cannot easily switch to working on new things, as they don't have the necessary knowledge and skills), causes this type of organization to hire more specialists to perform specific tasks. This makes the system even more complex and degrades over time. Our experience is that at the size of around 50 engineers, these challenges start to emerge and become painful enough to make managers want to act on them.
By the spring of 2021, the leadership team at Poster had recognized these drawbacks and was actively searching for an improved org design that would eliminate the aforementioned problems.
## 2. Org Topologies™ Scan of Initial LeSS-Inspired Org Blueprint
LeSS promotes org design based around long-lived, cross-component, cross-functional, customer-facing [feature teams](https://less.works/less/structure/feature-teams). Such teams deliver and learn much better than narrowly specialized ones. By learning to work on things that they previously didn't know, feature teams continuously improve their adaptability. Therefore, the whole large-scale product development system based on feature teams could potentially, over time, get better at delivery and better at learning.
These qualities enable faster value delivery and higher organizational adaptability:
* Faster value delivery comes from having teams that are learning to build products end-to-end.
* Higher organizational adaptability comes from teams that are learning to work on the whole product.
If the company's optimizing goal is faster value delivery and higher organizational adaptability, the LeSS-inspired org design is the most consistent with those goals.
In such an organization, the product owner will only have to _reorder_ the product backlog items to change the course of development for all the teams. No reorganization is required to realign the product development organization to adopt a changed product strategy. The product development organization is agile and can adapt to changing requirements just in time. Already during the next refinement session (in LeSS terms, "multi-team product backlog refinement" or [PBR](https://less.works/less/framework/product-backlog-refinement)) the teams will start learning that new high-value work.
At Poster, the leadership team plus all the developers and business stakeholders were trained in LeSS and its ideas before adopting this org design. It took around two months to arrive at informed consent on which org design to use. During that time, several org design blueprints were created, compared, and contrasted. The following illustration depicts a scan of the anticipated org design blueprint (later it was discarded due to the reasons listed below).
This org design consists of three "value areas":
* B2B (the core product).
* B2C (the new, innovative product development).
* Growth (product tuning to increase customer activation and retention).
The B2B area was the largest and was planned to have the biggest investment. Four feature teams were planned to share a single product backlog. Very much a LeSS-like structure. This design can be [classified](/post/org-topologies-key-archetypes) as B3.
The other two areas had fewer investments and were to have a single team each. They are capabilities-focused, as each team would have an individual feature-centric product backlog, i.e., having a relatively narrow product focus.
No changes for the infra/ops team and the designer group were planned.
### Analyzing the Initial LeSS-Inspired Org Design
As it can be clearly seen from the org scan above, several single-team value areas were envisioned (B2C and Growth), even though the leadership team at Poster had already embraced the idea of LeSS and [broader product definition](https://less.works/less/framework/product). What was driving the management to choose a sub-optimal org design? And what were the shortcomings of such an org design? Why not allow all the teams to work together on the entire product as LeSS proposes?
From our experience as org consultants, the most voiced arguments for creating narrow-focused single-team value areas are:
1. **Investments & Innovation**: "As we have never been able to work on X and Y, let's create an X-team and a Y-team".
2. **Experts & Ownership**: "There is an expert in Z, let's make her a product owner and give her a Z-team".
3. **Focus & Accountability**: "Teams need to have a clear focus and accountability for each component; otherwise the code becomes a mess".
4. **Learning & Specialization**: "Knowing everything is impossible, we value and need the specialists".
We often hear these kinds of objections when a LeSS-like org design is proposed. At Poster, it was a mix of the first two arguments that produced the initial blueprint.
Such arguments are hard to counter, as they stem from deep beliefs in the convictions of the leaders. They have not yet seen a different setup than their own, and all their experiences and career successes confirm that what they already know is working. This confirmation bias automatically disproves all new ideas.
An organizational design is the sum of the mental models (beliefs and value systems) of the people who created it. But all mental models are personal. If we want the managers to own (create and support) a new improved org design, there is not much choice but to work with them to help them see new options, help them challenge, and eventually have them adapt their mental models.
The breakthrough of discarding this model and going with a simpler org design (LeSS for all the feature teams) came from a realization that B2C and Growth can still be worked on, if needed, even with all teams sharing the same product backlog simply by setting the order of the items. Also, the people from the teams voiced a strong argument supporting wider collaboration of the teams: "Let's learn to work all together as one; isn't that why we want to go with LeSS in the first place?" To make such powerful conversations possible, during the preparation/learning phase, all the team members and the management representatives were regularly gathered for open-space-like events. That shared context helped them to uncover and collaboratively agree on many open questions. Eventually, building informed consent to start with a simpler holistic org design, is described below.
The real goal of the design activity is to create the simplest org design possible that would still work. More processes and roles can be added later when needed. But starting with a simpler org design empowers the people to own it and improve it.
## 3. Org Scan of LeSS-like Org Design at Poster
It took us several months to arrive at a simpler org design with no single-team areas. An org design that everyone was happy to start with. An org design that would barely work, but was understood by everyone to own it from day one. The improved org design would have all the feature teams sharing work and working across the product. That would classify them as WHOLE-4 teams.
### Analyzing Org Design: "LeSS for the Whole Product with All Teams"
This simpler org design covers many raised concerns above:
* **Investments & Innovation:** In this org design, when there is a need to work on Y or Z, these items simply get prioritized and put higher on the common product backlog. And then the teams (one, several, or all) will start working on them. There is no need to create specialized teams. If, for instance, the B2C or Growth topics become the most important, nothing stops the Product Owner (PO) from putting those items on the common Product Backlog and letting the teams start to refine and deliver them. This way, in every Sprint, the PO can decide with the teams how many teams should be working on these topics. This creates a fluid org structure where pairing between teams and topics happens just in time. In contrast to statically defined separate org units (value areas) per topic. This way, an organization stays highly adaptive, as it can decide to jump on any opportunity without any reorganization efforts.
* **Experts & Ownership:**Shared work on the common product backlog by all the teams leaves a lot of room for collaboration with experts. But this collaboration happens only on high-value work (just-in-time). Such a modus operandi eliminates the creation of proxy or clerk-type product owners. And welcomes the teams to work with many different experts and keep learning from them.
* **Focus & Accountability:**Good focus and a strong feeling of ownership in teams are still possible, even if they work broadly on the whole product together. This can be achieved by applying practices of [Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html), [Mob Programming](https://mobprogramming.org/), multi-team work sessions, and other means of [inter-team decentralized coordination](https://less.works/less/framework/coordination-and-integration).
* **Learning & Specialization:**Specialization is great. And learning to work broadly on a product by delivering customer value is great, too! These goals are not mutually exclusive. There is no false dichotomy, as we need them both. The LeSS-inspired org design allows the teams to pull items that they are capable of doing (utilizing their existing skills) as well as working with other teams on new things (acquiring new skills).
As is seen in the next illustration of a flow scan of Poster after the change, tight multi-function collaboration and the presence of feature teams contributed positively to shortening lead times for features. A big change for the developers was expanding the Definition of Done to include non-development activities like customer onboarding. Now, a feature is seen as done only after the first customer(s) use it. That created a powerful feedback loop for the teams and affected the way they design, work on, and deploy the features.
Weekly collaborative requirement refinement sessions became a collaboration opportunity for all the stakeholders and the experts: customers, product managers, designers, representatives of the support department, client onboarding, and engineering managers gathered with the feature teams. That accelerated the processes of forming requirements. And importantly, it has ensured a much better shared understanding of what is expected to be done. This process contributed to minimizing lead times for features not only by reducing waiting for specifications but also due to minimized rework because of improved alignment.
Note how the collaboration style of many groups has switched to facilitating, supporting the work of the heart of the new org design -- the feature teams.
## Conclusions
The LeSS adoption at Poster and its detailed org scans can be illustrated as an org topologies mapping provided below. The initial mix of **task-focused woek (TASKS-2)**, and **capabilities-focused teams (CAPS-2)**was mainly converted to an organization practicing holistic product development, with teams operating at **whole solution focus (WHOLE-4)**and optimizing for adaptivity in learning and delivery.
### Observed Adaptability and Resilience
Since the end of summer 2021, Poster and its feature teams have been operating in this new mode. They went through and recovered from the Covid-19 lockdowns. Now, as of writing this case study in winter 2023, they have spent almost 300 days serving their impressive B2B customer base during the wartime in Ukraine. They even managed to grow their clientele, a real sign of high resilience!
Business resilience comes from high organizational adaptability. And high adaptability comes from an org design that enables and nurtures it. Therefore, org design is an essential skill to be mastered by management — as the [three common organizational diseases](/post/three-common-and-contagious-organizational-diseases) show, most companies never make this leap.
© Written by Alexey Krivitsky and published with permission from Poster POS Inc.
_This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing._
---
# Org Design Defines Managers' Scope
**Date:** 2022-12-19 · **Reading time:** 2 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/org-design-defines-managers-scope
**TL;DR:** Org design dictates what kind of management is possible. Weak teams force managers into micromanagement — task breakdown, assignment, control. Strong cross-functional teams enable macro-management — strategy, stakeholders, value. Coaching product management without fixing org design first is futile. Structure enables or prevents the role.
## The role you can play depends on the org you're in
Have you ever tried coaching product management in an organization with no teams? It won't work, whether you call someone a 'product owner' or not. They won't be able to fulfill that role. But why?
Because organizational design defines and dictates the scope of work for the managers. So if you're a manager with no teams or in an environment with weak cross-functional teams – you will have no choice but manage *for* the teams. Micromanagement will be your daily job.
In contrast, if your teams are full-stack teams and even understand their shared work, there you as a manager will be able to do some true high-level management. Macro-management will be your playfield.
## Micromanagement vs. macro-management
And it is not that micromanagers are worse than macro-managers. No, this is not what I am implying. But the impact that you can make as a manager will be different depending on which type of management you are allowed to do.
And the type of management you can do – that will be dictated and enabled by the org design you're in.
Consider the diagram below:
This scheme above is a derived and simplified version of the seven archetypes of Org Topologies.
The higher the org design simplicity (vertical axis), the higher the level of management possible (horizontal axis): from project management (aka micromanagement) to product ownership (aka macro-management).
## The micromanagement side
On the micromanagement side, managers spend their days on:
- **Resource management** — direct management of work analysis, task breakdown, task assignment, control of task execution and work integration done by external managers and middlemen.
- **Dependency management** — planning work for narrow-specializing individuals and teams. Such teams can absorb a little part of the complexity as now managers don't need to dive into the task execution level that much.
## The macro-management side
On the macro-management side, the picture changes:
- **Feature management** — managing work of a real Scrum team. Such org design gets way simpler due to the creation of full-stack teams, as described in [*Three Ecosystems of Product Development*](/post/three-ecosystems). Now a team can take upon itself a complete business requirement and handle it from analysis to integration. Inter-team dependency management is still in the hands of the managers. But the managers can finally start to focus on *real* product work.
- **Pure product management** — holistic product development with Large-Scale Scrum (LeSS). The org design gets even simpler due to the creation of shared context for all the teams. The teams can not only manage their work end-to-end, but also manage inter-team shared work. Self-management is now reaching 100%. The goal of the managers is to form teams, remove organizational impediments, communicate product strategy and priorities.
## Start with the org, not the class
So if you want to pump up your managers to get better at product management – start with your org design. The structural path is laid out in detail in [*Elevate Product Management*](/post/elevate-product-management-for-business-agility). Don't start with a product management class (even with such a great one as my CSPO class), there will be no use for that.
Therefore, before teaching your product managers agile and hiring them a coach – create the right environment, consider a correct org design where teams will be able to absorb as much complexity as possible. [Extracting team leads](/post/extract-team-leads) is one structural move that frees up this space. Then your product management will flourish.
---
# Try Impact-Driven Product Backlog
**Date:** 2022-12-17 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/try-impact-driven-product-backlog
**TL;DR:** Epics lock you into fixed-scope projects disguised as agile. Instead, derive backlog items from impacts using impact mapping: goals to actors to impacts to candidate PBIs. Communicate impacts to stakeholders, not scope commitments to deadlines. This keeps you in continuous product development with fast feedback instead of shaky project management.
## The doomed land of fixed-scope projects
I've described earlier *why* to [avoid epics-driven development](/post/avoid-epic-driven-development). Now let's discuss *how* to do it. But before, here is one key reasoning on why working with epics is harmful for your product development:
When you manage your product backlog with 'epics' (which are essentially bulky items of work), then you are constantly making very difficult and expensive investment decisions. Say, if an 'epic' is worth just several sprints of work for a team, then its development costs are already in some tens of thousands of euros. These items and the associated investment decisions hold significant outcome uncertainty and execution risks. Therefore, it is not a surprise when your business stakeholders want to manage them in the most controlled way they know. And what's that? As fixed-scope & fixed-time projects.
This can also be reinforced by the product managers, who are used to communicate their roadmaps with an estimated duration of each epic along the time axis. The Gantt charts of the 21st century.
So by managing (or rather: *trying* to manage) those fixed-scope & fixed-time projects, you have quit the space of continuous product development with fast feedback. You are no longer practicing iterative-and-incremental (agile) development. You are now in a shaky project business, managing execution of a predefined output. Instead of managing for high value with less output.
## Think impact, not scope
Many product companies these days do grasp the idea of the impact. But on the operational level, they still have issues connecting impact to tactical planning. So, they typically end up with a half-backed solution:
- they use some sort of goal-setting technique (e.g., OKRs) on the strategical level,
- and still rely on an epic-driven product backlog for the tactical, operational level.
Such mixed approach implies using the modern terminology (OKRs, epics). But under the hood, it is basically no different from the same project management with guessed scope and artificial deadlines. You can say that such a blend of methods is even worse for an organization. Because some managers and employees will truly believe that they "do agile".
So, is there a way to come up with a holistic approach? Where the work can be naturally and continuously derived from the impacts? Where the benefits of iterative and incremental approach can be yielded? With the focus on learning acquired in the process of building the product? Without the process wastes that the scope management inevitable brings?
## Holistic approach to derive product backlog items from impact
You are, probably, familiar with the [Impact Mapping](https://www.impactmapping.org/) technique? Goals → Actors → Impacts.
The illustration below is focused on the right side of the mapping: from the impacts down to the candidate product backlog items (PBIs).
With this approach, the set of impact is what gets discussed and communicated to the business stakeholders, not the commitment of scope to a deadlines.
Examples of such impacts:
- make existing users recommend the product for the viral effect
- reduce dead-on-arrival user rate (with better onboarding)
- make users in Mexico use the product that doesn't break the local tax requirements
- increase rate of opened and read marketing emails
Note how these impact items are not prescribing the scope.
They might assume some product features – like the 2nd item with a better onboarding. Or the 3rd item with an implementation of the tax requirements. But they are not scope definitions per se. And that leaves a lot of space for the [empowered product teams](https://www.svpg.com/empowered-product-teams/) to figure out what needs to be changed in the product for these impacts to be reached. This is product engineering. This is good.
It is only when a team (or a group of teams in a [multi-team setting](https://less.works/less/framework/product-backlog-refinement)) gets together for a refinement session, the product backlog item candidates got identified. Those *emerging* items are derived from the impacts. They define scope. But they are small, so they don't have a lot of execution risk in them to be controlled with a heavyweight project management method. A team can *sprint* on them and deliver a handful of those in a few days, maximum weeks. Pure Scrum can be used to help manage this.
Interestingly to know, these product backlog items typically come in two shapes:
- experiments to implement and run to (in)validate a hypothesis
- specific product features to implement
So, not everything a product team does are experiments and hypothesis testing. Occasionally, you will need to build a specific feature that satisfies some external requirement (e.g., a tax law in Mexico). And it is fine. But those features are defined by the teams in refinement. And this leaves a hope, that the engineers will find some creative simple and effective solution that realizes that complex requirement with very few product changes.
The product management mantra of **maximizing outcome, minimizing output** can be finally made real.
## From impact mapping to requirement bubble maps
The above described technique links the impact mapping with the [requirements-as-bubbles](/post/requirements-like-bubbles) method that I've co-invented with a colleague of mine and back in 2018.
And by the way, since 2018 we have coached many of our clients to use this (awesome) backlog visualization method:
This technique helps to start having more meaningful product backlog refinement sessions where all the participants see the whole picture – share the same context.
This is because the 'bubble map' holds all the logical connections of larger items split into smaller ones. And this way, your regular refinement sessions turn into a continuous work of splitting large items, creating new smaller bubbles and detailing them. And then your sprint planning becomes literally a relatively simple process of finding small-enough and clear-enough items that worth building in the next sprint.
Now, connecting the bubbles with the impact mapping turns this into a holistic approach that fits all. You can track the work from the goals to actors to impacts down to specific backlog items of different granularity and clarity.
Give it a try. You will love this.
## Do you still need epics?
With the simple yet powerful approach described above, do you feel like you still require epics?
If yes, probably, it is a symptom of some deeper organizational dysfunctions that need to be addressed by your scrum masters and managers.
A common example of why an organization might believe it needs a roadmap with epics (scope and time) is an *inadequate team composition* (i.e., component teams).
In such a set-up, the teams are not autonomous (not cross-functional, not cross-component) enough to implement a meaningful product change that satisfies an impact. So in order to implement that change, many teams have to be involved. And furthermore, it is very likely that each of those teams have its own "manager who owns a list of work for his/her team". I won't call them "product owners" because they are not. They are sadly more of ["team output owners"](https://www.youtube.com/watch?v=LAvM4_JY0Ic).
So to coordinate work across those inter-dependent teams, some sort of timeline with work and time needs to be set up. And here comes that roadmap with scope commitments.
If this is your case, then you need to address the root cause – the inadequate team composition. Broadening [the scope of skills mandate](/post/teams-and-scope-of-skills-mandate) is the structural fix. Only then, the above-described method of "impacts to bubbles" will work.
## Then simplify your organization
And this advice can be generalized – if you feel like the above method of "impacts to bubbles" is far too simple and "it will not work in the real life" because of "x"…
… well, then you must simplify your organization, by removing that "x".
---
# Avoid Epic-Driven Development
**Date:** 2022-12-16 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/avoid-epic-driven-development
**TL;DR:** Epic-driven backlogs trigger three failure modes: coarse-grained prioritization that looks like projects, implicit sub-backlogs per epic that fragment the single backlog, and diminishing returns that nobody notices. Management loves the abstraction level of epics — and that is exactly why it pulls them back into sequential project thinking.
Epic-driven development is popular. Partially, such thinking is promoted by the so-called "agile" tools like Jira that have built-in features for roadmap management with epics.
So, what is the problem with the epics?
## #1 Epic-driven product backlog will promote large-grained prioritization (same as sequential projects)
Note: the text below and the images describe an antipattern: how *not* to manage product backlog.
That means that such a backlog will contain a list of epics. Top managers will love it! They won't have to understand the nitty-gritty details. But they all can understand statements, like:
- the teams are currently working on the epic 'introduce new payment methods'
- the next quarter, the teams will start the 'adapt the product to new legal requirements' epic
The management can understand that level of abstraction. And this is too bad. Because this also implies they believe know how to work with them.
Those epics represent some relatively large scope of work. They look like projects that need to be managed. Luckily, many organizations know how to do it – the scope of each epic (now project) needs to be detailed, estimated, planned and implemented.
I saw many product development organizations that should not have any projects going. But all they do is project management. Why? Partially, because they think of and work with epics. For a holistic alternative, see how to [derive backlog items from impact instead](/post/try-impact-driven-product-backlog). But epic-driven development triggers other interesting dynamics.
## #2 Epic-driven product backlog will promote implicit sub-backlogs
You have a product backlog with epics, that are understood by the management. A better visualization method — [requirements as bubbles](/post/requirements-like-bubbles) — can replace this flat-list thinking entirely.
However, the teams, in order to work with them, will have to split them up. So, here comes the split: each epic receives a list of user stories – smaller pieces of scope. Those can be ordered based on estimated relative value. And someone who manages that backlog will likely arrange them in lists.
Lists. In plural. Where each epic can be double-clicked to open a sub-view that represents a list of associated user stories.
So, how many backlogs do we have now? You can say "one with sub-lists".
I say: "as many as there are refined epics plus one". Simply put: we have many backlogs.
The big idea of a product backlog as a list in Scrum is that with a single list ordered by value, everyone knows the priorities. That creates a strong alignment and clear focus. It makes everyone work on the most valuable thing. Yes, priorities is a guessing game, but still working on guessed priorities is notably better than to work chaotically on whatever.
So with a single ordered-by-value product backlog, one can control investments to product development.
But now, with many backlogs, it is less so. You can also be hearing things like:
- "We need to focus on one thing"
- "Limiting the work-in-progress (WIP) is required for better flow"
- "Stop starting, start finishing"
So one could deduct that if the Epic A is more important than the Epic B, then working off the sub-list A before moving to the sub-list B is the right thing to do: better focus, less WIP, etc. That is intuitive, and most people would agree with that logic.
But do you see the trap yet?
## #3 Epic-driven product backlog triggers the law of diminishing return
When the epics are seen as sequential projects, the law of diminishing returns kicks in. Allow me to explain.
If the person who manages the backlogs (the sub-lists with stories) was doing her work correctly, then each sub-list is ordered by (guessed) value. Is that a safe assumption? I'd say so.
So, the people who work on those stories (s) are likely pulling them in that same order. And those people will assume they are working on the highest value first. But are they?
What are the chances that the tail of a more valuable Epic A is less valuable than the head of the next Epic B? Think of that.
It depends. But if the epics are big, that probability of that is not zero! The tail of an Epic A can be less valuable than the head of the next Epic B.
And what does that mean? Oh, but that actually means that the efforts of a team (or even many teams) can be spent on something of higher value. How? By dropping the Epic A in the middle and switching to work on the head of the Epic B!
This is exactly how organizations slip back into [fixed-scope project thinking](/post/product-roadmapping-in-practice) disguised as agile. But what is *your* guess: will the team(s) drop the Epic A to switch to the next one?
---
# Map Your Route to Mastering Agile Fluency
**Date:** 2022-11-06 · **Reading time:** 6 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/map-your-route-to-agile-fluency
**TL;DR:** The Agile Fluency Model inspired Org Topologies. Map the fluency stages onto OT: Focusing is a vertical move toward understanding value. Delivering creates cross-functional teams with continuous delivery. Optimizing and Strengthening are ongoing katas. Each transition is a paradigm shift — a kaikaku — not a gradual tweak.
The [Agile Fluency® Model](https://www.agilefluency.org/) is a fantastic model. We just love it. With this model, you start seeing your journey as a series of paradigm shifts and stages toward higher fluency in Agile:
The Agile Fluency model was an inspiration for us when we were designing [Org Topologies](https://www.orgtopologies.com/)™. So, no surprise, there are some similarities.
The axes of Org Topologies™ are two kinds of **fluency** – in delivering and learning value, along which different [**organizational archetypes**](/post/org-topologies-key-archetypes) can be mapped in the boxes. Each move from and to any box on the map is a realization of a certain **paradigm shift**. Org Topologies can be used by leaders to analyze the current state of an organization and find a roadmap for change. It is envisioned to serve as a map to navigate to the perfect state of high organizational adaptivity:
## Org Topologies™ as a Map for Mastering Agile Fluency
Having understood these two models, you shall be able to see how the Org Topologies™ can help to map a journey for Agile Fluency in a series of radical change steps ([Kaikaku](https://en.wikipedia.org/wiki/Kaikaku) in Japanese).
It all starts with _focusing_ on value. Without defining value, no agile transformation is possible. This is because the goal of such a transformation is to design an organization that discovers and delivers customer & business value continuously.
After focusing, _delivering_ goes – as a shift toward creating customer-facing self-managing teams. In Scrum terms, this is about improving upon the Definition of Done. And in the 21st century for software development teams, this means realizing the paradigm of [Continuous Delivery](https://continuousdelivery.com/).
Once the value is defined and the teams start to learn and deliver, the change isn't done yet. It is never done. As _optimizing_&_strengthening_ are continuously applied [improvement katas](https://en.wikipedia.org/wiki/Toyota_Kata) that are performed within the organization never stop improving and experimenting.
The image below illustrates this idea, mapping Agile Fluency stages onto the Org Topologies™. The next chapters detail these change steps.
Agile Fluency over Org Topologies
## Focusing
> Some organizations are winning when they realize the collaboration, transparency, and cost savings that come from _Focusing_ on business results.[agilefluency.org](https://www.agilefluency.org/)
We believe this too. On the map of Org Topologies, _focusing_ can be represented as a vertical move – a move towards a higher understanding of value.
Of course, every journey will be unique: some organizations will be capable of comprehending value at the feature level, to begin with. Others – at some higher levels, for instance at the level of customer needs and journeys. If so, they are likely to be forming [value areas](http://scrumbook.org.datasenter.no/value-stream/value-areas.html). Focusing on the value must be the first strategic move in the game of transformation. Only once the target understanding of value is clarified, the next steps of restructuring should take place to focus the teams on that value.
Structurally speaking, the focus is on creating an organizational understanding of value. It shall result in clear **accountabilities** (e.g., the role of a product owner) to manage the value at that defined level (e.g., with a product backlog). Plus, the technical **capabilities** in the form of teams focused on the value as goals and priorities.
For instance, if the target understanding of the target org design is to form a wholistic value area (a B-level of Org Topologies), then there should be a leader who can take accountability for maintaining that area backlog. Such backlog will be shaping the area investment decisions and inform the teams about the product strategy -- creating an environment of radical transparency, focus and shared ownership. Thus, any team-level backlogs of any kind would jeopardize that vision. We discussed this issue in detail in our analysis of [Spotify's Tribes and Squads](/post/tribes-and-squads-how-adaptive) model. To recap on that key message: if an organization is serious about optimizing at the level of a value area – that should be seen as an organizational cell built at the higher level, with no local suboptimization within.
## Delivering
> Other organizations require the minimal defects and high productivity that allows them to ship on cadence and receive the market boost that comes from consistently _Delivering_ when the market demands.[agilefluency.org](https://www.agilefluency.org/)
Once there is a target understanding of the value and corresponding supporting context for it (strategy, leadership, a backlog, teams), now the second part of the journey starts – to improve the delivery capabilities of the teams, individually and collectively.
On the map of Org Topologies™, _delivering_ can be represented as a horizontal move towards multidiscipline and multi-learning work with flow. Again, it is up to a given organization, how high it sets the bar and how incrementally it sees that change happening. But Org Topologies™ can be used to set the direction.
For instance, an organization might go with some stream-aligned and platform teams. That might be the right move to a better state in terms of fluency in delivering, but some thorough critical thinking is to be applied to make such improvements work continuously. Not to get stuck in mediocrity.
We have reviewed those ideas in an article on [Team Topologies](/post/how-adaptive-are-team-topologies) and highlighted some serious drawbacks of such an organizational design. Nevertheless, it is now the job of the leaders and coaches of such an organization to find the path of improving delivery of the value.
## Optimizing & Strengthening
> Yet other organizations need to anticipate the market, dance with change and receive the benefits that come from smoothly _Optimizing_ their value and applying their market expertise in new ways.[agilefluency.org](https://www.agilefluency.org/)
We love the Agile Fluency model because it is a description of a _journey_, not a static picture. There are enough static frameworks out there, that might help organizations improve just slightly or almost superficially. A good example here would be [SAFe](https://safedelusion.com/). So be aware. In order not to get stuck in some kind of agile-limbo state, an organization needs to have a **perfection vision** that will be pulling it further, no matter what.
> The mission of Org Topologies™ is to help organizational leaders to discover their long-term organizational development vector towards perfection and embark on a never-ending journey of realizing it.
We are carefully picking the words here. We are saying “development” (as a never-ending effort), rather than a “transformation project” (that can be accomplished and marked 'done').
**In this view, Agile Fluency is alike, it helps you embark on a journey. And now with Org Topologies, we want to believe, you also have the maps to help you navigate the land of agility.**
Agile Fluency® is a registered trademark of Diana Larsen and James Shore, used here with their permission.
© Alexey Krivitsky and Roland Flemm.
---
# Mapping Marty Cagan's Empowered Product Teams to Org Topologies
**Date:** 2022-10-22 · **Reading time:** 19 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/cagan-empowered-product-teams-to-org-topologies
**TL;DR:** Cagan's empowered product teams work from independent backlogs with embedded product managers — great for team autonomy, but a local optimization. At scale, isolated teams develop competing priorities that prevent multi-team collaboration on big customer problems.
_This article has been updated on November 1st, 2022 to reflect our improved understanding of Marty Cagan's model. As a result, the conclusion and mapping_ have _been changed._
## TL;DR
This is a series of articles (among them are analysis of [Spotify's Tribes and Squads](/post/tribes-and-squads-how-adaptive) and [Team Topologies](/post/how-adaptive-are-team-topologies)) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.
Empowered Product Teams is not a new concept and Marty Cagan hasn't coined this term, but he writes about [empowered product teams](https://www.svpg.com/empowered-product-teams/) a lot these days. So, we're going to use his quote from [this source](https://www.svpg.com/product-vs-feature-teams/) to set the stage:
> "...They [the teams] are _cross-functional_ (product, design and engineering); they are focused on and measured by _outcomes_ (rather than output); and they are _empowered_ to figure out the best way to solve the problems they’ve been asked to solve".
In other words, empowered product teams are not simply executing on requested features. They are not the “delivery teams” that work on whatever is spoon-fed to them. Instead, they do real product development work with the goal of maximizing the outcome while minimizing the output.
**What we conclude:**
* Per Marty's vision: an empowered product team has a product manager as a team member.
* Such a team works off an independent team-level backlog.
* This will make such a team work in isolation from other teams.
* Marty sees this as a sign of empowerment (from the team's level), and we see this as a local optimization (from the global company's level).
* A team, that works from its independent backlog, has its own local priorities.
* Per Marty's vision, a team's backlog should be set at a level of business/customer problems (not features).
* We agree that it helps a team to find more creative solutions by owning discovery and delivery as a whole.
* Though, Marty is not 100% clear if the whole team is involved in discovery, or it is just the product manager's job.
* At scale with many teams, individual teams will have local interests in solving problems that they own.
* Such individualism won't create a truly scalable product organization where teams collaborate in a multi-team fashion to share and solve big problems together.
**Such an org design doesn't lead to higher adaptivity and innovation; it doesn't create a resilient organization.** This is the same local-optimization trap that the [Ferrari Effect](/post/the-ferrari-trap) warns about — faster individual teams do not produce a faster organization.
## Empowered Product Teams in Marty's Words
Below is a short interview with Marty Cagan where he shares his views on this subject, while dropping some terminology that we will debunk in this article:
**He says a few things that we would like to highlight for further study:**
* “empowered product teams” are contrasted to “feature teams”
* from the outside they look very similar, they both are “squads” in the Spotify language
* they both have someone with a title like “product manager”
**How Marty understands what a “feature team” is and how it works:**
* the “feature teams” are told the solution, often without even explaining the underlying problem, like “go and build this feature that we need”
* then Marty describes a process when such a “feature team” designs the feature and puts it on its backlog to implement in a sprint (a very diminished view of Scrum)
* “it is all about output”, he says, “they can't be held accountable for the results”
* 20-30% success rate of such an approach
* a product manager on such a team is more like a project manager “herding the cats”
**In contrast, “empowered product team”:**
* is given a problem to solve: a customer problem, a business, or both
* and empowered means that they are given the freedom to determine the best solution to that problem
* they eventually build features too, but they measure the outcome and may try other approaches to succeed
* they might then try to redesign and even eliminate the features to find whatever works
* and because they were given a problem, they can be held accountable for the results
* such teams have a different purpose, they are to serve the customers the way it works for the business instead of _just building_ what the business wants
* and this has implications for the people on that team as their job is not just to code, but to solve – that is discovery to come up with a solution that is valuable, usable, feasible, and viable; and then build a quality implementation and ship it
* this is a much broader job for the entire team
* and the product manager on such a team is responsible for the valuable and viable aspects (the hardest parts)
* the designers are responsible for usable and the engineers – for feasible
* the product manager is more like a start-up CEO (the head of product in a startup)
These words have a lot of wisdom, the “empowered product team” do definitely provide organizations with high adaptivity and innovation, so they deserve to be placed higher on the Org Topologies™ map. More detailed analysis of this in the article below.
### **Clearing the Terminology Fog**
But that interview has some _disturbing_ parts too:
1. Marty Cagan seems to undermine and diminish Scrum to be just the implementation cycle.
2. Marty uses the term “feature team” when he tries to describe a team that is merely “coding” away the solution.
We both, authors of the Org Topologies™, train and consult organizations with Scrum and Large-Scale Scrum (LeSS) for many years. We are also affiliated with [Scrum Alliance](https://www.scrumalliance.org/) and [Scrum.org](https://www.scrum.org/) – two key bodies that represent Scrum in the industry.
So, we feel obliged to clarify the shadow of confusion that Marty's words are casting upon Scrum and LeSS.
**Our clarification on Scrum Team and “feature team”:**
1. Scrum (per its first early [source](https://hbr.org/1986/01/the-new-new-product-development-game) from 1986 and the modern [scrum guides](https://scrumguides.org/) updated in 2020) has never been described in such a way, where the Scrum Team solely implements a solution without any accountability for the results. So, Marty's words distort Scrum which is in fact a meta-framework that helps to find a suitable work process to deliver value through adaptive solutions for complex problems. Maybe, we guess, Marty refers to broken and dysfunctional Scrum implementations that he saw in the industry. But the game of football and the game of basketball are still great games, no matter if someone plays football with hands and basketball with no basket. And Scrum is a game with clear values, principles, and rules.
2. Marty's refers to “feature team” without really defining what those are and clarifying the source. We assume he means teams that are not involved in the discovery and are given pre-decided features to build. OK. But there is a well-established and not overloaded definition of a [feature team](https://less.works/less/structure/feature-teams) in LeSS. And according to that source, those teams are cross-functional cross-component long-living customer-facing self-managing teams. That are enough adjectives put together in this definition to help avoid any confusion with “delivery teams” – that just code things away.
If not for these two important corrections, Marty's vision of empowered product teams is an interesting concept to study. And now that we clarified some points and references that Marty Cagan has been making, we can proceed with analysis to see what it takes to create and sustain such organizational design.
## Mapping _Ideally_ Empowered Product Teams
In this and the next chapters, we will be looking at what we will call “_ideally_ empowered product teams”, i.e., without any anchoring to Marty Cagan's idea for now. We will do this to broaden our discussion and analysis. And then in the conclusion, we see if what Marty Cagan's claims match our understanding.
_Ideally_ empowered product teams should display a very different organizational culture than delivery teams. Formerly do _love_ the customer's problems and _own_ their solutions. Being organizational consultants, we believe that [_culture follows structure_](https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior)(in established organizations). That means that to create an environment for empowered product teams, management needs to put in place concrete structural elements. The structure goes first and affects how people see the work, do the work, and think of the work – affecting the culture of work. So, what are those structural elements required in the org design for empowered product teams?
## We will be looking at _ideally_ empowered product teams from the viewpoint of organizational adaptivity, innovation, and resilience using Org Topologies™ mapping. Our main question is always: how to create and sustain an organizational design to make such teams flourish?
The X-axis of the map is “fluency of delivering a given customer value item”. And the Y-axis is “fluency in learning the whole product”. This gives us a matrix where different org archetypes can be mapped and compared with one another. Organizational adaptivity, innovation, and resilience are increasing when moving top right. A detailed description of this mapping is available at [orgtopologies.com](https://www.orgtopologies.com/). Get yourself familiar if you are new to this. And then read on.
### **Scope of Work**
On the map, the scope of work increases going upward the Y-axes: from tasks to user feature focus, from customers to product & services focus. So logically, we can conclude that because _ideally_ empowered product teams are dealing with high-level concerns, such as customer problems and business objectives, their archetypes should be represented high on the map.
### **Team Skills**
_Ideally_ empowered product teams should be working on customer problems towards business objectives. That implies they speak both the customers and the business languages. They should be formulating problem statements, designing hypotheses, building prototypes, running experiments and measuring the impacts, and then iterating to improve.
Let's now try to understand the _empowered_ aspect. And what structural implications it has.
Being _empowered_ has many layers to this meaning. One that stands up for us as a prerequisite is to have technically sufficient teams (end-to-end). Teams need to have a high level of fluency in delivering features (the X-axes of the map) to have a short lead time, and receive and process market feedback fast. So, engineering excellence is the fair minimum for product teams to be empowered.
But not just that. Such teams need to possess more than just delivery skills. They ought to master product management, product marketing, human interaction design, quick prototyping, UX, IT operations – to name a few.
If we sum up all the skills, we are getting to a few dozen of them. Does it mean that such teams have a few dozen of team members in them? So, large teams?
### **Multilearning**
Having large teams is an option, but it contradicts what we observe to work best in software product development. Self-management, the feeling of empowerment, and process ownership are easier to cultivate in _smallish_ teams. Ideally with 5-7 members.
This leads us to an inevitable realization. Product teams must consist of multidiscipline individuals, people with primary, secondary, tertiary, and so forth skills. We need multiskill team members. This doesn't mean that everyone can do absolutely anything. But this definitely helps to understand and collaborate on the shared work that is in front of a team.
That's not new. Full-stack engineers are the kings of the software industry today. Also, the technologies such as Flutter and React Native help to minimize the zoo of programming languages and technologies required.
But there's more! Such teams are not just polishing the same feature subset over and over again. Instead, they got constantly challenged by novel customer problems and business challenges. They are product teams, for god’s sake!
How do they cope with that anyway? To be able to work on new things, they ought to be constantly learning to acquire new skills. That is inevitable. They are _learning_ teams.
We are going to refer here to a somewhat forgotten term of “multi learning teams”. This has been one of the six characteristics defined in the [very first article on Scrum](https://hbr.org/1986/01/the-new-new-product-development-game) in 1986. Surprisingly, empowered product teams stay very close to what Scrum authors were envisioning. And [modern definitions of Scrum](https://scrumguides.org/) come even closer to that.
So let us repeat this:
> Ideally empowered product teams are _multilearning_ teams that work on the product end-to-end, mastering and acquiring new technical, product and business skills.
### **Scrum Teams**
If you agree with our logic above, then we can conclude Scrum teams and _ideally_ empowered product teams are, in fact, the same. Provided for Scrum applied is the context of product development.
In Scrum, the Scrum Team has always envisioned doing the _real_ work for customers and business (not just feature delivery). A Scrum Team works end-to-end from business objectives to customer happiness, from concepts to cash.
It is the failure of our industry (and us, coaches) that we have allowed Scrum to be redefined and reduced to “executing delivery teams”.
_We_ have failed. Not Scrum. But let's move on.
### **Product Learning**
Let's try to understand the _product_ aspect of the ideally empowered product teams. And what structural implications it has.
There is one key structural element of product organizations that can either constrain or facilitate broad product thinking. It is the _product backlog(s)_. Some naïve coaches and consultants don't pay attention to the number and the level of the backlogs. But let us explain why this is a big deal.
Consider these two extremes:
1. Separate team-level feature-centric backlogs (one backlog per team).
2. A common product backlog with shared business objectives for a group of teams (one backlog for all).
Backlogs create mental filters and barriers in teams and team members. Note how different the teams will look at their work depending on whether they have individual feature-centric backlogs versus one common objectives-centric backlog.
So, what kind of backlogs do the empowered product teams should have? Do they have individual, narrow team-level feature-centric backlogs? If yes, the presence of such narrow separate backlogs will make the teams have a permanent focus on some predefined fixed set of product features. In such an organization, we will expect to find specialized teams. A “product catalog team” working on the product catalog, a “mobile team” working on the mobile app, and so forth.
It is not uncommon to see such teams in organizations. But is such an org design (with a narrow separate backlog per team) compatible with the idea of product teams working from concept to cash, from problem to happiness, that are driving high outcomes with low outputs? We don't think so.
The thing is that you can't keep working forever on something and expect to make a constantly high impact. An effect of diminishing returns will kick in eventually. And it will eventually stop making any economic and business sense to keep working on the same stuff over and over again.
Isn't that what those “product catalog” and “mobile” teams are destined to do? Sadly, yes. That's why those are _not_ product teams!
### **Broader Product Definition**
To avoid being fixed on a product aspect and face the effect of diminishing returns, a product team needs to have a moving focus. This is not the same as not having a focus. They will have to switch from one solved top-priority customer problem to the next unsolved one. If those problems affect the same product part – fine, they can leverage their present skills. But that might not always be the case.
This means such teams need to be constantly learning to work with different product parts, customer problems and business aspects. Over a very long period of time, you can expect that such teams will have worked already on the entire product and acquired a significant set of skills.
We claim that;
> Learning to work _broadly on the product_ (meaning not having a static fixed focus) is an inevitable characteristic of ideally empowered product teams.
Our understanding is that the _ideally_ empowered product teams need to share a common objective-oriented product backlog, with its items prioritized by a top-level business representative. And this view might be different from the one that Marty Cagan and his fellow consultants hold.
## Conclusion: Mapping “Empowered Product Teams” to Org Topologies™
We've looked above at _ideally_ empowered product teams – our understanding of what it takes to create and sustain an organizational design where such teams would flourish.
### **The X-Axes**
We've proven that such teams must be technically advanced and embrace multi learning. That should be the far right on the X-axis. But in some interviews, Marty Cagan claimed that a product lead is doing evidence value and viability proofs, before handing out this work to the team. And at the same time, Marty was saying that the team does discovery and delivery. We were not sure really what to make from this. Listen to the last 5 minutes of [Xagility podcast](https://anchor.fm/xagility/episodes/Walking-through-Empowered-with-Marty-Cagan-e135rne). Marty Cagan literally says there:
> “… We can have it [the evidence] with a lot of prototyping and quick testing… And when it's worth building, then it goes on the product backlog, and then the team, Scrum or Kanban, would … be delivering a product. “
Does that imply that someone (a team lead?) does the prototyping and testing? Is that done separately and without the involvement of the team (as implied by the quote from the interview above)? If this is the case, then such a team is not doing the work 100% multidisciplinary, as there is some kind of reliance on a specialist. It is not clear to us what Marty means. But this made us doubt whether a team stretches to the far right on the map.
### **The Y-Axes**
If we want the teams to work on the highest impact on customer and business problems, as we concluded above, the _ideally_ empowered product teams have to share a single prioritized product backlog. This way, when the teams pull work from the top of the backlog, they engage themselves with the discovery and delivery of something of high value. An example can be: to increase customer retention rate to some desired level. But when this goal is achieved, improving retention is no longer the most important goal (as it has already been achieved). Therefore, the teams will have to work on something different that is now at the top of the product backlog.
If we allow the teams to have individual backlogs, a given team might stay for as long as it wishes on a given topic, e.g., on improving retention. But it will also mean that the team isn't contributing to the highest impact because it ignores global priorities.
We didn't hear Marty Cagan saying anything to confirm the fact that teams in his model to share a common product backlog. In fact, he insists that a product lead (a product owner) should be on a team, deciding priorities. That contradicts the idea of having cross-cutting priorities and implies local backlogs at the team level.
It was also not in Marty's materials and explanations whether he sees multiple teams working with a single product lead (a product owner). And again, embedding a product lead (a product owner) into a team suggests the opposite. On the Org Topologies™ map, such an org design represents an A-row – teams working in isolation. This is not a place of high adaptivity, innovation, and resilience.
We conclude our analysis with the following mapping:
### **Comparing to SAFe**
In his articles, Marty Cagan contrasts “empowered product teams” with “delivery teams”. And we think we understand the distinction he tries to draw: product thinking vs. execution mode.
Marty Cagan is used to saying that they have never seen any successful product organization using SAFe. That's a powerful statement! We believe he's got a point. His observations are also aligned with ours – we believe SAFe won't create a proper environment for empowered product teams to flourish. Instead, SAFe creates disempowered delivery teams focusing mainly on the execution with [separated team-level feature-oriented backlogs](https://www.scaledagileframework.com/team-backlog/).
Below is the mapping of SAFe to Org Topologies™. Compare it with the mapping of empowered product teams: SAFe organizations and empowered product teams live indeed, slightly, in different worlds as per the mapping.
One significant difference between these models is that an empowered product team can decide which features to build to satisfy the given objective. Whereas teams in SAFe are simply given features to build.
## Towards Better Organizations (with Empowered Product Teams)
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all.
The mission of Org Topologies™ is to help _you_, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards.
1. Have the **most senior product manager be the Product Owner** (product's CEO). For a start-up of 50-ish people, this role shall be played just by the CEO. We see this role as similar to what Marty Cagan defines as a [Product Leader](https://www.svpg.com/product-leadership-is-hard/). This person needs to be: senior enough in the organization to have the necessary mandate in the context of the product work. This way, such a leader can drive the product strategy on a daily basis by making his list of business priorities clear (Product Backlog).
2. That**Product Backlog will likely be formulated as business objectives and customer needs**. That is precisely what it takes to let the empowered product teams solve real business and customer problems.
3. We suggest **avoiding creating a helpers group around the Product Owner** that typically consists of product managers and designers. Instead, make them team members of the empowered product teams.
1. Introduce product and discovery specialists right into the existing teams – avoid separate specialist groups. Thus, you will facilitate the expansion and growth of the teams to become real product teams.
2. What if you don't have enough product specialists for each team? It is better to have 5 out of 10 teams properly staffed than all the 10 teams understaffed and suffering. We believe that the fully end-to-end teams will show the difference by shipping faster, better solutions. And eventually acquiring the missing extra UX skills for some teams becomes a tactical decision.
4. **Employ the idea of multi-team work**. To offload some work from the Product Owner (product lead), try applying [prioritization over clarification pattern](https://less.works/less/framework/product-owner) and practices of [multi-team meetings](https://less.works/less/framework/product-backlog-refinement). This would minimize the bottleneck and increase the flow, allowing the single Product Owner to lead many teams and increase the business impact of their work.
© 2022-2023, Alexey Krivitsky and Roland Flemm. Org Topologies™.
---
# How Adaptive is the "Spotify Model"?
**Date:** 2022-10-01 · **Reading time:** 13 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/tribes-and-squads-how-adaptive
**TL;DR:** The Spotify model looks promising on paper, but post-transformation reality is different. Most adoptions produce non-autonomous teams with team-level backlogs and local priorities — killing value-area management. Teams remain isolated from customers and rarely reach full product ownership.
## TL;DR
This is a series of articles (among them are [Team Topologies](/post/how-adaptive-are-team-topologies) and [Marty Cagan's Empowered Product Teams](/post/cagan-empowered-product-teams-to-org-topologies)) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.
In this article, we will analyze the famous “Tribes and Squads” model (also known as a “Spotify model”) in terms of where it fits on the archetype map.
**The promise of**the **Spotify model:**
* The Spotify model sounds promising as it offers a fresh view of old problems.
* It has also made it to the large market thanks to [large consulting firms](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-journey-to-an-agile-organization).
* What is the promise of the model? Your organization will become agile by defining value areas and creating autonomous fast to deliver teams working in them.
* And there are cases like the one of [ING](https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation) that seem to prove that it works great to create a culture of delivery and innovation.
**What we're concluding:**
* On paper it might really look promising, the reality, though, is different.
* We've met companies after they've “accomplished their transformation to Spotify”.
* We see many non-autonomous teams owning some internal concerns like components and services. These teams are bogged down with interdependencies.
* They work in what is called “value areas” with an Area Lead being almost like a real Product Owner for the area.
* But each team has its own team-level backlog and a team-level output owner.
* This kills the idea of managing at the Value Area level because, with work defined at the team level, each team has its focus and agenda.
* And what's even worse is that such an organization might truly believe that it has transformed.
* But in fact, they are only using some new terminology like tribes and squads, but internally, it is all the same. Low adaptivity, low innovation. A culture of execution and dependency management.
* We've also seen cases when [SAFe](https://safedelusion.com/) applied with the Spotify model to deal with the inter-team blocking dependencies.
* Our classification is likely A1-A2. When the teams are truly great, customer-facing, and autonomous: A3.
## Archetype Map of Org Topologies™
If you are familiar with the concept of [organizational archetypes](/post/org-topologies-key-archetypes) – feel free to jump to the next part of the article, where we analyze the Tribes and Squads. Otherwise, here is a quick recap.
The map below represents two essential dimensions along which an organization can mature its design.
The first dimension, the horizontal axis, is **fluency**in**delivering a single customer value item**. Simply put, it is how much flow there is when working on a given feature: a) are teams getting blocked along the way with technical dependencies, sequencing the work? or b) are they self-sufficient and work end-to-end with the high flow? In Scrum terms, this is how mature the Definition of Done is.
The second dimension is the vertical axis, and it represents **fluency**in**learning the whole product**. It is nice when the teams are end-to-end. But if the teams are only given some low-level product work, and it is the work that they feel 100% comfortable with. You might agree that working on what you already know does not necessarily mean that you are constantly working on the highest value possible. In fact, almost certainly, the opposite is true: working on the same thing forever (or very long-term) means ignoring the business priorities.
This “product fluency” axis is the most overlooked in coaching organizations. This is why we've created the Org Topologies™. In the Agile & DevOps space, there are plenty of talks and books on team efficiency, autonomy, and team-level topologies. We claim that a high velocity of individual teams doesn't mean the entire organization succeeds at discovering and delivering customer value. High team velocity means no more than that the organization is successful in keeping the teams _busy_. Is that what your organization optimizes for? Hopefully not. If we want to create innovative, adaptive, and resilient organizations, then we should stop paying so much attention to the team-level metrics and start optimizing for long-term product and business success.
So, what is more important: the teams or the product? There is no wrong choice here. We simply need both: team-level fluency and product-wide fluency. This integrated organizational capability, essentially, is _adaptability_. It means how fluent (fast, easy, cheap, painless) an organization can discover new value and then work on it. In contrast, busy and interdependent teams with their overloaded team-level component-oriented roadmaps make it way harder and more painful to adapt to changing business priorities. So, we need to think in two dimensions: 1) product (or customer value) – around what we build the teams, and 2) teams – how good, flexible, and improving the teams are.
Now that we have a two-dimensional space, we can map different archetypical organizational designs to measure how fluent they are. So let's explore the Tribes and Squads.
Firstly, let's start clearing off the fog from these fancy names. Essentially, a squad is a _team_. A team on a mission, one can say. And a tribe is a group of teams sharing some kind of high-level common goal. For instance, taking care of the needs of a specific customer segment or the success of some customer journey(s). Essentially, a Squad serves a given business line. A more generic name for this would be a _value area_. And it is easy to conclude that the teams in a value area should share and work off a single tribe-level product backlog ordered by a tribe lead (product owner).
Ideally, all the teams in a product organization should share all the customer segments and all the journeys. That would be the C3 box on the Org Topologies map. But this is not what the Tribe and Squad model is optimizing for. It is made for creating business-oriented groups of teams (squads) to serve a business line. So let's stick with this optimization goal of the Tribe and Squad model.
## **Mapping Tribes and Squads: X-Axis**
Where do tribes-and-squad organizations belong on our map? Let's start with an X-axis (“fluency delivering a customer value item”). We have a range of options here depending on the teams' maturity. If the teams are dedicated to some architectural elements of the product (components, subsystems, services, platforms), then they are so-called “component teams”. Such teams don't deliver customer value on their own. In order to provide some real value, someone (a manager external to the teams) needs to break down a customer request, assign its parts to individual teams, and then engage in managing inter-team dependencies to get an integrated product feature. That is the first column on the map – the land of component teams and resource management.
If the teams are more advanced and fluent at delivering features independently of each other, then they can span all the way to the 3rd column. And it is a goal of each scrum master, an engineering manager, and first of all the teams themselves to make them as great as possible.
So to conclude our analysis of the Squads and Tribes model, the X-axis: maturity of such an organization is anywhere from the 1st to the 3rd column on the Org Topologies™ map. In other words, it is very much contextual.
#### **Mapping Tribes and Squads: Y-Axis**
Now, let's consider the product dimension. The higher an organization is on the map, the more customer-centric concerns the teams can deal with. Let us explain. In the A-row—those concerns are what is mainly known as “technical tasks” and “user stories”. The teams here are given requirements (scope) to work on. This is the lowest level on the Y-axis, as the teams don't have enough view to see how that work impacts the users and the business. Therefore, such teams can rarely measure the value of their changes and improve on those ideas. They can, of course, measure their velocity (the amount of work done per timebox), but this has nothing to do with delivering value. Working fast doesn't mean delivering what is needed. The teams (squads) in such an organization are in execution mode. This is like a factory, where some special people think and decide, and the others simply work on the orders. This is a major under-utilization of human capital in any organization. Do you recognize your organization yet? We hope not!
How does a more mature organization function? Teams of an organization that is one level higher on the map (in the B-row) deal with broader things. Their work is more directly linked to the impact. Those teams are aware of user personas and their customer journeys within a somewhat narrow business line (business area, value area – synonyms). They understand the customer domain within this business area and know how to talk directly with users. The teams speak the customer's language. Therefore, they are aware of how their work impacts users' behavior. Therefore, they can measure and iterate to improve their solutions. The innovation here is high, and so is the impact and learning. It is a creative environment. But can we get any higher?
The teams in an organization, that we map in the C-row, deal with business objectives. The things that are items on their overall, shared, single-product backlog are formulated in a business language. The teams understand and work on the things like higher customer retention, deeper market penetration, expanding new customer segments, and so on. The teams speak the business language and can refine those objectives-oriented backlog items together with the users, experts, and business stakeholders to ideate product hypotheses and feature experiments. Here everyone and every team dreams thinks, experiments, measures, and learns. Note how different this world is from the A-row.
The following map illustrates this idea:
So, where do we put Tribes and Squads finally on the Y-axis?
You can probably answer this question already yourself for your context. Because each implementation of the Spotify model is different. We will share our generalized observations below.
What we see in the industry is that the vast majority of the Squad/Tribe adoptions are at the lowest level along the Y-axis. That is sad news. In those organizations, there are “customer discovery” and “business analysis” specialists and roles. They understand the customer domain and the things like product impact and customer journeys. But one of the cornerstone management beliefs there is that it is “expensive and inefficient” to involve developers in discovery and analysis. And developers themselves start to believe they are not good at communicating with the customer and are happy to “delegate” that work to others. This drives a system where middle-men specialists prepare output-level backlogs for teams. This isolates teams from the world of customers and business. They stop learning. See a map below on output-driven vs. outcome-oriented organizations.
## **Our Conclusion**
It is not up to us to judge your org transformation… But if all the above is true and the squads (teams) are kept focused on the outputs and have individuals backlog, then they have a very limited understanding of the outcomes. Such an organization is clearly in the A-row of the Org Topologies™ map: from A1 to A3.
### **Agile Transformations: Expectations and Reality**
Interestingly, if you read some well-written [materials on the model of Tribes and Squads](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-journey-to-an-agile-organization), you see there things like “a team structure mostly aligned to customer and … user journeys” and “dedicated teams to grow selected businesses”. Such an org design would classify at least as an outcome-driven B-row of the map.
In reality, though, when we go and talk to organizations after their “transformation projects” are “successfully accomplished” and the consultants (and the budgets) are gone, we see unexpected things. We see the structures and processes that are incompatible with the ideas of “teams aligned to customer user journeys to grow selected businesses”. We see low-level maturity on both dimensions.
Often there are teams working off individual backlogs full of “pre-groomed” low-level “stories”. Stay there for a sprint or two, and you will notice that the teams frequently get blocked by each other. They are not end-to-end cross-component teams, so there is a lot of waiting, groaning, and wasteful dependency tracking. A lot of managers-coordinators-and-pushers too.
Moreover, because each team is led by its team-level work-output owner, those teams are kept busy working on narrow aspects of a product. Be it a component, a subsystem, a product capability, or a microservice. Have you seen teams such as “search service team”, “mobile team”, “user registration team”, “reports team”, “data mining team”, and “instant messaging team”? These are just some examples. Those names imply that the teams are fixed (forever or at least long-term) to those product parts. This means that the teams will be working only on what they already know. That may sound alright as the teams have a steady, narrow focus and can apply their existing skills effectively.
But do the search, the messaging, or some other product parts always need to be worked on and improved? But what if those backlogs are full of work only because they exist? Or because it is someone's full-time job to fill those lists in? And do we assume that all the changes and improvements of those product parts (like reports, mobile apps, microservices) are always and equally top priority from the viewpoint of the customers and the business? That can't be true. Priorities do change. Users change their minds. Business expectations mutate. Strategies shift focus.
Generally, in such organizations, each team's focus is very narrow, but the organizational focus is spread too broad. Things are moving slowly, and a change is hard. Don't get us wrong. Organizations with such a design function. They do deliver value to their customers and stakeholders. But because of everything that is said above, they are lacking constant market innovation, sharp business focus, and high organizational adaptability. Every change of strategy is a tragedy, not an opportunity. Your organization can do better. And we as an industry can do so much better, too!
### **Towards Better Organizations (with Empowered Product Teams)**
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all.
The mission of Org Topologies™ is to help _you_, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards.
So, are we against squads and tribes? Of course, not! If you can envision your target state, any intermediate state can be a good next step. We just want you to keep going, keep growing.
Below is some advice on how not to get stalled, stuck, or lost on your agile transformation journey toward perfection when applying the Tribes and Squad ideas:
1. **Manage the product backlog at the tribe level**by someone who is a knowledgeable and respected domain expert with power and budget.
2. **Make that leader the tribe's only product owner who gives work to teams**. Promote analysts and other specialists back to the squads as team members.
3. Having the above-mentioned in place, **strive for creating an environment where all squads of a single tribe work together, have a feeling of shared work.**
4. Squads then should **meet regularly to agree on how to pull items** from the single outcome-oriented backlog, respecting the product owner's priorities.
5. This way, the squads will be **sharing work and learning together**, enriching organizational capability to innovate and adapt.
6. The squads and its product owner (the tribe) and the general management of the organization should **work together to remove systemic impediments** – things that are getting in the way of implementing the above five points. This way, the tribe as a whole will be improving over time. And so is the organization.
© 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.
---
# In Search of Adaptivity Fit
**Date:** 2022-05-04 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/in-search-of-adaptivity-fit
**TL;DR:** Adaptivity costs real money: iterative practices, new roles, cultural shifts, consulting. Benefits are invisible at first. The default argument — our market is stable, we are fine — has two gotchas: stability is never permanent, and adaptivity compounds over time. Organizations are naturally adaptive until something internal starts impeding them.
## Imagine an Adaptive Organization
This article is a part of a series on [Org Topologies](https://www.orgtopologies.com/) — a map to make your agile transformational journeys thoughtful and continuous.
Can you imagine an organization in which, to adapt to a new strategy, one needs just to re-order items on a single organization-wide backlog? Wouldn't it be awesome if the entire organization would react like a living organism to a change in an environment — flex all the muscles, turn, and start immediately moving in the new direction?
Groups of people are inherently highly adaptive. A few weeks ago I was in the Alps looking for free-ride adventures. Our group had a leader and a rough plan of where to go and what to do. For several hours, we were having fun doing exactly what we were planning to do, but then the sun came out, the snow condition changed, and the risk of avalanches increased. So we moved to more northern-facing expositions, also staying at lower angles. That was a natural thing to do — to adapt.
Organizations (being groups of people) are adaptive too. By their nature. Think of this: at some point in time, a particular firm didn't exist. People who are now called the staff had been doing something completely different elsewhere. Then a business idea emerged, then the first team got assembled, and now we have these hundreds of people working there and everyone contributes to the value with her personal traits and skills. Isn't that miraculous?
Organizations can remain adaptive as they grow and mature — unless something from within starts to impede their ability to see and react as an organism to new information, to changes in the environment. These internal impediments often take the form of [three contagious organizational diseases](/post/three-common-and-contagious-organizational-diseases) — silos, shrunken Scrum, and autonomy blockades.
So let's talk about how to nurture and preserve adaptivity as organizations grow. But first, let's consider why adaptivity is something organizations would want to pursue.
## Costs of Adaptivity
When most agile consultants try to sell "agility" (meaning higher adaptability or better adaptivity) to organizations, they typically mean one key benefit it can bring: being able to change the course of product development when the market changes. That is a vital skill for an organization, won't you agree? So if it had come for free, everyone would have had it. But it comes with a price that contains several cost parameters:
- learning and mastering an iterative and incremental approach
- changing habits and policies to rely on empirical process control
- introducing new roles to sustain those new processes, like Product Owners, Scrum Masters, etc.
- and consulting to make it all work
So as you see, increasing adaptivity is not for free — it has its costs. And what makes it even worse, its immediate benefits are hard to see, as this is a long-term change that requires cultural and structural transformations.
This all makes it a tough sell from all sides: the promised benefits are invisible at a glance, but are already costly from the beginning.
So a strong argument against that change is likely:
> "Hey, we don't need that because [pick an option that fits the context] a) our market is not changing that rapidly, b) our clients don't change requirements too often, c) we are in a stable niche, d) and we've been able to survive past course corrections. And we are just fine the way we are."
There are two gotchas in this thinking that I'd like to highlight:
1. "Being fine" is fine — unless there is another company on the same market that is getting finer and starts beating you. So likely you don't want to be just fine based on your past standards; you probably want to be the best (or at least better than before) at what you're doing. And that requires constant work on yourself. A constant strive for perfection. A constant change in how you're running things.
2. Even if you believe that you are in a relatively stable environment (congrats!) your plans might go south (oops!) because of planning and/or execution failures, for instance. And this is not intuitive: even when the surrounding environment didn't change a single bit, you might need to adapt and do course-correcting actions to improve execution that has gone wrong.
So there are at least two good reasons to consider wanting more adaptivity, even if it is not for free and the effects are not immediate. In the age of AI, this becomes even more urgent — [AI-native startups moving at 100X](/post/ai-native-startups-100x) are setting the benchmark your organization will be measured against.
## Reactive Reasons to Adapt
There are numerous situations when an organization would benefit from being adaptive — to react to certain things:
1. to changing market demands.
2. to feedback on unchanged (but missed) requirements.
3. to unfulfilled plans turned unrealistic.
4. to discoveries that are more promising than the older ideas.
Notice that only the first case is about external change. The other three situations are caused by various inner forces: misunderstanding in requirements, failure in plan execution, and insight or learning that happened while correctly executing a good plan.
And from the list above, I bet, a sudden market-initiated change is the least frequent. So what does that mean? It means that being adaptive is vital, no matter whether you consider your environment stable or not. And this is without even taking into account the *proactive* reasons to be adaptive — the kind of [multi-learning](/post/multi-learning-org-design-pattern-ai) that turns teams into genuine problem-solvers rather than feature factories. But that's another story.
---
# Agile Transformation Will Not Be Televised
**Date:** 2021-04-30 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-transformation-televised
**TL;DR:** PowerPoint-driven agile transformations produce change theater, not real change. Making slides and making decisions require different skills. Instead: find pockets of agility already working, agree on a single broadly defined product, build a real 100% product organization around it, and keep improving. Deep and narrow beats broad and shallow.
> *"You will not be able to stay home, brother. You will not be able to plug in, turn on and cop out. You will not be able to lose yourself on skag. And skip out for beer during commercials, because — the revolution will not be televised."*
>
> — from "[The Revolution Will Not Be Televised](https://www.youtube.com/watch?v=QnJFhuOWgXg)" by Gil Scott-Heron
## Agile transformations don't exist (in foresight)
I mean it. And it is true. At least partially. Let me borrow 3.5 minutes of your time to explain myself.
Many organizations right now (as you are reading these lines) are spending a huge amount of time preparing slide decks and roadmaps to lay down their plans for the upcoming "agile transformation". That's a PowerPoint-driven transformation. It won't be televised.
In most cases, if you visit those places and ask around, no one really can explain in simple language what exactly is to be transformed, how, and what's important — at what costs. It takes no balls to send PPT decks around. The opposite is true for real transformational decisions — like, for instance, dismissing the project management office. I've seen so many PPT-driven transformations leading to nothing because of a lack of real management will and courage to make strong decisions. Again — making slides and making changes require different skills.
In some cases (banking, telecoms) these "transformational projects" come down from the parent companies, in a form: *"thou oughtest get transformed, within 3 months, and by the way, here's the paid consultant with a slide deck to teach you how"*.
My personal experience over the last years (being that paid consultant) while trying to help several large financial and automotive institutions: that top-down, lack-of-leadership, slides-driven approach just doesn't work. It creates a lot of confusion, and actually — from my experience — it will 100% guarantee a lack of any real transformation, but nice-looking slides.
It is such a commonly observed theme that we consultants even came up with a name for it: *"an agile theater"*, or more broadly *"a change theater"*.
An "agile transformation" — a.k.a. a "change theater" — done as a project (with goals, budgets, deadlines) misses the whole point of creating a culture of continuous improvement. This is [Human Framework Dependency Syndrome](/post/human-framework-dependency-syndrome-hfds) in action — hoping a slide deck will solve your problems. The project will get finished, the budget will get spent, the managers will get their dreamt-of promotion (or fired and re-hired). But hey, nothing changes really. [SAMO](https://en.wikipedia.org/wiki/SAMO).
## Deep and narrow over broad and shallow
That's it. Instead of going big (doing a "transformational project") and ruining the whole idea of people taking proactive steps to improve their working life — which is the heart of the agile movement — stop, breathe, think, and take it slow.
Here is one million dollars worth of consulting advice for you, for free:
1. **Find the pockets of agility you already have.** Figure out what already works in your organization by finding the "pockets of agility" and the signs of true change leadership happening. That's your goldmine. Any large functioning complex system started with a small functioning system. Find the small good seeds of agility before planting a large garden.
2. **Agree on a single, broadly defined product.** Something important that enables your business in some aspect. This can be a product serving a revenue stream or a business line. Or a particular service offered to a given customer segment. You name it — find it and agree to work all together to improve it.
3. **Build a real, 100% product organization around that product** (the *deep and narrow* principle I admire) — starting with good old plain-vanilla Scrum. For a real-world example of how this plays out, see the [LeSS adoption at Poster POS](/post/less-adoption-at-poster-pos). But instead of scrumming with several teams in parallel, treat all the engineers involved plus their stakeholders as a single product team doing Scrum. Focus on quality and customer value. Engage a coach or consultant with deep know-how on product development work. Invest in the culture of doing it right from the beginning. That's transformational.
4. **Keep improving.** And God forbid calling it an "agile transformation".
Liked this line of thought? Check out the [Large-Scale Scrum adoption principles](https://less.works/less/adoption/three-principles).
## Yet, the agile transformation exists — but only in retrospect
And while doing the four steps above, you are actually doing real deep change on multiple levels at the same time. With AI now in the picture, the urgency is higher than ever — [agile was the homework, AI is the assignment](/post/agile-was-homework-ai-is-assignment). And that's the best there is.
Looking back, of course, your followers would say: *"Hey, that was an agile transformation!"*
But you'd just shrug your shoulders, make a funk move, and sing:
> *"The revolution will not be televised. The revolution will be live."*
>
> — [Watch the video](https://www.youtube.com/watch?v=QnJFhuOWgXg)
---
# Org Design Models, Part 4: Product Slicing
**Date:** 2021-01-19 · **Reading time:** 9 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/organizational-design-models-evolution-managerial-part-4
**TL;DR:** Five ways to slice a product organization: functional, sales funnel, business lines, one-business-one-product, and adaptive product areas. If you can avoid slicing altogether, you win — nothing beats a single backlog for adaptability. But if you must divide, the adaptive model preserves the most flexibility while giving teams focus.
## Where we are in the series
The [previous part of the article series](/post/organizational-design-models-evolution-managerial-part-3) concluded that if the choice of organizational design is product-centric, then there are at least 5 sub-models at your choice which you can use to approach "slicing" your product organization:
1. **Functional slicing**
2. **Sales funnel slicing**
3. **Cutting along business lines**
4. **One business = one product**
5. **Adaptive product areas**
One word of caution — if you can avoid slicing altogether, you're the winner. Nothing beats the adaptability of a product company that is guided by just one (overall) Product Backlog. In such an organization a change of business strategy is just a reprioritization exercise on the Product Backlog. Can you imagine that level of agility?
But if you believe you're too big, and you need to "divide and conquer", then the described 5 models are at your disposal (not all of them though are leading to the same level of adaptability, so read on to learn the details).
## Organizational Design Options in (Vertical) Product Development
### Functional slicing
Does the product have one feature related to payments, another with messaging functions between users, and a third with exporting complex data into some sort of reports? You can fall for the "feature equals products" bait and build a product organization of three teams, each of which deals with its own features. And many companies do — because it looks simple.
Most often, in such an org design, each team is assigned its own "product owner" (I write in quotes and with lowercase — read on to understand why), which each have their own "backlog" (also in quotes and in lowercase) and control development priorities within their feature areas. In total, we have three product owners and three backlogs in a blueprint of such an organization.
The advantages of such a system are the strong *focus* of the teams. And no one has ever been fired in the history of IT for introducing more focus. Everyone seems to love that. Here the teams have a focus on functionality and code behavior as likely different teams will be working on different codebase pieces.
Disadvantages are hard to spot from first sight. But they have long-term consequences on the organizational ability to learn and adapt:
1. Low adaptability towards changes of org strategy and/or market needs.
2. Local optimizations happening at the team level.
Let me introduce this with an extreme example. Imagine that from the next quarter, the company's strategy changes significantly and the features of complex data export, which are gradually growing into a complex user's workflow, become 10 times more important than all other product features altogether. That is, each item of the "workflow backlog" (even the lowest ones) is more important than the topmost item of other "backlogs". Yet every PO continues to massage her own "backlog" and feed their team from it. So each backlog is optimized but locally.
If we'd only had the single common true Product Backlog for all (here with a capital letter and without quotes), then it would have become transparent what's important and what's not so. But there is no such thing as a Product Backlog, but instead, such a company lives in the area of feudalism and internecine wars for their small land plots.
How adaptive is such a company? Will the "product owner" of the "messaging product" give her team to the "workflow product owner"? That's a rhetorical question.
In my experience — no way she would do it. The thirst for status, the fear of losing a job, the ability to invent features, and politics-playing skills — all of this will work contrary to the common sense, which shouts: "everyone should work on the workflow and nothing else!" So nothing will change and the company will be *slowly* doing what is so *important*, while simultaneously spending resources on what is not important at all. That drastically reduces adaptability. Yet increases the local focus.
Can we stop choosing and strive for the focus AND adaptability? This is the central tension explored in [*In Search of Adaptivity-Fit*](/post/in-search-of-adaptivity-fit).
### Sales funnel slicing
If feature-based slicing does not stand up to serious criticism, then conversion-based slicing is more difficult to dispute — it sounds serious and business-like. No one has been fired for trying to optimize the sales funnel (or doing some good lip service to it)!
Imagine a company has come up with a three-part funnel: one focuses on converting guests into leads, the second part is for leads-to-payers conversion, and the third one is for returning users and repetitive sales.
"Let's divide our product organization into three verticals" — oh, that sounds reasonable.
"How about growth hacking then? All competitors have one" — asks someone who is rather fashionable.
"Oh, let's add a fourth stream then. It will be more adaptive and more flexible. They could use Kanban too."
(Noticed how we've now switched the discussion to operate in *streams of work*, rather than *customer value*? That is so common.)
If we ignore the Growth-thing for a moment, the problem with such a funnel-cutting is that the optimization of one conversion (for example, guests-to-leads) can potentially have a negative effect on the next one. How come? I've seen companies buying customer email databases or partnering with other resources, generating many fake leads that were never destined to become paying users. You can be creative here! That's probably an advantage of such org design — it promotes creativity.
But *creativity*, as well as *focus*, are only good if applied to *value* creation.
So here we too can easily fall for the trap of fast local optimization. After all, in fact, intermediate (partial) conversion rates are only good for analyzing conversion losses. Yet in order to optimize business income, one needs to look and work across the entire value chain.
Again, in different periods of a product's life, different funnels may have different development priorities. And here we are no more flexible than when slicing by functionality. So adaptability here is too very low.
### Cutting along business lines
Now, this is more interesting. The business lines are not fictional entities. They are hard-coded in the P&L. So we're dealing here with real stuff that can (and shall be) optimized.
In Russian, we have a saying: "the one who pays bills, calls the tunes". So business lines (however you define them) are legible entities to get to decide on development investments.
An example of organizations where this fits perfectly into their modus operandi is service organizations, like banks. Here, for example, the credit-and-risk department can quite legally be developing a custom IT solution for its needs — it is an internal product. The question of leadership can also be managed here quite reasonably, as each department has its head.
The bottleneck of such a design will be the eternal questions, such as "who is responsible for shared libraries and common infrastructure?" So establishing a separate horizontal entity, such as a "platform" or a "core" team, is not as rare as we would like to see.
Sigh... While those centralized components will be the source of many incoming dependencies. Hence, one could decide for its own "platform backlog" with a "platform product owner" (noted the quotes and lowercase here?).
What considerations would this so-called "product owner" take when prioritizing her backlog? ROI? No. Business needs? No. She doesn't operate with those terms. She will be prioritizing based on internal yet understood things, for example, the availability of a back-end Java developer. That guy will pull all the "ready" Java tasks into his dashboard to focus on in the next month (have we discussed the evil side of focus yet?)
Sadly, a business-oriented org design, that we've started with, has been now totally undermined and compromised. In the end, the louder-screaming business owner will be getting her things faster. Yet when we say a *"sound org design"* we mean something different.
### One business = one product
This list of product slicing models that we're going through is ordered by *decreasing* usage frequency. That is, the lion's share of the cases that you are likely to see are already described above. And they are full of flaws if you've been following my analysis.
It's a pity since this option "one business = one product" is devoid of the above-mentioned disadvantages of local optimization traps and low adaptability. In this regard, everything is very good here — there is one common Product Backlog for the entire organization, and it is controlled by one powerful Product Owner.
Criticism of this approach often rests against the lack of understanding of its implementation — how can one Product Owner work with all the development teams that are in the organization? Can she be driving dozens of developers at the same time? How does the process look like? How do you manage the staff, workload, teams, processes?
The answer here is ***yes!*** This can be learned. It is not simple, but it can be mastered. And you likely need mega-experienced process experts, AKA facilitators and Scrum Masters who are real Scrum and Large-Scale Scrum practitioners. Fortunately, all the information is open, described in books and [case studies of real companies](https://less.works/case-studies/index) that work this way.
And you can do it too — unless you have reached the limit of mental overload of the Product Owner (that is at around 7–10 teams).
### Dynamic product areas
This is an extension of the previous case, only you have *dozens* of teams. In this case, whether you like it or not, you have to chop the ideal "one business = one product" idea into subproducts, or what we sometimes call "product areas". And, obviously, it is important to do this without falling into the traps of the "slicing by functionality", "sales funnel" or "business lines" described above.
But how? *Dynamic product areas* are here to solve this dilemma for you. Yes, people need focus and some more or less unchanging domain area — so that the engineers become experts in it. Therefore, product areas can be seen as boundaries of various sets of domain knowledge within your business. For example, working with large clients differs so much from working with smaller ones that it takes months for engineers to enter this domain. Then, naturally, we want those who already figured it out to stay in this area (at least for a while), developing the product for the benefit of these users. But this is not to be confused with a business line approach described above. This is all — one business, we just cannot know everything, and entering a domain requires investment, so we're creating these domain knowledge pockets to ease the pain of needing to learn too much to be minimally productive. It is a healthy balance between the need for learning and being highly productive.
Importantly, there is still the single common Product Backlog guiding all the areas and all the teams. But its items have different domain colors, and some teams are comfortable with only a few colors. The presence of the single common Product Backlog keeps adaptability high at all times. The world is changing, so is the product strategy as the product must adapt to reality. How does this organization cope with this? Dynamic domain areas can grow, shrink (meaning teams can switch between them), and get their goals adjusted — that increases the instant need for learning. That later will result in the ability to deliver more value.
Then we get a pure adaptive organization that constantly learns to seek and deliver customer value. At the same time, it has a clear structure and does not need transformations and reorganizations to change the course — the change of the strategy is made by the Product Owner constantly as the elements of a single common Product Backlog get reprioritized.
Sounds like a phantasmagoria or maybe, like a path of development?
## Summary
We looked at six completely different org design models. We walked through a modern history of a company and observed in time how structures, processes, and managerial thinking typically develop.
It is worth noting that there is always some kind of org design. But it is not always thoughtful of and does not always have the right fit to the needs of the business. So the essential task of management, as I see it, is to form meaningful structures and processes, regularly review them, watching and noticing growth crises.
It is also important not to be led by fashion and "management schools" — [management fads do not last](/post/fads-do-not-last) — but to look critically at the current org design and radically revise it as the company grows, exploring alternatives and experimenting.
And without the involvement of employees who understand the real problems on the ground, and without the managers deepening into the realities of the company (practice "Go See", Gemba), meaningful org design is impossible.
---
*Big thanks to Yaroslav Novoselov and Dmitry Nezabytovsky for helping to improve this article.*
---
# Org Design Models, Part 3: Satellite & Product
**Date:** 2021-01-18 · **Reading time:** 8 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/organizational-design-models-evolution-managerial-part-3
**TL;DR:** Satellite development is the shortcut that avoids real transformation — spinning off a side team to innovate while the core stays unchanged. It fails because the innovation cannot integrate back. Vertical Product Development is the real move: cross-functional teams owning end-to-end value slices, guided by a single Product Owner.
## Where we are in the series
This is a series of articles discussing models of organizations and the mental models of the leaders who design them. The first two models were described in [Part 1 of this series](/post/organizational-design-models-evolution-managerial-part-1):
- **(Simplified) Startup.**
- **(Centralized) IT development.**
Further development and complications were discussed in [Part 2](/post/organizational-design-models-evolution-managerial-part-2):
- **(Horizontal) Component development.**
- **(Overcomplicated) Project development.**
Now we are to understand ways to actually start taking things in real (not illusionary) control:
- **(Side) Satellite development.**
- **(Vertical) Product development.**
## (Side) Satellite Development
Everything was good (for years) in terms of operational efficiency until competitors (damn them!) started to release those new modern "apps" and compete with us with new unprecedented business models.
**This is an innovation crisis.** As you know, the optimization of operational activities is contrary to the level of innovation, creativity, and freedom of creativity: more focus on predictability reduces the capability to innovate. See if you can agree with me here — striving for creativity is challenging if you have three levels of programs in a project portfolio with five-year budgeting cycles...
But then a *garage-level company of "two friends and a dog"* enters the market and begins to gnaw off loyal customers from our stable business. What is really unclear is why are they leaving us? So what if there is an app, so what if mobile traffic in the country is now 70%, so what if everyone uses Netflix, Zoom, Airbnb, and Miro... Well, maybe there is *something* in these weird new business models?.. And then the first-minute doubt about the correctness and steadiness of the chosen development path creeps into the heads of the management (but the suddenly remembered amount of cash on the bank accounts and the number of client emails in the database quickly relieves the uncomfortable tension).
> *"Well, OK. To change so to change — let's put together a team of 5 people, quickly release the app and forget it. By the way, in this case, we can add Scrum to the list of project management tools, our PMO has been talking about this for a long time. Let's Scrum! And yes, we will of course use our current Redmine project tool to reduce costs."*
>
> — an internal dialogue in the head of the CIO
This is how what I call satellite development is born. It's like product development, but not at all! This is a development of something on the side, and unfortunately, this something at first (and for a while) seems like a real product.
This is an attempt to escape from the inevitable transformation, an attempt to procrastinate. It is a pilot without the possibility of scaling and accordingly to learn something. Since it is one thing to write an app on the sidelines, and another is to transform your view and learn to look at your "core solution" as a product, and not as a set of software systems, services, and components... This is a wasted chance with good intentions.
Remember some pages up at the beginning of the article series (about 5–10 years ago in the life of the organization), when, being a startup, all its software was a *product* that solved all the business problems? It was maybe hard to say what it was — but it was one thing that was developed and run for the sake of the potential business opportunity...
That was not only forgotten but even people who remembered that were also forgotten. And the presence of engineering groups who individually own the "components", "systems" and "platforms" plus the fat layer of *project mythology* does not allow looking at this whole thing as a product (or at least a family of products), not to mention finding the real owner of this product from the business side.
So the only possible experiment here really is to play on the sidelines with something new and in new ways ("oh sweet innovations!"), and the existing legacy, on which the operating business is based, shall continue to do as before (after all, it is already being done highly operationally efficiently). And it's just scary to break something that works!
But it is important to understand that the iOS App is not a product. Pause to think of this. It is a channel, an interface, an "additional keyboard" for the customer to access the value your business offers. This is not the product itself. This is essentially another frontend layer. Nothing more.
With all the seeming benefits of piloting a new app on the side without breaking the existing functioning organization, the company will just see how many dependencies such an app will have on its core systems. And later even more dependencies upon trying to reach the feature parity — requests for features that are in the old product, but they are not yet in the app, which breaks the user journey.
It should be worth noting that such Satellite Development is not a new model, it is still the same Project Development paradigm since for a project organization, writing an app is just another project. So do not expect that in this approach the company will learn something radically new about itself, except perhaps how "everything is tightly connected and complicated", and that "we have not been even able to release a simple app for a year now!"
## (Vertical) Product Development
*A product is everything that an interface provides access to, plus the very same interface.* And if the word product does not seem large enough or is overloaded in your industry with other definitions (for example, "banking product" is not what I mean), then you can try using the term "business product".
The choice between operational efficiency and innovation is what one calls a "false dichotomy" — it is a false choice. A healthy organization that understands the dynamism of the world needs both and at the same time. You can't be successful long-term if you can't keep innovating, and at the same time you can't be successful long-term if you can't operationalize your innovations.
Remember above I wrote about a "seesaw" of organizations that are swinging from being a startup to wanting to be enterprise and back. Embracing product development is a turn towards the startup field — being adaptive, innovative and hungry for more cool stuff. With such an organizational design, each product vertical (and ideally there is only one for the entire corporation, since most businesses in fact have just one business line) is a startup in its essence — a product organization encapsulating all the functions required for success of a business case.
Transitioning to a vertical organization structure by building product (a la startup) groups within a corporation, in my experience, does not happen naturally or evolutionarily. A revolution is required that is driven by a reformer from within. This is a transformation of the organizational structure through rejection of everything unnecessary and wasteful that has been accumulated over the history of the company. It is simplification of the structures and processes. It is difficult, slow, thoughtful and expensive work. But at the same time, it can be done without any special risks and also gradually. For example, [one recommended strategy is forming product groups one by one](https://less.works/less/adoption/three-principles.html), gradually melting down the centralized IT department and forming new permanent cross-functional and cross-component teams with a business focus with volunteers — people who believe in success.
But only experienced consultants are not enough here — for such radical changes in the organization's structure, a *managerial will* is required. And a prerequisite to this is a desire to deeply understand the causes of excessive complexity and the reasons for aging and slowing down of the organization. According to my observations, 2% of organizations are capable of such feats. But, as Deming said, "You don't have to change. Survival is optional." The dinosaurs need to die out. I'm sorry.
But, if you are thinking about product development, then it is important to understand the entire palette of options and traps of thinking. Defining and dividing product verticals is a separate big topic, which also greatly influences future org design. The most common models are the following:
1. Functional slicing
2. Sales funnel slicing
3. Cutting along business lines
4. One business = one product
5. Adaptive product areas
The [next and final chapter](/post/organizational-design-models-evolution-managerial-part-4) of this series will explain these five options of (vertical) product slicing.
---
# Org Design Models, Part 2: Component & Project
**Date:** 2021-01-17 · **Reading time:** 6 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/organizational-design-models-evolution-managerial-part-2
**TL;DR:** As IT departments grow, they split into component groups around technology layers — backend, frontend, core, test, ops. This architectural segregation creates Conway's Law in action. The next stage, Overcomplicated Project Development, tries to manage the resulting dependencies with even more process. Both are management crises masquerading as normal growth.
## Where we are in the series
This is a series of articles discussing models of organizations and the mental models of the leaders who design them. The first two models were described in [Part 1 of this series](/post/organizational-design-models-evolution-managerial-part-1):
- **(Simplified) Startup.**
- **(Centralized) IT development.**
Now we move on to the further development that is likely as the organization keeps growing:
- **(Horizontal) Component development.**
- **(Overcomplicated) Project development.**
- **(Side) Satellite development.**
- **(Vertical) Product development.**
## (Horizontal) Component Development
Component development — the formation of functional engineering groups around technology layers (databases, backend systems, various layers of integrations, frontend channels).
With the growth of the IT department, it will eventually split into groups owning "their own" parts of the architectural layer (architectural segregation). In such a model the correspondence between the "software component" and the "selected group of people" becomes almost unambiguous. So there will be a "core", "backend", and "frontend" component with their corresponding specialist groups, as well as "test" and "operation" functional groups — all with their line managers.
So we come to what is often called "component development" — a logical extension of the previous model, which gets intensified and crystallized with the increase in the complexity of systems and the number of engineers. In this kind of organization, the design of the software system and the design of the organization itself become mirror images of each other. This phenomenon is sometimes called [Conway's Law](https://en.wikipedia.org/wiki/Conway%27s_law) — or rather the [myth of Conway's Law](/post/myth-of-conways-law) as we have argued elsewhere — and it works both ways, where one reinforces the other.
"Components" can be called differently in your domain — "platforms", "core layers", "data buses", "systems", "software complexes" — yet they have the same essence. But no matter what they are called, they describe the architecture of the system, the internal properties of the product, not the use of it by users. This is the techies' jargon, not the product/business one. That is why the involvement of business stakeholders in such an organizational design is complicated: there is a certain mental barrier between business needs (functionality for the client) and what engineers and their groups work with (architecture layers).
> "Why do I need to know about the bloody business needs, give us tasks for the backend!" — says a hypothetical programmer working full-time with the backend internals of the system.
This is how the split between the two worlds of business and IT intensifies. They begin to speak different languages and wield different metaphors. Remember the Startup model in Part 1? Back then we all used to speak in one common language — how did it become that we so quickly forgot we were able to communicate?
And now there are two ways to approach further organizational design — transition to product development through the transformation of teams (more on this below, in the corresponding chapter of the article), or the introduction of "translators" by adding layers of project managers, analysts, and architects.
If you use the second approach: imagine a business request for development comes in, and you have five component groups, each of which owns its own part of the system. They all have to do something in the code to implement this business request. How do you manage it? You obviously need a group of people who can analyze and stratify the business request into engineering tasks, then formulate and deliver them to performers. Then you need some people to regularly make sure that this work is being done, to resolve conflicts and dependencies between groups, and to ensure that "at the end" it works.
Congratulations — you've just designed a more complex org system, one that lacks transparency, has low adaptability, long queues, slow feedback loops, and a different focus for different groups. This is getting even more difficult to manage.
But the important thing to note is this *added* complexity. It is not caused by the inherent complexity of digital development. It is caused by your org-design decisions. It all could have been different if you hadn't started looking at your organization as a mirror of your IT systems and building departments around the layers of the system. Now, what engineers are working on and what the business needs are orthogonal things. And that world cannot hold without translators, analysts, managers, pushers, and controllers…
## (Overcomplicated) Project Development
…because this complexity needs to be managed.
Despite the constant communication between parts of the organization and the scooping of water from holes (which is why such an organization is still afloat), business goals are being met in one way or another, the number of business stakeholders continues to grow, and the number of diverse requests, of course, also.
If earlier directors and line managers inside R&D managed to hold the offensive and dam back the flood of requests, now they are simply not able to cope anymore. Everything is aggravated by the growth in the number of IT heads — there are already 70+ engineers in the company (and the level of process chaos is growing exponentially) and the constant increase in the complexity of systems. Ironically, hiring grows as compensation for low development performance, and development performance gets worse the more the IT department grows.
We see the next (second) **management crisis — the difficulty of managing dependencies between parts of an organization and the process**. Solutions? Project management and a matrix structure.
The PMO gets institutionalized. And the corresponding jargon gets introduced. Typically, the development processes are practically no different from the previous phase, except that the work is now clustered into fictitious entities called "projects", each of which is assigned a project pusher (project manager). But where the projects are pushed to remains unchanged — it is the IT department, the same as before, with all the same approaches and issues of release and neglected quality.
The number of projects keeps growing. In order to understand at least something, "projects of projects" are set up — "programs" and "project portfolios". Internal workflow and the level of hierarchical reporting grow. Program and portfolio managers appear, respectively.
This is a mental add-on, an overhead. And it doesn't help business and development communicate more effectively. Despite all the redundant reporting, project management tools, reporting automation, and attempts to clean up the mess, the PMO does not become an effective communication interface between business and R&D. It is an outgrowth of an organization, an appendix, a world of illusion that dulls organizational pain. After all, you must admit — when there are projects, there is a feeling of control.
On the good side, such a structure can withstand tens of hundreds of engineers (and even thousands), and unlike the previous two approaches (Startup and IT Development), it is scalable, so the next crisis is very long to come.
So, unlike the previous stages of crises and the further development of companies, this stage is very stable and can last for years (in some cases, even decades) even if a company keeps growing. The stability of this phase is also associated with the lack of new views on organizational design at the highest level of management — everyone is familiar with project management even from the cradle, so everything that happens seems to be "common sense without alternatives". And the presence of such volumes as PMBOK, and such stable organizations behind them as PMI, gives confidence in the chosen path.
> An example of companies that are at this level: businesses that need a significant amount of software (banks, telecoms, for instance), but treat software utilitarianly — it is not yet placed at the head of the business model (possibly due to the slowness of middle-aged managers in realizing the level of digitalization of the world) and is only needed as a service for solving business problems.
## What's next
We've covered four models so far:
- **(Simplified) Startup.**
- **(Centralized) IT development.**
- **(Horizontal) Component development.**
- **(Overcomplicated) Project development.**
In the next chapter we'll walk through the remaining two:
- **(Side) Satellite development.**
- **(Vertical) Product development.**
So read on in [Part 3](/post/organizational-design-models-evolution-managerial-part-3).
---
# Org Design Models, Part 1: Startup & IT
**Date:** 2021-01-16 · **Reading time:** 7 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/organizational-design-models-evolution-managerial-part-1
**TL;DR:** Six org-design paradigms for software product development, from Simplified Startup to Vertical Product. Some grow naturally as headcount increases; others require a management mindset transformation. Part 1 covers the first two stages and the first management crisis — when the startup structure breaks under growth and centralized IT emerges as the default fix.
> *"You can't always get what you want. But if you try sometimes, well, you might find. You get what you need."*
>
> — The Rolling Stones
## A map of the management battlefield
**What kinds of different organizational design paradigms are known for software product development? How do organizations develop over time, and are there any shortcuts on this journey? What should company management and executives know about all this?**
In the role of an organization-agility consultant, I often help my clients — in particular leaders of mature organizations — find a *better organizational design*: a *better fit* between the structure of the organization and the needs of the business. This is a non-trivial task with no obvious right answers. What makes it even more difficult is the lack of a clear *common basis* — terminology, vocabulary — and *shared understanding* among practitioners. So if this article takes off, it can serve as a map of a management battlefield with its core strategies that practitioners can relate to and build on top of.
This article shares some of the most commonly observed models of how organizations that produce software get typically structured. Such organizations don't necessarily *sell* the software they produce (though that is one option); they ought to produce some software that is necessary to run the core business — whatever that is. And because nowadays arguably any business comes with some sort of custom software it relies upon, this article can hopefully be useful outside of the classical IT crowd.
I'll share six somewhat distinctive models of organizational design (or management paradigms). Some of them are linked to each other with *evolutionary* ties — that is, they grow naturally on top of each other as headcount and business desires grow. Others require some sort of *transformation* of the management mindset to jump out of the status quo.
Since organizational design (*how things are structured*) is inseparable from process (*how things are running*), we will consider six schemes that combine the organization and operation of software production:
1. **(Simplified) Startup.**
2. **(Centralized) IT development.**
3. **(Horizontal) Component development.**
4. **(Overcomplicated) Project development.**
5. **(Side) Satellite development.**
6. **(Vertical) Product development.**
In this article I will guide you through a typical evolutionary path from a Startup to a mature Product development organization, with its unavoidable crises on the way. I will describe how one hypothetical organization goes through these models one by one as if they were stages of development — but they are not. It is important to keep in mind that this storyline is just one option from a wider set of possibilities of how companies might decide to develop. I'm following it for the sole purpose of more coherent storytelling. But for you, the reader and leader of an organization, it should be clear that companies are not destined to follow any given path; the path being taken is the sum of all cornerstone decisions made.
So I do believe in the *free choices* of managers who consciously (or unconsciously) make them and by doing so keep forming their organizations — what we call an "org design". This article is about the causes and consequences of these uneasy management decisions, and also about some of the irrational thinking that kicks in on the way.
This is also not an article about "waterfall vs. agile" — that would have been an overly simplistic view of things. Here you will learn about the broader field of decisions that the *designers of organizations* are facing.
## Startup
You cannot start exploring how mature organizations function without having a quick look at how startups get formed, from the viewpoint of their structure and process. Understanding startups is essential to understanding "mature" organizations, because in the life of every organization there are times when the company wants to add processes, structure, and rules — and times when it wants to "hack around and just get things done". These movements are like a seesaw: today a company wants to be more like an enterprise (dreaming of more standardization and operational efficiency), then more like a startup (dreaming of more results and better alignment), then more like an enterprise again, and so on. These back-and-forth movements are periodic and are provoked by temporary growth crises (more about them below), so understanding what makes the "startup dream" so powerful is important to understanding the dynamics of any mature organization.
In a nutshell, an idealized startup-like style of software product development is an organization of cross-functional work of a small number of people around a clear business strategy. Usually with direct access to clients and end-users. Note how close this is to a Scrum prescription of a cross-functional, colocated, dedicated, full-time, customer-facing team. This is not a coincidence. The goal of Scrum, if you will, is to help organizations return their lost youth…
Nowadays startups are also seen as lean operations — thanks to the Lean Startup movement that has really become the norm and the status quo of how entrepreneurs operate their young ventures. Startups naturally don't have excess resources to waste, so they have to stay laser-focused on a specific mission: for instance, getting traction from a wisely chosen customer segment. (Nothing stops more mature orgs from taking on this lean approach — their resources are limited too — but for a startup this is a clear survival mechanism creating strong alignment and focus, not an artificially fixed "project budget".) From a clear shared focus, other good things are derived: goals, expectations, metrics, milestones — shared by everyone involved, typically by the entire team. Until the moment this unity starts to compete with locally-set goals driven by some organizational changes.
"Sales" is most commonly the first department being formed that immediately starts to drift away from the cross-functional core (R&D in the future). This can be related to the "noisiness" of salespeople's work, their extraversion that happens to be somewhat uncomfortable for the IT crowd, and other common beliefs — but these are just stereotypes. The only reason this starts to happen is because someone decides this is to happen. Remember the "free managerial choice" thing we talked about a few paragraphs back?
Isolation of the sales department can lead to consequences whose negative impact can only be clearly seen in the long run. Examples I've seen include a desire of salespeople to close contracts at any cost — including negative profitability, agreeing to unrealistic customer demands for impossible product functionality, setting wishful deadlines, and so on. From that moment, R&D will be forever blamed for "low quality of estimates and missed deadlines". The consequences such decisions bring are usually hard to fight, because they turn everyone into being extremely busy, overstressed, and unhappy with whatever outcomes. And when everyone is like that, there's no time for clear wide system thinking, and a shortcut-looking mindset kicks in. Then it quickly becomes a habit and a vicious cycle only makes things worse with every loop.
The real task of a competent org designer in such a young company is to try to avoid this split at any short-term cost. This is the same structural trap that the [three common organizational diseases](/post/three-common-and-contagious-organizational-diseases) describe — once the split hardens, it becomes contagious. This implies practicing long-term thinking at the cost of "quick cheap wins" that are so tempting at times when cash is burning low. Keeping everyone in the same boat of a common business cadence, making everyone believe in shared goals, practicing cross-department collaboration with the clients, holding a focus on the value delivered — these are some vital practices for keeping the startup spirit alive. If management can withstand this first fight and keep the naturally-born product culture and client orientation of a startup, then with upcoming growth such an organization can jump over the next few models described below — Centralized IT Development and Project Work — right into Product Development. And if not — the journey will be long and winding.
It is worth saying that the odds of sustaining the product culture in a growing startup are very low — like 1–5%, in my observation. Why? Being a *maverick* sounds cool only if you read about one; no one really wants to be one, and what I see all around are mere unthoughtful copy-and-paste solutions. Top management of a company copies the ideas of others, even though the others are not really doing any better. And then joint tuition in "Exec MBA" schools only strengthens their belief in collective righteousness. So it seems all the business forces of the universe work together to keep management isolating software product development from the rest of the organization, from the business. Why? Simply because others are doing so.
And that's the beginning of a downward spiral that is pushing IT to the underground floors of organizations, literally. (For a visual mapping of where these structures land on the adaptability spectrum, see [*The Three Ecosystems*](/post/three-ecosystems).)
## (Centralized) IT Development
At this stage of development, the initial business model — or its adapted and improved increment — has already been validated by a positive market response. The company gets its first real investment round. The appetites of shareholders start to grow faster, and with them the stress and pressure on IT. Growth in terms of more headcount is kicking in.
This soon leads to the **first management crisis** — a crisis of direct management. It can be seen already with 30–50 engineering staff. This is a growth crisis dealing with the fact that the power of personal influencing connections, which used to glue it all together with fewer people despite various issues, is no longer enough to serve as the center of gravity. Smaller cracks in the organization, created earlier, are now opening wider and wider with every new person hired.
The situation worsens as the execs get themselves separated from the realities of work and busy with "strategies" — sometimes out of sheer incompetence in solving real organizational issues (sorry to say). To compensate for the lack of their involvement, a special squad of specialists enters the company doors: process guys "with a good track record and prior enterprise process experience". They start to form a new elite — vice presidents. Each department now has its own VP.
Of course, here we see the emergence of the VP of Engineering. His presence reinforces the IT silo with its opaque processes, lack of agility, and the known problems of "missing deadlines and bad estimates". But now IT has *more expensive* excuses, stated with the proud voice of an enterprise.
> "We've overgrown the startup, we are a mature organization now, we need to focus on processes," says the VPoE. "You want clear estimates from us? Fine, I'll handle it. But to control our estimates we need to limit the continuous flow of change requests coming down on us from the chaotic sales team. We need better engineering processes."
From this moment on, the organization is in a trap. The appetite of the business elites will keep growing (resulting in more pressure). Marketing folks will tap into new prospects and new customer segments (resulting in less focus). But R&D will be fencing itself off from uncomfortable requirement changes (by the way, it's not the requirements that get changed — it's our understanding that grows).
The dynamics described above lead to a mutual lack of trust between the business and the IT side of the org. What would fix the issue is the presence of a business stakeholder holding these two worlds together, acting as a leader and owner — what would introduce a real Product Owner as we see this role in Scrum. But ironically, it is highly unlikely to expect a business stakeholder to risk his skin and step into the IT side. It's too dangerous for the career, as IT constantly fails. And because no business stakeholder will be willing to lead and guide software product development, it will stay in the hands of engineering heads, who will be focused on constant operational issues — fixing software holes and ruling permanent release dramas (due to constant pressure and rush, software quality has been degrading, making it harder to introduce changes). So the IT heads will be busy dealing with all this chaos (for which they were hired in the first place), thus having a lack of strategic and business focus.
Can you spot the vicious cycle here?
An example of companies that might be facing these kinds of challenges: businesses (for instance, e-commerce) that need some custom software to operate — maybe even a lot of it — but unable (yet) to see and embrace software production as their direct activity. Also, businesses that try to limit the amount of software they actually need — a few dozen IT staff plus several vendors.
By the way, using a vendors-only approach might not be such a bad idea here — provided the vendors are real software professionals, they can showcase to the business ways of how to guide software development.
## What's next
We've just covered two models:
- **(Simplified) Startup.**
- **(Centralized) IT development.**
A real company can stop at this level when there is no need or opportunity for growth. But in the next chapter of this article, we will watch our sample organization passing through the next phases:
- **(Horizontal) Component development.**
- **(Overcomplicated) Project work.**
- **(Side) Satellite development.**
- **(Vertical) Product development.**
So read on in [Part 2](/post/organizational-design-models-evolution-managerial-part-2).
---
# Agile Product Roadmapping in Practice — How We Ran It at IPLAND
**Date:** 2020-03-21 · **Reading time:** 7 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/product-roadmapping-in-practice
**TL;DR:** A two-day product roadmapping workshop, end to end. Roadmapping is a process, not an artifact — the point is building shared understanding of the bigger picture, not producing a fixed plan. Everyone holds fragments; nobody holds the whole. This is not PI Planning — it is collaborative sense-making about what matters for the product long-term.
This piece describes a way of building long- and mid-term product plans, written up after a two-day workshop with the Ukrainian product company IPLAND and their product *effie*.
## Roadmapping — is it a map of the product's future?
*"Responding to change over following a plan"* is a core line of the agile philosophy. It does not mean *no plans*.
Plans or response to change? Predictability or adaptivity? Long-term strategy or tactical goals? — picking between two essential halves of one whole is what science calls a *false dichotomy* and Buddhism calls *dualism*. Both halves matter. One does not work without the other.
Plans are useful. Updating them as new information arrives is also useful. This is common sense. We do it in life: we plan vacations long in advance, knowing the weather may force a tweak. We plan a renovation knowing the money and patience will run short and something will have to be sacrificed. We answer the "where do you see yourself in five years" question knowing full well it will turn out nothing like we picture today.
Even so, lifting your head from the desk and looking into the distance is a useful exercise. Product roadmapping is doing it not alone, but together with colleagues and leadership.
## Roadmapping as a process
The word "roadmap" — or as politicians like to say, "the road map" — is not quite the right metaphor.
On a road map every detail is drawn at the same level of resolution, regardless of how far away it is. That's not what we want when building plans for a product. We don't want to spend time fleshing out things that are very likely to change before we get to them. We want to clarify things as our horizon of understanding widens, without burning effort now on details that will move.
So from here on we'll say *roadmapping* — to underline that it is not an artifact (a roadmap), but a process (*~ing*) of clarifying goals, milestones, metrics, and the other things that matter for the product.
Artifacts come out of it, of course. They help drive the process and make shared understanding visible. But they are a side effect, not the point.
## Roadmapping for the bigger picture
However good your organization is at agile, however hard you push cross-functionality inside Scrum teams, however tightly customer representatives, the Product Owner, analysts, and developers work together — information will always be somewhat fragmented, and the *bigger picture* will live in pieces, never wholly with anyone.
But when the bigger picture is missing, there will *always* be a shortage of details to act on. The classical fix — strengthen the analysis phase, write more documentation, sharpen the input requirements — counter-intuitively makes the situation worse. Don't believe me? Run a small experiment.
- Ask every workshop participant to take a sheet of paper and a pen and draw a sofa.
- When the sofas are ready, walk around and add feedback: it should be small, red, and stand in the middle of the room.
- Now ask each person to draw a framed picture hanging on the wall behind the sofa.
- The clever ones will smell a trap and ask for detail — dimensions, position, orientation. Provide them: rectangular, landscape, hanging on the left.
- Now ask them to add hair. Everyone gets stuck.
- Then show them the photo from the Dalí museum below — and I promise it all clicks into place.
- Now ask them to draw a second picture on the wall. They'll do it without further clarification.
- Ask them to add a fireplace-nose. No trouble at all.
So what's the punchline?
When the bigger picture is clear, you need far fewer details to do the work correctly. And the inverse holds: when the bigger picture isn't clear, no amount of added detail will get you the quality you want — only rework and frustration.
That's why product development needs sessions for building the bigger picture from time to time. Those sessions are product roadmapping.
## Is roadmapping the same as product backlog refinement?
Product backlog refinement (often called *grooming*) is a useful joint exercise to work out details. Mature Scrum teams have learned to do it on a regular cadence. It is a chance to look past the current sprint, peek at what's ahead, and dig into upcoming work.
This joint work between the Product Owner and the team helps maintain enough ready detail to forecast feature dates, plan architectural improvements, and avoid duplicate or throw-away work.
But the refinement horizon is normally limited to a few sprints — a couple of weeks to a month and a half, at best — and the meetings are squeezed into the flow of normal delivery, usually an hour or two a week. From experience, that's not enough to see the bigger picture. Questions pile up, the vision blurs, fragmentation grows.
Refinements don't deliver a coherent bigger picture. Remember the exercise with the Dalí photo: when the picture is missing, details will always feel insufficient. Refinements without roadmapping are weak. Refinements *after* roadmapping click — from the larger to the smaller, from the general to the specific. (For a complementary approach to breaking work down from impact rather than scope, see [*Try Impact-Driven Product Backlog*](/post/try-impact-driven-product-backlog).)
## Who attends a roadmapping session
Since the task is to assemble the product puzzle from scattered pieces, we bring everyone into the room — both the people who hold the pieces and the people who will benefit from seeing them.
We call this group the *extended product circle*. Depending on the product and the company, it includes:
- marketing
- sales
- customer care
- product support
- development teams
- product management
- project management (where this function exists)
- top management and executives
For IPLAND and their product *effie*, that came out to about 20 people, and we worked together for two days.
One exception to the "pick a representative per function" rule: regardless of how big the development team is, or how many teams there are in a large-scale product, we strongly recommend bringing *every* engineer. Attendance is mandatory, and they will most likely enjoy these sessions a lot.
## Is roadmapping the same as PI-Planning in SAFe?
Not really. Or rather, not at all.
Even though for large-scale development (hundreds of people, dozens of teams) we still recommend inviting every team member to the roadmapping session, do not confuse this with what SAFe calls *Program Increment Planning*, or PI-Planning.
What's the difference?
PI-Planning in SAFe (as I understand it) targets a detailed delivery plan for the next several sprints and a commitment from teams up to management. In our experience, that process has upsides — the same bigger picture, goal discussion, tactical clarity — but its downside is producing internal "contractual obligations" between teams and management about detailed sprint plans.
In my view, that reduces system flexibility and pulls in the well-known negative effects of waterfall: the process fixes both time *and* scope, and that's dangerous. To meet the plan, developers have little choice but to open their "secret toolbox of corner-cutting" — clean code, tests, refactoring — and start trimming. Quality and motivation suffer. Then everyone suffers: management, customers, end users.
So PI-Planning in its pure form is *not* what we want. Really, it isn't.
Roadmapping is about collectively clarifying product goals and strategy. The output is clarity of the long-term perspective onto which the teams and the Product Owner will, sprint by sprint, day by day, feature by feature, thread effective tactical decisions. No one promises anything here. What can we promise each other about the future anyway? Only that it will look nothing like what we picture today. So we paint with broad strokes.
## Roadmapping — what exactly do we discuss?
As I said above, the point is to pull together the scattered pieces of the bigger picture. That covers four vectors:
1. Understanding of the current state of the product (except, of course, for a true greenfield where there's no product yet).
2. Business strategy and goals.
3. Knowledge of the market and user needs.
4. Technical constraints and risks.
The session format really comes down to bringing these four vectors together. How? Simple: give the people who hold information about each one a chance to present what they know. (A rough two-day schedule follows.)
Sounds banal? It is, probably. That doesn't take away from the remarkable effect we see in roadmappings with clients.
## A rough two-day schedule
**Participants:** the whole product circle.
**Workshop goals:**
- Bring four vectors of product development into one place: current product state, users, business, engineering.
- Build a high-level strategic product map across the three vectors at the epic level.
- Start placing epics on time horizons (summer, autumn, winter).
Both days run 10:00–19:00.
### Day one — gathering information
We bring in everyone involved in building, growing, and supporting the product. That can be 20+ people. The day's program is built so that every group can present its current understanding of the product and where it should go.
- **10:00–12:00 — Product demo and recent evolution.** Get everyone on the same page about the current state. Take a moment to be proud of what's done. Start thinking together about what's next.
- **12:00–13:30 — Current picture from the business side.** Describe the product vision from a business and market angle.
- **13:30–15:00 — Extended lunch break.**
- **15:00–17:00 — Insights from the market and users.** Outline key persona types and their needs so this vector enters the roadmap.
- **17:00–19:00 — Aggregation, open questions, buffer.** Time to digest and rework what was gathered.
### Day two — building the product map
At IPLAND, day two mostly worked the development team and its Product Owner, drawing on the cross-functional input from day one.
- **10:00–12:00 — Building the product roadmap.** Visual map work.
- **13:00–16:00 — First-pass refinement of near-term ideas.** Mini-training on writing good backlog items, with a lot of practice on the freshly drawn roadmap.
- **17:00–19:00 — Lessons learned.** A whole day in — time to widen the circle again, look at the roadmap, and close out.
## What product roadmapping buys you
**More alignment.** Everyone in the product process — stakeholders, business representatives, management, engineers — gets the same picture. That creates alignment on strategy, on long- and mid-term goals, and makes sure people walk in the same direction.
**Less management and process.** Strategic alignment lowers the need for management overhead (and documentation in particular). When goals are agreed and clear to all, far fewer written details are needed to keep shared understanding intact.
**More self-organization.** Clear goals — endorsed by everyone in the room — let teams and engineers make day-to-day decisions and experiment freely without waiting for sign-off from above.
**Better products.** That's the real goal, of course, but you only get there indirectly. We believe regular roadmapping sessions (our recommendation: once a quarter) make for better products. This is especially powerful when paired with [multi-team PBR](/post/cross-team-collaboration-multi-team-pbr) to take the roadmap into tactical execution.
---
# Agile Teams Working From Home, WTF?
**Date:** 2020-03-21 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/agile-teams-working-from-home-wtf
**TL;DR:** Distance is a thing of mind, not space. You can be remote in the same building and close across continents. The key question is not how to be productive at home — it is how to build a virtual office where teams feel present, connected, and keep improving. Think virtual office work, not remote work.
## Yes, and you'd better start building good habits earlier
In the space of modern management — *agile* — we value face-to-face communication because it is proven to be the most efficient way of conveying ideas that we know of. It is so much easier to clarify misunderstandings and build a shared vision when talking than when emailing or chatting. I've spent the last 15 years breaking down every wall and barrier, physical and metaphysical, that stops individuals from creating environments of rich and diverse collaboration.
Are those times now gone for good? Did the last week change the world of work so that there is no space for rich face-to-face communication anymore, because everyone is working from home? (For a research-based perspective, see my later synthesis of [remote work studies](/post/remote-work-synthesizing-the-studies).) Is the agile mindset now obsolete? Do all the agile coaches turn overnight into proponents of distributed work and remote coaching? Hope not. Sure it is not. Quite the opposite.
## Remote work still sucks — and it is not about the distance
I remember my first job as a junior developer in 2001. I shared an office with a dozen other software engineers on the 2nd floor. I was given a project and assigned someone with testing skills to help me ensure quality. She, my testing lady, sat on the 4th floor. Same building. A real distance of some 50 metres. About 60 seconds from desk to desk when running up the stairs (I did run a lot of stairs those days). We used ICQ to chat and FTP to share compiled binaries.
Despite our short distance I felt remote and lonely. Especially when she didn't return my ICQ messages or set 'away' when I needed to come up and see her immediately. We were remote even while in the same office, quite close to each other. On my next project I got another test engineer and he sat on my floor, four doors down the hall. Far closer. Far easier to reach. Yet the same issues.
Four years later I joined a company opening a dev centre in Kyiv with all the management and client representatives based in Odense, Denmark. Video conferencing was already a thing, internet channels were almost good enough, and we used that opportunity heavily — hours per day. Two offices, 1,500 km apart, four hours of flight and train commute. But, boy, we were really close then — *mentally* close.
## Proximity over distance — virtual doesn't necessarily mean remote
Most of us have similar stories. And those who do usually feel that distance and proximity are more things of *mind* than of *space*. You can be close to someone on another continent and yet feel as far strangers from someone sitting on your sofa. The same goes for remote work.
So instead of *remote work* think **virtual office work**. This is where everything we've learned by coaching team collaboration, building team trust, and helping teams reach shared understanding can and must be applied today.
The key question of today is not "how can I be productive in a home-office environment" but rather:
> *"How do we create a virtual office space where everyone feels connected and close to each other, as if they were physically together?"*
## It is not about the tools — despite what the ads say
Before writing this article I googled what had been written on this in the last few days. A lot of posts are endless reviews of tools they say you *need* to use to make it all work.
Bollocks. Tools help, that's for sure. But you will get very little benefit from tools if you don't get the principles right. And vice versa: if you understand the *principles of building mental closeness*, you can use basically any set of tools — even free and sloppy ones — and still be better off, because you grasp what makes people feel present and connected.
## Principle #1: Virtual presence
Are you present today at work? Can you feel others being present too? Or do you feel puzzled, lonely, and isolated?
That's about it. We need to help people feel surrounded by each other, like in those good old office times (remember those — it was, like, what… two weeks ago?).
**Practices that help to implement virtual presence:**
- **Teams have constant video calls during the day.** With a dedicated persistent video conference room for each team, people feel among others. They join when they start working and check out when closing the day. Being in the shared virtual room means: *"I'm here. I'm in the office. I'm present."*
- **Create a feeling of higher interdependence between team members.** Independence creates isolation, isolation drives loneliness, loneliness causes depression. (This is also why [Autonomitis Blockadus](/post/three-common-and-contagious-organizational-diseases) — teams pursuing independence at the cost of collaboration — is such a dangerous pattern.) So add more dependability, maybe even more than needed. How? For instance, work in shorter iterations than you'd normally do, or have fewer high-priority initiatives (backlog items) at a time, so that people have to coordinate and integrate their work on a few higher-priority items. (That's also good for business.)
- **Run daily stand-up meetings several times a day.** With higher interdependence, the need for coordination should also grow. So why not run team syncs more often? It helps team members feel a shared work space, with clearer plans. And clarity and confidence are very important right now, when the world outside is kind of collapsing.
## Principle #2: Emotional connectedness
Having shared work is great, but nothing jells people more than shared emotional experiences, sympathy, and empathy.
Everyone knows how important this *soft stuff* is, and yet discussion about *work* usually dominates our conversations. A team facilitator (whoever takes this role at the time — see the role below) needs to incorporate emotional exchanges into the daily work routines.
**Practices that help to implement emotional connectedness:**
- **Start every virtual meeting with a check-in and end with a check-out.** This sounds obvious — everyone knows it. But ask yourself how often you actually do it. Besides the emotional exchange, this is also a mandatory step to make sure everyone's headset and microphone are working. Spend at least 10% of the planned meeting duration chatting about how people feel, what's on their minds, what stops them or slows them down. 10% sounds like a huge waste, but it ensures the remaining 90% has a higher chance of being really productive. Check-ins help people raise self-awareness, and hence improve engagement by clearing some bugging emotional baggage out of their minds. Brave enough to do more? Offer a 2-minute meditation at the beginning of a virtual meeting.
- **Have a 'team care' facilitator role.** We have customer care because customers are important, right? So why not have a team care role? A rotating role in a team, daily or so, focused on relationships, emotions, and all this untouchable stuff — and less on daily work. This dedicated person can offer to run check-ins and check-outs in a fresh format, lead short stretching exercises, conduct a short meditation, host quick feedback rounds — anything goes here, if it helps the team step out of *doing the work* mode for a short while and focus on improving relationships and connectedness.
- **Stop using emails.** Email is the most dangerous tool we've created in the internet era, despite its huge benefit. I mean when it is used within organizational boundaries, and especially within teams. Just stop using it for internal team communication. Instant messaging is not much better. Switch to video chats and video calls. We — people — are so much nicer to each other when we can see each other's faces. This is due to the power of mirror neurons and other capabilities of our developed brains to read emotions and reactions in an instant. Evolution hasn't been preparing us for reading emotions by looking at weird symbols someone has typed onto a piece of plastic.
## Principle #3: Improve on presence and connectedness constantly
You won't get it right the first time, despite some of the ideas I've shared here and thousands more you can find online. Also because every team is different — and dynamic.
So it is vital to find ways to collect constant feedback, run small experiments, and keep improving the well-being of your virtual office. That's obvious. But again — in an era of turbulence and looming economic crisis, working *harder* might feel like the only right thing to do. It isn't.
**Practices that help here:**
- **Run short informal retrospectives.** Nothing new here. But do them more often and keep them short. A good idea: team members collect their individual tensions, and when the number reaches N (like 3 or 5), run a spontaneous 20-minute retro.
- **Find a way to gather constant feedback.** Because you don't bump into people at the smoker's corner or the water cooler anymore, you're missing a lot of channels that used to carry important stuff in safe, friendly, informal ways. So find virtual substitutes. Gathering all kinds of feedback helps a lot. It always does. But in times of change and chaos this is more true than ever — especially when the feedback process is transparent and the results are seen and made actionable by everyone, not just by management.
- **Act as a leader.** We leaders are in charge of creating and sustaining cultures of cooperation — and today, of the emergence of new habits of virtual work. It is important to do it before bad habits kick in. Company cultures are already being dramatically affected by people working virtually. The first days and weeks of the *new era* are exactly the right time to start shaping and re-shaping your corporate culture. Act now.
Good luck. Wash your hands. And create other great new habits of virtual work.
> *If you like this train of thought, I've continued with a 17-page micro-book that contains these and other pieces of advice (20 in total): [Working from Fucking Home](https://leanpub.com/working-from-fucking-home).*
---
# Requirements are like bubbles
**Date:** 2018-04-19 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/requirements-like-bubbles
**TL;DR:** Epics are black holes that swallow infinite effort. Requirements are bubbles — they have size (effort) and uncertainty (how likely is scope creep). Visualize both dimensions before committing. The ones with high uncertainty and large size are the dangerous ones. Refinement should pop bubbles into smaller, clearer pieces — that is real learning.
> **'Epic' is too good of a name for a piece of uncertainty that could fail you so badly!**
I'm sure you've seen similar graphs before.
It's a release burn-up chart depicting approximation of done work to the planned scope. After three sprints the plan looks green: seems like the team will make it after the 5th sprint.
And then a KABOOM! New scope — updated projected release date.
Why does it happen? Many reasons: from scope creep to…
Wait a second, but what is *scope creep* exactly? Is "creeping" a kind of characteristic of "scope"? Can some scope be creeping more than some other? How likely is it in fact that a certain scope would creep, and at what pace?
We usually answer that we don't know. And some even would say that "we don't know what we don't know" (smart asses!).
But let me unpack this for you.
## But how much do we really not know about what we don't know?
Let's imagine you need to implement payment mechanisms in your existing product. Some would call it an "epic".
I'll be calling it a "black hole". Because it can suck an infinite amount of effort and time. And no investments will ever go out of it. Don't go there. (For more on why epics are dangerous, see [*Avoid Epic-Driven Development*](/post/avoid-epic-driven-development).)
A black hole.
Scary? Certainly should you be!
Let's look at some dynamics — evolution of black holes. As you guess, not everything that there is is what we know 0% about. Some things are clearer than others. Some can be refined at a faster pace. Some would remain black for some long time.
Here is a possible evolution of knowledge acquisition. That is what is happening within a product team that does its best to refine its upcoming work.
Now "payment" is not a disturbing point. But "other payment methods" is. PayPal is relatively straightforward to implement; Visa and MasterCard have more work and more uncertainty.
## Bubbles bubbles everywhere!
In one recent product that I was consulting, we've started to apply this approach to all product features.
And we quickly realised that such a representation can help capture two essential dimensions:
1. Level of uncertainty / clarity
2. Relative size / complexity
So logically the size of bubbles is their relative size, and the colour — well, how clear they are.
If you're like us, you will end up using a simple tool (like Google Drawings) to capture and preserve requirements long-term. Having these diagrams widely accessible (at the corporate Google Drive) to everyone in the company allows you to infect people with the idea of bubbles — and it won't take long before you see the bubbles being drawn at any "product backlog refinement" session.
## Let's add colours!
The size and uncertainty are two essential dimensions that allow you to have good deep discussions. But if you like complication then you'd go further (not necessarily that you have to).
We (complicated people) decided to add another dimension — readiness of implementation. The pro is that you can visualise not only how small/big and unclear/clear things are, but also how close they are to making money for the business. I guess that makes sense.
Refining requirements and separating knowns from unknowns is a good start, but being able to have a laser focus to deliver the clear pieces as fast as possible (to my view) is the next level of organisational maturity.
## What's next?
I later connected this technique to impact mapping in [*Try Impact-Driven Product Backlog*](/post/try-impact-driven-product-backlog) — impacts feed into bubbles, bubbles feed into sprint-ready items. I recommend you try this tool — bubble diagrams for requirement work.
And if you're like me (loves clear instructions), here's one for you:
1. Don't use JIRA or any other requirements tool during your product backlog refinement sessions (that's a really important step) — and if you have JIRA tickets, print them and bring them over to the session.
2. Invite people who have the knowledge of the upcoming work (subject-matter experts, users, user proxies) plus members of your development teams.
3. If you're too many — split into groups, otherwise stay together (but I really recommend splitting up).
4. Each group needs a whiteboard (flip-charts or big sheets of paper will do too, but whiteboards are much better here).
5. During a given time-box (say 15 to 30 minutes) each group focuses on one large piece of requirements (a product capability or a feature) and tries to break it visually apart by drawing a bubble diagram with two dimensions: uncertainty and size.
6. By bubbling the work, the team collects lists of open questions — they can be attached as leaves to the diagram too. Essentially the bubble diagram is an overcomplicated mind-map, so it is good for keeping associations.
7. Once the time-box is done, groups can either rotate (World Café style of facilitation), take new requirements to work on, or share their learnings with the whole group. Remember: product backlog refinement sessions are learning sessions, so your goal is to amplify group learning.
8. Once done, take photos and upload them to a wiki. Or update the Google Drawings to make sure the teams can continue referring to the bubble work where they have stopped today.
Critique? Questions? Comments? Please do.
---
# Live Up to Your Coaching Visions
**Date:** 2016-08-27 · **Reading time:** 6 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/live-up-coaching-visions-agile-canvas
**TL;DR:** Scrum Masters get lost in routines and forget the dreams that brought them to the job. The Agile Coaching Canvas reconnects you with the high dream: visit your team a year from now in your imagination, then pull specific actions back into next Monday. We like our dreams — the problem is we stop visiting them.
## Low and High
I had proposed a session on this topic at one of the un-conferences this year. My fear — my so-called *low dream* — was that no one would show up.
Well, I was wrong. One person did.
*(photo from [flickr.com/photos/neilsingapore/](https://www.flickr.com/photos/neilsingapore/))*
The guy who came was very eager to learn about the Agile Coaching Canvas, so instead of explaining how it works, I offered him a coaching session to demonstrate it in action. He gladly accepted (did he have a choice?) and we quickly left the room to make sure no one else would join and break up our coaching intimacy.
We went for a walk around the event premises. Sunset, hills and meadows all around us. He was describing his current engagement as a Scrum Master and all the associated challenges — when I kindly interrupted him and asked him to briefly visit one of his teams a year from now.
In the beginning he wasn't sure how. But then he literally didn't want to stop. That's how it usually works — we *like our dreams*.
Forty minutes later I had to pull him back to the present to wrap up the session and pin down some specific things he'd want to do next Monday. He was very fluent in knowing what to do with his team, though his initial coaching request was to get at least some clarity on the next steps.
## Dreaming Never Ends
**What's your *low dream* on reading this article?**
Probably that this reading is going to be some kind of yet-another-consultant-bluff about how cool his services, tools and client reviews are. That you'd end up scrolling to the very end only to find zero comments and navigate away to find one to read.
Can be.
**And what's your *high dream*, then?**
Likely that this article would make your day and you'd end up sharing it with all your network. (That's also my high dream.)
These two completely opposite thoughts are both dreams. This idea is actually quite interesting, because a typical understanding of a "dream" is that it has to be something high, positive, sweet and inspiring — or else it isn't a dream, it's a complaint.
Well, that's not true. At least partially.
Dreams (as we now know) can be both — low and high — with the full range of amplitudes in between.
And hence all expectations are dreams: we in fact never stop dreaming. Some of us have long-lived habits and preferences for dreaming low, others for dreaming high. But we're all dreamers. That's why this tool — the Agile Coaching Canvas — works so well.
Let me explain.
## That Day
Do you remember the day when you learned the news that you actually got that job (or contract, if you're consulting like I am)? You finally got the long-awaited engagement you'd been dreaming of.
How did it feel?
*(photo from [flickr.com/photos/sking](http://www.flickr.com/photos/sking))*
I bet it felt good. And in fact, I'm pretty sure right in that moment you started having all sorts of dreams about coming in and changing that team (project, department, company).
You likely envisioned the wide and deep impact you'd be creating, and how everyone would see and appreciate it.
I can't read your dreams (and you can't read mine — which is, by the way, a good thing). But we can come back to them and get reconnected with that great source of clarity and power.
There is only one problem with that…
## Lost Dreams
How often do we actually come back and re-live those high dreams during our "core office hours"?
I don't know about you (maybe you're special), but I tend to spend my days juggling daily routines. I barely have time to do anything else. Not to mention dreaming. (I'd love to see the face of your boss when you log an hour for a *dreaming activity* in your timesheet.)
We forget our dreams. We lose them. We get lost.
## Lost Dreams of a Scrum Master
If you're working as a team coach or a Scrum Master, your "job description" — or in other words, "what they expect you to be 100% busy with" — likely boils down to a list of repetitive low-level tasks:
Instead of being the change agents — the ones who keep the flame of Agile and Scrum values burning — most of the Scrum Masters I talk to end up following that routine list.
Talking to hundreds of Scrum Masters a year, I know this is true for most of us. And this has become *my* low dream of ScrumMastery as a profession. It's a sad one of mine, and I'm working hard to change it.
## Dreaming Up
One way to change the impact of our work as Scrum Masters and agile coaches is to go *broader*: work with more teams in the organization, with stakeholders, with the overall product organization, serving the entire value stream. That's going *wide*. If you stay narrow, you risk becoming one of the [Scrum Masters who are getting fired](/post/why-scrum-masters-are-getting-fired) because the role never reached its potential.
Another way is to get reconnected with a higher purpose without redefining the status-quo scope of the work. That's going *higher*.
These two directions — higher and broader — are not mutually exclusive.
## Getting High
Some time ago I published an article — [ScrumMaster is not (just) a Team Facilitator](/post/scrum-master-just-team-coach-facilitator) — which got rather positive traction in the community. That one was about going wide.
Today, I'd like to offer you a way *up* — a way to reconnect with your high dreams without redefining your current job description. You can also call it "hacking a job description", because no one can stop us from dreaming big and acting bold.
*(photo from [flickr.com/photos/arselectronica/](https://www.flickr.com/photos/arselectronica/))*
So here it goes.
You're lucky. You have a chance to visit your team (department, project, company, client) a year from now. For a very short period of time. Intrigued?
Three… Two… One… You're there. Bam!
> **Let yourself enter the building.**
>
> **To your surprise, everything you had been working on and hoping for a year ago did happen.**
>
> **And not only the way you thought it would — it is exceeding your expectations.**
>
> **You and your colleagues have been working really hard yet very efficiently. Now simply enjoy observing the result of those great returns.**
>
> **Notice what's different as you walk down the halls and rooms of the building.**
>
> What's on the walls?
>
> What's on people's faces?
>
> What are people doing?
>
> What are they talking about?
>
> What's the energy there like?
>
> What is slightly different?
>
> What has drastically changed?
Pause now to take some notes. Jot down the key observations you'll be taking home with you.
> How is what you see impacting you?
>
> Who else is benefiting from these changes in the organization? Stakeholders? Clients? Who else?
Now stay there for as long as you'd like, and let me know when you're back.
## Ground Control to Major Tom
I do hope you allowed yourself to spend a few minutes dreaming. If not, please do. You deserve it.
And you should know one thing: those dreams are no one else's but *yours*. You have all permissions to have them. It is your birthright.
If you don't dream them — no one will. So please, take some time and allow yourself to dream.
### Skills
Now, Major Tom, provided you liked that dream:
- Which individual skills do *you* need to deepen in order to make those changes come true?
- Which skills do people around you need to deepen?
- Which new skills would help if they start acquiring them?
- Which new habits to gain? Old ones to forget?
### Support
In order for your dream to stay coherent with the environment you're in:
- Whose support do you think you need to seek?
- If there is one person you really wouldn't want to open up to and share your dreams with — who is he or she?
- Who else can impede your dreams? What can stop them? How? Why?
These are the people you'll need to learn how to connect with in order for the dreamed future to happen. They'll need to be onboarded.
And you know what — they also have *their* dreams. The low and the high ones. So instead of seeing them as your "impediments", why not start some light discussions about what they are hoping for? Let them dream out loud.
You'll be surprised how much easier it is to reconnect with people on the dreaming level.
## P.S. Become the Dreaming Master
The [Agile Coaching Canvas](https://web.archive.org/web/2024/http://www.agilecoachingcanvas.org/) is a compact, illustrated guide you can use to keep dreaming — and to help others do the same.
I often use it with the fellow Scrum Masters I mentor. I also run so-called [*futurespectives*](https://www.infoq.com/articles/new-year-resolution-retrospective) with agile teams to get collective dreaming going.
The goal of using such tools is to distort (at least a little) the stiff perception of reality we all have — and help us see new options, other perspectives, and fresh ideas on *how* to get where we truly want to get.
Not to mention: dreaming is a very emotional process that stays long in our memories. These bright pictures then work as our best motivators, helping us persevere in the harsh times.
So if you've followed me through this article and allowed yourself to dream — you already know how to use this tool. In a nutshell. There is a bit more to it, as the ultimate goal is to facilitate some specific actions, something we'd do differently "next Monday".
Hence — feel free to download the [Canvas and its accompanying materials](https://web.archive.org/web/2024/http://www.agilecoachingcanvas.org/) and master this simple yet powerful dreaming toolset.
BTW, it is free and open-sourced.
---
# Scaling Scrum Meetings to 50+ People
**Date:** 2016-06-22 · **Reading time:** 4 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/running-multi-team-scrum-scaling-natural
**TL;DR:** Growth adds hierarchy and roles. Scaling increases intelligence while minimizing complexity. Scrum scales naturally by pushing intelligent work down to teams. All Scrum ceremonies work at 50+ people if you prepare the space, invite the right people, and let self-organization do the rest. You don't manage water molecules — you allow them to work.
## Scrum Scales
Growth is about increasing size. Scaling is about increasing intelligence.
Growth is about adding more layers of hierarchy, defining new roles and adding policies. Scaling is about mastering the complexity by minimizing it.
Scrum doesn't easily support growth: it is against adding roles, having bigger teams, multiplying backlogs. That's why it is so easy to overlook its inherent scaling capabilities while looking for more "correct" solutions.
Scrum allows scaling by raising the inner intelligence of human systems — enabling and empowering each of its parts to act independently yet aligned. Like water molecules that dissolve dirt and help you wash your clothes, dishes, car and even children…
Well, team members don't exactly *dissolve* product-backlog items during refinement meetings. But you get the idea.
You don't have to manage molecules of water to let them do the job. You just need to *allow* them to do it for you. The same way Scrum helps to solve complex matters: by pushing the intelligent work down to the level of teams and individuals, to let them figure out the necessary details.
## Scrum Meetings Scale
In fact, all Scrum meetings scale so naturally that I've been hesitating to write about it for quite some time.
Scaling Scrum ceremonies requires you — the process facilitator — to do a few key things:
1. **Prepare the space.**
2. **Invite the right people in.**
3. **Explain the goals to be achieved.**
4. **Facilitate the formation of smaller self-managing groups.**
5. **Give sufficient-yet-minimal guidelines on how to go about the matter.**
6. **And stay away to let the intelligence of the system handle the complexity.**
Let's see how this works in real practice.
## Scaling Product Backlog Refinement
Managing complexity is not about breaking complex things down into simpler elements: you're not breaking a dish into pieces to get it washed (not to mention your car or kids). Instead you're letting the water take it all and do its job on the invisible — sub-managed — level.
The same goes for products. You will not help the system handle the complexity of product development if you break the product into many sub-products with many tiny backlogs.
In fact, by doing so you will *increase* complexity, because someone now needs to take care of gluing things back together. Some things are counter-intuitive. You need to see it working to believe me.
### Preparing the space
When we scale product development we follow an advice from Large-Scale Scrum: [whole product focus](/post/whole-product-focus-team). So I help a group of stakeholders, visionaries and product thinkers co-create a big picture. Sometimes they bring their mini-backlogs and we start gluing things back. This can take some time.
In most organizations this actually takes *quite* some time — the status quo of today's product management relies heavily on breaking things down into small "manageable" pieces. So I always carry a tube of super glue along with markers and post-its in my bag. I can also make nasty jokes with it… but that's another story.
Below, a group of product managers co-creates a visual product-backlog board. The board carries the overall business goals, release goals, user journeys and empty placeholders for backlog items.
Once it's prepared, we call everyone in.
### Bringing everyone in and explaining the goals
Once all are in — and by "all" I mean literally everyone who can help us dig into the details of the work — one of the product managers walks the room through the thinking behind the board: goals, priorities, challenges, hypotheses, big questions.
So far it looks easy-peasy. Look what happens next.
### Breaking into smaller groups
[One product, single product backlog, overall backlog refinement](https://less.works/less/framework/product-backlog-refinement.html) — that's the mantra we follow for our multi-team Scrum approach. I describe this facilitation pattern in more detail in [*Cross-Team Collaboration with Multi-Team PBR*](/post/cross-team-collaboration-multi-team-pbr).
To maximize learning — and by the way, the backlog refinement meeting is a *learning* meeting — we shuffle the members of the existing development teams and form new groups just for this meeting. We want each group to have members from all of the development teams.
This ensures that everyone in each development team will know some product backlog items (PBIs) — and together as a team they'll be familiar with all of them. That amplifies learning, maximizes the spread of knowledge, and allows product management to change priorities without worrying about team structure and potential knowledge gaps.
That's what agility on the product level actually means — among other things.
### Defining simple guidelines
Once we have the groups, the process works like this:
- Each group pulls an unrefined PBI, invites one of the product managers, and spends no more than 15 minutes on the topic.
- The main goal is to build a shared understanding of the item: what the problem is, what the user journey looks like. Just enough clarity to know whether this is feasible and can be done within a few days of work. If not — the item gets split into smaller ones.
- After the time-box is over, the whole group decides — by voting — how refined the current item is, makes a note of its readiness (one dot — not enough understanding; two dots — there are some questions, but OK; three dots — *alles klar!*) and moves on to the next unrefined PBI.
- Oh, by the way, our PBIs are not stored in Jira. In fact we cancelled our Jira license after we started using A3 sheets for collecting the details of a PBI. We figured out that paper size is just enough to keep the right level of detail. (Don't ask me how XPers used to manage their stories on 5-inch index cards. Size apparently matters.)
- When the group is done with the item, they fold the A3 sheet and hang it back onto the backlog wall. Everyone else in the room now knows the item has been refined — it has dots on it.
- During our 60-minute meeting we refine about 12–15 PBIs — roughly two weeks' worth of work for all of the teams.
### Staying away (a reminder for the manager)
This meeting looks unorganized, chaotic, and if you walked into the room you might say the meeting is *unmanaged*.
Some working groups *occasionally* split into smaller groups, some people *spontaneously* jump to a whiteboard and draw diagrams, some folks *sporadically* decide to have a one-on-one discussion in the middle of the room.
Well, that's OK.
In fact, chaos is a sign of self-organization. Compare an army marching on parade with a long-haired crowd entering a stadium for a Red Hot Chili Peppers concert. Which one looks ordered, and which one is chaotic? Which one is managed, and which one is self-organized?
So it's OK for things to look messy. In fact, when a Scrum meeting is *not* messy enough — you're doing it all wrong.
---
# ScrumMaster is Not (Just) a Team Facilitator
**Date:** 2016-06-19 · **Reading time:** 5 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/scrum-master-just-team-coach-facilitator
**TL;DR:** The team facilitator vs. enterprise coach ladder is a false dichotomy invented by certification bodies. A real ScrumMaster coaches the whole value stream — from idea to cash — not just the team bubble. If you only coach the team, you are coaching inside a water-scrum-fall and calling it agile. Look at the full system.
## The False Dichotomy
> Bisexuality immediately doubles your chances for a date on Saturday night.
>
> — Woody Allen
**"Do you work as a ScrumMaster or an Agile coach?"** — that's a question I'm being asked quite often. Far too often. When I answer that I am a freelancing agile coach, I'm sometimes also asked if I am an "enterprise agile coach or [I guess *just*] an agile coach". I silently walk away.
Just a few days ago I returned from an open-space un-conference where a group of experienced agile trainers were trying to define the levels of agile coaches — from a team facilitator (a.k.a. *powerless coach*) to an enterprise-level agile coach (a.k.a. *agile god*). That discussion didn't go too well.
But I have to tell you that the certification bodies *love* these wordings. Imagine: if you can convince someone that being *just* a team-level agile facilitator (a poor boy) can become a level-five-blue-belt-god-mode agile coach — just sign over here, pay over there, and receive a new stamped paper with a hologram.
I personally don't think defining these levels is a good idea. I actually think it is a *bad* one. Although of course there is a mastery path (or paths) we all follow along our professional journeys, the formal ladder of agile coaching levels is already doing more harm than good to our industry.
But these (certification) machines have been running for far too long to be stopped. So I'm not going to fight them. Instead, I'll try to explain to you, dear human, why this duality — team facilitator vs. real enterprise agile coach — is adding close to zero value.
Speaking of value…
## The Value Streams
> Scrum helped us to suck less.
>
> — Source unknown
[Scrum is a process framework used to manage complex product development](http://scrumguides.org/scrum-guide.html#definition). At the heart of Scrum (and of any other agile framework) is the idea of infinite continuous process improvements with the bigger purpose of **delivering more value faster to the customers**.
The schematic view of the process of delivering value from idea to cash (also known as a *value stream*) in the most simplistic way might look like this:
In real life a value stream will likely have queues, buffers, loops, bottlenecks and god-only-knows-what. It might start looking as complicated as the example below (taken from an article on Value Stream Mapping):
But in its pure essence: it is still a flow of value that is hopefully reaching its customers.
So the goal of any agile product-development framework (like Scrum) is to help manage — minimize — the complexity of the product-development process in order to be able to start optimizing the value stream. And from this view, the role of an agile coach is to help the organization (including its leaders) start understanding how their value stream looks and how to go about improving it… continuously.
As a matter of fact, the latest State of Agile report proves this, claiming that over 60% of organizations adopting agile are pursuing acceleration of product delivery.
## Hence, Coaching Development Teams is Not Enough
> If your project is delayed, you should have started it earlier.
>
> — DeMarco, Lister, *Waltzing with Bears*
Continuous acceleration of product delivery can't be achieved by working only with one (or even several) development teams — unless they are an endless source of all types of inefficiencies. Which is unlikely to be true.
Instead, it requires having a holistic view of the value stream (based on real facts). This implies coaching all involved parties during all of the activities of the value stream: from early idea generation and validation, to feature development and deployment, to maintenance and post-release activities.
Sadly, I see many ScrumMasters who are limited — by the status quo of their organizational structures — to working with development teams. This confinement is part of [why Scrum Masters are getting fired](/post/why-scrum-masters-are-getting-fired) across the industry. These *chained* agile coaches are not empowered to help improve the value stream and hence can't help accelerate product delivery. They keep optimizing development processes as if it were the only box of the value stream. And in most cases, there are many more things to start improving.
Working with development teams can be very exciting and inspiring — it requires not only a hell of a lot of empathy, patience and self-awareness, but also a deep understanding of the nature of software development. Sadly, it is not enough. As we all intuitively know: **optimizing a part of the process that is not a bottleneck will not have any positive effect on the overall system.**
## Stuck in Water-Scrum-Fall
"We do Scrum in software development, but since our development teams don't have control over the production environment it is up to the ops now to get it deployed. I'm assigned to the dev team. They have another coach. Perhaps they do kanban." — I do hear this, and it makes me sad.
The dynamics of such an organization are interesting and exciting (for an observer). The organization will keep optimizing and self-improving, but since no one has an overall view or interest in optimizing the whole, it will likely become a source of various local optimizations.
So no surprise that I see companies getting rid of the ScrumMaster role. It doesn't add value. The changes are not observed. In fact, the level of conflict and employment dissatisfaction might even be growing — because of the gap between potential and reality.
And this is not a unique case. They say "this role is not adding value". Of course not, if the key function of the role is defined as "facilitation of team Scrum meetings". The structural problem runs deeper — it is often the [Team Lead role that absorbs the real work](/post/extract-team-leads), leaving the ScrumMaster with nothing but ceremony.
## Set ScrumMaster = Agile Coach for a Product Organization
> See, understand, and optimize the whole system (not parts), and explore system dynamics. Avoid the local and sub-optimizations of focusing on the 'efficiency' or 'productivity' of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps.
>
> — [Systems-thinking principle](http://less.works/less/principles/overview.html)
So if you want real systemic improvements (and not something fake like an increase in team velocity), you need to redefine the scope of the work of your ScrumMasters. They need to work with the overall product organization. (Otherwise you may just delete ScrumMasters, as Tobias Mayer once said.)
Good news: you don't need to choose between team facilitation and organizational coaching when defining the *real* ScrumMaster. There is no false dichotomy.
Instead of assigning ScrumMasters to teams (not enough view of the whole) or having your enterprise coaches fly too high (not enough knowledge of the work being done) — see your company as a **set of product organizations** (organized by value streams), and then have one or several ScrumMasters focus on and coach each of the streams, from idea to product to cash.
Newly formed teams and product organizations will need more team-level coaching than more mature ones. So the density of coaching will likely vary over time, as illustrated below:
> Further inspirational reading: [a product-wide definition of a ScrumMaster](http://less.works/less/structure/scrummaster.html).
---
# Why Scrum Is Silent on Team Leads
**Date:** 2016-04-27 · **Reading time:** 3 min · **Category:** Org Design
**URL:** https://krivitsky.com/post/why-scrum-silent-team-leads
**TL;DR:** The Scrum Guide does not mention Team Leads — and that silence is intentional. The role is not relevant to Scrum. But it is present in your system and cannot be ignored. The real issue is not the title but the leadership style: whoever holds power over technical decisions shapes how the team self-organizes, or fails to.
## Did Scrum Forget to Mention Team Leads?
Just reread the Scrum Guide. Still no updates. Not a word on this subject.
The only occurrences of the root *lead* are these two:
> "The Scrum Master is a servant-**lead**er for the Scrum Team."
> "The Scrum Master… **lead**ing and coaching the organization in its Scrum adoption."
The reason the Scrum Guide isn't mentioning this commonly seen role is probably because it isn't relevant to Scrum. I guess this is true.
But it can be of *your* high relevance when it comes to a Scrum adoption — because this role is most likely present and is part of the system you're working in. So it can't be ignored.
Today on my CSM class (surprisingly full of Team Leads) I got surrounded by them, seeking the truth. They wanted to know: **how do I see this role fitting with Scrum organizations?**
When I ask for a definition of the role, in most cases it is something like:
> "Be responsible for the overall technical excellence and development of the specialist group."
It can be less or more verbose, but in the end it boils down to *certain power in someone's hands* in making decisions that affect how the team does what it is supposed to do.
## My Insight (It Is Never Too Late to Be Enlightened)
I started to remember all the team leads I've worked with. And also the strong individuals who shaped the teams I was working with. And then it struck me.
I remembered a guy who was not formally a lead but rather one of the oldest developers (by oldest I mean he made the first commit) — and *how bossy he was* with the others.
And then I remembered a recent example of a formal team lead who was very *gently querying others' opinions* and bringing teams to consensus whenever possible.
It is not about titles and roles. It is definitely about the level of personal growth and leadership style. And we all have one.
## Leadership Maturity
Recently I got lucky to be introduced to [Pete Behrens](https://www.linkedin.com/in/petebehrens) and his work on Agile Leadership. Pete uses the following diagram (not sure who originally invented it) representing the growth of a leader: from an **expert** (doing all on their own), to an **achiever** (making things done by influencing others), to a **catalyst** (empowering others to take actions and lead).
> **A technical *expert*:**
> — I've coded this framework the other night. Integrate it.
> **A technical *achiever*:**
> — We need a new framework. I believe Max and Alex are the best people for this job.
> **A technical *catalyst*:**
> — Let's sit together and see how we should evolve our frameworks. I gave it a thought, but I'd like to know your opinions so we can make a decision.
## Anyone Can Be Bossy (But No One Should Be)
If the threat of ruining a team's self-organization by being bossy can come from any direction, then we — team coaches — need to watch out for these behaviours from everyone on the team. And then train, mentor and coach team members in proper leadership style.
So I'm not concerned any more with specific roles like Team Lead, Tech Lead, Team Coordinator, Delivery Manager, Engineering Manager and so on.
Roles are secondary. Personalities are primary. It will be specific people helping or jeopardising your Scrum adoption. So forget about the roles. Work with the people. This is fundamentally a question of [reactive vs. creative leadership](/post/reactive-to-creative-leadership) — fear-driven control versus purpose-driven trust. For a structural take on why the team lead role keeps appearing, see [*Extract Team Leads*](/post/extract-team-leads).
---
*Generated from https://krivitsky.com. For citation guidance see https://krivitsky.com/llms.txt*