Automation Adoption: Making Your Team the Experts
Best practice, a proven approach, and the hands-on time it takes for your own engineers to become the people everyone else asks about automation
Why Automation Programmes Stall
Most organisations do not lack the will to automate, and many have already bought the tools. What stalls them is everything around the tooling: who owns it, how it is tested, how changes are reviewed, and whether anyone beyond the person who wrote it can safely change it. These are the patterns we see most often.
One person understands it
The automation works, but only one engineer can change it with confidence. When they are on leave, it stops being touched; when they leave, it starts being worked around.
Tooling bought, practice missing
A platform licence does not come with standards, review, testing or a way to measure value. Without those, the platform becomes a place to run the same scripts that were run by hand before.
Nobody trusts a run
If a playbook has ever taken something down, people stop running it against production. Automation that is only run when someone is watching is not saving the time it was meant to.
The wrong first project
Starting with the hardest, most political system makes for a long pilot and a sceptical audience. Starting with frequent, low-risk, well understood tasks builds the confidence the harder work needs.
Stuck between pilot and production
A proof of concept proves the tool works. It does not answer how changes get approved, how secrets are handled, or who is on call for it, and that is where many pilots stop.
Value nobody can show
If nothing measures the hours saved or the incidents avoided, automation competes for budget on faith. The work that would have scaled it never gets approved.
The Goal: Your Team Becomes the SME
We measure an engagement by how little you need us at the end of it. Building automation for a client and walking away leaves a codebase nobody in the building fully understands, which is the single-expert problem again with a consultancy in place of the engineer. Our aim is the opposite: your own people become the subject matter experts, and they can extend, fix and defend the automation without us in the room.
Pair, do not hand over
Your engineers write the code alongside us from the first week. By the end, they are writing it and we are reviewing it.
Teach the why
Every standard comes with the reason behind it, so your team can judge when it applies and when a case is genuinely different.
Leave a practice
What stays behind is a way of working (review, testing, pipelines, documentation) rather than a pile of code that has to be maintained by whoever wrote it.
How We Approach It
Six phases, in order, though few organisations need all six at the same depth. We start from where you are, and each phase ends with something your team owns.
1. Maturity Assessment
Where you stand across tooling, process, skills and governance, and a prioritised view of what to address first.
You keep: an honest baseline to measure progress against.
2. Strategy and Roadmap
Automation goals tied to business outcomes, tooling chosen to fit the estate and the team, and a phased plan that mixes quick wins with lasting change.
You keep: a roadmap your stakeholders signed up to.
3. Proof of Concept
A targeted pilot on a real, frequent task, chosen to de-risk the approach and build confidence rather than to impress.
You keep: working automation and evidence it pays off.
4. Implementation
Production automation built to your compliance and quality standards from day one, with your engineers writing a growing share of it.
You keep: code your team has already changed and shipped.
5. Team Enablement
Pairing, workshops and structured knowledge transfer on your own code, until your engineers are reviewing each other's work rather than ours.
You keep: the in-house expertise.
6. Governance and Standards
Coding standards, testing, peer review and documentation practices that keep the automation healthy and auditable as more teams contribute.
You keep: guard rails that work without us.
The Practices We Build In
None of these are novel. They are the habits that separate automation a team relies on from automation a team works around, and they are what we leave behind.
Everything in version control
Playbooks, inventories, variables and pipeline definitions all live in Git. If it is not in the repository, it does not exist.
Review before merge
Every change is read by a second engineer. It catches mistakes, and it is the cheapest way to spread knowledge across a team.
Tested before it runs
Linting and automated tests in CI on every change, so problems surface in a pipeline rather than on a production host.
Safe to run twice
Idempotent tasks that converge on a state rather than replaying steps, so a rerun fixes drift instead of causing it.
Secrets out of code
Credentials come from a vault or the platform's credential store, never from a variables file someone forgot to exclude.
Reusable building blocks
Small, well named roles and modules with documented inputs, so the next team builds on them rather than copying and diverging.
Compliance in the pipeline
Hardening applied as code, as we do with Ansible-Lockdown, and checked as code with a validation tool such as Syver.
Measured, not assumed
Time saved, change failures and lead time tracked from the start, so the case for the next phase is made with numbers.
Why Learn It From Us
We work in the open. Mark Bolwell, our founder, is a core developer of Ansible-Lockdown, the community's security hardening roles, so the review, testing and release practices we teach are the ones we use on code that runs across a great many estates we will never see.
Teaching is part of the job too. Mark speaks at AnsibleFest, ConfigMgmtCamp and UK and European meetups, and organises the Ansible London meetup. Helping engineers get good at automation is something we already do for free; an engagement is that same work, focused on your team and your code.
Automation Adoption Questions
No, and that is the measure we hold ourselves to. Every engagement is planned so that your engineers write more of the automation as it goes on and we write less, and the standards, pipelines and documentation stay with you. Ongoing support is available if you want someone to call, but nothing we build needs us to keep running.
Almost never. The maturity assessment starts from what you already run, keeps what works, and identifies what is holding the rest back: missing tests, no review process, secrets in code, or one person who understands it all. Rewrites are a last resort, not a starting point.
Mostly Ansible, AWX and Ansible Automation Platform for configuration, Terraform or OpenTofu for provisioning, and Packer for images, wired into GitLab CI or GitHub Actions. We recommend tooling to fit your estate and your team's skills rather than pushing one product, and the practices on this page apply whichever you choose.
Yes. Engagements are scoped around where you are, so if you already have the delivery capacity and want the skills and standards, we can focus on pairing, workshops, code review and setting up the guard rails. In practice the learning sticks best when it happens on your own code, so we usually work on a real piece of your automation together.
It depends on the size of the estate and how far along you already are. Most maturity assessments take two to six weeks, and we give you a detailed timeline at the first consultation rather than a number that has not seen your environment.
Ready to Build the Expertise In-House?
Tell us where you are: a blank page, a pile of scripts, or a platform that is not delivering. We will start from there, and plan the work so your team ends it as the experts.
Talk to Us