Exploration and exploitation in technical standards
In engineering organizations, we live in a constant tension between the forces of Exploration, and Exploitation.
If you’re not familiar with Explore/Exploit algorithms, let me give an analogy. Let’s say you like restaurants.
- Exploration is trying a new restaurant.
- Exploitation is going to your favorite restaurant.
In all aspects of our life, we’re balancing these two impulses: to Explore new things (and thus discover something potentially wonderful or interesting), and Exploitation: to take advantage of the things we’ve discovered.
Successful engineering organizations:
- are disciplined about both exploration and exploitation.
- engage in a low level of constant Exploration, but are ruthless about cutting off experiments that aren’t successful.
- bias towards standardization, because introducing something new immediately introduces debt into your whole tech stack. To be exploited appropriately, it has to be so valuable it’s worth going through and updating everything to take advantage of what you’ve discovered.
The value of lightweight standards
Most startups don’t spend much time thinking about standards. And most engineers in startups resist them. They view standards as something that limits their freedom.
There is a cost to having standards. Standards make it harder to do things in non-standard ways.
But there can be a huge payoff to establishing lightweight standards in your engineering organization:
- Fewer patterns in your code.
- Less tech debt to navigate.
- More deliberate conversations about tradeoffs with new approaches
- A lower cognitive load required to understand your codebase and make changes in it. This results in lower onboarding requiremenst for new team members, and faster velocity in releasing new features. It also results in teams that can maintain and operate their code.
Most startups don’t think about these things because they are fighting to survive and these seem like distractions. And in some ways they can be.
But the same people who resist standards are also the people who complain about the results when you lack standards: a messy codebase that is hard to reason about.
My recommendation is that startups put in place very minimal standards and roles around technical decision-making. Having high-quality conversations about technical direction can be very high value time spent. And having some lightweight guidelines around how new technology is introduced or little conversations that need to happen to introduce new things can be easy to introduce and have a big payoff.
And some of the benefits can be huge. You may avoid enormous problems a couple years down the road, by simply establishing some patterns around which conversations to have when you want to do something new.
Credits to the book Algorithms to Live By for a inspiring some of thinking on exploration and exploitation.
Comments powered by Talkyard.