I wrote this while working in Australia's fastest growing startup, and I shared it to the product and engineering teams. We had been adding more and more defined roles and many of them wanted to implement processes to our workflow, and I was starting to feel like every time someone was trying to implement a new process, they were not accounting for the context switching and cognitive load or sequencing of adding processes to teams that were for the most part, working well at a fast pace.

Don't introduce processes that slow down the ability of your team to be agile, unless the challenge you're solving, and the process you're implementing will bring exponentially more benefit.

— Benjamin Doyle ✍️

The scars we carry

The startup and scale-up journey leaves marks on everyone who walks it. We all bear the scars constant change, things we wanted to do but couldn't, processes we tried but ultimately needed to change. These aren't just professional disappointments; they're formative experiences that shape how we view change, improvement, and what "good enough" really means.

When someone new joins the team, they see everything with clarity we've lost. Their suggestions feel revolutionary, their solutions seem obvious. To them, the path forward is crystal clear: why haven't we done this already? But what appears novel, fresh, and undeniably right to one person often doesn't take in the full context of why we haven't done it already.

The question that reveals everything

One of my favourite questions to a potential new hire which will have a say in team processes is:

When you want to implement a new process that you know may be unpopular, what is your plan to get buy-in from the team and implement it?

This question is a great way to gauge the person's ability to listen to the team, and their ability to understand the context of the problem. It's also a great way to gauge whether they implement processes that are not needed, and have in the past adapted processes to fit the team, rather than the team adapting to the process.

The best answer is always one in which the person has listened to the team, and has a plan to get buy-in, and sets check-ins to see how it's going over time.

Someone coming into the organisation might see a deficiency or need, but what they should start with is what the team has done well, with what they have. Any role that can affect this should listen, so you want to implement a new process?

The team should be consulted, and asked about it, just like anything you want to get done, the easiest way to do it is involve others to have them be part of the solution. You do this, and when it comes time to implement, the team will be more invested in the process, and more likely to follow it.

Start With a Social Contract

Before any process touches your workflow, you need agreement on the problem. Not just acknowledgment, genuine agreement that this pain point is worth solving and worth the disruption that comes with change. This social contract isn't a formal document.

It's a shared understanding that emerges from conversation. "Yes, we all feel this friction." "Yes, we think addressing it will help us more than it will slow us down." "Yes, we're willing to try something different here."

Without this foundation, you're building on sand. The most elegant process will crumble if the team doesn't believe in the problem it's solving.

The Scientific Method for Process Change

Once you have that social contract, treat every process change like an experiment. Because that's exactly what it is. Hypothesis: "If we implement [specific process] then [specific outcome] will improve because [specific reason]."

• Variables: What are you changing? What are you keeping the same? What might influence the results?
• Measurement: How will you know if it's working? What signals will tell you it's working or not?
• Timeline: How long will you implement this before you evaluate?
• Exit criteria: Under what conditions will you abandon this approach?

The beauty of this approach is that it removes ego from the equation. You're not defending a process; you're testing a hypothesis. If the data says it's not working, you pivot. If it's working better than expected, you double down.

The One-Change Rule

Here's where most teams go wrong: they try to fix everything at once. They see multiple problems and implement multiple solutions simultaneously. Then when things go sideways, they can't tell which change caused which effect. Treat your team's change capacity like a finite resource. Because it is.

Only run one process experiment at a time. Let it stabilise. Let the team adapt. Let the data accumulate. Only then consider the next change. This isn't just about measurement; it's about respect for the cognitive load your team carries. Every new process requires mental energy to learn, follow, and internalise. Pile on too many changes and you'll exhaust that energy, creating resistance to all change, even the good kind.

When Good Intentions Compound

Each discipline in your organisation (engineering, design, product, marketing) wants to optimise their piece of the puzzle. Each sees a clear path to improvement. Each has a process that worked somewhere else. In isolation, each suggestion makes perfect sense. But when these individual solutions compound, they create a crushing weight of change that no team can bear gracefully. This is why the scientific approach matters.

It forces you to sequence changes, to measure their true impact, and to understand the hidden costs that come with even the best intentions. You also need to tell other teams, how many processes are changing from other disciplines and other stakeholders, including your own team.

The Art of Saying No to Good Ideas

The hardest part isn't identifying bad processes; it's saying no to good ones that come at the wrong time, or that solve problems that aren't quite painful enough yet. Your team's scars have taught them something valuable: not every problem needs solving right now. Not every improvement is worth its cost. Not every process that worked elsewhere will work here. Listen to those scars. They're not signs of resistance to change; they're wisdom about the true weight of change.

Conclusion: Iteration Over Arrival

The goal isn't to find the perfect set of processes and lock them in forever. The goal is to build a team that can navigate change thoughtfully, scientifically, and sustainably.

• Sometimes that means moving fast and breaking things.
• Sometimes it means moving deliberately and preserving what works.
• Sometimes you need to say no, or not yet to good ideas.
• Maybe it's time to remove, or reduce a process.

The wisdom is in knowing the difference, and work with the team to find out when you're not sure.