Planning your IT workforce before the urgency kicks in.
Successful IT hiring starts well before a vacancy arises. This guide will help you identify the skills and capabilities your organisation genuinely needs, define roles clearly, understand evolving market demands, and make informed workforce planning decisions that support long-term success.
Many organisations only think about IT hiring when a role is vacant. By that point, the options are limited, the urgency creates pressure to compromise, and the process almost always takes longer than expected. Proactive workforce planning changes that equation.
When IT hiring is driven by urgency rather than planning, the consequences are predictable:
Research consistently shows that the total cost of a poor IT hire can reach two to three times the annual salary, when recruitment costs, lost productivity, management time, and the cost of re-hiring are all accounted for. Proactive planning is a financial discipline, not just a HR one.
You don’t need a complex HR system to plan your IT workforce effectively. A few questions asked quarterly can significantly improve the quality of hiring decisions:
When a capability gap is identified, there are three ways to address it:
| Option | When it works best |
| Build (upskill existing staff) | Best for: capabilities that are evolving and where existing staff have the foundations to develop. Builds loyalty and institutional knowledge. Takes time. |
| Buy (hire permanently) | Best for: capabilities that are core to the organisation’s long-term function and where you can offer a compelling permanent role. Highest cost and longest process. |
| Borrow (contract or consulting) | Best for: short-term project needs, specialised skills not needed permanently, or situations where speed of deployment is critical. Higher day rate but lower total cost for finite needs. |
How should businesses plan ahead for their IT workforce needs? Start with the projects and initiatives on the horizon and work backwards from there. If you know a major cloud migration is coming in twelve months, you shouldn’t be starting to hire cloud engineers in month eleven. Toni Lake, Younity
Artificial intelligence is reshaping IT roles and skill requirements faster than most workforce planning frameworks can keep up with. The organisations that navigate this well are those that focus on the problems they need to solve, rather than the tools they’ve heard about.
The most useful reframe for AI-related hiring is to start with: ‘What problem are we trying to solve?’ Asking ‘who knows AI’ leads to a sprawling search across dozens of platforms and products. Asking ‘we need to automate this specific manual process’ or ‘we need to improve the speed at which our team can process these documents’ leads to a much more targeted brief.
As AI becomes embedded in IT work across most specialisations, almost every interview process now includes some form of question about candidates’ relationship with AI tools. The most effective questions are not about which tools they’ve used, but about how they think:
| Question | What it reveals |
| When you found a new tool, what did that process look like? Why did you choose it? | Reveals whether they look beyond the obvious options and have a considered approach to tool selection. |
| Tell me about a time you used AI to solve a specific work problem. What was the outcome? | Reveals practical application, not just familiarity. |
| How do you validate AI output before using it? Where do you not trust it? | Reveals critical thinking and professional judgement around AI limitations. |
| How has AI changed the way your team works in the last twelve months? | Reveals awareness of organisational impact, not just individual use. |
One consistent pattern in the NZ IT market is that development teams have been among the most resistant to AI adoption, despite being in a domain where AI tools like GitHub Copilot offer significant productivity benefits. This resistance is not uniform and it’s not irrational. Experienced developers are right to be critical of AI output and cautious about the introduction of generated code into production systems. The best teams balance AI advocates who push adoption with sceptics who interrogate quality.
As AI handles more of the routine, repetitive elements of IT work, the skills that become more valuable are those that AI cannot readily replicate:
Vague role definitions create expensive problems downstream. The time invested in defining a role clearly before advertising it pays for itself many times over in reduced time-to-fill, better candidate quality, and more successful hires.
| Mistake | What it looks like |
| The committee brief | A job description assembled from multiple people’s wish lists, resulting in a role that no single person could possibly fill and a very long skills section. |
| The cloned brief | A job description copied from a previous hire without consideration of what the role actually needs now given how the team and organisation have changed. |
| The vague brief | A high-level description of what the team does with insufficient specificity about what this person will actually do day to day. |
| The misleading title | A job title that doesn’t reflect the actual role, either because it’s overstated (calling a support engineer a ‘DevOps Architect’) or understated. |
| The misaligned brief | A document that describes itself one way in the summary and a different way in the responsibilities section, creating confusion about what’s actually needed. |
A clear role definition answers these questions specifically:
How can employers clearly define role responsibilities? Start with what success looks like in the role, not just the list of things they’ll do. If you can describe what a great hire would have delivered at the six-month mark, you’ve defined the role clearly. Elena, Younity
The people closest to the work often have the clearest view of what a new hire actually needs. Before finalising a role definition, spend thirty minutes with the team lead or technical lead and ask:
A job description is both an internal planning document and an external recruitment tool. The best ones do both jobs well: they give your hiring team clarity about what you’re looking for, and they give candidates enough information to make a genuine self-assessment of fit.
| Section | What it should contain | Length |
| Opening | A brief, compelling description of the organisation and team context. What does the company do? What’s the team working on? Why is this role important right now? | Two to three paragraphs. Human and engaging, not corporate and generic. |
| Role purpose | A clear statement of what this role is for. What problem does it solve? What does success look like? | One paragraph. |
| Key responsibilities | What will this person actually do? Specific, actionable descriptions of the core work. | Five to eight bullet points. Outcome-oriented, not task-oriented. |
| Essential requirements | The genuine non-negotiables. Skills, experience, and attributes without which the candidate cannot do the role. | Keep this list short. If it has more than eight items, it’s probably a wish list. |
| Nice to have | Skills or experience that would add value but are learnable or not critical. Be honest about which category things belong in. | Optional section. If everything is ‘essential’, the signal is lost. |
| What we offer | Salary range (strongly recommended), flexibility, development opportunities, team culture. This section is what converts good candidates from ‘maybe’ to ‘apply’. | Be specific. ‘Competitive salary’ is no longer compelling. State the range. |
There is strong evidence from NZ and international research that job ads with salary ranges attract significantly more applications from qualified candidates, particularly from women and candidates from underrepresented groups who are more likely to self-select out when salary is unclear. It also saves time on both sides by filtering out candidates whose expectations are misaligned. If there is genuine flexibility in the range, say so.
What should a practical job description include to attract the right people rather than overwhelm or confuse them? Keep the essential requirements genuinely essential. When you put fifteen things on the ‘must have’ list, you’re not describing a real person. You’re describing three people. And then none of the actual candidates feel qualified to apply. Isabella, Younity
Separating what’s genuinely essential from what’s simply preferred is one of the most valuable things you can do for the quality of your hiring process. It takes discipline, but the payoff is a significantly higher volume of appropriate candidates.
For each item on your requirements list, ask two questions:
The goal is a list of essential requirements that is short enough to be credible and specific enough to be useful. A list of fifteen ‘essential’ requirements is almost always a wish list.
| Requirement | Why it may not be truly essential |
| Specific product experience (for technical roles) | Most strong IT professionals can learn a new tool, platform, or product within weeks. What matters more is depth in the category, not specific product knowledge. |
| Industry sector experience (unless domain knowledge is genuinely technical) | Most IT skills are highly transferable across sectors. A developer who has worked in retail can work in healthcare. The exception is when regulatory knowledge or domain-specific technical knowledge is genuinely required. |
| Academic qualifications (for experienced candidates) | For candidates with five or more years of relevant experience, degree requirements often eliminate strong candidates unnecessarily. |
| Specific certifications (unless required by a client or regulator) | Many excellent IT professionals have not pursued formal certifications despite being highly capable. Certifications demonstrate commitment to learning, but they don’t automatically indicate capability. |
How can hiring managers decide which skills are truly essential? Ask your best performer in a similar role to list what they actually use every day. That list is usually much shorter than what ends up in the job description. Cornelia, Younity
The NZ IT talent market has distinct characteristics that affect what’s achievable in a hiring process. Understanding them upfront prevents frustration and enables better decisions.
New Zealand has a relatively small technology talent pool, concentrated primarily in Auckland and Wellington. For most IT specialisations, the number of available candidates at any point in time is limited. Some key realities:
| Role Level | Typical Timeframe | Caveats |
| Junior to mid-level roles (individual contributor) | Three to six weeks from brief to offer for a well-defined role in a streamlined process. | Can extend significantly if the brief is broad, the process has many stages, or market supply is limited. |
| Senior individual contributor or specialist | Six to ten weeks typically. Often involves waiting for the right candidate to surface. | Specialised roles (security, data science, architecture) may take twelve or more weeks. |
| Leadership and management roles | Eight to fourteen weeks is common. These roles attract fewer applicants and typically involve more interview stages. | Senior leadership roles often require confidential search approaches with longer timelines. |
| Contract roles | Two to four weeks for most contract roles when the brief is clear. Faster for common role types. | Highly specialised contract roles, or those requiring security clearance, will take longer. |
What should employers understand about supply and demand in the NZ tech market? The candidate pool for senior roles is genuinely small. If you’re expecting to see twenty strong applications for a principal engineer role, you’re going to be disappointed. You might see five, and one of them might be exceptional. That’s the market. Toni, Younity