Every growing company builds its technology function in roughly the same order, and most of them skip the same step.
The order looks like this:
- Founder stage. Technology is managed by whoever is handy. Somebody technical keeps the lights on. At that size this is the right call.
- Traction. There is more IT than one technical person can absorb, so you bring in an MSP for helpdesk, laptops, and backup. Skip this one and your engineers do password resets and new hires set up their own machines.
- Growing. Nobody owns the whole technology estate.
- Scaling. There is more to build than one person can build, so you hire engineers and contractors.
- At scale. Technology touches every business decision, and the technical lead needs to be full-time.
- High stakes. Security is competing with everything else for the same attention, and it needs dedicated leadership separate from IT.
Stage three is the one that gets skipped. Companies go straight from an MSP to hiring builders, and the named senior technical owner - architect level, accountable for the whole estate and how it fits together - never gets appointed.
Why it gets skipped
It is expensive, and nothing is visibly on fire.
The MSP is closing tickets. The developers are shipping features. The board dashboard is green. There is no incident forcing the conversation, no customer asking for it, no auditor requiring it. It is the only stage in that list with no external forcing function, so it loses every prioritization argument it enters, right up until the moment it stops being optional.
By then the bill has been accruing for three years.
What skipping it actually costs
Cloud infrastructure nobody owns. Servers spun up for a project years ago, still running, still billing every month. Architectures that made sense at launch and now pay premium rates for capacity nobody uses, where a redesign would cost less and scale better. On one engagement, an early look at this produced a reduction of about three quarters in cloud spend. Nobody had been dishonest or careless. Nobody had been looking.
Software left so long without maintenance that there is no upgrade path. Not "expensive to upgrade." No path at all. Dependencies whose migration guides assume you are two major versions back rather than nine. At that point the only remaining option is a rewrite, and a rewrite is the most expensive form of maintenance there is.
Findings nobody closes. A test gets commissioned, a report comes back, and the work between the report and the retest belongs to nobody in particular.
Deals that stall on a security questionnaire. An enterprise prospect sends 40 questions about your environment. The answers all exist somewhere in the estate. Nobody owns them, so nobody can produce them, and the deal sits while somebody guesses.
An MSP everyone assumed was handling security. They were handling tickets. Nobody found out otherwise until there was a breach. That one matters most, because it is the failure nobody sees coming, and it is why a managed provider is not a security program.
Paying an MSP is not the same as having technical ownership. Somebody has to read their reports, verify that endpoint management is actually deployed rather than merely purchased, and hold them to it when it is not. That somebody has to know what good looks like.
Three ways this ends
Best case, nobody bothers you. That is luck, not a strategy, and it is what most companies are unknowingly running on.
Next best, you get breached and you know it. Expensive, disruptive, survivable. At least you get to respond on your own terms.
Worst case, you get breached and you do not know it. Someone is in your environment and you hear about it from a customer, a regulator, or a buyer's diligence team. That is what an ungoverned MSP produces: nobody reading the alerts, and nobody checking that anyone is.
More developers is usually the wrong answer
The failure mode I see repeatedly is a company that knows something is wrong, diagnoses it as insufficient capacity, and hires builders.
A company had come through a rough CRM migration and then bought a third-party AI-powered search product to find records in the resulting mess. Users could not find what they needed. The product was blamed. Whoever chose it had no application development background, which is not a criticism - it was simply not their field, and there was nobody in the building whose field it was.
The actual problem was not the search engine. It was tens of thousands of records whose meaningful content sat unstructured in free-text fields, which no search product can query usefully. Once that was named correctly, the fix was quick: extract the structure, populate real fields, and put a search in front of it with the filters people actually needed.
Real time and real money went into the wrong solution before anyone identified the right problem. Not because the company was badly run, but because the person who could have said "that is a data problem, not a search problem" in the first meeting did not work there and had not been asked.
The cost was not just the money. It was months of a system that did not do what users needed, eroded trust from the people who had to use it every day, and customer-facing work the company paused while it waited for the thing to be sorted out.
What this role is not
It is not a reporting line you hand to the CFO or the COO because they are organized and available.
It is not a project manager who runs the vendor calls.
It is not a people manager. Managing engineers and owning architecture are different jobs, and companies conflate them constantly, usually by promoting the best engineer into a role that stops them doing the thing they were good at.
It is someone who can open the architecture, read the code, look at the cloud bill, and tell you what is actually wrong - and who has the standing to be believed when they do. The standing matters as much as the skill. An architecture opinion nobody can overrule on instinct is worth more than the same opinion from a contractor.
The smallest version that works
You do not need a full-time hire for this. Fractional works, and at most growing companies about five hours a week is enough to change outcomes.
That sounds too small to matter. It is not, because the value is concentrated in a handful of moments: someone senior looking at what is about to be decided and saying that there is a better way to do it. Which vendor. Which architecture. Whether to buy or build. Whether the MSP's compliance report says what everyone thinks it says.
The company still decides. It just decides from a position of knowledge instead of ignorance, and over three years the difference between those two compounds into either a platform or a rewrite.
The math people get wrong
A senior fractional technology owner who genuinely knows what they are doing is not cheap. A growing company looks at the rate and does the obvious arithmetic: that is three to five engineers.
It is, and it is the wrong comparison. Those engineers execute decisions. They do not make the decision about whether the thing being built should exist, whether the architecture will survive the next order of magnitude, or whether the vendor's demo matches the vendor's product. Those decisions have a far larger blast radius than any individual sprint, and they are the ones the company is currently making without help.
Two things are shifting this. One is that the leverage of a senior person has gone up sharply. I get the output of several mid-level engineers now, with better coordination and fewer integration seams, because the tooling has moved and I use it heavily. The other is that the cost of a bad architectural decision has not gone down at all.
Companies still buy seats rather than judgment. That is the habit worth breaking, and it is cheaper to break it before the rewrite than after.
None of the companies I am describing were badly run. They were growing fast and making a reasonable call each time. The cost of skipping this stage just does not land in the quarter you skip it. It lands three years later, all at once.