Building ServiceNow Capability In-House

Building in-house ServiceNow capability means training platform administrators first, then developers, then process owners — in that order, because each depends on the one before. Most organisations invert this by training developers before establishing administration discipline, which produces capable people building on an ungoverned platform. Certification matters less than supervised delivery experience on your own instance.

Why capability building usually fails

The common approach is to send two people on a developer course after go-live and hope capability follows. It rarely does, for reasons that have little to do with the training itself:

• Training precedes ownership. People return from a course with new skills and no defined responsibility, so the knowledge decays before it is applied.
• Developers are trained before administrators. Development capability on an ungoverned instance produces customisation debt faster, not better outcomes.
• No supervised practice. Certification demonstrates knowledge. Competence comes from delivering real work with review, which courses cannot provide.
• Capability concentrated in one person. A single trained administrator is a single point of failure, and eventually a resignation risk.

The order that works

1. Platform administration first

Before anyone builds anything, someone needs to own instance hygiene: users and roles, update set discipline, instance scan findings, upgrade planning and performance monitoring. This is the foundation everything else sits on, and it is the role most often left vacant.

Target: at least two people with genuine administration capability, so the function survives one person leaving.

2. Process ownership

Platform capability without process ownership produces technically sound implementations of processes nobody agreed. Process owners — for incident, change, request, and whichever workflows you run — need enough platform literacy to know what is possible and what it costs.

They do not need to be developers. They need to be able to have an informed conversation with one.

3. Development capability

Once administration and process ownership exist, development capability compounds. Before that point, it mostly accelerates the accumulation of things you will later pay to unwind.

The most valuable thing to teach developers is not scripting but restraint: configure before customise, scope everything, document deviations, and understand what each choice costs at the next family release.

4. Specialist depth, selectively

ITOM, SecOps, HRSD and integrations each have real depth. Build specialist capability only where you run the module heavily and the work is continuous — otherwise a partner relationship is usually cheaper than maintaining rarely-used expertise.

Certification: useful, but not the goal

ServiceNow certifications provide structured curricula and a credible baseline, and the Certified System Administrator is a reasonable starting point for anyone owning the platform. Beyond that, value depends on relevance to what you actually run.

What certification does not provide is judgement about your environment: which customisations are worth their upgrade cost, how your data model should evolve, or when to say no to a request. That comes from delivering work under review.

The blended model that works best

In most organisations, the effective pattern is neither fully outsourced nor fully in-house:

• In-house: administration, process ownership, day-to-day requests and small enhancements — the work that benefits from context and continuity.
• Partner-led: major implementations, upgrades, specialist modules and anything requiring depth you would not otherwise maintain.
• Shared: your team works alongside the partner during delivery, which is where the most durable capability transfer actually happens.

That last point matters. Capability built during real delivery, with someone experienced reviewing the work, transfers far better than capability built in a classroom and applied months later.

A twelve-month path

1. Months 1–3. Two administrators trained and given explicit ownership. Update set and instance hygiene disciplines established.
2. Months 3–6. Process owners identified and given platform literacy. Governance for change and customisation decisions defined.
3. Months 6–9. Development capability built, working on real backlog items under review rather than sandbox exercises.
4. Months 9–12. Specialist depth where the workload justifies it. Partner relationship narrowed to genuinely specialist work.

Slower than most plans assume, and considerably more durable than the alternative.