One of the most consistent failure patterns I have seen in IT and security is the rush to automate processes that were never designed properly in the first place. Many organisations assume that automation will make things faster or more scalable. In practice, automation amplifies whatever is already there. A clear and simple process becomes more reliable. A messy one becomes messier at a higher speed and with more impact.
Startups often avoid the idea of process because they associate it with heaviness and a loss of flexibility. But process is not bureaucracy. Process is simply how work happens. If an organisation relies on a form of controlled chaos, automating that chaos does not create efficiency. It creates bigger and faster chaos. Good automation starts with good design, and good design starts long before any workflow engine is involved.
Why Organisations Automate Too Early
There are a few recurring reasons why teams automate long before they are ready for it.
They try to save themselves from pain. Manual processes are frustrating, so teams look to automation as a shortcut. But automating a painful process does not remove the pain. It removes visibility and adds new failure modes.
They misunderstand what process means. In many companies, especially younger ones, process is equated with bureaucracy. People avoid documenting flows or defining responsibilities. But automation requires clarity, and without clarity it simply encodes confusion.
They overuse frameworks. Methodologies like Scrum or SAFe can be useful, but only when adapted to the organisation. Too often, "that is how the framework works" becomes an excuse to avoid thinking critically. When the framework becomes more important than the outcome, it creates rigidity and unnecessary ceremonies. Automating this locks the rigidity in place.
They hide behind regulation. Industry rules are real, but they are also frequently used as justification for slow or complex processes. I have seen organisations insist a workflow must stay exactly as it is because regulation requires it, even when other companies operating under the same rules manage to work far faster with far less friction. Regulation rarely demands inefficiency. The interpretation of regulation often does.
A broken process should not be automated. It should be redesigned.
What Good Process Design Looks Like
Real process design is not about adding steps. It is about identifying what is essential and removing what is not. Many organisations assume complexity is necessary because they have never questioned the work from first principles.
Start with what the business needs. TOGAF, despite being heavy when followed literally, gets one thing right. It starts with business needs, then data, then applications, and infrastructure last. Technology should support the work, not dictate it.
Define clear but lightweight responsibilities. Responsibilities do not need to be perfect or rigid. They simply need to be known. IT owns core infrastructure and security boundaries. Teams own their data and their operational decisions. The exact lines can shift as the organisation evolves.
Design for outcomes instead of gates. Many approval flows exist because they look good in documentation. In practice, they slow teams down without improving quality. Approvals should be used sparingly and mainly for regulatory-controlled decisions. Everything else benefits more from clear expectations and trust.
Focus on user experience. If a process is frustrating, people will bypass it. This applies to simple flows like password resets and to complex ones like onboarding or provisioning. UX is a security control and an operational control.
Remove friction before automating anything. Lean principles matter here. Remove waste first. Simplify. Once the process is stable and understood, automation becomes a multiplier instead of a liability.
When a process is simple, predictable and grounded in real needs, automation reinforces it instead of breaking it.
Where Automation Creates Real Value
Once the foundation is healthy, automation can transform the organisation.
Self-service with guardrails. Engineers can provision resources quickly when the platform includes guardrails. This avoids multi-week approvals and reduces shadow cloud use.
Silent and well-timed updates. Vulnerability management can be effective without disrupting work. Updating software during downtime, reducing interruptions and focusing on meaningful risks improves both security and productivity.
Integrated evidence collection. GRC automation works when the evidence being collected is actually useful. Some controls require daily checks, others monthly, others annually. Automating everything blindly wastes time. The goal is insight, not volume.
Clear boundaries with decentralised execution. IT defines the sandbox. Teams operate freely within it. Automation reinforces consistency without limiting autonomy.
Automation is most effective when it supports people, not when it replaces thinking.
The Bottom Line
Automation does not fix unclear responsibilities, outdated assumptions, weak UX or poor communication. It amplifies them. Organisations that automate too early end up with brittle systems, frustrated teams and a growing fear of change.
The companies that use automation well design their processes intentionally. They remove friction before adding tools. They define ownership clearly. They adapt frameworks to their own reality instead of following them blindly. They focus on outcomes, not ceremonies.
Automation should make good processes stronger. It should not be used to hide broken ones.