Dr. Martin Kramer

Author: martin

  • The most effective strike follows every rule. Your AI agents do it every day.

    The most effective strike follows every rule. Your AI agents do it every day.

    The most effective strike doesn’t stop work. It follows every rule to the letter.

    AI agents do exactly that. And they’re not on strike.

    I’ve been turning this thought over lately, because I run a small team of AI agents myself. I built it over the summer to take work off my plate in my day-to-day job. It has an orchestrator called Ruby, a quality gate called Sherlock, and a growing list of specialists. It also has a growing rulebook. That last part is what this article is about.

    What I describe here is what I saw in my own agent team over the last few days, as the rulebook grew and progress slowed down significantly.

    Work-to-rule is a weapon, not a slowdown

    Labor movements figured this out long ago. You don’t have to walk out to shut an organization down. You only have to do exactly what the rules say. In 1984, French and Italian customs officers inspected every single vehicle at their border crossings, meticulously and by the book. Nobody broke a rule. The result was massive traffic jams.

    The German sociologist Stefan Kühl makes the point sharply in his 2020 work on rule-breaking in organizations. In his view, work-to-rule is the most effective way to paralyze an organization. His reasoning is worth sitting with: literal compliance with every rule and instruction makes any organization steadily more cumbersome, no matter how well it was planned.

    Read that again with a management hat on. It says the plan is not what keeps the organization running. Something else is.

    Organizations survive their rules because people break them

    German organizational sociology has a name for that something else: brauchbare Illegalität, or “useful illegality.” Niklas Luhmann coined the term in 1964, in Funktionen und Folgen formaler Organisation. Kühl’s 2020 book carries it in its title.

    The idea is simple and slightly uncomfortable. Every organization has a formal side: the org chart, the process, the rulebook. And it has an informal side. The colleague who skips a form because the approval is obvious anyway. The team that ships on a Friday although the release calendar says Tuesday. The manager who looks the other way because the rule was written for a different situation.

    The informal side is not a lack of discipline. It is how the formal side survives contact with reality. Rules get written in advance, for the cases someone could imagine. Reality keeps producing the other cases. People close the gap, quietly and case by case, usually with the tacit consent of everyone around them.

    I’ve personally lived through the shifts from waterfall to agile, from project to product, from requirements engineering to design thinking, from agile to agentic, and so on. Every time, the process on the slides and the process in reality were two different things. The one that ran day to day was the one that delivered the results.

    That flips the usual picture. Breaking rules is not the exception management has to contain. Full compliance is the exception. And when you actually get it, you get a strike.

    The agent is the perfect member of the organization

    Now put an AI agent into that picture.

    An agent’s only access to the organization is the written text: the prompt, the process description, the rule file. No hallway conversation. No colleague who says “we don’t really do it that way here.” No sense that a rule has outlived its purpose, because it can’t know what the rule was for unless someone wrote that down, too.

    So here is my hypothesis (and I want to be clear that it is one): a team of AI agents lives in a permanent state of work-to-rule. It executes the formal structure literally, and it lacks the valve that lets human organizations survive their own surplus of rules.

    If that’s right, the practical consequence is uncomfortable. The same set of processes we have today, but in the “hands” of AI instead of real people, will produce high lead times and high token costs — because the process debt now gets followed rigidly, instead of people quietly absorbing its defects for years.

    The counterargument is strong, and I don’t want to hide it. Agents deviate from their instructions all the time. Anyone who has worked with them knows this. They skip steps, reinterpret things, occasionally do something nobody asked for. Taken literally, “agents follow every rule” is wrong.

    My claim is narrower. Agent deviation looks like noise: unsystematic, hard to attribute, not tied to the situation. It is not the kind of deviation Luhmann’s term points at, the kind that fits the situation, serves the purpose better than the rule does, and gets tolerated because the people around it see why. An agent will sometimes skip a step. It is far less likely to skip the one an experienced colleague would have quietly left out.

    What would prove me wrong? An agent team that demonstrably deviates from its written rules in ways that are functional and fit the situation, reliably and not by luck. I would be interested to understand how this would work.

    What I see in my own system

    Currently, the trend is rather the opposite. We are all excited about harnesses. I have put my own AI team into a tight harness. I need results I can trust. I have no room for hallucinations. And therefore I built a tight rulebook that I am regularly expanding. But I have also experienced the downside of it: slow execution speed, sub-agents arguing with each other, going back and forth all the time, burning my tokens.

    In my own setup, I have one observation that fits. One system, one case. Not a study.

    We have a rule for breaking a larger piece of work into steps. At some point, a rule meant for splitting work got applied to splitting decisions. Every step became its own delivery, and every delivery waited for my approval. Nothing was wrong with any single step. But the lead time for a feature went from 1.5 to 10 calendar days, and most of those days were waiting, not working.

    The rule was followed. Its purpose wasn’t.

    A second observation belongs next to it. On September 3, we cut the system’s central rulebook by 37%. Eighteen days later, it was longer than before the cut. Fixes arrive as new rules. Every incident leaves a sentence behind.

    Does that prove the hypothesis? No. A human team could have misread the same rule the same way, and I have no second team to compare against. What it did show me is where the valve sits in my setup. There is exactly one place where useful illegality can live: with me.

    So I’ve started acting like it. My own counter-rule, written down in September: “Waiting time is more expensive than a defect that reaches me.” Review effort now scales with how recoverable a change is, not with how big it is. Something I can undo in an hour gets a light check. Something that can’t be undone gets the full treatment.

    I’m aware of the irony. That is also a rule.

    Some questions before you hand a process landscape to an AI agent team

    I don’t have a method to offer. I haven’t found research on how to take process out of an agent system, and I’d be wary of anyone who claims to have one today. So these are questions, not best practices.

    • Which of this process’s rules do your people break today so that it works? If you don’t know, the agent will find out for you, by following them.
    • Who in your agent setup is allowed to suspend a rule? And how would you even notice that it happened?
    • Do you plan deleting rules as carefully as you plan adding them? In my own system, the honest answer was no. Yet that is probably the reason why Boris Cherny advises we should periodically scrap our AI setup.

    Agents do what we write down. That is their strength, and it’s why I work with them every day. It also means the parts of our organizations we never wrote down are about to matter a great deal.

    Which rule in your organization only works because someone quietly breaks it — and what happens on the day an agent takes over that job?

  • Digitalization Didn’t Do the Learning for Me. It Shortened the Feedback Loop.

    Digitalization Didn’t Do the Learning for Me. It Shortened the Feedback Loop.

    When I was about five, my parents gave me my first camera. My dad prepared a small booklet for writing down the key settings of every picture: aperture, distance, shutter speed.

    I took my first pictures and logged everything carefully. Once the film was full, it took another one or two weeks to get it developed. Only then could I see what had worked and what hadn’t.

    That feedback loop was slow. So was my progress.

    Many years later, I bought myself a DSLR. Now I could see right away what aperture, focal length, and shutter speed actually do. I could try different flashes and lighting situations on the spot. The loop shrank from weeks to a glance at the display. It was a real joy to experience how quickly I got better.

    I had a similar experience with music. I never imagined I would compose orchestral music myself. Then I installed several orchestral sample libraries and started experimenting: how an orchestra works, how individual voices sound together, what voice leading really does. With the help of YouTube videos and orchestration tools, I wrote my first orchestral pieces fairly quickly.

    In both cases, digitalization didn’t do the learning for me. It shortened the time between trying something and seeing, or hearing, what it did. That, to me, is what makes it a learning accelerator.

    The same logic sits behind short iterations in software development: the sooner a team sees the effect of a change, the sooner it learns.

    Where has digitalization cut a feedback loop for you — and what did that do to how fast you learned?

  • Courage in leadership is what you let go of

    Courage in leadership is what you let go of

    Years ago, walking through the headquarters of the company I was working for, I passed a photo shoot. The man running the company was posing for new portraits. Asked how he wanted to come across, he answered, more or less: bold and determined.

    A small moment, I recall it well. In hindsight, it said a lot.

    The company was going through a large transformation under his lead. In the regular briefings with the management team, the same instinct showed up in another form. He usually told us “I insist!” He told people they didn’t know. Over time, mistrust and fear grew in the leadership team. Everyone looked out for themselves. That culture did not stay at the top. Managers carried it into their teams.

    Mihály Csíkszentmihályi describes the mechanism in Flow: once such practices “become part of the norms and habits of a culture, people assume that this is how things must be.”

    At Thoughtworks, we talk about the courageous executive. Their courage does not come from looking bold and determined. It comes from building a culture in which they don’t control everything. They give teams room to develop their own ideas and to make mistakes.

    Mistakes are not good in themselves. The freedom to make them, and to learn from them, is.

    That transformation failed. There were many reasons, but the culture at the top is the one I saw up close.

    In my day-to-day work, I also see the other side: leadership built on psychological safety, on leading rather than managing, on strong teams, on true empowerment, getting much further, especially in digital transformations.

    Courage in leadership shows in what you are willing to let go of, not in how in control you look.

    If you are in a transformation right now: How bold is your leadership team?

  • Friday Run, Ruby in My Ears

    Friday Run, Ruby in My Ears

    Friday afternoon. Running in the local forest near the Alte Försterei, AirPods in. I’m talking to Ruby — the orchestrator of my new AI agent team — somewhere between km 7 and km 8.

    Not a crisis. Not an urgent decision. I’d just been thinking about something we are currently working on, and the next thought arrived before I could stop it.

    Which is fine. Except I was on the one trail I reserve for not thinking about work.

    Here’s the thing: having an AI agent team that is genuinely always available — one that is starting to deliver real work every day this week — creates a pull I didn’t fully anticipate. It’s not really stress, at least not the bad kind. It’s something closer to momentum. When things are going well, switching off feels like friction, not rest.

    I finished the run. Ruby was still there when I got home. I still don’t know if that’s a feature or a design flaw.

    Both, probably.

    Where do you draw the line — or have you stopped trying to draw one?

  • The Jazz Mindset: What My Business Card Says About How I Work

    The Jazz Mindset: What My Business Card Says About How I Work

    My business card has a photo of me playing jazz piano. People notice. They ask why.

    I’m a bit of a jazz nerd, so that explains some of it. But there’s also a business reason.

    It’s a quick shorthand I’ve found for how I think — for my mindset.

    Jazz musicians listen before they play. Not as a courtesy — as a mindset. You find the space before you fill it. Miles Davis is often quoted on this: “Don’t play what’s there, play what’s not there.” And you’re not just listening for your own next note — you’re listening for what everyone around you needs.

    Underneath that listening is something called groove. Not tempo — a metronome keeps tempo. Not harmony — that’s the chords. Groove is the shared pulse the whole group locks into together. In a client room, it’s the difference between work that feels transactional and work that actually moves.

    That’s the part most meeting cultures train out of people. We show up with our answer ready. A jazz musician shows up open.

    But listening alone isn’t enough — because you’re not playing alone. The other musicians are shaping what you do next. That’s harmony: not everyone playing the same thing, but everyone playing things that work together. What you do depends on what the person next to you is doing. The result is something none of you could have made on your own.

    And when something unexpected happens — a wrong turn, a surprise from the room — you don’t stop. You play through it. That’s improvisation: rigorous preparation, played in response to what the room is actually giving you, not what you rehearsed for. It’s not winging it. The best client work I’ve been part of looked exactly like that.

    Herbie Hancock told a story about a night playing with Davis when he hit what felt like a disastrously wrong chord mid-solo. Davis responded by playing notes that made it fit. Hancock later reflected: “Miles didn’t hear it as a mistake. He heard it as something that happened. As an event.” The band didn’t stop. They built on it.

    That idea — the listening, the harmony, the groove, the shared thing you create together — has shaped how I think about client meetings, virtual or in person.

    What does your business card say? I’m curious.

  • When delivery scales — and architecture sets the pace

    When delivery scales — and architecture sets the pace

    When a program scales to more teams, I am regularly involved designing the team setup — and regularly the wrong person to do it.

    Not because I lack the experience. But because the knowledge that should drive that decision is not with me. It is in the domains.

    Anyone scaling a large modernization program often has the same instinct: build more teams, divide the scope, assign the available people to the newly defined areas. Bring in a leadership group that has the overview and can decide who’s needed. That sounds like sensible program management.

    It is structurally wrong — and the root cause is architectural, not organizational: as long as the domain boundaries are unresolved, resource allocation drives architecture. That is Conway’s Law. And we now know exactly what follows from it.

    The assumption that holds the classical approach together

    The classical approach works like this: a leadership group — program managers, architects, sometimes external consultants — designs the target organization. Teams are structured around capabilities, technical layers, or resource availability. Then the available people are fitted into that structure.

    McKinsey puts the starting point plainly in their Agile transformation methodology: “Most transformations start with building the top team’s understanding and aspirations.” That sounds plausible. The problem is the assumption underneath it: that the knowledge of what good team structure looks like sits at the top.

    It does not. And in a transformation of the complexity that decades-old legacy or even mainframe estates carry, that mistake is particularly consequential.

    Why the knowledge sits in the domains — and what Conway has to do with it

    The teams working daily with the systems and business processes understand the dependencies of the existing estate better than any leadership group does. They know which parts of the system are tightly coupled. They know where the real interface problems lie.

    Melvin Conway formulated in 1968 what we now call Conway’s Law: organizations that build systems inevitably produce designs that mirror their own communication structure. This is not a metaphor. It is a causal statement. If I cut teams along technical layers or by availability, I get a system architecture that mirrors that division — not the one I wanted.

    MacCormack, Rusnak, and Baldwin gave this empirical grounding in a 2008 Harvard Business School study. They examined how closely organizational structure correlates with product architecture — the so-called Mirroring Hypothesis. The finding: products from loosely coupled organizations are roughly eight times more modular than those from tightly coupled ones. Poor organizational design produces poor modular architecture — not as a side effect, but as a direct consequence.

    For a large modernization program — the type I work with — this means: the decision about how to cut teams is not a resourcing question. It is an architectural decision. And it must be made before the resourcing begins.

    The Inverse Conway Maneuver: architecture first

    Anyone who wants to deliberately create the architecture they want must design the team structure accordingly — not the other way around. Instead of defining teams and hoping the architecture follows, we reverse the sequence. We start with the question: what architecture do we need? What domains does the system have, how strong are their internal dependencies, how loose their connections to the outside?

    This reversal — known in the literature as the Inverse Conway Maneuver and listed on the Thoughtworks Technology Radar as an established technique — is the central lever when scaling delivery programs.

    In practice, this works through domain analysis. We use Domain-Driven Design: Event Storming sessions with domain experts from the business, Bounded Context definitions, Context Maps. The goal is always the same: a domain map that shows which areas of the system are strongly correlated internally and have as few external dependencies as possible.

    That map is the starting point for the team cut — not the free slots in people’s calendars.

    Skelton and Pais develop a complementary idea in Team Topologies: every team has a cognitive load — a maximum mental overhead it can carry. Stream-aligned teams that follow a single value stream minimize handoffs and keep that load manageable. Top-down structures that distribute capabilities by availability routinely ignore that limit.

    A layer-based cut forces handoffs across all teams for every business change. A domain-based cut eliminates that dependency entirely.

    What this means concretely in a complex program

    A large modernization program — with a legacy and sometimes mainframe estate where logic has grown into a practically inseparable unit over decades — brings exactly this challenge.

    The modernization strategy we recommend in these programs is consistent: build domain by domain, following the Strangler Fig pattern, slice by slice. Start with a core that proves the architecture under real conditions — before the program scales to further domains. The core business domains provide the structure; their boundaries must be established before the team cut.

    This is exactly where the Conway thesis applies directly: the domain cut must precede the resource cut. Team ownership follows from domain structure — not from capacity availability.

    That is why the first phase of such a program begins with Event Storming and Domain-Driven Design. Not as a methodological ritual. But because that step lays the foundation for every subsequent decision: what Bounded Contexts emerge within the core domains? Where do the boundaries lie — and who takes ownership of them?

    A concrete example from practice: core insurance processes — new business, and mid-term policy amendments — each span at least three business domains in complex systems. A quote request triggers pricing in one domain; an accepted application issues a policy in a second; and the binding event (cover going effective) drives downstream obligations — billing, correspondence, commissions — that live in still other contexts. These cross-domain handoffs are exactly what Event Storming makes explicit — and exactly the evidence a team needs to decide where Bounded Context boundaries should be drawn. Had the team made that cut before this analysis, it would have either ignored those handoffs or split across them arbitrarily.

    A leadership group at the drawing board cannot answer these questions. They emerge through working with the domain experts from the business — in the workshops, across the event maps, through the collaborative refinement of Bounded Contexts. Only once that map exists does it decide how teams are formed and how accountability is distributed.

    Self-Selection: letting the team decide

    In some programs we go one step further — and this is the step that generates the most resistance when we first propose it.

    Instead of centrally assigning available people to the newly defined domain teams, we let the team organize itself. The domain map is on the table. The available slots are transparent. The constraints are clear: skills, experience distribution, seniority. And then we ask people where they see themselves.

    The evidence for this approach is consistent — even if it comes from case studies rather than controlled experiments. Sandy Mamoli and David Mole documented self-selection through their work at Trade Me and in their book Creating Great Teams: teams that formed without direct management assignment became high-performing teams over two years, with minimal subsequent adjustments. Martin Lohmann’s experience report on SimCorp’s Product Division — a SAFe rollout involving roughly 550 people forming 55+ teams across seven ARTs — shows the same pattern at larger scale. At New Relic, around 50 software teams were entirely reformed through self-organization under predefined constraints. The organizers described the outcome afterwards as “way more successful than anybody anticipated”. And I have seen it working myself.

    An unexpected side effect: people chose colleagues they wanted to work with. That sounds simple — and it is. Those who get to choose take ownership. Those who are assigned wait and see.

    The natural moment for a self-selection session is the close of the program’s first phase: once the Bounded Context map of the core domains is in place, the team slots and their areas of responsibility are transparent enough for people to make an informed choice.

    Execution matters: self-selection requires active facilitation. Without it, the results are not good teams — the case studies show that as clearly as they show the successes.

    The further a program moves from self-selection toward central assignment, the less ownership people feel — and the more adjustment the structure needs afterwards.

    How this fits the broader conversation

    The Spotify model appears in every discussion about team scaling. Joakim Sundén, one of the Agile Coaches who worked alongside the model during its formation, described it as “part ambition, part approximation” — never fully implemented, always an aspirational image. What companies copied was the structure: squads, tribes, chapters. What they ignored was the culture — genuine autonomy, psychological safety, the willingness to let mistakes happen. Structure without domain logic and without real decentralisation is just a label.

    The difference does not lie in the org chart. It lies in who holds the knowledge that informs the cut.

    What this means in practice

    Scaling is not a resourcing problem. It is an architecture problem.

    Adding new teams without first understanding the domain structure of the system builds an organizational form that — by Conway’s Law — produces a system architecture. And that architecture will not be the one you wanted. The HBS study shows this effect is real and measurable, not theoretical.

    For a complex modernization program, this means concretely: the investment in Event Storming and Domain-Driven Design at the outset is not a methodological box-tick. It is the precondition for the teams that scale in later phases to work along the right boundaries. Domain ownership, Bounded Contexts, Context Maps — these artifacts are not just architecture documents. They are the foundation of the team organization.

    Who decides where the domain boundaries should lie? Someone in the leadership group who knows the scope — or the people who work with the system daily and know where the real couplings are?

    In the programs I work with, this question is regularly answered implicitly before it is ever asked. That is usually how the problem starts.

    Sources and further reading

    Thoughtworks / Inverse Conway Maneuver

    Conway’s Law — empirical foundation

    Team Topologies

    Self-Selection

    Spotify — a closer look

    McKinsey Agile

  • Never made for this place. And still here.

    Never made for this place. And still here.

    Header image — Photo credit: “Oryx and Wild Horses (37049749623)” by Sonse, CC BY 2.0, Wikimedia Commons

    A 500-kilogram horse needs 25 to 30 litres of water a day. In extreme heat, that need can more than double. A camel survives two weeks without a drop. An oryx cools its blood through a heat-exchange system in its skull and only begins to sweat once its core temperature has risen by six degrees.

    The horse has none of that.

    And yet horses have been living in the Namib Desert for over 110 years.

    I first saw this in a documentary on ARTE. In 2023 I was in Namibia — and the image of these animals stayed with me.

    Twenty-five kilometres west of Aus lies Garub. A borehole, drilled in 1908 to supply steam locomotives on the railway line. A small observation shelter. And in front of it: horses — in a landscape that was never meant for them.

    How they got there is not documented with certainty. The most plausible explanation — also cited in the official Namibian management plan — is this: Emil Kreplin, mayor of Lüderitz, ran a stud farm on the Kubub estate until 1914, just a few kilometres from Garub. When he was interned as a civilian and transported to South Africa, his horses were left behind. In March 1915, an attack on the South African supply post at Garub likely drove additional military horses into the desert.

    There are other stories, as well. Whatever exactly happened: a historical event — colonial rule, the First World War, the upheaval of a collapsing administration — threw these animals into an environment they were never built for. And they stayed.

    Namib wild horses in the open steppe near Aus

    Photo credit: “Desert Horses close to Aus – Namibia” by Raymond June, CC BY 2.0, Wikimedia Commons

    Telané Greyling has documented what that looks like in practice across 28 years of field research. The horses drink every two to three days — not daily, as domestic horses do. They sleep roughly four hours a day to keep the distances between grazing ground and waterhole as short as possible. They accept grasses and desert shrubs a domestic horse would refuse.

    A physiology study in 1991 put it plainly: the Namib horses are behaviourally adapted — not physiologically transformed. Per unit of body mass, they differ little from an ordinary domestic horse. They survive because they have learned to go thirsty. Not because they have become desert animals.

    They remain, and always will be, something that does not belong there.

    And they cannot leave.

    To the north and east: the wildlife fence of the national park. To the west: the Atlantic coast, where there is no water. The borehole at Garub is the only reliable water source for hundreds of kilometres. Their entire home range: roughly 34 square kilometres. They never stray more than 15 to 20 kilometres from the waterhole.

    Wild horses at Garub waterhole — field research photo

    Photo credit: Telané Greyling, CC BY-SA 2.0, Wikimedia Commons

    Between 2013 and 2018, not a single foal survived. A spotted hyena clan had established itself in the territory — and the horses had no escape route. In 2013 alone, roughly 100 animals died, half of them foals. The population dropped from 286 to 74. Only targeted intervention and better rainfall years turned the tide: the herd today is estimated at 250 to 300.

    The conservation debate around these horses is revealing. The Namibian ministry views them as a non-native species and tends towards letting nature take its course. NGOs and the tourism industry push for active protection. In 2019, the ministry shot three spotted hyenas to protect the horses — a native, protected species, sacrificed for a feral non-native one.

    The horses fit no clean category. Not native. Not invasive in the conventional sense. Not domesticated. Not wild in any evolutionary sense. They exist in a gap that the existing terms do not cover.

    Now, why do I write about this?

    It is not about the feat of survival — that is remarkable, but it is about the situation of living beings who arrive in an environment they were never made for — not through choice, not through evolution. In the case of the horses, it has been through a historical event. My thoughts wander to living beings that are adapting in behaviour but remaining physiologically foreign. Who cannot break out. Who survive — but in a state where adaptation and emergency have become indistinguishable.

    I sometimes wonder about us, homo sapiens in the 21st century. I am looking at myself and wonder how much I am equipped as a human being to survive my current environment.

    The horses at Garub don’t ask this question. They drink.

  • The Atlantic: A Bass Built by a Friend Who Cares

    The Atlantic: A Bass Built by a Friend Who Cares

    My friend Tillman has been building electric basses for years. I finally bought one. There’s just one small problem: I don’t play bass. Yet.

    Tillman Anton is one of those rare people who has turned a deep love of his craft into a life’s work. He has been building electric basses for many years — and the Atlantic, a five-string he made, is a masterpiece. The wood, the weight, the detail in the neck. You hold it and you understand immediately that this came from someone who cares.

    I am a musician. Not a bass player — but anyone who loves music gets drawn into the world of beautiful instruments. I could not keep admiring Tillman’s work from a distance any longer. So I bought one. And yes, the coming months will involve learning to play it. That is part of the joy.

    If you love basses — or you know someone who does — take a look at what Tillman builds. He will find the right instrument for you too.

    antons-instruments.de

  • Automate the Boring Stuff: Why the Book Was Right All Along

    Automate the Boring Stuff: Why the Book Was Right All Along

    Years ago I bought a book called Automate the Boring Stuff with Python. I read most of it. I understood it. I never actually automated anything.

    The book was fine. The problem was me.

    I was a developer earlier in my career. I knew enough Python to follow every example — renaming and organizing thousands of files in one go, scraping a website instead of copy-pasting data by hand, bulk-processing Excel files or PDFs, filling forms automatically. The use cases were real. The payoff was obvious. And yet none of the scripts ever happened.

    The honest reason: I had stepped away from daily coding. Getting fluent enough to actually build and debug a working script would have cost more time and mental energy than the task I was trying to automate. The ROI was negative. So the book sat on the shelf.

    That changed when I started using ChatGPT and Gemini as coding co-pilots. I was still writing Python — but with help. The activation energy dropped enough to make some scripts worth finishing.

    Then I started working with Claude Code. Now I don’t write the Python myself at all. I describe what I want. The AI builds it, iterates, fixes it when something breaks. The barrier is simply gone.

    What I keep thinking about is this: the book’s promise was always correct. The bottleneck was never the tool, and it wasn’t willpower either. It was the cost of re-fluency for someone who had moved away from daily coding. AI removed that activation energy entirely.

    Which means the constraint has shifted. The question is no longer “can you code well enough to automate this?” That question is gone. The question now is “do you have good enough judgment about what is actually worth automating?” That’s a thinking skill, not a technical one.

    The tool was never the barrier. Knowing what to point it at — that’s the work that remains.

    What boring task would you finally automate — now that coding fluency is off the table?

  • Cynefin: We need to teach this in school!

    Using the wrong tools

    You probably know about his metaphor: Using a hammer to drive in a screw. While I knew about the idea of using the wrong tools to solve problems for many years, I only recently learned about the Cynefin. This framework describes this situation much more profoundly and has been an eye-opener for me. Having been a victim but also a perpetrator of “using the wrong tools”,  I can’t wait to write this blog post. Because so much pain has been created.  So much effort, money and motivation has been wasted. And even worse, it continues everyday. We need to change this! You need to learn about the Cynefin-framework and you need to pass on the word.

    I will only scratch the surface of the framework, but that might already sufficient to change the way you see the world. At least that‘s how it was for me when I first got in contact with it. But before I start to talk about the framework let me provide some of my very own examples that should explain  why we need to learn about it:

    • Several years of time and lots of money wasted trying to develop a new revolutionary product for a large German firm; treating this as project to implement some fixed scope without regularly asking for feedback and quickly pivoting.
    • A large, company-wide transformation project managed with a project plan containing some thousand tasks.
    • Countless well-thought-out strategies and large re-organisations failing or not fully reaching the desired and planned outcomes
    • Neglecting what we already know of good-practices in project management when building an office 
    • Hours and hours of heated discussions about the best way of working

    And these are only me own personal experiences… So, without further ado, let me quickly present you the the Cynefin-framework. I will come back to these examples and some notes on digital transformations later.

    The Cynefin-Framework

    This is how the Cynefin-framework looks like. You can see four quadrants. Unlike many other models, it does not have dimensions, i.e. there is no x or y axis. It‘s basically these four quadrants and some area or space that separates these area. I will not talk about these borders and why some of them are thicker and some are thinner. Let‘s keep it simple. Four quadrants. The titles of them all start with with the letter „C“. They are called CLEAR, COMPLICATED, COMPLEX, and CHAOTIC.

    What can we find in these quadrants?

    Let me quote Sonja Blignaut from the book “Cynefin. Weaving Sense-Making into the Fabric of our world”. She writes “At its most basic, Cynefin allow us to distinguish between three different kinds of systems:

    1. Ordered systems that are governed and constrained in such a way that cause and effect relationships are either clear or discoverable through analysis;
    2. Complex systems where causal relationships are entangled and dynamic and the only way to understand the system is to interact; and
    3. Chaotic systems where there are no effective constraints, turbulence prevails and immediate stabilizing action is required”.

    Let‘s start with Clear: Clear is the domain of best practices, the solution to a problem is visible to everybody. The relationship between cause and effect is obvious or has become obvious. Some examples might help: How about  the work in a call center: a customer calls, the agent listens and then quickly chooses a corresponding script to help the customer with a solution to the problem.

    Another example could be building a family home. A house. That‘s not a simple task. But it has been done a billion times before. We have best practices. The domain is fully understood. There are even catalogs in which you can choose your dream home. By the way, clear or obvious or simple does not mean easy. It can still be difficult and hard work. Moreover, building a special opera house like the one in Hamburg does not fall into this domain. 

    Now the Complicated domain.  Here, the solution is not visible to anyone.  You need expert knowledge. This is the expert domain. An extreme example could be flying to the moon. There was a massive amount of expert knowledge and analysis required to master this enormous challenge. Yet the relationship between cause and effect, although complicated, could finally be understood. Or how about building cars. Engineering work. Another example from the IT world would be the global roll out of an ERP system. This is clearly not an easy task, yet we have good practices for that. We can build methodologies for that. We can have process charts, templates, role descriptions, artifacts. We might build a physical or commercial model. We might even be able to analyse and estimate the work and offer a fixed price since we know how to control and manage the work.  Problem solving in the complicated domain is not easy. But if you get enough brain power, if you get your best engineers and experts onto the project, you will be able to find a good solution. Maybe not the best one. This is because the relationship between cause and effect can be analysed and understood.

    Now, this is all different in the Complex domain. Here, the relationship between cause and effect can only be perceived in retrospect. What does that mean? Well, the impact is enormous. No matter how many experts you assigned to a problem, no matter how smart they are, no matter how hard you try, you are not able to derive a solution. Well, in fact you might be able to create a solution, and you might convince yourself and others that this is the solution. But as the cause and effect relationship in the complex domain is only visible in retrospect you are simply fooling yourself and others. And this is happening everyday. And I can confess: I have been a great fool myself.

    To make this article concise, I am skipping the Chaotic domain. The interested reader will have no problem to finding out more about Cynefin and go much deeper.

    For now, let’s focus on the implications: Like many of us, I have been socialised with the belief that through proper analysis we can find a solution. Being trained in mathematics and engineering I would look at a problem (“sense”), then take it apart, understand its properties (“analyse”) and finally develop a solution (“respond”). With proper training and some years of experience, I have become an expert in my field (e.g. project management) and became good at applying the practices. Where is this approach located in the Cynefin framework? Well, you guessed it right, it’s in the Complicated domain. So far so good. But the problem starts when we apply our good practices in the complex or chaotic domain. Here, the cause-effect relationship cannot be known in advance. Thus, we need a very different approach. In the complicated domain, we first need to try out something (“probe”), then we see how things develop (“sense”), and from the feedback we have received, we continue or change our approach (“respond”). In a nutshell, this is what agile methodologies are all about. They emphasise on fast feedback and acting upon it.  So coming back to the initial metaphor, we get into trouble when we apply the wrong tools (think “hammer”) in a specific environment. Most often I see this as good practices from the complicated domain being used in the complex domain. That might be project and program management methods used in complex product development or for transformations. But sometimes also (yet, less often) when we use agile methods in situations where we already have good practices in place.

    Moreover, knowing the Cynefin-framework, the discussion we often have during a digital transformation becomes much easier. As it is not about which way of working is better. Is agile better than waterfall? Or the other way around? This is fundamentally the wrong question. It’s rather if the set of tools or approaches are well suited to the domain. 

    I wished I would have known about Cynefin much earlier.  This would have saved myself and my teams a lot of wasted effort (being the person using the wrong tools).  Or it would have given me the confidence and the arguments to say out loudly that something is going deeply wrong (being the victim). I wished we all would learn about the Cynefin-framework. So why not discuss it in school? Until we are there, please help to save ourselves lots of wasted effort. Please have a look at it yourself and tell others about it.