Hire for IT capabilities, not tech checklists: How to move from buzzword job specs to capability-based hiring that actually ships value

Janine Stoffberg • October 30, 2025

It's time to flip your specs from tools to capabilities

If you’ve ever written a job spec that reads like a shopping list - ten frameworks, five tools, three clouds - you’re not alone. It’s been the default for years. But there’s a problem with this approach: laundry lists are exclusionary, outdated the minute they’re posted, and they don’t predict whether a hire will actually improve delivery speed, reliability, or security.

What does actually deliver results? Capabilities.

Think of a capability as a repeatable, observable ability to deliver an outcome in context. For example, “design and operate a secure CI/CD pipeline” is a capability. “Three years’ experience in Jenkins” is a buzzword. One tells you what tool someone used. The other tells you what they can do.

And in 2025, if you want to build IT teams that deliver value instead of just ticking boxes, it’s time to flip your specs from tools to capabilities.

What to hire for: the capability set

Pick four to six core capabilities tied to the outcomes your business needs over the next 12 months. That’s the signal top talent is looking for.

Cloud and platform reliability remains a cornerstone.

You need people who can design resilient services, manage infrastructure as code, build CI/CD pipelines, implement observability, and keep a grip on cost control.

Secure delivery is no longer optional.

From threat modelling to secrets management and dependency hygiene, companies need engineers who can bake security into every stage of the SDLC. Just as important is enabling data and AI responsibly. That means data modelling with SQL, building pipelines with tools like dbt, and supporting visualisation in Power BI or Tableau, all while keeping an eye on how AI is applied in practice.

Product delivery capabilities separate strong hires from average ones.

Developers who can slice work into smaller increments, use trunk-based development, apply thoughtful testing strategies, and measure value will bring compounding returns. Finally, don’t underestimate collaboration and decision making. The ability to align stakeholders, write clear design notes, learn from incidents, and explain trade-offs in plain English often matters more than another framework on a CV.

Why settle for buzzwords when you can have the building blocks of faster, safer, more valuable delivery?

Let’s compare these two job specs.

With Buzzwords:

5+ years Kubernetes,
Terraform,
Istio,
Helm,
Jenkins,
Prometheus,
ELK,
AWS,
Azure,
GCP.
Must know Go, Rust, Python, Bash. Nice to have: Kafka, ArgoCD.

Capability-Based:

Role purpose: Increase deployment frequency while keeping change failure rate <10% and MTTR <1 hour.

Core capabilities (must-have):

Design and operate CI/CD pipelines with automated tests and rollbacks
Build and review IaC; prevent drift; manage secrets safely
Implement service health (SLIs/SLOs) and on-call runbooks
Communicate trade-offs (cost, reliability, security) in writing

Evidence we’ll look for: a small work sample, a design note, and a past incident you helped prevent or recover from.

See the difference? The second spec tells candidates what success looks like for this business. The first just tells them what tools to name-drop.
Once you’ve rewritten the spec, make sure your process actually measures the right things.

When it comes to requesting the work sample from the candidate, keep it short, respectful, and relevant - no 12-hour take-home projects, please. One to two hours really is plenty.

Here's a work sample example you can reference from:

Containerise a tiny service,
Add tests,
Create a CI workflow that runs tests and builds an image,
Define IaC to deploy it,
Write a one-page runbook.

Structured interview prompts:

“Walk me through a change you shipped that improved a metric (lead time, MTTR, cost). How did you measure the impact?”
“Show me how you keep dependencies and secrets secure in your pipeline.”
“An outage occurs during a release. What signals do you check first, and how do you decide to roll back?”
“How do you decide when to pay technical debt vs ship?”

Red flags tend to show up in subtle ways. Candidates who talk about “building dashboards” but can’t link them to a KPI change, or who submit a sample with no version control or tests, usually don’t have the delivery discipline you need. Another warning flag is when someone over-indexes on tools instead of outcomes - it’s a sign they’re chasing buzzwords, not solving problems.

Partnering with recruiters and staffing firms

If you work with recruiters, don’t just send them a long JD. Equip them.

Give them:

A one-page capability brief (role purpose, 4–6 core capabilities, evidence to show)
The scorecard so every CV and interview is rated consistently
Two clear use-cases the hire will own in their first 90 days (stabilise CI/CD for service X; cut infra cost per user by 10%)
A process SLA: response times, interview stages (max 2 + work sample), and decision owners

Blended resourcing strategies without chaos

Permanent hires bring the platform continuity, domain knowledge, and security stewardship that keep systems stable. Contractors, meanwhile, are a great option for well-scoped spikes like migrations, hardening, or performance tuning. The key is to run one toolchain and one process for both groups - that’s how you protect your standards without creating chaos.

Onboarding that halves time-to-impact

A good hires are also made in the first 90 days. Below is a clear plan that halves time-to-impact and shows new hires how they’ll contribute from the start.

Time Frame	Outcomes
Day 7	Environment set up; one small PR merged; buddy assigned.
Day 30	Owns a minor service; writes or updates a runbook; joins incident review.
Day 60	Leads a change that moves a metric (e.g., MTTR ↓).
Day 90	Owns a KPI with a quarterly plan (e.g., SLO adherence, cost per user, deployment frequency).

Remember, thoughtful onboarding is how you get someone delivering value fast without burning them out in the process.

KPIs - Measure what matters

Finally, prove your hires are working by tracking flow, reliability, and cost metrics — and tying them back to money.

Deployment frequency ↑
Lead time for change ↓
Change failure rate ↓
MTTR ↓
Cost-to-serve / cloud waste ↓
Security posture (vulnerability age, secrets exposure) ↑

Report them monthly in plain English: what changed, why, and the next experiment. That’s the story leadership wants to hear.

Closing thought

Buzzwords don’t ship value - capabilities do. If you define outcomes, hire for capabilities, and measure the right metrics, you’ll build an IT team that’s faster, safer, and easier to scale.

And if you’d like, we can help turn this into a one-page hiring kit: a capability brief template, a scorecard, a work sample brief, and a 30/60/90 plan you can hand straight to your recruiters.