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 and select the best tools, techniques, and processes for every challenge their face. ownership over their decisions On the other hand, we want to have 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. a strong set of best practices and architecture standards 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. 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. Teams should know that when they face a “not normal” problem 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. they are expected to challenge the golden path 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!

10 Challenges in Setting OKRs

How to estimate the tremendous value of technical debt work

Download a section of my book Product Direction

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Challenges in Setting OKRs

I Built a Product with a No-Code Tool and Pitched it to VCs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Top Industries To Be Transformed By Artificial Intelligence, Soon

10 Tips for Building a Successful MVP with Flutter

10 Things To Do Right Away Before Starting Your Product Journey

10 Challenges in Setting OKRs

I Built a Product with a No-Code Tool and Pitched it to VCs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Top Industries To Be Transformed By Artificial Intelligence, Soon

10 Tips for Building a Successful MVP with Flutter

10 Things To Do Right Away Before Starting Your Product Journey

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps