n8n Moves Its Automation Team Away From the Service Desk Model

Where the service desk model hits its ceiling

Da Costa argues that a centralized automation team solves a real problem, but that solving it well creates a new one. The rest of the organization comes to rely on the team, so the bottleneck is not removed. In her words, it is shifted downstream. Once the backlog is cleared, she says, a question nobody budgeted for remains: who maintains everything the team built.

At n8n, the team was created to fix a clear issue. According to da Costa, staff were drowning in manual work and nobody was joined-up enough across the company to fix it systematically, so engineers were hired to build workflows. She calls that the right call at the time and says the team did the job remarkably well. She joined earlier this year to lead the function and found that the model had reached its limit. n8n has "somewhere north of 12,000 internal workflows," she writes, and no team can build and maintain all of them.

From building automation to building a culture

Da Costa says the guiding question has changed. It is no longer how to build more automations, but "how do I build a company where every team can think and act like automation engineers?" Under the old question, success looks like throughput. Under the new one, it looks like how many teams stop needing the automation team at all.

She also addresses the argument that easier building makes a central team redundant. Building workflows, agents and internal tools is becoming far more accessible to people who are not engineers, she notes. Her view is that this makes the job more important, though different. The scarce skill becomes judging whether something should be built, how to know it worked, which tool fits, and who owns it when it breaks.

The principles in practice

Da Costa says the shift has turned into four principles. The excerpt covers the first three in detail.

• Build the builders, not just the builds. The team prioritizes enablement over shipping workflows. One engineer spent time this quarter sitting with a colleague while she debugged her own automation instead of writing it for her. At department level, the approach includes training sessions, reusable workflows, office hours, and a network of technical champions, one person per department who understands the team's processes and owns its tools. At company level, n8n is creating an AI fluency framework with shared standards for responsible AI use.
• Require a baseline before you build. Da Costa describes an AI agent that generated six figures in pipeline in a month. When she asked "Compared to what?", the comparison proved messy. The agent runs around the clock, and the human SDRs were by then mostly handling harder, escalated work the agent had already filtered. Before any project starts, her team now asks the requesting team how often the work happens, how long it takes, how many people touch it, what it produces and what would count as a meaningful improvement. Guesses are acceptable.
• Choose the tool for the problem. The team often pushes for buying rather than building, which da Costa admits surprises people given that the company is n8n. Her rule of thumb is that a proven, specific tool that has existed on the market for a year or more is usually the better choice. Building internally means taking on maintenance and security surface indefinitely, while a vendor keeps shipping against its own roadmap.

What it means for other organizations

Da Costa stresses that the pattern is not unique to n8n and that she does not see it as a mistake. She expects most organizations, especially large enterprises, to reach a version of the same realization after standing up a central team and clearing the backlog. Her advice to anyone stepping into a similar role is to interrupt that natural course deliberately, particularly when the goal is a highly automated, AI-first organization.

The practical takeaway from her account is a change in what an automation team is measured on. Workflows shipped and tickets closed give way to how well other teams can run on their own, supported by champions, shared standards and a clear baseline before work begins. The excerpt ends partway through the third principle, so the fourth is not covered here.