A founder asked me over coffee not long ago what the first thing a fractional CTO actually looks at before touching a company’s technology stack. I told him it was not the stack at all, and his surprise at that answer is fairly typical of most founders meeting a fractional CTO for the first time, since the assumption is usually that the engagement begins with a technical audit.
Before I look at a single system, I look at how decisions actually get made inside the business. Who has to approve what before it moves forward. How fast information travels between the people who need it. Where people have quietly built workarounds because the official process is simply too slow to keep up with the pace the business actually needs to move at.
Why Decision Patterns Explain the Stack Better Than the Stack Explains Itself
The technology stack, once you understand these underlying decision patterns, almost always makes sense in a way it would not have if I had started by examining the code and the infrastructure directly. Most of what looks like a technical problem on the surface is actually a decision-making problem that happened to manifest inside the technology, and treating the symptom without understanding the underlying cause tends to produce fixes that do not hold.
Consider a common scenario. A company’s engineering team has built a system with an unusual number of manual approval steps embedded directly into the software, steps that slow down every release and frustrate everyone who has to work within them. Approached purely as a technical problem, the fix looks like automating those approval steps. Approached as a decision-making problem, the more useful question is why those approval steps existed in the first place, and whether the underlying concern they were meant to address has actually been resolved, or whether it has just been quietly overridden by an engineering team eager to move faster.
The Order Matters More Than People Expect
By the time I actually do review the technology stack itself, I already know which parts are genuinely holding the business back and which parts merely look messy on the surface while functioning perfectly well in practice. That order matters considerably more than people expect when they first engage a fractional CTO, because fixing technology before understanding the business behind it usually means fixing the wrong thing first, however competently that fix is executed.
How Business Decision Patterns Reveal Themselves
Understanding how decisions get made in a business requires more than reviewing an org chart, which typically shows formal reporting lines rather than how information and authority actually move day to day. I spend the early part of any engagement observing actual meetings, reviewing how past decisions were reached, and asking specific people to walk me through a recent example of a decision that took longer than it should have, and why.
Most of what looks like a technical problem is actually a decision-making problem that happened to show up in the technology.
These conversations reveal patterns that never appear in formal documentation. A department that officially reports through one channel but actually resolves most real decisions through an informal relationship with someone in a different part of the organization. A process that exists on paper but that everyone quietly routes around because it was designed for a scale the company has since outgrown. These patterns, once identified, explain far more about why a particular piece of technology looks the way it does than any amount of code review would.
Why This Approach Changes What Gets Fixed First
Once the underlying decision patterns are understood, the technical priorities that emerge often look different from what a purely technical audit would have surfaced. A system that looks technically outdated but sits within a well-functioning decision process might not need immediate attention, because the business is not actually being slowed down by it in any meaningful way. A system that looks technically fine but sits within a broken decision process is often the more urgent priority, because the technology is quietly reinforcing a dysfunction that will keep producing problems regardless of how much the code itself is improved.
What This Means for Companies Considering a Fractional CTO
Companies engaging a fractional CTO for the first time often expect the initial weeks to focus heavily on technical assessment, reviewing architecture diagrams, evaluating code quality, and benchmarking system performance against industry standards. Those activities do eventually happen, but they happen after, not before, a genuine understanding of how the business itself makes decisions and where the friction in that process actually lives.
Fixing technology before understanding the business usually means fixing the wrong thing first, and it is a mistake that a purely technical hire, focused primarily on the stack from day one, is more prone to making than someone deliberately trained to look at decision patterns before touching a single system. For founders evaluating whether their technology problems are truly technical, the more useful starting question is often not about the code at all. It is about how decisions move through the business, and whether the technology is a cause of the friction, or simply a visible symptom of it.
