Working on a platform team I think a lot about whether we should focus more on enabling or enforcing. Are we more effective as agents, or as gatekeepers? I think about how to nudge developers into the pit of success. There are tradeoffs and there's no one-size-fits-all solution, but I've got opinions! (Who doesn't?) After a few years I've seen some things that work and some things that don't.
I first joined a platform team a few years ago, and our mode at the time was enforce. We were in charge of the style guide, the libraries people could use, who could review code... it all went through us. Our team was tiny and the company was going through a growth spurt, so we quickly became a bottleneck. We had our reasons: we had a monolithic codebase so third-party libraries had to be pretty tightly controlled to avoid bloat. Since we were the ones who approved new code reviewers, if people shipped poor quality code it ultimately reflected on us.
As a result, the code review process was stringent and thorough, focusing on technical knowledge as well as soft skills. It wasn't unusual to take months for a person to be an official reviewer (with the ability to approve code for production). I went through the process myself, which solidified my foundation and gave me much-needed confidence coming into a platform team where I felt serious imposter syndrome.
And hot dang did we produce some quality reviewers... but it was unsustainable. There were three of us approving new reviewers in a company growing by dozens of employees every week.
We ultimately moved to a decentralized model where there was a baseline proficiency test, but beyond that teams were responsible for their own standards. Reviewership came easier, teams were free to loosen the restrictions—but much more of the responsibility for maintaining standards was in their hands. We were moving from enforce to enable. This had pros and cons but was on balance a real positive.
The shift towards enabling freed us up to focus on making devlopers' lives better with tools and automation. In my eyes this is what a platform team should be focused on. When we were the gatekeepers we had a lot of baggage to maintain. After decentralizing we could listen to teams' pain points and ideas, produce what they were asking for, and even some things they hadn't asked for. We could innovate! They were now truly our customers, and we could serve them better. This made us happier too!
Another factor in moving towards enable was a large-scale decoupling effort. We were transitioning from a monolithic codebase with centralized deploys to individual repos for apps and libraries. Teams had a whole new set of skills to think about: deploying, versioning, dependency management... these were in their hands now, to the chagrin of some and the delight of others.
Seeing the variation across teams made me realize there's another dimension to enforce vs enable: the size and seniority of the team. In my experience, generally speaking more junior teams are looking for structure, they want you to enforce. More senior teams are more comfortable choosing their own tools, so they're happier when the platform is there to enable.
Ok, so there's one more side to this. Enable or enforce isn't the whole story, and given the choice I'd go with door number three: encourage. Also known as the paved path, we provide a supported solution but if teams really want to go their own way they can... they'll just be doing it without platform support. In some ways it's the best of both worlds, providing a solution for the majority use case while giving seniors the latitude to pick their tools, and enabling us to give focused support rather than trying to keep up with dozens of teams doing different things.
Of course there are tradeoffs. One of the benefits to the enforce mode is higher signal to noise ratio: when you have one state management library to choose from, you can focus on understanding it inside and out. When you have two or three you have to invest the time to understand a bit about each, and why to choose one over the others. Some people love that, but others prefer when the choice is made for them.
If you forced me to pick the one I think will work best in most situations, long term, I'm going with encourage. Even for junior teams who need more support, when you relax some of the restrictions they're likely to surprise you. In my experience platform teams are happier and produce more value when we can enable while focusing on a paved path, we just have to remember to listen to our customers, the developers.
A note on the terms: words can be interpreted in different ways, so I want to clarify how I'm using them. In this case I see them as levels of opinionation on a spectrum. On the low end, enable means giving the ability without being opinionated. Encourage implies a stronger opinion but still gives developers freedom to choose another path. Enforce is the most opinionated, enough impose restrictions.
