Automation and headcount
Pitch automation as a way to need fewer engineers and you lose the people who know where the real problems are.
Insights and thoughts Andrew Wood
If you want engineers to help automate their own work, don’t pitch it as a way to need fewer engineers.
Every delivery team I’ve run has had more work than people. The backlog doesn’t empty, and senior engineers spend too much of their week on repetitive tasks a script could handle. Automation should give that time back.
Sell it as a headcount saving and you immediately lose the people who know where the real problems are. Every estate has undocumented quirks: the monitoring alerts everyone knows are false positives, the fragile legacy service that needs restarting in a specific order, and the runbook steps everyone quietly skips because they’re five years out of date. If engineers think they’re building their own replacement, they keep that knowledge to themselves, and your automation fails the first time it hits an edge case.
What works is talking about consistency and capacity: fewer repeat incidents at 2am, and your best engineers focused on the architectural problems that actually need them. Departmental cost to serve comes down either way. This way you keep the team that understands how it all fits together.