Building an IT Team Fast: The Risks and the Upside

Building a team in a month sounds like a flex on a standup call. In practice it's a trade-off between speed and quality: you pay for every week you save. I closed the core team in a month and the full roster in two. Ten people. And yes, I did misjudge a couple of specialists. Let me explain why it was still a success and what I took away from that sprint.

Why the rush happens in the first place

Fast hiring is rarely about "I felt like it." Usually it's about a window that's about to close. The project kicks off, the budget is approved, the client wants first results "yesterday," and all you've got is an empty Jira board and a tech lead carrying the entire backlog alone. In that spot the choice is simple: either you staff up fast, or the project starts slipping before the first sprint even begins.

I deliberately went the first route. I badly needed the specialists, and on every formal factor — hard skills to soft skills — the candidates fit. They passed the interviews fairly; I squeezed them on time, but I didn't cut corners during the interview itself. And still, two of them turned out to be different from what they seemed on the way in. Why that happens — we'll get back to that.

The core idea: some problems with a person are impossible to spot in an interview. They only surface on real tasks. Give a candidate an individual chunk of work, look at the result — and in a couple of weeks you'll learn more about them than in five rounds of interviews. The catch is that when you hire fast, you don't have those two weeks.

The risks of fast hiring

Speed isn't free. Here's exactly what you end up paying for.

Wrong-fit candidates. When time is tight, you unconsciously lower the bar. Not on hard skills — on the match with the project and the team. A person may be able to do exactly what's needed, but not handle the context in which that "exactly" has to be applied. In the interview they solve an algorithm puzzle; on the project they have to reverse-engineer undocumented legacy and negotiate with three adjacent teams. Those are different skills, and the second one is almost never tested in an interview.

Undertested competencies. Any interview is a model, not reality. And that model can be gamed: prep for the standard questions, tell a nice story about past projects where your role was, let's say, creatively exaggerated. I'm relaxed about cases like that — I know how the market works. But the fact remains: the shorter the funnel, the higher the odds you're buying the packaging, not the contents. The only honest cure is a probation period with real tasks, and when you're in a hurry you're tempted to skip it.

Damage to team culture. This is the most underrated risk. Hard skills are visible right away, but how a person behaves in a conflict, how they react to criticism in code review, whether they'll pick up someone else's task on a Friday night — that's about values, and in a rushed hire there's no time to assess it. One badly-fitting person on a team of ten can drag down the atmosphere so much that you only notice when two of your strong people show up with resignation letters. Culture is fragile, and it's harder to fix than it is to hire.

Overpaying for speed. Want someone fast — and the offer has to match. Otherwise the specialist will take their time, weigh it, talk it over with their spouse, and you don't have time for that. A strong candidate is already comfortable where they are; to pull them off their seat quickly you need a real incentive. And it's easy to overdo it here: in the rush you overpay and hire someone who's worth less on the market than what you ended up offering them. And once the numbers surface, the imbalance is now inside your team.

The upside of fast hiring

If it were all risk, I wouldn't do it. But speed has very tangible upsides — the ones that make those risks worth tolerating.

You start sooner. The most obvious win. While others spend six months sifting resumes in search of the perfect candidate, your team is already in the fight and shipping first releases. In IT this often decides everything: the market, the window of opportunity, the client's priorities shift faster than a careful funnel can close on a single mid-level hire. Sometimes a "good enough" team today delivers more than a "perfect" one in six months.

Room to experiment. A team you assembled fast is a team you built for a concrete task here and now, not for some abstract "ideal profile." Those people are usually easier to move, more willing to try new things, and less attached to "how it's always been done." Flexibility at the start is worth a lot: it's easier to change your approach while the processes aren't set in concrete yet.

You catch the people who care about tempo. There's a distinct breed of specialist that slow hiring scares off. They're bored waiting three weeks for feedback after the final round. A fast, honest, decisive process attracts, on its own, the people who thrive on that tempo. And those are exactly the people you need at the start of a fast-moving project.

How I lower the risk without slowing down

The compromise between speed and quality isn't about picking one. It's about giving speed what you can give up without losses, and protecting what's critical.

First — a real task instead of one more interview round. Not an abstract brain-teaser, but a small piece of actual work with actual context. A couple of days of that kind of check tells you more about a person than an hour of talking about their past achievements.

Second — don't treat probation as a formality to breeze past. If you're hiring fast, the most honest insurance is to watch the first weeks closely and give yourself the right to a quick rollback. It's cheaper to admit a hiring mistake in week two than to drag it out for six months out of pity for yourself and the person.

Third — keep culture in mind, not just the stack. At least one interview question should be not about technologies, but about how the person works in a team and what drives them. It's not a guarantee, but it beats zero attention to soft skills.

And yes, I don't count my miss on those two specialists as a failure of the whole endeavor. Overall I consider the hiring a success: core team in a month, full team in two, project rolling on time. Two out of ten didn't fit — that's the price I paid for speed, and I knew what I was signing up for.

Personally, I'd rather bring people in quickly than wait months for that one perfect hire. The perfect candidate doesn't exist, but the window of opportunity very much does — and it closes fast. What matters is keeping the risks in mind, building in insurance for a quick rollback, and not being afraid to move forward.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP