The Principle Studio the Codex
Scroll · turn the room
Hover a plate to read its title. Click to open. Scroll to travel the register. Tap to open · swipe to travel
A system is just a set of things that work together to produce a result. Every business is made of them. The trouble is that half of them are invisible, and that half is where the real problems live.
The situation
A founder called me about a contract-manufacturing business doing about ฿140M a year. Forty staff. Healthy order book. He could describe his sales process, his production schedule, and his Monday operations meeting in clean detail. On paper the company looked well run.
But he was working twelve-hour days and could not say why. Every time we traced a delay or a dropped ball, it led back to a decision that had quietly routed through him. He was not slow. He was the single point every important thing passed through, and he had never noticed because none of it was written down.
The first read
When I read a business, I separate what it can describe from what it actually runs on. The first question is never "is this a good process." It is "where does this decision really get made, and who has to be in the room for it to happen."
In his company, the describable systems were fine. The invisible ones were the problem. The way a price got approved, the way a production exception got resolved, the way a new hire learned who to ask: none of it existed on paper. It existed in his head. So the company could not run a day without his head in it.
The frame: two systems
1
The describable systemSales process, reporting cadence, the weekly meeting. Written, trainable, improvable. Knowledge lives on paper, not only in people. This is the easy half.
2
The invisible systemHow decisions actually get made, the informal hierarchy that overrides the official one, the workarounds built around things that do not work. Lives in heads. This is where most business problems sit.
When I say "systems," I mean both kinds. An owner who keeps getting pulled into decisions he should be delegating is not failing at delegation. He is operating inside an invisible system where delegation does not work yet. The intention loses to the structure every time.
The working
We spent two weeks writing the invisible system down. Not inventing new process, just making the existing one legible: who decides a price, inside what band, and when it has to come up to him. Who owns a production exception. What a new buyer needs to know in week one. The change was small in effort and large in effect.
| Before | After | |
|---|---|---|
| Price approvals routed through owner | All of them | Above ฿200K only |
| Decisions that needed him in the room | Most | A handful |
| New buyer time to independence | ~5 months | ~6 weeks |
| Owner hours per week | ~60 | ~45 |
Nobody worked harder. The work that used to require him simply stopped requiring him, because the system around the work could now hold it.
Why I talk about systems so much
Not because it is a consulting habit. Because almost every business problem I have seen, traced far enough, is a systems problem. The product is rarely the issue. The team is rarely the issue. The system those people are operating inside is the issue. When the system changes, behavior changes, without anyone having to try harder.
Change the system and behavior usually follows. That is most of the job.
What I do is diagnose both layers, then build a describable system that can slowly absorb the invisible one. That is what I mean by systems.
There is a kind of business problem that never shows up on a dashboard. The numbers are fine. The owner is not.
The situation
A specialty food distributor, about ฿180M in revenue, growing ten to fifteen percent a year. Good margins, loyal clients, a capable team. By every metric the owner tracked, the business was winning. And she had not taken a real week off in four years. She thought about the business at eleven at night. Every decision that mattered still flowed through her.
She came to me thinking she had a discipline problem, that she needed to manage her time better. She did not. She had a structural problem wearing the costume of a time problem.
The diagnostic question
There is one question that exposes this faster than any audit. I asked her: if you stepped away for three months, which parts of the business would hold, and which would start to drift?
She answered without hesitating, which told me she already knew. We wrote it down. The exercise is simple and it is brutal, because the list of what drifts is a map of everything that secretly depends on one person.
| Function | Holds without her? | Why |
|---|---|---|
| Fulfilment + logistics | Holds | Real process, owned by ops lead |
| Routine reorders | Holds | Standardised, team runs it |
| Key supplier terms | Drifts | Relationships live only with her |
| Pricing on new accounts | Drifts | Judgement never written down |
| Big-client escalations | Drifts | Every one routes to her |
How I read it
The business had grown large enough to create real complexity, but it had not grown into a structure that could hold that complexity without her. So she held it. Personally. All the time. That is what I call a business that cannot leave you.
The word founder usually means someone who started something. At some point it has to evolve. What gets a company to ฿100M usually lives in the founder’s head: personal skill, personal judgement, personal relationships. Getting to ฿300M means the opposite move. You turn that judgement into structure other people can run, so the company stops depending on the person who built it.
The move
- 1Name what driftsThe three-month test gives you the exact list. Do not guess. Let the business tell you where it depends on you.
- 2Write the judgement downPricing logic, supplier terms, escalation rules. The thing in your head becomes a rule someone else can apply.
- 3Hand over the decision, not just the taskGive a person the choice plus the authority and the band they can move within, then a way for the exception to come back up.
This transition is not automatic. Most founders never notice they have entered it. They just feel tired in a way they were not before. The tiredness is the signal. It means the business has outgrown the structure that runs it.
A business that cannot leave you is not a strong business. It is a business with a single point of failure, and the point is you.
The list of what drifts is not a verdict. It is the work plan. Each item you move from your head into the structure is one more week you could be gone and the company would not notice.
Most founders see AI integration as either a tool they buy for the team or something technical that needs an engineer to explain. Both framings miss the point. At the ฿100M scale, AI integration is mainly a business problem, not just a technology one.
The situation
A distribution business, around ฿120M, had bought every tool the market offered. The team used them. The founder kept asking why the company did not feel any different. He was measuring adoption and seeing usage, but the shape of the business had not moved an inch.
The reason was simple. All of his AI work sat in one layer, the shallowest one. He was buying speed on individual tasks and calling it transformation.
The frame: three layers
1
Task automationAI drafts, summarises, answers routine inquiries. A two-hour task becomes twenty minutes. Real speed, but the shape of the business does not change. Many companies stop here.
2
Process integrationAI changes how work flows. Review steps route automatically, week-long reporting generates overnight, knowledge trapped in heads gets captured and made operational. Gains compound. This is the untouched upside.
3
Decision supportAI surfaces what the business could not see: not what happened, but what will likely happen, and where human judgement actually matters. Rare at this scale. Hard to replicate once built.
How I read it
The question is never which tools to buy. It is which work the tools touch, and how deeply. Layer one is already happening in most businesses by accident. The real value sits in layer two, in the handoffs between steps, where key knowledge still lives in people’s heads: the experienced buyer who knows which suppliers are reliable, the ops manager who can feel which client is about to churn.
The working
We mapped his processes against the three layers and found the pattern almost everyone has.
| Layer | His effort | Actual upside |
|---|---|---|
| Task automation | High | Low, already captured |
| Process integration | Almost none | High, untouched |
| Decision support | None | Real, but needs layer two first |
He had spent eighteen months optimising the layer with the least left to give and ignored the one with the most. Not because he made a bad call, but because layer one is visible and easy to start, and layer two requires you to change how work actually moves, which is harder and quieter.
The move
Start at layer two, and only on the sequences where knowledge is currently trapped in a person. Layer three is worth wanting, but it requires layer two to be solid first. You cannot model what will happen until the record of what does happen is captured and clean.
If your team uses AI but the business does not feel different yet, you are still in layer one. The work that changes the company is in layer two.
The right question to spend a week on is not which tool. It is: which sequence of work, today, still depends on one person remembering something. That is where layer two begins.
Most strategy work fails at the beginning, not the end. The offsite goes well. The plan is sound. Three months later almost nothing has changed, and everyone blames execution. They are looking in the wrong place.
The situation
A services firm, about ฿90M, ran a clean strategy offsite. The leadership team agreed to move upmarket: fewer, larger clients, higher fees, deeper work. Everyone left aligned. A quarter later the firm was still taking the same small accounts it had decided to stop taking.
The owner wanted to talk about accountability and follow-through. I asked to see how the sales team got paid.
How I read it
When a strategy stalls, the cause usually sits upstream of execution. Two structures defeat more plans than any lack of effort, and both are invisible until you look for them.
1
The incentive structureIf people are still rewarded for the old behaviour, the new strategy loses every time. Not because they disagree with it, but because the system makes the old move the sensible one.
2
The decision structureA strategy that needs fast, decentralised decisions runs aground in a business where every real call must reach the top. The structure obstructs the plan, and no one is to blame.
The working
The firm paid its salespeople on volume of accounts closed. The new strategy asked them to close fewer, larger, slower deals. The math told them to ignore the strategy, so they did, rationally.
| What strategy asked | What pay rewarded | |
|---|---|---|
| Deal size | Larger | Any size |
| Deal count | Fewer | More |
| Sales cycle | Longer, deeper | Fast close |
| Rational choice | Move upmarket | Keep churning small deals |
No one was obstructing the plan. The plan was simply more expensive to follow than to ignore, given how the business was built. That is what a real diagnosis looks for: not whether the strategy is good, but whether the business is structured to support it.
The move
Before starting any strategy work, I ask one question: what would have to be true about this business for the strategy to actually run? The answer usually names the real problem, and it is rarely the strategy itself.
The answer is not to explain the strategy more clearly. The strategy is clear enough. What is unclear is why the business is built to make it expensive.
Most businesses are not structured for their own strategy, not because of bad leadership, but because structure changes slowly and strategy moves fast. Fix the incentive and the decision path first. Then the plan runs on its own.
Most businesses try to fix the wrong thing first. Not because they make bad decisions, but because they solve for what is visible instead of what is foundational.
The situation
A consumer-products company, about ฿75M, decided its problem was sales and invested heavily in a bigger sales team. Six months later revenue was up modestly and profit was flat. They had sold more of a product whose margin could not carry the cost of selling it. The sales investment was real. It was just second in line.
How I read it
When something is broken, the visible problem is rarely the first thing to fix. If the basic math of the business is not right, better sales will not solve the core problem. It just grows the same problem faster, at higher cost.
So I read a business in layers, and I fix from the bottom up. The order matters more than the size of any single investment.
- 1The economicsDoes each unit, client, or job actually make money after the true cost of serving it? If not, nothing above this holds.
- 2The operationsCan the business reliably deliver what it sells, at that economic structure, without heroics?
- 3The growthOnly now does more sales, more marketing, more capacity convert into durable profit instead of faster loss.
The working
We went one level down before going forward. The product mix was the real issue: two lines carried the company, three quietly drained it. Once the economics were fixed, the same sales effort produced a different result.
| Sales-first | Economics-first | |
|---|---|---|
| Revenue | Up ~12% | Up ~9% |
| Gross margin | Flat | Up 6 points |
| Profit | Flat | Up materially |
| What scaled | The problem | The business |
Slightly less top-line growth, far more profit, because the growth was now landing on a foundation that could hold it. Selling more had not been wrong. It had been out of order.
The move
Going one level down usually means slowing down, which feels dangerous in a business under pressure. But the companies that sequence well are the ones that make durable progress. They find the thing that, if fixed, makes everything above it easier or unnecessary.
Solve the foundational problem before the surface one. The ordering matters more than the investment.
That is the sequencing principle. When you invest in sales, the business should already be ready to convert it. When you add operating capacity, the structure should already be there to hold it. First the level below, then the level above.
The pilot ran. The tool worked. Three months later, nobody uses it. This is the most common AI story I hear from founders right now. Not "we tried AI and it failed." More like "we tried AI and it kind of faded."
The situation
A ฿100M services firm ran an AI pilot that everyone agreed was a success. The demos were good. A few people loved it. By the next quarter, usage had quietly collapsed to two enthusiasts who were already efficient before it arrived. Leadership concluded AI was overhyped. The tool was never the problem.
The frame: four reasons
When a pilot fades, it is usually one of four structural reasons. None of them announce themselves clearly, and none of them are fixed by buying a better tool.
- 1It ran beside the work, not inside itOptional tools rarely become habitual. If using it requires a deliberate choice every time, most people skip it most of the time. In three months only the enthusiasts remain.
- 2It helped, but not the important workPilots go where they are easiest to introduce: drafting emails, summarising documents. The highest-value work stays untouched, so the payoff reads as a slightly faster email process.
- 3Nobody owned it after launchOne champion onboards everyone, then moves on. Prompts that worked in month one stop working in month two as context shifts. Nobody updates them. The pilot becomes a static artifact.
- 4The business changed and the pilot did notA ฿100M business is not the same business it was six months ago. New bottlenecks appear. A pilot built around yesterday’s problem will not hold into tomorrow.
How I read it
In this firm it was the first two reasons stacked. The tool sat next to the workflow as an option, and it had been aimed at the easiest tasks rather than the work that actually moved the business. So adoption depended on willpower, and the payoff was too small to be worth the willpower.
| Reason | Tell | Fix |
|---|---|---|
| Beside the work | Usage needs a deliberate choice | Build it into the default flow |
| Wrong work | Payoff is a faster email | Aim it at high-value decisions |
| No owner | Prompts decayed, nobody noticed | Assign ongoing ownership |
| Business moved | Solved a problem you no longer have | Re-fit to current bottlenecks |
The move
The fix is not a better tool. It is a different approach to integration: put the tool inside the flow so using it is the path of least resistance, aim it at work that actually matters, and give it an owner who keeps it fitted to a business that keeps changing.
If your AI pilot did not stick, look here first. The answer is almost never the model. It is one of these four.
The good news is that all four are fixable, and none of them require starting over. They require treating the pilot as a system to be maintained, not a demo to be admired.
Is this actually different, or is it just a new kind of the same? That is the question I hear from founders whenever a major shift arrives. It came up with e-commerce, then with mobile, and it is here again with AI.
Why the question matters
The answer determines what you do. If a shift is genuinely different, you have to move. That can mean changing what you compete on, rebuilding parts of the business, or repositioning entirely. If it is the same pattern in new clothes, you might need only a targeted adjustment, or simply to wait. Reading it wrong in either direction is expensive.
How I read it
The founders who read a shift correctly look at it through the lens of their specific business, not the general narrative. The narrative says "AI changes everything." That sentence is useless to you. The useful question is: what does it change for a ฿150M food distributor, a specialty manufacturer, a regional services firm? Yours, specifically.
Three patterns from the last two years
| Business | How they read it | What it cost |
|---|---|---|
| Distributor at ฿200M | Treated AI as an IT project, moved slowly | Two years of compounding advantage lost to a competitor |
| Services firm | Saw it only as a tool | Five staff left in a year to start AI-assisted versions of the firm |
| Founder I worked with | Read it as a decision-ownership question | Eighteen months to make it hold, but it held |
The distributor read the shift as technology and moved at the speed of an IT upgrade. A competitor read it as an operating change, restructured sourcing, cut lead times, and took margin. The services firm read it as a feature and missed that it was a structural signal: its own people could now rebuild its service with a fraction of the firm underneath them.
The pattern underneath
In all three, the technology was visible and the business problem underneath it was not. The founder who succeeded did not move fastest. He read the shift through one precise question: who owns the decisions about how work actually gets done. That is why his integration took eighteen months and still held, while faster efforts faded.
Reading the era correctly means reading your specific business, not the general signal.
The move
The shift is real. The question worth spending a week on is not whether AI matters. It is: what specifically changes for you, and what specifically does not. Write both columns. The honest version of that list is your strategy for the era, and it will look nothing like the headline.
The best operators in any business are often the hardest people to move. Not because they are bad at leadership, but because they are so good at their current role that moving them creates two problems at once.
The situation
A manufacturing business, about ฿110M, was built on its founder. Deep product knowledge, personal relationships with every major client, the ability to make fast calls with incomplete information. These were real, hard-won strengths. The company was designed around them. And they had quietly become the ceiling.
The frame: two forms
1
The trapped performerA founder keeps a high performer in a role they have outgrown, because the business cannot afford to lose what they do there. The person stalls, grows frustrated, and eventually leaves anyway, taking the skill and the time it took to build them.
2
The trapped founderHarder to see, because it happens to you. The exact skills that built the company start to limit it. Your strengths and the business’s needs begin to diverge, and you feel it as working harder for less effect.
How I read it
I look for the places where a strength has turned into a bottleneck. In this business, each of the founder’s strengths had become a constraint as the company grew.
| Founder strength | At ฿30M | At ฿110M |
|---|---|---|
| Deep product knowledge | Decisive edge | Bottleneck: every spec routes through him |
| Personal client ties | Loyalty + trust | Vulnerability: one relationship from losing an account |
| Fast solo decisions | Speed | Congestion: too many to make, all waiting on him |
Nothing about him got worse. The company got bigger, and a set of personal capacities that scaled beautifully to ฿30M could not scale to ฿110M, because personal capacities rarely do. That is the trap. It is not a failure of the person. It is a failure to convert the person into structure.
The move
The way out is not to diminish what the founder built. It is to build a structure that can absorb it. Make the decisions repeatable. Document the product knowledge. Give the key relationships a structure that can survive a transition. The goal is a business that runs on its own, not one that runs on a person.
The competence trap is the moment your strengths and the business’s needs stop pointing the same way.
It takes longer than most founders want, because it means handing over the very things you are best at. But it is the only path from a company that depends on you to one that does not. The strengths do not disappear. They become the design.
Most delegation fails because it is treated as a handoff instead of a design problem. The leader is busy, passes a task to someone, and hopes it works. Sometimes it does. When it does not, the leader concludes delegation is unreliable and takes the task back.
The situation
A founder told me he had "tried delegating and it does not work here." His people either froze on decisions they should have been able to make, made calls they should not have, or quietly routed everything back to him. He read this as a people problem. It was a structure problem, and it had a precise shape.
The frame: three elements
Delegation that holds requires three things. Hand over a task without them and you have not delegated, you have abdicated with good intentions.
- 1A decision frameWhich choices can this person make without checking, and which must come back up? Without the boundary, they either freeze or overstep. The band is the whole point.
- 2A feedback loopHow will you know something is going wrong before it becomes a crisis? Delegation without visibility is a gamble, and you will pull the work back the first time it surprises you.
- 3Real authorityNot just the task, but the power to execute it without constant interruption. If everyone knows it still really runs through you, nothing has actually moved.
How I read it
When delegation is failing, I check which of the three is missing. It is almost never all of them, and the missing one tells you exactly what to build.
| What you see | Missing element |
|---|---|
| Person freezes, asks about everything | Decision frame: no clear band |
| Person makes calls they should not | Decision frame: band too wide, or unstated |
| You get blindsided by problems | Feedback loop |
| Everything quietly routes back to you | Real authority |
The move
Building the delegation structure is design work, and it takes time. It asks the leader to think carefully about what they are actually handing over: not just which tasks, but which decisions, which relationships, and what context the person needs to succeed.
Companies that scale write down how decisions get made, not just what decisions were made.
This is the difference between a business that grows by adding people and one that grows by adding capability. The first kind just gets bigger. The second kind gets stronger, because every handover that holds is one more thing the company can do without its founder in the room.
A founder called me last year about a sales problem. Revenue had been flat for eighteen months despite a hard-working team. I spent the first two sessions not talking about sales at all.
The situation
The numbers looked contradictory. Activity was up, the pipeline was full, conversion rates were fine, and revenue would not move. When the obvious inputs are healthy and the output is stuck, the problem is almost never where the pain is. It is one layer down.
How I read it
I do not start with the presenting problem. I start with one question: what in this business would make these exact results predictable? Flat revenue with high activity is not a mystery. It is a signal that effort is being pointed somewhere that does not move the number.
The working
The business had three product lines. We put the team’s time against the margin each line produced, and the picture resolved immediately.
| Line | Sales-team time | Margin | Trend |
|---|---|---|---|
| Line A | ~20% | High | Growing fast |
| Line B | ~45% | Low | Flat |
| Line C | ~35% | Low, service-heavy | Declining |
The team was spending four-fifths of its time on the two lines that could not move the company and one-fifth on the line that could. They were not underperforming. They were optimising for the wrong thing, because the incentive structure rewarded activity, not margin. The structure was pointing them at the wrong work, and they were responding to it rationally.
Improving sales output without fixing the incentive would have trained people to work harder in the wrong direction.
The move
We changed what the structure rewarded, so the team’s rational choice and the company’s interest finally pointed the same way. The structural change took about three months. The sales trajectory turned in the first quarter after it landed.
That is what diagnosis actually looks like. You do not treat the symptom the client names. You find the structure producing the pattern, and it usually sits one quiet layer beneath the place that hurts.