Building an IT Team Fast: Risks and Benefits

This case comes from a separate team formed before I moved to the new Decision Engine project in late September 2024.

We assembled the core team in roughly a month and the main roster in two. That pace let the project start on time, but we also had to revisit several hiring decisions. Fast hiring is not an achievement by itself. It trades time for additional risk.

Why teams rush hiring

The delivery window is usually already open: the budget is approved, the first tasks are waiting, and the team does not exist yet. Careful selection can reduce hiring risk, but a prolonged search delays product feedback. Sometimes that delay costs more than making an imperfect decision and correcting it quickly.

An interview is only a model of the future job. A candidate may discuss the stack confidently and still struggle with legacy systems, ambiguity, or cross-team negotiation. Real work exposes those gaps much faster.

Where speed becomes dangerous

Fit with the context. Technical knowledge is not enough if a person cannot work with the dependencies and constraints of the actual project.

Team behaviour. How someone handles feedback, explains decisions, and resolves disagreement matters as much as the code they write.

A rushed offer. Deadline pressure can create unrealistic expectations on both sides. It is better to surface them before the start date than months later.

How to protect quality

First, discuss situations that resemble the work instead of abstract puzzles. How does the candidate approach an unfamiliar service? What do they do when priorities conflict? How do they communicate a delivery risk?

Second, treat the first weeks as a continuation of the selection process. Give people clear tasks, regular feedback, and agreed success criteria. It is cheaper to acknowledge a mistake early than to defend the original decision for months.

Third, hire for collaboration, not for the longest possible technology list. A team is stronger when its decisions and knowledge do not depend on one person.

I still prefer timely hiring to waiting months for a perfect candidate. But speed only works with clear criteria, careful onboarding, and the willingness to revisit a mistake honestly.

Start with the launch plan, then define vacancies

Hiring urgency becomes more manageable when it starts with the next product outcome. The first slice may need a strong analyst–engineer pairing, while a specialist is needed only after an architecture hypothesis is tested. Hiring against a picture of the future department can bring people in before useful work exists.

For each role, I would define the initial outcome, required independence, and dependencies on others. This helps distinguish permanent hiring, temporary delivery support, and expert consultation. They solve different problems.

Use a shared interview scenario. Suppose the team receives an undocumented API from a neighbouring system and an agreed launch date. What does the candidate ask, validate first, and report as a risk? This is more relevant than a long technology quiz unrelated to the work.

The first weeks are management work

A new colleague needs environment access, someone to ask, a small complete deliverable, and an explanation of how decisions are made. Without these, a slow start says as much about onboarding as it does about the candidate.

Tie feedback to observable work: understanding a contract, demonstrating a result, asking for missing context, and coordinating with colleagues. An early mistake is not automatically evidence of a bad hire. First check whether expectations were clear and support was available.

Useful observations include time to the first independent delivery, support required, and recurring obstacles. Filled vacancies measure recruitment activity. These observations show whether the team can now build the product.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP