There is no free lunch when dealing with engineering processes
Now that we have learned that the software development process involves structured routines (like meetings, quality gates, tracking systems, triage rules) that help a team move from idea to production, our first instinct might be to apply a new process every time we see an inefficiency in the development cycle. But before we rush to add a new rule, we need to look at the other side of the coin: when a well-intentioned process becomes bureaucracy.
No process comes without tradeoffs. Every time your team follows a process, whether they're in a meeting, waiting for a quality gate to pass, or triaging bugs, it consumes time and attention that could be spent delivering work.
Many managers don't realize this hidden cost of adding a process. As a result, their teams suffer from "process bloat," where no one questions why they do what they do or why certain ceremonies still exist.
Process bloat creeps in slowly. For example, imagine an engineer gets careless and ships code with a bad UI to production. Designers complain, managers panic, and a new rule is dictated: every pull request must have a designer's approval.
