Build vs Run IT Operations: How to Fix the Balance

The plan-build-run operating model sounds tidy until you look at your own week. Your IT team is supposed to be shipping projects and hardening systems, and most of the queue is password resets, access approvals, and Slack DMs.

The useful version is simple: separate work that changes the business from work that keeps it running, then stop the second from swallowing the first. Whether work that prevents fires survives an ordinary Tuesday is the real test.

What follows covers what each category holds, how the formal three-function version works, why the DevOps reading doesn't transfer to a two-person team, and what a healthy split looks like in money and in hours. The question underneath all of it is whether your Run work is actually shrinking.

TL;DR:

• Build is project work that changes what the company can do. Run is the operational work that keeps today working, and every project Build finishes lands there permanently.
• The formal plan-build-run model adds a Plan phase for strategy, portfolio, and budget decisions, and it only pays for its own overhead at a scale most 50-to-1,500-employee companies never reach.
• "You build it, you run it" is a hyperscale practice. It works when a service team owns one system, and it breaks when a two-person team owns everything.
• For a lean IT team, direction of travel beats any target percentage. The question is whether repetitive Run work took fewer hours this quarter than last.

What Does Build vs Run Mean in IT Operations?

Build and run splits IT work into two categories, creating new capability and keeping existing capability alive. Build ships change, Run operates whatever ships. The longer name, plan-build-run, adds a Plan phase for strategy and budgeting above both.

• Build covers project work. New tool deployments, infrastructure design, workflow automation, and security rollouts all sit here, and each one leaves behind something that has to be supported after the project closes.
• Run covers operational work, the service management basics that never appear on a roadmap. Service requests, access management, troubleshooting, patching, and compliance evidence all sit here, and none of it ends, which is why Run's workload moves in one direction unless something actively takes work off it.

The term comes from two traditions that pull in opposite directions. The operating-model lineage is the enterprise one. McKinsey documented functional plan-build-run models as a way of organizing infrastructure work, separating strategy, delivery, and operations into distinct functions. The DevOps lineage does the reverse, collapsing the wall between the two so the team that ships a system also carries the pager for it.

For a lean IT team, build vs run rarely shows up as an org chart decision. It shows up as a capacity problem. Run work is reactive and urgent, arriving as Slack messages and escalations that demand an answer now, while Build work needs the kind of uninterrupted stretch those messages destroy. It's the reason your best engineer spent Tuesday morning provisioning Figma licenses instead of finishing the SSO migration.

How Does the Plan-Build-Run Operating Model Divide IT Work?

In its formal version, plan-build-run splits an IT organization into three functions, each with its own leadership, staffing, and performance targets. It's most common in large IT organizations, where running three separate units costs less than the coordination it removes. Each function owns a distinct slice of the work.

• Plan owns IT strategy, enterprise architecture, portfolio management, budgeting, and vendor decisions. Sitting apart from delivery lets Plan set direction without getting pulled into firefighting, and it lets Plan drift from what the other two functions see every day.
• Build owns program management, application development, solution architecture, testing, and deployment. Concentrating delivery skills in one function speeds projects up and guarantees a handoff every time something ships.
• Run owns application maintenance, performance management, the service desk, and daily operations. Run inherits every system the other two functions decide on without getting a vote on the decision, which is why its staffing case always gets made after the fact.

The model also bends in a SaaS-heavy stack, which is probably the stack you run. Run work shifts away from infrastructure upkeep toward vendor management and integration governance, so renewals, access reviews, and keeping dozens of tools exchanging data cleanly replace patching windows. Build shifts toward configuration and API work instead of ground-up development. The phase boundaries hold, and what fills each phase's hours changes completely.

Why Doesn't "You Build It, You Run It" Work for a Lean IT Team?

"You build it, you run it" assumes a team that owns one service. A lean internal IT team owns every service, so a practice that tightens a feedback loop at hyperscale just widens the queue at a 200-person company.

The phrase comes from a 2006 ACM Queue interview with Werner Vogels, then Amazon's CTO, who contrasted it with the older habit of walking finished software to the wall between development and operations, throwing it over, and forgetting about it. His teams each owned a bounded system, from scoping through operating it, and the operational feedback improved that one system. Ownership came with the job description there, rather than arriving on top of a job that already existed.

Inside a 200-person company the arithmetic inverts. Your team owns the identity provider, the device fleet, the HRIS integration, the VPN, and the laptop that won't boot, and there is no second team to hand any of it to. The principle stops being a discipline and becomes a description of what already happens, which is the exact condition it was written to fix.

One piece does translate. Whoever ships a system should own the operational cost of the choices they made, and that cost should be written down before the project closes, while the person who created it still remembers why. A new SSO integration that adds four manual steps to every access request is not finished, and the only moment anyone will admit that is the week it ships.

The same trap catches engineering-heavy teams that absorb their own request queue. Someone still answers the access questions, and an engineering support layer that nobody defines gets paid for out of sprint capacity instead.

Why Does Run Work Keep Eating Your Build Capacity?

Run consumes Build capacity because most of it gets handled by hand, and manual coordination doesn't get cheaper as volume rises. It gets more expensive, because the number of people who have to be chased per request stays the same while the number of requests climbs.

A single software access request means verifying the request, checking with the employee's manager, confirming budget with Finance, provisioning the license, updating whatever spreadsheet tracks licenses, and telling the requester it's done. One of those six steps is technical. The other five are coordination, and coordination is where the elapsed time goes.

Now multiply that across every access request, password reset, onboarding checklist, and broken laptop that lands in a week. Access requests alone routinely take 10+ hours a week off a lean IT team, and that's before anything breaks. Every Build project you finish then adds something new to support, monitor, secure, document, and renew, so Run grows even when nobody adds operational headcount. The growth arrives as a side effect of shipping.

