Engineering decisions,
derived down from the P&L.
Most technology advice starts with the technology. Mine starts with the business: where you make money, where you lose it, what the board is actually asking. From there it derives the architecture, the team, and the AI. It's the same method every time. The answer never is.
The method is how I engage: disciplined, repeatable, accountable. What I build inside it is never boilerplate, because in the AI-native world the state of the art moves too fast for canned solutions. The spine stays; the solution is always current.
What “business-down” actually means.
Two ways to make a technology decision. Only one of them survives contact with a board.
Technology-up is the default in our industry. You start from the stack (the framework someone likes, the cloud you already pay for, the model that's trending right now) and you reason upward toward the business, hoping the architecture you happened to choose lines up with where the company actually makes money. Sometimes it does. Often it doesn't, and you find out eighteen months and a few million dollars later.
Business-down inverts that. I start at the P&L (revenue, margin, cost of delivery, the risk on the board's mind, the number the company is being valued on) and derive every technical decision down from there. The architecture, the build-vs-buy call, the org chart, the security posture, and where AI earns its place all fall out of one question asked relentlessly: what does this do for the business?
It sounds obvious. It is almost never how technology gets decided. The reason is that business-down is harder: it requires someone who can read a cap table and a Kubernetes manifest in the same afternoon, hold both in their head, and translate each into the other. That seam, between the boardroom and the codebase, is where I've spent twenty-five years, and it's the only place this method works from.
The pay-off is that the method is repeatable without being canned. The four movements (Read, Direct, Build, Operate & Optimize) run the same way every engagement, so the work is disciplined, legible, and accountable. But because each call is derived down from your numbers and built with today's state of the art, the output is bespoke every time. The discipline is fixed. The solution is always current.
This is also why it's an AI-native method rather than an AI-flavoured one. AI isn't bolted onto the end as a feature; it's evaluated at every movement as a lever: sometimes the biggest one available, sometimes a distraction dressed up as strategy. Business-down is what tells the difference, because it measures AI the same way it measures everything else: against the P&L.
Also known as: the business-first method · P&L-down engineering · top-down technology strategy · the Read-Direct-Build-Operate method.
Technology-up vs. business-down.
Same engineers, same tools, opposite starting point, and very different outcomes.
Start at the stack, hope it reaches the business
- , Begins with frameworks, clouds and models: the tech that's interesting or already on the bill
- , AI adopted because it's the trend, measured by demos, not dollars
- , Roadmap is a feature backlog; the board can't see the money in it
- , Architecture optimised for engineering taste, not unit economics
- , Hiring fills seats by title; the org chart drifts from the strategy
- , Success is shipping; nobody can tie it back to margin or risk
Start at the P&L, derive the technology down
- →Begins with revenue, margin, cost of delivery and the board's real question
- →AI evaluated at every movement as a lever, measured against the P&L
- →Roadmap reads as a business case; each item maps to money or risk
- →Architecture optimised for unit economics, scale and cost control
- →Hiring derived from the strategy; the org is built to run the model
- →Success is the outcome: margin moved, risk retired, delivery made predictable
The reason it works: Conway's Law.
A fifty-year-old observation about software that quietly explains why most AI projects fail.
In 1967 a programmer named Melvin Conway noticed something that has held up ever since: any organization that designs a system will produce a design whose structure mirrors the organization's own communication structure. Put plainly, your software architecture ends up looking like your org chart. Four teams that barely talk will build four services that barely talk. A monolith built by one room of people stays a monolith long after it should have been split.
This isn't a metaphor; it's a force, and it acts whether or not anyone is paying attention. Most companies meet Conway's Law by accident. They pick an architecture for technical reasons, staff it with whatever org they already have, and then spend years puzzled about why the system keeps re-growing the shape of the teams instead of the shape they drew on the whiteboard.
Technology-up engineering is especially exposed here. It decides the architecture first and treats the org chart as an HR problem to be solved later, so the two get set by different people, at different times, for different reasons. Conway's Law then quietly overrules the architecture diagram and hands you the system your communication structure was always going to produce.
Business-down does the opposite, on purpose. In the Direct movement I draw the architecture and the org chart together, both derived down from the same P&L, so the team boundaries and the system boundaries are designed to match. Engineers call this the inverse Conway maneuver: shape the teams to get the architecture you actually want, instead of letting an accidental org produce an accidental system. Because business-down owns both decisions in one movement, it can use Conway's Law as a tool rather than be ambushed by it.
This is the single biggest reason AI projects fail, and it's almost never the reason that gets named. The models work. The pilots demo well. Then implementation meets an organization that was never designed for AI-native operations, and Conway's Law does the rest: teams, hand-offs and decision rights built for a pre-AI company can only produce a pre-AI system, so the AI ends up bolted to the side of a structure that quietly rejects it. The post-mortem blames the model, the data or the vendor. The real cause was the org chart. The company asked an organization that wasn't built to run AI to suddenly run it, and it faltered exactly when it was time to implement.
That's why an AI-native transformation has to redesign the organization, not just adopt the tools. The org now includes agents, pipelines and the people who supervise them, and the communication paths between them become part of the architecture. Derive that operating model down from the business and Conway's Law works for you: the system you ship is the system the business needed. Bolt AI onto a structure nobody designed, and the law hands you the mess your org chart was quietly describing all along. Business-down treats that redesign as the work, which is why it ships AI that survives contact with the company instead of stalling on it.
Conway's Law (Melvin Conway, 1967): organizations build systems that mirror their own communication structure. It's the main reason AI initiatives stall at implementation, and the inverse Conway maneuver is how the method turns it into a design tool instead.
Read → Direct → Build → Operate.
Four movements, one spine. Each call derived down from the business, never off a shelf.
Diagnose the system and the business
A clear-eyed read on product, team, architecture, security and spend, tied to your P&L. The real root cause, not the loudest symptom, plus where AI creates measurable leverage and where it's a distraction. You leave with a 90-day plan you can act on immediately, with or without me.
- →A system & architecture read
- →A team & delivery read
- →A spend & risk read
- →A 90-day plan you keep either way
Set the AI-native direction
Technology strategy tied to revenue. An architecture that scales. An AI-native operating model and the org to run it. Build-vs-buy, security and compliance posture, and the hiring plan. Every call derived down from the business.
- →A roadmap tied to revenue
- →An architecture blueprint
- →An org & hiring plan
- →An AI governance & usage policy
Ship the systems, build the team
Hands-on. Production AI systems in the product and the pipeline: agentic and retrieval architectures with the right guardrails, eval, observability and cost control built in. The SDLC rebuilt AI-first, security in every pull request. And the AI-native team, hired and operating, delivering at elite DORA. This is the part most “AI advisors” don't do. I do.
- →Production AI in the product
- →An AI-first SDLC & pipeline
- →Security in every pull request
- →An AI-native team, hired & running
Run it, measure it, make it stick
AI moves too fast to rest on a launch, so the work compounds. I run the operating model and measure it: DORA for delivery, cost and quality for AI systems. I re-run evals as models drift, adopt what's genuinely better, and feed production signals back into the product. Then I plan the transition: to an internal hire, an advisory cadence, or a trained team. No permanent dependency.
- →DORA & AI cost/quality metrics
- →Eval re-runs as models drift
- →Production signals fed back in
- →A clean transition plan
A typical engagement,
movement by movement.
The shape is consistent; the depth flexes with the company. A representative path from first read to a team that no longer needs me.
Diagnose
- Interview leadership, engineering and the operators who run the business
- Trace revenue and cost of delivery to the systems behind them
- Audit architecture, security, compliance and cloud spend
- Map where AI is a real lever and where it's theatre
- Deliver a written diagnostic and a 90-day plan you keep
Decide
- Set a roadmap tied to revenue and the board's question
- Choose the architecture and the build-vs-buy calls
- Design the AI-native operating model and governance
- Draw the org chart and the hiring plan to run it
- Align founders, board and team on one direction
Ship
- Ship production AI into the product and the pipeline
- Rebuild the SDLC AI-first with eval, observability and cost control
- Put security and compliance into every pull request
- Hire and onboard the AI-native team, hands-on
- Drive delivery toward elite DORA performance
Compound & transition
- Run the operating model and report on it monthly
- Re-run evals as models drift; adopt what's genuinely better
- Feed production signals back into product decisions
- Coach the internal leader who will take the seat
- Plan a clean exit: internal hire, advisory cadence, or trained team
Discipline you can measure.
The method is repeatable because its outputs are concrete. A sample of what comes out the other side.
What holds every time.
The movements change shape with the company. These don't; they're the constants that make the method itself.
Derived down from the P&L
Every technical decision starts at the business (revenue, margin, risk) and is reasoned downward to the stack, never the other way around.
One method, many answers
The four movements are fixed and repeatable. What they produce is bespoke to your numbers and built with today's state of the art. The discipline is the constant.
AI-native by default
AI isn't a feature bolted on at the end. It's evaluated at every movement as a lever, and measured against the P&L like everything else.
Hands-on, not hand-wavy
I build, ship and hire inside the engagement, not a deck and a goodbye. The Build movement is the part most advisors skip. It's the point.
Measured continuously
DORA for delivery, cost and quality for AI systems. The method reports on itself, so progress is legible to the board, not a matter of faith.
Built to hand off
The method ends in a transition: an internal hire, an advisory cadence, or a trained team. Success is the company carrying it without me.
Who it's for, and when.
The method works best in a specific situation. Honest about where it fits, and where it doesn't.
It's built for $10M–$50M software and software-enabled companies past product-market fit, with real revenue and real stakes, where a technology decision now moves the valuation, not just the backlog. Founders, CEOs and boards who need the engineering to serve the business, and private-equity investors who need a credible read before they sign and an AI-native value-creation plan after.
It's just as much for traditional organizations that run on little or no software: companies where the work still lives in spreadsheets, email, phone calls and people's heads, and where AI is the first serious technology bet the business has ever made. Business-down is arguably a better fit there than anywhere, because there's no legacy stack to reason up from and no engineering culture defending it. You start where the value and the cost actually sit, in the operation itself, and derive the software, the automation and the AI-native operating model down from the business for the very first time, with the org designed for it from the start rather than retrofitted later.
It fits best when the question is genuinely business-shaped: margins are being eaten by cost of delivery, the board is asking what AI means for the company, a troubled product needs to become predictable, or a transformation needs an owner who will actually build it. In those moments the bottleneck isn't more hands; it's a single person who can derive the right calls down from the P&L and then execute them.
It's not the fit for everything, and I'll tell you so. A pre-revenue idea that needs a first prototype, a pure staff-augmentation ask, or a mandate that's already been decided and just needs typing: those don't need a method, they need a different kind of help. Business-down earns its keep where the technology and the business are tangled together and someone has to untangle them on purpose.
The lowest-risk way to find out is the Read: a focused version of Movement 01 that ends in a 90-day plan you own whether or not we continue. It's the method's opening move, and it's designed so you can act on it immediately, with me or without me.
The method, answered.
The things founders, CEOs and investors ask before we start.
What is The Business-Down Method?
It's my signature methodology for running an AI-native CTO engagement. Instead of starting from the technology and reasoning toward the business, it starts at the P&L (revenue, margin, cost of delivery, board-level risk) and derives the architecture, the team, the security posture and the AI down from there. It runs in four movements: Read, Direct, Build, and Operate & Optimize.
Why “business-down” instead of technology-up?
Because technology-up decisions are bets that the stack you happened to pick will line up with where the company makes money, and you find out whether the bet paid off eighteen months later. Business-down starts from the money and the risk and reasons downward, so every technical call is tied to an outcome the board can see. It's harder to do, because it needs someone fluent in both the boardroom and the codebase, but it's the only version that survives contact with a P&L.
What are the four movements?
Read: diagnose the system and the business, tied to your P&L, ending in a 90-day plan you keep. Direct: set the AI-native direction, covering strategy, architecture, operating model, org and hiring plan. Build: hands-on, ship production AI systems, rebuild the SDLC AI-first, and hire and run the team. Operate & Optimize: run it, measure it with DORA and AI cost/quality metrics, re-run evals as models drift, and plan a clean transition.
If the method is always the same, how is the solution not boilerplate?
The method is the discipline: fixed, repeatable, accountable. The solution is derived down from your specific numbers and built with today's state of the art, which in the AI-native world moves every quarter. So the spine stays the same across engagements while the output is bespoke every time. The discipline is the constant; the solution is always current.
How is this different from a typical AI consultant?
Most AI advice stops at strategy (a deck, a workshop, a list of use cases) and leaves the building to someone else. The Build movement is the centre of this method: I ship production AI into the product and pipeline, rebuild the SDLC, and hire and run the team, hands-on. And because every call is derived from the P&L, AI gets measured against the business, not against demos.
What does Conway's Law have to do with it, and why do AI projects fail?
Conway's Law (Melvin Conway, 1967) says any organization that designs a system produces a design that mirrors the organization's own communication structure: your architecture ends up shaped like your org chart. It's the primary reason AI projects fail. The organization was never designed for AI-native operations, so when it's time to implement, the system mirrors the old org and the AI falters, no matter how good the model is. Technology-up engineering makes it worse by picking the architecture first and setting the org separately, so the law quietly overrules the diagram. Business-down draws the architecture and the org chart together in the Direct movement, both derived from the same P&L, so team boundaries and system boundaries match by design. That deliberate use of the law is the inverse Conway maneuver, and it's a core reason the method works where bolt-on AI stalls.
Who is it for?
$10M–$50M software and software-enabled companies past product-market fit, where a technology decision now moves the valuation. Founders, CEOs and boards who need engineering in service of the business, and private-equity investors who need a clear technical read before a deal and an AI-native value-creation plan after. It also fits traditional organizations that run on little or no software and are making their first serious AI or digital bet: with no legacy stack to fight, business-down can derive the technology and the AI-native operating model down from the operation itself. It's not built for pre-revenue prototypes or pure staff augmentation.
How do we start, and what's the lowest-risk way in?
Start with the Read movement: a focused diagnosis of system, org, spend and AI leverage, ending in a 90-day plan you can act on with or without me. It's the best first step: it tells us both whether a deeper engagement makes sense, and you keep the plan either way.
How does the engagement end?
By design, in a transition, never a permanent dependency. The Operate & Optimize movement includes coaching the internal leader who will take the seat and planning a clean exit: an internal hire, a lighter advisory cadence, or a trained team that carries the operating model on its own. Success is the company running it without me.
Want the
read first?
The fastest way to know if I can help is the Read: a focused version of Movement 01 that ends in a 90-day plan. Yours to keep whether or not we continue.