A lean IT org answers every capability question one of two ways, and both are wrong. One reflex says we are too small to build that, so buy it. The other says we are regulated and different, so build it. The first outsources things it will spend years regretting. The second rebuilds what a mature market already does better, then carries it forever as headcount it cannot spare. Both skip the only question that matters.
That question is not build versus buy. It is which layer of this capability is judgment and which layer is commodity. Almost every capability I have sourced splits cleanly along that line, and once you see the seam, the decision mostly makes itself.
I should be honest about the seat I am reasoning from. I do not sign the whole IT P&L. I run a real slice of it, security and DevOps at a fintech that serves more than 1,500 financial institutions, and I report its return to a board. The sourcing question shows up identically at every altitude. Whether I am deciding how to staff detection-and-response or a CIO is deciding how to run the entire estate, the discipline is the same: keep the judgment, rent the heavy lifting, never confuse the two.
The seam runs through every capability, not around it
Take a capability everyone treats as a single thing and watch it split. Security monitoring. The commodity layer is real and large: round-the-clock eyes on a console, log ingestion, alert triage against known signatures, the follow-the-sun staffing a small team cannot sustain without burning people out. That layer is undifferentiated heavy lifting (the phrase the cloud providers use for the parts of the job no customer is better off doing themselves), and there is a mature market of managed detection-and-response firms who do it at a scale and price I cannot match.
The judgment layer lives right next to it. What counts as a real incident in our environment. Which alerts are noise because of a quirk of our architecture that no outside analyst will ever internalize. When to pull the cord and call it a breach. What we tell an examiner, and when. That layer does not scale by adding analysts and it does not live in anyone else's runbook. It is ours, and it stays ours.
Every capability has this seam. Payroll: the tax tables and the direct-deposit rails are commodity; the compensation philosophy is judgment. Cloud infrastructure: the data center, the hypervisor, the physical network are commodity the provider runs better than anyone; the architecture and the control plane are judgment. The mistake is treating a capability as one indivisible thing you either own or hand away. The skill is cutting along the seam instead of across it.
Three modes, and what each is actually for
The commodity layer still has to land somewhere, and there are only three places to put it. Each does one job well and turns into a liability the moment you use it for the other two.
- In-house. For the judgment layer and the genuine differentiators: the handful of things a customer or an examiner would notice we do a particular way, plus the control plane over everything else. In-house is expensive and slow to staff, which is exactly why you reserve it for what actually differentiates.
- Managed service. For commodity work that still carries regulatory weight or needs a single accountable owner. Managed detection, patch and endpoint operations, a co-managed SOC. You are buying operated capacity and a partner who signs an SLA, not a product you run yourself. Someone with more scale runs the treadmill.
- SaaS. For commodity work where the market is mature, the switching cost is bounded, and the capability is generic: identity, ticketing, email, most of the productivity estate. You are renting a product, not a partner. The test is whether you could leave in a quarter without a war.
The failure mode is using the wrong mode for the layer. Handing a differentiator to a managed-service vendor because it looked like commodity from a distance. Treating a managed-service relationship like SaaS and discovering, during an incident, that nobody was accountable. Match the mode to the layer, not to whichever budget line happens to be open.
The test I actually run
I reduce the placement decision to two questions, asked in order, because asking them in the wrong order is how you talk yourself into building things you should rent.
First: does this capability differentiate us? Not whether it is important; everything is important. Would a customer choose us, or an examiner trust us more, because we do this in a particular way? Detection tuned to our ledger and our fraud patterns differentiates. The email server does not. This is Geoffrey Moore's core-versus-context distinction, and his instruction is the one I follow: pull resources out of context so you can pour them into core. Most of what a lean IT org does is context. Admit it and you free up the people you need for the few things that are core.
Second, only for the things that are not differentiators: is there a mature market that does this better than we could at our scale? If yes, rent it. SaaS if it is generic and portable, managed service if it carries regulatory weight or needs an accountable owner. If the market is immature, or the thing is so specific to us that no product fits, you may have to build it, and you accept that you now own a treadmill. Simon Wardley's mapping work makes the same point from the other side: capabilities drift from novel to commodity, and the ones that have reached utility should be rented, not lovingly rebuilt by a team that could be doing something that matters.
The order protects you. Ask "can we build it" first and the answer is almost always yes; engineers can build anything, and they want to. Ask "does it differentiate us" first and most candidates fall out before pride ever gets involved.
You can outsource the work. You cannot outsource the accountability.
This is where "never the judgment" stops being a slogan. When I hand detection to a managed provider, I have outsourced the work. I have not outsourced one gram of the accountability. If there is an incident, the examiner does not call my vendor. The interagency guidance on third-party relationships that the federal banking regulators issued is explicit on the point, in language every fintech should internalize: using a third party does not diminish an institution's responsibility to operate safely and to comply. The work moves. The responsibility does not.
That has a design consequence. For anything I outsource, I keep enough of the capability in-house to stay accountable for it. Enough understanding of my own environment to tell when the managed provider is wrong. Enough of the data and the decision trail to reconstruct what happened without asking permission. Enough of the control plane to answer, in my own words, why the system did what it did. Outsource the muscle. Keep the nervous system.
It is the same reason we built AgentOS, our internal agent platform, around a control plane rather than around the models. The undifferentiated part, the model capacity underneath, is rented and swappable. The judgment (what an agent is allowed to touch, what gets logged, which actions need a human, how we prove all of that to an examiner) is ours, in one place, and it does not move even when the vendor beneath it does. Rented capacity underneath, owned judgment on top: that is the shape every sourcing decision should take.
And keep counting past your direct vendors. Your provider has vendors of its own, the fourth parties, and the accountability runs back through them to you whether or not you have heard their names. A lean team cannot audit the whole tree. It can insist on knowing the branches that touch regulated data.
Insourcing the commodity is the quieter mistake
Everyone warns about outsourcing the judgment, and they are right to. Hand a managed SOC your decisions and not just your staffing, and within a year the only people who can reason about your environment work for someone else. That failure is loud and well-documented.
The quieter mistake, and the one a proud engineering culture makes constantly, is insourcing the commodity: building your own where a mature market already exists, because it felt beneath you to buy, or because a clever engineer wanted the project. It works, at first. Then the engineer who built it leaves and it becomes a bus-factor-of-one liability nobody wants to touch, a line of maintenance the roadmap routes around forever. A lean IT org can survive one or two of these. It cannot survive a portfolio of them, and it usually has one, because the reflex to build feels like strength and only reveals itself as debt years later.
So I hold both mistakes in view at once. Outsourcing the judgment costs you the ability to run your own shop. Insourcing the commodity costs you the people you needed for the work that mattered. Refusing both at once is harder than it sounds, because they pull in opposite directions and each feels virtuous while you make it.
Design the exit before you sign the deal
Every sourcing decision is reversible in theory and expensive to reverse in practice, and that gap is where lean teams get trapped. The time to close it is before you sign, not during the fire.
So I treat exit as a design input. Can I get my data out in a usable form without a professional-services engagement? Is the configuration mine, or does it live in a format only the vendor can read? If this provider doubled its price or missed an SLA through an examination, how many weeks, not years, until I am running on something else? None of these changes the decision to outsource. All of them change the terms, and they are worth far more in the evaluation than at the renewal. A commodity you can leave is a commodity you actually outsourced. A commodity you cannot leave is a differentiator you handed to someone else without meaning to.
Keep the judgment, rent the rest
For a lean IT org in a regulated business, the sourcing model comes down to five instructions:
- Cut every capability along the seam between judgment and commodity before you decide who runs it. You are never sourcing the whole thing.
- Ask whether it differentiates you before you ask whether you can build it. Do context cheaply so you can do core well.
- Outsource the work and keep the accountability: enough environment, data, and control plane in-house to stay the answerable party.
- Watch both mistakes at once. Never hand away the judgment, never lovingly rebuild the commodity.
- Design the exit before you sign, because a commodity you cannot leave is a differentiator you gave away.
That is how I reason about it from the security-and-DevOps seat, and the logic holds all the way up to the whole estate. The relationship to watch is the managed one that quietly took your judgment along with your work. It never announces itself. You notice it the year you can no longer explain your own environment without a vendor on the call.