Run/Build/Scale Isn't a Sales Framework. It's What Your IT Workforce Already Looks Like.
Most IT leaders I talk to can describe what's broken about their team structure within about ten minutes of conversation.
Too many contractors doing run work. Permanent staff stuck in project delivery with no headroom for operations. No one with a clear mandate to flex when demand spikes. They know something's off. They just don't have a name for it.
Run/Build/Scale gives it a name. And to be clear — I didn't invent this. It's just a way of describing what every IT workforce already is, whether you've drawn it out or not.
What the Three Modes Actually Mean
Run is keeping the lights on. Network monitoring. Infrastructure support. Helpdesk. Patch cycles. The work that has to happen on Tuesday morning whether anyone asks for it or not. It's predictable, repeatable, and measurable. You can write SLAs for it. You can staff it with precision — if you've decided to.
Build is delivery. Cloud migrations. Platform upgrades. Security uplift programmes. The work with a start date, an end date, a budget, and a defined outcome. This work is temporary by design. That matters enormously for how you resource it.
Scale is the variable layer. The capacity your team can't absorb through permanent headcount, but can't afford to ignore. A burst of specialists for a major programme. A pre-vetted engineer deployed in 48 hours. A team that drops in to own an outcome and hands it back when it's done.
Every IT organisation has all three. The question is whether you've been intentional about where your people actually sit — and which of those modes is quietly eating your capacity without anyone noticing.
The Problem Isn't That You Have Three Modes
The problem is that most NZ IT teams run them as one undifferentiated blob.
Permanent staff doing Run work until a Build project kicks off, then dropping ops to deliver — until ops breaks and someone has to scramble back. Contractors brought in for Build who end up doing Run because there's no one else. The Scale layer nonexistent until a crisis forces the conversation.
This is how you end up with a helpdesk backlog, a stalled migration, and a contractor who's been on-site for 22 months doing work that should sit inside someone's job description.
I see this constantly across NZ enterprise IT — particularly in organisations that grew fast, leaned heavily on contractors during the 2021-2023 boom, and never rationalised the structure when the dust settled.
Why Permanent vs. Contractor Is the Wrong Debate
NZ IT hiring keeps getting stuck in this binary. Permanent hire or contractor. Headcount or agency. Opex or capex.
None of that maps cleanly to Run, Build, Scale.
Run work often suits permanent staff — it's ongoing and benefits from institutional knowledge. But not always. Some organisations get better Run outcomes from managed services with real SLAs than from internal headcount where accountability is diffuse and no one owns the number.
Build work often suits fixed-term or project-based engagements. The work is temporary by definition. Hiring permanent staff for Build means you either let people go when the project ends — which is expensive and rough — or you redeploy them into Run, which is fine if you planned for it and painful if you didn't.
Scale work needs something else entirely: capacity that's warm, pre-vetted, and deployable fast. Not a recruiter trawling LinkedIn. Not a job ad running for six weeks. A bench that's already been qualified and can move when you call.
When you name the modes, the workforce model follows naturally. Before you name them, you're just reacting to whatever lands in your inbox.
What Drawing It Out Actually Looks Like
I'm not talking about a six-month org design programme. I mean a whiteboard, your infrastructure lead, your ops manager, and an hour.
Draw three columns. List every role and function your team covers. Drop each one into Run, Build, or Scale.
You will immediately see the problem.
Work that belongs in Scale is sitting in permanent headcount. Run work is being done by contractors because no one planned the handover. Build has no defined endpoint, so it's creeping back into Run and consuming people who should be keeping the lights on.
That conversation — just naming where the work actually lives — is the one most IT leaders haven't had explicitly. Usually because they've been too flat-out doing the work to stop and look at it from the outside.
Scale Is Where NZ Gets It Most Wrong
Run and Build are concepts most IT leaders recognise, even without the labels.
Scale is where the logic falls apart.
NZ's ICT talent pool is small. Roughly 40,000 professionals across the country. The ones with genuine depth in cloud infrastructure, security architecture, or data engineering are a subset of a subset. They're not available. They're not waiting for your job ad. And they won't be by the time your recruiter calls them.
Which means your Scale layer can't depend on recruitment. By the time a candidate makes it through a process, the window has closed or the project has already slipped.
Scale works when it's pre-built. When there's an actual bench — people who've already been interviewed, reference-checked, and agreed to deploy on short notice — not sourced at the point of crisis when you have the least leverage and the most pressure.
Traditional recruitment was never designed for this. It's a brokerage model built for predictable timelines. The Scale layer needs something closer to infrastructure.
The Simple Version
Draw the three columns. Run. Build. Scale.
Put your current workforce in them — permanent staff, contractors, managed services, anyone doing IT work for your organisation today.
Look at whether the people match the work. Look at where the gaps are. Look at what's sitting in the wrong column.
That's it. It takes an afternoon. It will tell you more about what's actually broken in your resourcing model than any workforce planning workshop you've sat through.
The labels are simple. The structure is yours — it already exists. You just haven't drawn it yet.
Lexel operates across all three modes. Managed services for Run. Project delivery for Build. A pre-vetted talent bench for Scale. If you want to do the whiteboard exercise, we're easy to reach.