Five patterns show up once the balance has already tipped.

• Project timelines slip on repeat. Infrastructure upgrades and security work get pushed because nobody can protect a long enough stretch of focus. The slippage never gets decided, it accumulates.
• The same requests keep arriving. Password resets, access provisioning, and onboarding checklists each feel small, and left unautomated they add up to a full-time job nobody is staffed for. Watch how request load grows against headcount rather than in absolute terms.
• Handoffs between departments stay manual. Onboarding a new hire by emailing HR, messaging Finance, and updating three systems by hand is a coordination problem, and coordination problems get worse with scale.
• Employees route around the queue. When the formal channel feels slow, requests arrive as DMs to whoever answered last time. That work never enters a queue, so it can't be measured, delegated, or used to justify a hire.
• Nobody is looking at the queue itself. Reporting and bottleneck analysis are the first things to go when the current queue is the only thing there's time for, which is what keeps the problem invisible to everyone above you.

None of the five is a management failure. They're what happens when demand is elastic and capacity isn't, and they survive any amount of individual effort. Someone in a budget review will eventually ask the obvious follow-up. How much Run is too much?

What Is a Healthy Build vs Run Ratio?

A healthy ratio is one that's moving. Less repetitive Run work this quarter than last, with more capacity available for change, matters more than hitting any published number.

How Much of IT Spend Should Run Consume?

Most technology organizations sit somewhere between a 50/50 and a 70/30 split of Run to change spend. Oliver Wyman puts a fully optimized ratio at 20% Run to 80% change, which is a target state rather than a starting point. That analysis speaks to CIOs of large technology functions with legacy estates to rationalize, so treat the 20% as a direction and the 50/50 range as the honest comparison.

Splitting spend two ways also hides a distinction that budget conversations depend on. Run, Grow, Transform breaks it three ways instead. Run keeps existing operations alive, Grow expands capabilities the business already uses, and Transform funds capabilities that don't exist yet. Lump Grow and Transform together under "Build" and you can't tell leadership whether project spend is scaling what works or betting on something new, which is usually the first thing a CFO asks about.

How Do You Tell Whether Your Run Share Is Shrinking?

Tag where your team's hours actually land. For two weeks, mark every task Run, Grow, or Transform as you close it, then total the columns. Your own number comes out rougher than any published figure and more useful, because it's yours and it moves the moment you automate something.

Repeat the exercise after you've standardized or automated a high-volume workflow. If access requests, password resets, onboarding tasks, and status chasing take fewer hours in the second sample, the ratio is improving, and you have the before-and-after that a budget or headcount conversation needs. Measuring automation returns on a lean team works the same way, one workflow at a time.

A percentage target isn't the point. Direction is. A team at 65% Run and falling is in better shape than a team at 45% Run and climbing, and only one of those two facts is visible from an org chart.

Ratios describe the money. Day to day, the balance is about hours, and hours are where you can intervene.

How Do You Shift Capacity Back to Build?

Three moves, in order. Standardize the work so it's describable, automate the parts that need no judgment, then defend the calendar time the first two give back. Jumping straight to automation just encodes whatever mess already exists.

1. Standardize Run Work Before Automating It

Document what Run actually looks like before you buy anything. Map the most common request types, the steps each one takes, and the departments each one touches. The patterns usually repeat, which is what makes them automatable in the first place.

Then define routing rules and SLA targets per category. Hardware goes to whoever owns procurement, access requests go through identity, HR questions go to People Ops, and each category gets a response time your team can state out loud without wincing.

2. Automate the Repetitive Layer

Once the steps are written down, automate the ones that need no human judgment. Smart request routing classifies and assigns incoming requests before a person reads them. Approval workflows send a request to the right manager and chase it. Self-service knowledge answers handle the questions your team answers every week.

Aim at the coordination layer. Nobody automates the SSO migration; the Figma license request that stole Tuesday morning from it is the automatable part.

3. Protect Build Time on the Calendar

Automation alone doesn't help if the calendar stays open to interruption. Block explicit Build time, whole days or fixed hours, where the team works on projects and the queue keeps moving without them. That only holds if routing and approvals run unattended during those blocks, which is why this step comes third.

Write down what the block is for. "Focus time" loses to an escalation every time; "SSO migration, cutover Thursday" survives one.

How Can an AI Service Desk Help Fix the Build vs Run Balance?

An AI Service Desk makes Run predictable so the hours come back to Build. Siit runs inside Slack and Teams, so employees ask for help where they already work rather than adopting a separate portal. Requests get classified, assigned, sent for approval, and updated with status automatically, and access grants or revocations execute in your identity provider without anyone chasing them.

One thing an AI Service Desk doesn't do: make the judgment calls. Automation removes routing, chasing, and status-update work, not the decisions, so escalations and exceptions still need a clear owner on your IT team.

Getting the Build vs Run Balance Back

For a team your size, build vs run is a capacity question rather than an org chart one, and it has one honest test. Did repetitive Run work take fewer hours this quarter than last? If it didn't, prioritization won't fix it, because the work arrives whether or not you have room for it. Leaner operations come from removing steps, and until steps come out, the SSO migration keeps losing to the license request.

Siit takes out the coordination layer that makes Run expensive, running requests, approvals, and access changes inside Slack and Teams instead of a portal nobody logs into. Unit's two-person IT team supports 200+ employees across three countries with a 60% reduction in helpdesk labor, and avoided one to two additional hires doing it.

Book a demo and see what your Build time looks like when Run stops eating it.