The Expensive Mistake
A mid-sized retail company decides to build an in-house IT department. They post three senior developer roles, hire quickly, and six months later have three talented engineers, no deployment pipeline, no architectural standards, no on-call process, and a team that rewrites the same logic in three different styles.
This isn’t a failure of talent. It’s a failure of sequence.
Building an IT department isn’t about headcount — it’s about capability infrastructure. Hire first, you build headcount. Build the infrastructure first, you build a department.
Phase 0: Define What “IT Department” Means for Your Business
Before any hire, you need to answer one question: what decisions will this department own?
Not responsibilities. Decisions. There’s a critical difference.
- Will the IT department own the build-vs-buy decision on software tools?
- Will they own security policy, or advise on it?
- Will they own vendor relationships, or execute on someone else’s vendor choices?
- Will they own product roadmap input, or just delivery?
Without clear decision rights, an IT department becomes an execution arm that never develops organisational leverage. You’ll have engineers, but not a department.
Phase 1: Infrastructure Before People
The instinct is to hire a CTO or lead engineer and let them figure out the infrastructure. This delays everything by six months while the new hire gets their bearings, asserts their preferences, and makes you pay for their learning curve.
A faster approach: stand up the non-people infrastructure in parallel with the hiring process.
What this includes:
Development environment standards — where code lives (GitHub, GitLab, Bitbucket), branching strategy, PR review requirements, merge gates.
CI/CD baseline — even a simple pipeline (lint → test → deploy to staging) means new hires can contribute without creating a deployment debt.
Security baseline — SSO, secrets management (HashiCorp Vault, AWS Secrets Manager), basic access controls. Not a full security posture — just enough that you don’t start with obvious exposure.
Communication and documentation norms — where decisions get written down. A team that documents nothing is not a department; it’s a dependency.
On-call and incident response skeleton — even with two engineers, having a defined on-call rotation and an incident channel prevents “who owns this?” chaos at 2am.
Setting up this infrastructure typically takes four to six weeks with external support. It then runs as the stable layer every future hire steps into.
Phase 2: The First Three Hires Define Everything
The first three engineers you bring into a new IT department will set the cultural and technical tone for the next three years. This is not an exaggeration.
First hire: generalist with strong production instincts. Not the most senior person you can afford. Someone who has shipped in a production environment under constraints, has opinions about reliability, and communicates clearly with non-technical stakeholders. This person becomes your institutional memory.
Second hire: a specialist in your highest-risk area. If you’re an e-commerce business, that’s probably backend performance or payments. If you’re SaaS, it might be DevOps. Don’t round out the team — reinforce the critical path.
Third hire: someone who disagrees with the first two. Seriously. Intellectual monoculture in small engineering teams is a long-term liability. The third hire’s most valuable attribute is that they’ll push back.
Phase 3: The Leadership Question
Many companies want to hire a CTO as the first IT hire. Resist this instinct unless you have a very clear answer to: “What decisions will this person own that currently aren’t being made well?”
If the answer is “we need someone to run the department,” you don’t need a CTO. You need a Head of Engineering or an Engineering Manager with strong individual-contributor history.
CTOs are most valuable when they’re making product-technology strategy decisions, representing engineering in the board room, and setting a 3-year technology vision. If the department has fewer than eight engineers, most of a CTO’s leverage doesn’t exist yet.
What External IT Department Setup Actually Provides
An IT department setup service does three things you can’t easily do yourself:
1. Transfers a proven playbook. The infrastructure decisions above — branching strategy, CI/CD pipeline, secrets management approach — have been made hundreds of times. An external team brings defaults that work and reduces the cost of your first 20 decisions to near zero.
2. Provides bridge leadership. An experienced interim CTO or technical director can run your engineering function for 6–12 months while you recruit permanent leadership. You get momentum without a bad permanent hire.
3. Builds the team in parallel. Sourcing, screening, and onboarding engineers in parallel with infrastructure setup compresses the timeline from “decision to hire” to “department operational” from 12 months to 4–6.
The Honest Timeline
If you start from zero with no existing technical team:
| Phase | Duration | Output |
|---|---|---|
| Infrastructure setup | 4–6 weeks | CI/CD, standards, tooling in place |
| First hire onboarded | 6–10 weeks | First engineer contributing |
| Team of 3 assembled | 3–4 months | Core team operational |
| Department with process | 6 months | Repeatable delivery, incident response, docs |
Trying to compress this by skipping phases doesn’t save time — it moves the cost to later, where it’s more expensive to fix.
The companies that build IT departments well aren’t the ones who move fastest. They’re the ones who build in the right order.