100X Developers vs. 1X Organizations

May 19, 2026Munich · 202646 slides

AI makes individual developers 100X — but structures, handoffs, and approval chains built over two decades keep the system at 1X. What separates 10X organizations, and how to redesign for AI.

100X Developers vs. 1X Organizations

Why AI Productivity Gains Don't Compound and How to Create 10X Organizations

This talk, roughly:

70% Agentic engineering 30% Organizational impact

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).

03 04

AI replacing?..

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

An abundant spread of fresh fruits and vegetables — variety and balance.

An AI-native developer at a multi-monitor setup — working at more than 100X.

A pre-AI, established organization — a dense modular concrete building.

Your org had been on a certain trajectory — AI is an accelerator.

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.

Anyone working in a pin factory?

"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."

— Gary Hamel, The Future of Management, 2007

Fresh, varied produce beside a rigid modular concrete building — a living system versus a fixed structure.

100X locally, 1X globally — system costs up 72% while performance shows no significant change. The local improvements do not compound globally.

A red Ferrari on an open country road — raw speed with nowhere to lose it.

The Ferrari Trap — a Ferrari stuck in dense city traffic behind a GO SLOW sign.

AI adoption in established organizations:

Socio/technical

Let's visit one cubicle inside the pre-AI organization.

Here is Debian, a DB Designer. Historical org trajectory: leveraging experts' primary deep skills — "efficient".

Now with AI, Debian can do things 100X faster. So, in 3 days, he can do the yearly load of DB design.

...But what is he supposed to do with the remaining time now? It is unlikely there is demand for 100X more databases...

An after-hours desk — a hand-drawn schema, a "Ship Value Repeat" sticky note, and a checklist marked DONE.

Minimizing transaction costs — closing the value loop: Discovery to Delivery to Observability to Operations and back to Discovery.

Org Topologies — Four Intelligences. Debian sits in the DOING quadrant: narrow skills mandate, incomplete work mandate.

There is the Search Team, building and maintaining an e-Commerce search. Historical org trajectory: creating fast-flow teams — "efficient".

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.

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?

The empty Search Team room — whiteboards full of strategies, a toy Ferrari on the table.

The Law of Diminishing Returns — productive, then diminishing, then negative returns. AI accelerates… you along the curve, not past it.

Org Topologies — both are boxed: Debian in DOING, the Search Team in DELIVERING. Both stuck in the outputs half of the map.

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.

How do we stay relevant? Debian the specialist on one side, the fast-flow Search Team on the other.

Millions of years of brain evolution as multi-learners. Temporary local optimization only lasted 200 years. Back to our strength.

Redesign, then AI.

Towards 10X ORG:

Keep experts utilizing their primary expertise

→

Allow growing more skills

Keep teams fixed for fast flow

→

Allow working in new domains

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.

Real Org Topologies case studies — LeSS adoptions, wartime transformation, e-retail replatforming, fintech, and more, at orgtopologies.com/case-studies.

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."

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 new skills and enter new domains.

100X vs. 1X — the AI-native developer's speed against the established organization's structure.

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?

Back to human strength — Org Topologies, with a green arrow moving from the outputs half up into DRIVING: complete work, broad skills, real outcomes.

Thank you!