The explore/exploit strategy is an iterative approach to systems engineering and team formation.
It starts out with an exploration phase and scales both system and team size during the exploitation phase.
Later on, the strategy is repeated for either product improvements, disruptive changes, or new projects and teams.
A general introduction to the explore/exploit strategy is described in Brian Christian's and Tom Griffiths' book named "Algorithms to Live By".
The advice divides the time you spend on tasks into an exploration and an exploitation phase.
Exploration is gathering knowledge, and exploitation is using the knowledge.
The idea is to explore things when you will have time to use the resulting knowledge, and exploit it when your are ready to cash in.
Another example of the explore/exploit startegy is given in Richard Hamming's book "Learning to Learn".
He concluded one should have a plan to first explore things in a research phase, and then exploit that knowledge to build something.
The exploration phase is best described by scientific research:
In science, if you know what you are doing, you should not be doing it.
While the exploitation phase maps well to engineering:
In engineering, if you do not know what you are doing, you should not be doing it.
Of course, both exploration and exploitation as well as science and engineering are tightly coupled with each other in an iterative process to make progress.
Change does not mean progress, but progress requires change.
Progress is achieved then by repeating the explore/exploit cycle over and over again with the results of an exploitation phase fueling new exploration phases.
From time to time, this repeating process ends up in disruption and disruptive technology, a terminology defined by Clayton Christensen in his book "The Innovator's Dilemma".
The explore/exploit startegy helps to understand and boost various aspects in both software engineering and team formation.
Explore
The exploration phase must be started by a small, motivated and joyful team with common sense that focuses on the hardest problems first.
Louis Pasteur's remark, "Luck favors the prepared mind", perfectly summarizes the purpose of this phase.
It both admits there is an element of luck and yet claims to a great extent it is up to you.
You prepare yourself and your team to succeed or not.
Good advice for how to master the exploration phase can be found in Frederick Brooks' book on "The Design of Design".
A quick summary can be found in one of my older blog posts about "Frederick Brooks on Software Design".
The few designers who do the exploration phase, build up a plan in mind for later execution.
According to Brooks, the outcome of the exploration should be a plan with conceptual integrity - unity, economy, clarity, delight.
The plan is partly implemented during the exploration phase to learn fast from mistakes and other aspects of the design.
Another, bigger part of the plan is done during the exploitation phase while the team grows in size.
An important fact, according to both Richard Hamming and Clayton Christensen, is that most of the great innovations come from outside the field, not from the insiders or experts.
Probably because experts tend to neglect or shorten the exploration phase and immediately rush into the exploitation phase.
Another remark from Richard Hamming is that some, not all experts rely too much on their own knowledge bubble:
Working with one's door closed lets you get more work done per year than if you had an open door, but I have observed repeatedly that later those with closed doors,
while working just as hard as others, seem to work on slightly the wrong problems, while those who have let their door stay open got less work done but tend to work
on the right problem! I suspect the open mind leads to the open door, and the open door tends to lead to the open mind.
A further good source of advice about the exploration phase is Richard Hamming's talk about "You and your research":
If you prefer text, have a look on Hamming's paper on "You and your research".
Exploit
The interaction with harsh reality tends to push you into significant discoveries which otherwise you would never have thought about while doing pure research in a vacuum of your private interests.
That means it is very important to start exploiting the knowledge garthered during exploration alongside scaling the team, not too early and not too late.
The most important step during exploitation is team formation as well as building a common mindset and language within your team.
Therefore, defining a few basic architectural building blocks during the design phase and documenting them with a software development kit and examples is crucial.
While scaling your team always assure to build up many experts, not just a single or few knowledge towers, as explained by Richard Sheridan in his book "Joy, Inc.".
Otherwise such superstars will hoard knowledge without sharing it, and ultimatively wreck the overall team results and morale.
Keeping high quality results while expanding the team requires a balanced team without a central superstar, a team which truly and authentically cares about things.
Also see one of my older blog posts about the Characteristics of an efficient engineering team.
The leader of such a team is best when people barely know he/she exists. As Laozi said, that when the work is done, the aim fulfilled, they will say: we did it ourselves.
Keep in mind that there is never time to do the job right, but there is always time to fix it later.
As mentioned by Alan Kay: "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."
So as long as the overall system design has conceptual integrity, you and your team will have plenty of room for future improvements and refactorings, hopefully without changing public interfaces.
Repeat/Iterate
Great designers grow with their challenges. They need a constant flow of exciting challenges for mastery.
Therefore, you will repeat the explore/exploit startegy over and over again for product improvements or new projects.
Success means you and your team will get better problems to work on.
But what you did to become successful is likely to be counter-productive when applied at a later date.
For that reason you have to iterate to a new exploration phase with some of your team not to get stuck in exploitation.
Being an expert all the time is not what you should aim for. Be a hungry and foolish beginner from time to time.
