Engineering strategy beyond good and best practices
Applying good and best practices isn't strategy
A couple of months ago, I wrote some thoughts on LinkedIn about applying best and good practices isn’t a strategy, and today I want to explore that idea in a deeper way.
You can read the full post here.
What are the good and best practices?
Good and best practices are well known solutions to common problems that we face in our day to day as software developers, staff engineers, platform engineers, …
Which are the main differences between best and good practices?
Best practice: Universally applicable to the software context. Some examples can be using version control systems, CI/CD, …
Good practice: They might or might not apply to your context, but when it does, it offers a clear benefit. Some examples can be microservice architecture, Pub/Sub, …
Those best and good practices can also be about Agile, Lean, XP, TDD, collaboration and communication patterns, DORA metrics, monitoring and observability, Cloud, …
Companies that apply good and best practices perform better than the ones that don’t
I have been in the industry for at least 10 years, and I can tell the difference on velocity, team health, stability of the systems, … between companies that apply them and those who don’t.
The gap is huge.
In that sense, we can tell that investing in those practices has a huge impact on the organization that it can be seen as strategic.
By making this investment, it positions ourselves better than competition. Isn’t this the goal of a strategy?
Well… IMHO, it is not, or at least not per se.
Best and good practices are the foundation in which you build your strategy on top of.
Those practices don’t difference your strategy from your competence because they apply to the same contexts for everyone playing in the same domain.
Investing more in those practices won’t position you better than your competitors.
Wardley Mapping Doctrine
Then, what are the best and good practices applied to Wardley Mapping? They are doctrine. Simon Wardley defines doctrine as:
Doctrine are the basic universal principles that are applicable to all industries regardless of the landscape and its context. This doesn’t mean that the doctrine is right but instead that it appears to be consistently useful for the time being. There will always exist better doctrine in the future. As with climatic patterns we will go through some basic forms and refine in future passes through the strategy cycle.
Based on the Strategy Cycle, doctrine is only one step on the strategy.
The good part of investing in doctrine is that it is a more “known” path with plenty of resources available (like trainings, consultants, and people with experience).
The problem when investing only in doctrine
Investing in doctrine is “finite”. Let me explain myself.
It isn’t finite in terms of that you can learn everything but that the impact of the investment compared to a competitor that’s making context specific decisions decreases overtime.
You will need to move from known practices to unknown. From easier decisions that everyone agrees to harder conversations based on imperfect information, with unknown consequences, and feedback loops that will always take longer than you expect.
That’s uncomfortable, but that’s the game you are playing, and in order to win, you will need to be exposed to the unknown vs. play safe by only investing on doctrine.
My recommendation, go beyond best and good practices
Invest in creating the necessary engineering foundations using those good and best practices.
It is not easy nor trivial.
It takes time and energy to make it happen, that’s why when it is in place, you will be better positioned than your competition.
Given that moment, you need to choose between keep investing on those foundations or start making decisions that are only specific for your context.
The good part is that having a good foundations make it easier for you to make context specific decisions that can place you better than your competition.
The more you practice those, the better you will become. At some point, you will find yourself with a higher situational awareness, and making better decisions faster.
Reaching a good foundations take time
A pain we all have is that reaching the situation where you have the foundations in place takes longer than anyone would expect. So, you might need to design a strategy to focus on creating those strong foundations and overcome any friction within your organization that's preventing it to happen.
Good luck on your engineering strategy journey, I hope you can go beyond engineering best and good practices, and start making context specific decisions.