back to blog
Gatekeeping ensures quality and control but can stifle innovation when overly restrictive. Excessive processes in growing organizations slow decisions and discourage experimentation. As a result, promising ideas often fail to reach clients for validation.
In the world of product development, gatekeepers play an essential role in ensuring quality, mitigating risks, and maintaining standards.Many industries require strict control over their product delivery, and the easiest way to do that is to introduce gatekeeping. However, even with good intentions, gatekeepers quite often disturb your company's innovations. When gatekeeping becomes too restrictive or inflexible, it can force people to think twice before trying something new.I am sure most of you have experienced legal, HR, and finance as gatekeepers. Still, when it comes to product development and IT, many small decisions can slow down the process, and people only sometimes realise it.I have been in projects where good ideas died before even being validated by clients. They were never shown or approved because of all of the processes you have to follow in order to make it happen. As the organisation grows, it introduces more and more activities to follow. In order to gain control over the organisation, we lose the speed and people's willingness to try something new.
Sometimes, when people care about what they are doing, they are trying to find a workaround. For example, if your organisation has a complex process of creating a new environment, people will try to find a way to they can avoid using these processes. This is counterproductive, and if this is happening in your company, I can suggest not introducing a new rule that will prevent people from doing it but looking into the core of the problem, how you can help your developers set up a new environment fast and easy, so they can focus on the product instead of looking for a way to avoid systems that suppose to help them, to begin with.All of these small decisions that teams have to make or wait for delay the time when your product can be tried and tested by your clients. In a modern world where agility and adaptability are key to staying ahead of the competition, it is important to build teams and platforms which support it.
Many of you know about agile frameworks and methodologies like Kanban, SCRUM, etc. But when you come to the project and review the team's board, you can immediately see the agile board with ten or more states. From backlog to todo, ready for development, in development, ready for review, in review, ready for testing, in testing, ready for deployment, deployed, released, and god knows what. If we add multiple environments like dev, staging, pre-production or more, we will add even more state of the feature.Even passing all the states on the Agile board can take much time. While the development team waits from state to state, they will start a new feature that they will have to stop work on when they receive feedback, or the feature will have to wait. Then the process becomes even more complicated and slow because suddenly you have 10-15 features on your board that are "sort of done" but still in progress.
After all these long processes, what will usually happen is that the team will stop development and take care of only features in progress. Finally, after some time, they go through the process and are ready for deployment. But then comes the next problem — instead of 10 minor improvements to release, we are talking about a big release with ten changes that affect all our applications. Everyone becomes anxious because of the added risk since it is a more significant change. We talk about more testing, validation and final approval to make a release. The gatekeeper at the final stage rarely understands the risks, and usually, it is a formality; if the team suggest deploying, the deployment will happen.
So, why is it happening? The more time your feature needs from idea to release, the more issues it raises. People lose motivation if they know how long it takes to implement their ideas, how many decisions to make and meetings to have. Developers lose focus and must switch between features in different states to finish them. Testers must remember what is deployed, where, and how it affects their testing. There are projects where the testing team have to make an Excel file with mapping where each feature is. How can we improve it? Reduce unnecessary steps. Try to speed up your Lead Time for Changes without compromising your quality. Today, there are many ways to do that.
Build independent teams that are responsible for delivery themselves. They should have all they need to decide what to build and when to release it. Less outside interaction between the team needs to do and external dependencies — faster they can make decisions. Include other departments in your decision-making on the team level. For example, coordinate with sales for your next release and include your DPO in the early development stage to ensure that what you do is correct and privacy is not the issue.
Look into your development processes. Do you really need so many environments? How can you change your platform so every commit goes to production? If your organisation is big enough, do you have a platform team that helps other teams deployment, monitoring, alerting, metrics, etc.? Look into DORA metrics, but any metrics can be tricked and optimised by people to gain personal benefit. So, it is important not to overuse metrics but instead focus on global improvements.
Jeff Bezos
Distinguish between deployment and release. Deploying every commit to production does not mean releasing a new feature. Your product and sales team might have different processes, but it does not mean that the development team have to wait for them. In Norway, we have a great company, Unleash, with an awesome product that helps teams deploy code and then decide when to release a new feature to the customer.
Review your processes, map them and find where you lose most of the time. Suppose your code can live days in code review. Then, it is an issue to resolve. Do you need to review every commit? Can it not be mandatory? How your platform can support save release and rollback if something goes wrong. How do you ensure that your system is fine? Do you have enough monitoring, checks and notifications?
To overcome the challenges that come with well-meaning gatekeeping, it is important to be open-minded to new ideas, have a forum where people can share them and encourage everyone to try and test new things. It is a long process and will include failures, but the only outcome from these failures should be new learnings, which will encourage people even more to strive for a new, beautiful future.
Related articles
