Most software companies have gatekeepers at specific parts of their development process. They engage at some point in the process to review work done by others and either approve or reject it. Companies set up Security, UX, or Database design teams to do these reviews.
The two main problems with having gatekeepers in the process are:
- They do not contribute to fast flow, as reviews introduce wait times and delays.
- Gatekeeping is coercive and harms people's autonomy. It assumes that people will do a lousy job, and it is the gatekeeper's job to prevent that.
Why and when do gatekeepers exist, and how are these processes designed?
Building software requires a wide range of knowledge and skills. Software Engineers need the expertise to meet nonfunctional requirements like security and quality. And they also need to learn the business's domain. Technology stacks also have their learning curves as well. Building all this expertise can take years. Companies can't have experts in all these skills in every team.
So companies build a system to access this expertise, optimizing for the expert's time. If they didn't, there would be a bottleneck when trying to get ahold of the expert. How do they do this? By asking experts to review the work of their peers after they completed it.
The problem with this system is that we can't optimize for fast flow
By design, a system with late reviews in the process will discard work from time to time.
How do you improve this? If you ask the gatekeepers, they'll answer the following: "You need to involve us earlier in the process!". But we know that can't work. We do not involve you earlier because we don't have enough experts to discuss all our ideas! Also, you are not the only expert you need, we also need to talk to Security, UX, and many more!
That's not only impossible to do at scale. People would also suffer a total lack of autonomy.
It wouldn't also address the problem of adding time to the development process. Not only the consulting and reviewing time but also time waiting for the expert to be available. And wait times are much higher than the time spent doing work!
At the same time, teams need this expertise. That's why we introduced gatekeepers in the first place!
How do we transform gatekeepers into enablers?
The most important thing is to change the narrative of distrusting team changes. If the experts translate what they review into requirements, teams can plan how to address them. If they do not have the know-how, they can go to the experts asking for support.
Now, this is hard for gatekeepers to figure out. Translating all the things they review into requirements looks like an impossible task!
Doing it step by step
Another thing to try is to get out of the loop of simple cases. Having good default paths that do not need expert intervention.
For instance, a DBA team can teach teams how to self-review tasks like adding a column or index. They can get out of that review loop and keep reviewing other activities, like a new database for a service.
Another way the gatekeepers can turn into enablers is by letting them own their stuff. Enabling the team can achieve this by providing visibility and radiating information.
A Quality team might set up public reports with the defects reported by customers. It could also show important information like the percentage solved within the SLA. Teams can see how they are doing, and they can turn to the enabling team to help them improve those indicators.
And what about platform teams?
Platforms can reduce the cognitive load and efforts stream-aligned teams need to do. They can automate or solve part of the things gatekeeper reviews try to prevent.