The story of Stone Soup goes like this: you arrive in a village hungry and without any food in your backpack. The inhabitants are suspicous of strangers, so you start boiling water over an open fire. When passers-by inquire, you show them a stone that you’ve put in the pot, and announce that you are making delicious stone soup. This seems nuts at first, but you persist in singing the praises of this odd dish, and offer to share the meal once it’s ready. Then comes the kicker: you ask whether each villager would be willing to share a garnish or two, perhaps a carrot, or an onion, or a bit of chicken to make it even tastier. Soon enough everyone has tossed in a little something and there is a scrumptious meal for all (once you remove the stone, which was only a ruse to get things started).
The moral typically drawn from this tale is that sharing benefits everyone. But I think there’s another lesson, namely that the communal soup was actually better than the meal any of the individual villagers would have made themselves, since it included a wider variety of ingredients and ideas—and it took less work for each individual besides.
I apply Stone Soup all the time with my clients to get great results with minimal input from me. Today I’ll describe one of my favourite applications: onboarding.
Training new staff is a continuing headache for my clients; someone has to document every system permission, every build step, every local configuration needed for an engineer, say, to do the basics of his or her work. This knowledge is typically implicit in the team, held in the heads of the original crew who set up the system, and so the documentation is done poorly or not at all, leading to delay in new joiners becoming productive. Or even worse, different team members wind up with inconsistent setups that are brittle and painful to update for months or years into the future.
Instead of a single document written by a knowledgeable person, the Stone Soup method starts with a “stone”, namely a wiki page (or Google Doc or Notion document or whatever) with minimal setup instructions. This typically has multiple gaps and isn’t very clear, and is hardly enough for a full “meal” of configuration, but the crucial bit is the the final item on the page: “It’s your job to update this document to fill gaps and add information you wish you had known”. This is the request for “garnish” which puts the responsibility on the new starter to improve the setup document. As each person learns what is needed to set up successfully (and as the configuration itself inevitably changes and improves over time!) the document gets better and better. And in fact I inevitably find that the result, after only a few iterations, is in fact better than any single expert in the team could have produced, as it’s incorporated the diverse perspectives of multiple joiners.
Stone Soup is a powerful technique for taking advantage of diverse knowledge across a team. I imagine it can be applied with even more sophistication to the problem of onboarding—for instance, what if the result were not only a wiki page, but also a set of build scripts?—but there’s no need to overcomplicate to get the benefits. And the best part is that you don’t have to do the documentation work. What could be better?