Who should actually be responsible for building automation inside a company?
Many organizations still answer that question the same way: a specialized team, usually small, usually stretched thin, building on behalf of everyone else. I wrote about why that model breaks down as a company and its automation vision scales in my last piece. So here’s the follow-up question: If centralizing that capability is the wrong long-term answer, what actually replaces it?
My answer, and I admit it’s an opinionated one: everyone builds. Not everyone has to become an automation engineer. But the ability to spot a repetitive piece of your own work and automate it yourself, without filing a ticket and waiting in a queue, has to become a normal part of how people work, the same way spreadsheets did a generation ago.
This isn’t a nice-to-have; it's what the future of work looks like, and companies that treat it as optional are going to find themselves permanently behind the ones that don't.
Why the gatekeeping model was never going to last
The instinct to centralize building makes sense at the start. You concentrate scarce technical skill in one place, and that team clears a real backlog fast. I've written about what happens next: the team that solved the backlog problem becomes the new bottleneck, because the rest of the organization never had to build the capability itself.
Zoom out past automation teams specifically, and the same pattern shows up whenever technology gets treated as something a specialist does on your behalf, the way infrastructure did before platform engineering existed. A central team provisioning servers on request is slower, creates a permanent dependency, and puts judgment about what's actually needed in the hands of the people furthest from the problem. Platform engineering exists because infrastructure teams eventually stopped being gatekeepers and started building self-service paths instead. Automation is a few years behind, but I believe we will be going through a similar shift.
What's changing
Building is getting radically easier at a pace faster than most leadership teams have adjusted to. The practice of “flowgramming” using built-in AI assistants like the one available in n8n or via MCP has made it so that someone in finance can now build something in an afternoon that used to require a ticket, a queue, and several weeks of waiting. The barriers to entry are only getting lower.
This is not the only argument for decentralizing, and it isn't a universal one either. For companies in regulated industries, or serving customers with strict security requirements, keeping build access centralized can be the right call even if it's not technically necessary. That's a legitimate choice tied to risk appetite, and each organization will have to decide where they land on that speed vs. risk equation.
For a scale-up in a fast moving space like n8n, the calculus is different, and the risk runs the other way. Now that the technical barrier has significantly dropped and will continue to do so, the longer we keep automation concentrated in one team the more we risk falling behind organizations that are working out how to open this up safely. There's another reason to embrace decentralization that is true for n8n specifically: we build the product meant to make this kind of building accessible to everyone everywhere and we can't credibly sell a future we haven't lived ourselves. That's the whole idea behind starting “n8n on n8n:” getting it right internally is key to showing the world what is possible.
How decentralization goes wrong
Two responses are common when companies hear the call to "let everyone build." They either resist it entirely, worried about chaos, or they open the floodgates with no structure and chaos ensues.
Both reactions miss a key opportunity. The future of work being built by everyone doesn't mean no standards. It means the standards have to travel with the capability, instead of living inside one team's head.
At n8n, the things we want to scale are the same ones I hold my own team to:
- Understand the process before you automate it, so you're not just making a broken process move faster.
- Know when a proven tool beats building something yourself, so people aren't quietly reinventing things that already exist, or creating an unnecessary maintenance burden.
- Build things that outlast the person who made them, with enough documentation that someone else can actually pick them up.
- Treat responsible use of data and AI as non-negotiable, not something only a central team has to think about.
None of that requires a computer science degree. But it does require investments in upskilling, enablement, and architecture that will support more people thinking and building the way an automation engineer would.
What the journey looks like
For us, this has meant moving the Automation team towards something closer to a guild than a service desk. We are developing a network of people across departments who've picked up enough of this discipline to be the person their own team turns to first, backed by shared resources instead of everyone reinventing the same workflow from scratch: reusable templates, office hours where people bring a working problem instead of a request, and a documentation standard we're still rolling out that's meant to travel with every workflow regardless of who built it.
It’s still early days and much of this remains aspirational, as the standards I just described aren't consistent across every team that does. Our Automation team is still struggling with a growing workflow maintenance burden with workflows that we are not in a position yet to fully hand over or redistribute to teams. But we are naming the problems and creating solutions rather than simply increasing headcount. This forces us to continue to prioritize the most business critical work, and create the right incentive structures for learning and development in automation across the organization.
Why this is actually about the future of work
The companies that figure out how to give people real building capability, safely, are going to move much faster than the ones that keep it locked inside one team. That gap is going to show up in how quickly a company can respond to almost anything: a new competitor, a new regulation, or a tool that changes what's possible overnight.
The future of work isn't a smaller number of very powerful specialists doing more with AI. It's an organization where building automation becomes part of basic technical literacy, the way using the internet itself did. The difference is pace. That shift took a generation to settle in. This one won't take as long, partly because the pace of change has been astounding, and partly because the benefits don't concentrate on one function: they show up everywhere at once, which means the upskilling has to happen function by function, and faster than we've ever had to do it before.
Getting there isn't about handing everyone a tool. It's about deciding, deliberately, that this is worth teaching, worth standardizing, and worth building a real team around: one that sets the standards, builds the architecture everyone else builds on top of, still owns the highest-stakes and most business-critical systems itself, and makes everyone else capable of the rest.