Should a team have complete freedom of choice on tools and processes?

The flexible vs rigid standards dilemma

A few days ago a conversation with our most senior Dev executive triggered this dilemma, worth exploring in more detail.

The argument went something like this: we want the teams to feel ownership over their decisions and select the best tools, techniques, and processes for every challenge their face.

On the other hand, we want to have a strong set of best practices and architecture standards that we have evaluated and decided to be the best for our business and services. We have the tools to “enforce” the correct use of them.

These two goals are in conflict. What should we do?

First know the rules, then break them.

The first thing to mention is that I do not quite believe this is actually a real dilemma.

Let’s imagine a new team of developers we just hired. They join the company and are assigned their first product to work on. They would probably “love” to have a set of best practices, tools, and process to follow. It would actually make things easier for them, showing the “golden path” and being able to use common scripts and homemade tools to support those standards.

A few months later they decide to work on a new feature for their product. They face a very particular challenge that they feel is not compatible with the golden path. They should know that breaking the golden path is possible (even encouraged) when it doesn’t fit their purpose. They may need to ask for a particular access (for instance, access to change a particular server configuration that most teams do not have access to), but it will be possible and congratulated after the successful launch of the feature.

Team seniority

Moving away from this “new team” perspective, a more realistic scenario is how team seniority affects the possibility of moving away from golden paths.

Any company has more junior teams that need those golden paths “enforced”. This teams usually work on “business as usual” problems and features for which the golden path was purposely defined. There would also be senior teams, that will be pushing to create new and better standards that would later be incorporated into the golden path.

Culture vs “following a script”

Going back to the “new team” scenario, I said:

“They should know that breaking the golden path is possible”

I believe there lays the cultural problem.

1. 
   

   People should want to follow the golden path as much as possible. It has the best practices, and the company will have tools around that golden path to make life easier for those who follow it.Some junior teams may not see how valuable this is or even worse in the pursuit of solving a problem with “what they know”, they may break the expected rules. The value of the golden path and how to use it should be communicated and constantly reminded.

2. 
   

   Teams should know that when they face a “not normal” problem they are expected to challenge the golden path and find a more suitable solution.The same constant communication of this principle is needed. And if a junior team faces a weird challenge, some help will be needed to put them on the right path for that problem.

3. As a feedback loop, the company should make visible those teams that successfully moved away from the golden path, and periodically revisit the golden path to incorporate new emergent patterns.

Conclusion

• Enforce the golden path as much as possible with the right tools (ie blocking access to unneeded configurations, automating build and releases with certain patterns, enforce code quality with standards tools, etc)
• Constantly explain the value of the golden path. Constantly remind that it should be broken when the challenge deserves it.
• When it’s broken, look for patterns or opportunities to improve it.

Thanks for reading! I would love to hear feedback and other people stories on this topic.

If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers!