What a Rugby Team Knows About Workforce Structure That Your Hiring Manager Doesn't
A role opens. Your hiring manager writes a job description. They hire someone. Problem solved.
Except it's not. Three months later the same gap opens differently. The new person is fine individually, but the team still isn't working. Your senior engineer is babysitting infrastructure they shouldn't be touching. Your graduates are stuck in a queue waiting for work. The project is stalled because you have three people who can design the solution and nobody to actually build it.
You filled a seat. You didn't build a team.
A Rugby Team Doesn't Work Like This
Think about how the All Blacks select a squad.
Every position is defined before a single name is written down. The roles aren't interchangeable. A prop isn't a winger. A hooker isn't a fullback. Each position has a specific job, a specific set of physical and skill requirements, and a specific place in the structure.
The bench isn't an afterthought either. Those eight players are specialists chosen for specific situations. The loosehead cover who comes on at 60 minutes to hold a scrum under pressure. The first-five replacement who can manage a kicking game in the wet. The bench exists to address predictable stress points in the match — not just because someone got injured.
And the head coach decides the team structure before the season starts. Not five minutes before kickoff.
Your IT team should work the same way. It mostly doesn't.
What IT Teams Actually Look Like
Most NZ IT teams are assembled reactively. Someone leaves, you hire a replacement. A project lands, you bring in bodies. Budget gets cut, you freeze headcount. Nobody ever sat down and drew the team they were trying to build.
The result is a team where nobody planned the shape. You end up with:
- Three senior engineers doing work a mid-level could handle, because you never hired mid-levels
- A project team with three architects and nobody to actually build anything
- On-call coverage held together by whoever's available, not whoever's right for it
- Contractors doing run work because there's no permanent bandwidth, and permanent staff doing build work they're not equipped for
This isn't incompetence. It's the natural outcome of hiring one role at a time without a picture of what the full team should look like.
Run, Build, Scale Is Your Forwards-Backs-Bench
The way I think about it, every IT function needs three types of work covered.
Run — keeping the lights on. Infrastructure, support, BAU operations. This work is continuous, repeatable, and needs reliability over brilliance. These are your forwards. Workhorses. They need to show up every week, absorb pressure, and execute consistently. You don't need someone flashy here. You need someone dependable.
Build — delivering projects and capability uplift. Cloud migrations, platform transformations, security uplifts. This work has a defined start and end. It needs specialists who are excellent for a period, not necessarily permanent fixtures. These are your backs. They need pace and precision, deployed when you need them, not carried on the books when you don't.
Scale — surge capacity and specialist depth. The bench. When a critical project lands unexpectedly, when an engineer goes down, when you need a specific skill for a specific window. This isn't a gap in your headcount plan. It's an intentional part of your team design.
Most organisations fund permanent headcount for Run, understaff Build, and have no plan for Scale. They call it lean. It isn't lean. It's fragile.
The Coach's Job
The All Blacks coach doesn't wait until someone tears an ACL to think about depth at first-five. They've already planned for it. They know who's next. They've given them game time. They're not starting from zero when the gap opens.
Your IT function needs the same forward visibility.
Who are your Run specialists, and do they have the capacity to actually run? Or are they constantly pulled into Build work because there's no one else?
What does your Build team look like for the next two quarters? If three projects land at once — and they will — do you have the bench to absorb that without breaking your Run capability?
Where's your specialist depth? If your only Azure architect hands in their notice tomorrow, what happens in the next 90 days?
These aren't hypothetical questions. They're the team sheet. And right now, most organisations haven't written it.
The Hiring Manager Problem
Hiring managers are good at filling roles. That's the job. Here's a vacancy, go fill it.
So they fill it. And six months later there's another vacancy, in a different shape, with the same root cause: nobody planned the team.
This is fixable. But it requires someone to own the team structure — not just the headcount, not just the current vacancy. Someone needs to look at the whole squad and ask: what does Run/Build/Scale actually look like for this organisation over the next 18 months? Where are the single points of failure? What's the bench plan if the season gets harder than expected?
Not just pick the next player. Pick the right player for the right position in a deliberate team shape.
The Simple Version
Before you open the next requisition, ask two questions.
What position is this? And does filling it make the team better, or just bigger?
If you can't answer the first question clearly, the second one doesn't matter.
Lexel works with NZ technology organisations on workforce structure — not just filling vacancies, but designing the team shape that actually delivers. If you're building capability for the next phase, not just reacting to the last gap, let's talk.