Hiring an IT manager without looking for a smaller version of yourself

It is comfortable interviewing someone who approaches a problem the way you do. The conversation moves quickly. You recognise the terminology and agree on the obvious mistakes to avoid.

That comfort is not enough to establish that the person is right for the role. A CIO who enjoys architecture may gravitate towards another strong architect when the team needs a manager who can stabilise service delivery and develop people.

I would define what the new manager must change before deciding what an impressive candidate looks like. The role should fill a real gap, not reproduce the leader's strongest preferences.

Describe the work the manager will own

Write a short set of outcomes for the role. These might concern a dependable support operation, clearer allocation of work or better handovers from projects. Keep them specific enough to assess and realistic enough for the authority being offered.

Do not write outcomes the manager cannot control. If they must improve delivery predictability, they need a role in setting priorities and handling interruptions. If they must manage suppliers, they need access to contracts and a defined commercial remit.

Separate essential capabilities from skills the team can provide. A manager may need enough technical judgement to challenge a recommendation without being the most experienced engineer in every platform. Conversely, a small team may genuinely need a manager who can perform some technical work. State that honestly rather than hiding it behind a broad leadership title.

Discuss the role with the people who will work with it. Their input can reveal practical expectations that a generic position description misses.

Ask for evidence, not familiar vocabulary

Use consistent questions linked to the role outcomes. Ask candidates to explain a decision they made, the information they had and what they would do differently. Distinguish their own contribution from the work of a wider team.

When someone describes a successful service improvement, ask how they knew it helped. When they describe a conflict, ask what the other party needed. You are looking for judgement and reflection, not a perfectly polished story.

A candidate should be able to discuss relevant experience without sharing confidential employer information. Make that clear. If detail is sensitive, invite them to describe the structure of the problem or use a hypothetical equivalent.

Do not reward confidence as though it were evidence. A thoughtful candidate may pause, ask a clarifying question or identify an uncertainty. Those behaviours can be useful in the actual role, especially when the alternative is a fast answer built on an unsupported assumption.

Use a bounded work scenario

A short fictional exercise can reveal how a candidate thinks. Keep it proportionate and avoid extracting unpaid work on a live business problem.

For example, give every candidate the same fictional service situation: a support queue is growing, a planned change needs uninterrupted attention and a business sponsor is asking for an additional urgent feature. Ask what they would clarify, what they would decide themselves and what they would escalate.

Assess the reasoning against criteria agreed beforehand. Did they distinguish impact from seniority? Did they ask about existing commitments? Did they explain the consequence of moving work? There need not be one correct ordering if the candidate makes sensible assumptions explicit.

Allow candidates to ask questions and adjust their recommendation. Real management involves obtaining missing context, not guessing what an interviewer is thinking. Keep the exercise accessible and offer appropriate adjustments through the recruitment process.

Score the evidence before the panel discusses general impressions. That gives quieter or less familiar candidates a fairer chance to be assessed on what they demonstrated.

Make room for a different strength

A complementary hire will sometimes approach a problem differently. Decide which differences are acceptable before offering the role.

If the manager is stronger in operational discipline than you are, they may ask for clearer priorities and resist informal additions to the team's workload. That is useful only if you support the boundary when a favoured request arrives.

If they are stronger in coaching, they may invest time in development rather than personally resolving every issue. Do not then assess them solely on the technical tasks they complete themselves.

Agree decision authority early. Explain what you expect to be consulted on and what the manager can decide independently. A new manager cannot establish credibility if the CIO routinely reopens their decisions through side conversations with the team.

Support the first months with access and feedback

Before the manager starts, identify the information, relationships and practical access they will need. Provide the current commitments and known difficulties without presenting every inherited problem as theirs to solve immediately.

Set early review points around learning and decisions as well as delivery. Ask which assumptions about the role have proved wrong. Check whether the remit matches the work arriving and whether the team understands the new authority.

The approach in the first ninety days as an IT leader is relevant here: discover the existing obligations before promising a new structure.

Give specific feedback. "Be more strategic" is too vague to help. Explain which decision needed a wider view, what information was missing and how you would expect the manager to handle a similar situation.

A good appointment should change how the leadership team works. If the only acceptable outcome is someone making exactly the decisions you would make, in exactly your way, reconsider whether you are offering a management role or asking for an assistant with a different title.