The most common way an automation programme fails is not technical. It is that the people who built it leave, and the people who remain cannot keep it running. Bots that nobody understands get switched off at the first serious incident. The fix is a team that is built to last: the right roles, the right mix, and reasons to stay. Here is what that looks like in practice.
The roles that matter.
| Role | What they own | Common mistake |
|---|---|---|
| Automation lead | Roadmap, sponsor relationship, prioritisation, reporting | Making the best developer the lead and losing both |
| Solution architect | Design patterns, platform decisions, design review, hard problems | Having none, so every developer designs differently |
| Business analyst | Process discovery, PDDs, acceptance criteria, exception rules with the business | Treating the role as optional and letting developers guess the process |
| RPA developer | Build, unit test, documentation, support rota | Hiring only for a platform certificate rather than engineering habits |
| Platform engineer | Environments, upgrades, credentials, monitoring, licences | Splitting the job across developers as a side task |
| Support analyst | Exception queues, first-line incidents, run reviews | Leaving it to whoever built the bot, forever |
In a small programme one person covers two of these. In a programme with more than thirty bots in production, every row needs at least one named person, and the support analyst is the one most often missing.
The mix: more analysts than you think.
Teams tend to over-hire developers and under-hire analysts. The result is a fast build queue and a slow intake, with developers doing discovery badly because no one else is. A ratio of one analyst to two or three developers keeps the pipeline fed with well-defined work, and the analysts become the people who know the processes, which is exactly the knowledge that must not leave with a contractor.
As agentic automation grows, the balance shifts further. Writing evaluation sets, tuning thresholds with the business and reviewing agent decisions is analyst work, and it suits people who know the process better than the platform.
Three ways to staff it.
Hire from the market.
Experienced automation engineers are available but expensive, and the good ones are selective about the programmes they join. Hire this way for the architect and the lead, where experience is the point.
Hire, train, deploy.
Recruit graduates or career changers with the right aptitude, put them through a structured programme on the platform and on engineering practice, and deploy them into the team with a mentor. It takes a few months before they are productive and it produces people who know your standards from day one and have a reason to stay. This is how most sustainable teams are built, and it is the model we run for clients.
Augment.
Bring in external developers or a dedicated pod for a defined period, to clear a backlog or to deliver while the in-house team is being built. Augmentation works when there is a plan for the knowledge to transfer: pair the external people with in-house ones, document as you go, and set a date for the handover. It fails when it quietly becomes permanent and the in-house team never forms.
Why people leave, and what keeps them.
- No path. A developer who has built forty bots and sees no next role will look elsewhere. Define the ladder: developer, senior developer, architect or lead, with the skills each needs.
- Only maintenance. Nobody joined automation to babysit bots. Rotate support duty, and keep every developer on at least one new build.
- No learning. The platforms move fast, and agentic work is new to most. Fund the training and the time to use it.
- Invisible impact. Share the numbers: hours released, errors avoided, what the business said. People stay where they can see that their work matters.
- Isolation. A team of three with no peers is fragile. Connect them to a community, inside the company or outside it.
The handover test.
Whatever the staffing model, run one test every quarter: pick a bot at random, and ask someone who did not build it to explain what it does, rerun a failed item and make a small change through the release process. If they can, the knowledge is in the team. If they cannot, the programme is one resignation away from trouble, and the fix is documentation, pairing and training, starting now.
A programme is only as durable as the second person who can run it.