My dear friend Alex Komoroske did a podcast episode recently on all of my favorite topics. I highly recommend watching it and studying the excellent deck that the majority of the discussion rotated around. I also wanted to riff on the builder and gardener archetypes that were featured in the title of the article.
Briefly, the distinction emphasizes the difference in mindsets with which we approach unsolvable problems. As builders, we view them as ultimately solvable, and so our actions usually yield building something that solves the problem. Unfortunately, as the problem is unsolvable, the thing that we end up building is solving a problem that is different from the one in front of us. In rare cases we are lucky: the difference is small enough and we get to reap some benefits from the solutions. More often, we now have a solution that still needs to find a problem that fits it.
In my experience, the latter outcome is pervasive around ecosystem work, aka “platforms”. Since ecosystems adapt to our actions, changing them to behave in accordance with our intentions is indeed an unsolvable problem. So when a team charges forth with the idea of building a platform from scratch, my response is usually a skeptical eye roll or a wince: I detect the “builder” mindset and all that falls out of it.
The mindset Alex suggests as an alternative is that of a gardener. Just like builders, gardeners have blueprints. They have an idea of some state that they want the garden to eventually reach. The key difference is that they accept that they are working with a living matter. Living matter has a mind of its own and is likely to surprise us. The blueprints will need to be redrawn and mental models adjusted frequently. In many cases, gardeners never reach what they’ve drawn in the initial sketch. They know it and hold them lightly, and it’s the only feasible approach. Holding firmly to the original blueprints is a path to eventual madness.
For technologists, the shift from “building” to “growing” is a bit hard to perform. There are two common traps that I am familiar with. The first one is what I call “garden-builders”. Here, even after armed with the gardening metaphors and ideas, we still imagine how we’ll grow perfectly cylindrical carrots and spherical potatoes. We may talk the talk, but underneath, the builder mindset is still present. Projects run this way will have words like “ecosystems” and “platforms” and maybe even “emergent” and “complexity” plastered all over them, but the manifested outcomes reveal the story of rigid construction.
The second trap is “garden-workers”. This one plagues teams that swung way too hard into the idea of working with the living matter and abandoned the intention behind it. Garden-working is still an engineer’s escape. Assuming that gardening is just about waking up very early, weeding, watering, and tilling the dirt is comfortingly similar to the common activity of continuous refactoring that many teams in mature stages undertake. The blueprints are mostly forgotten in the soothing practices of daily work. Projects run this way will ship incoherent bags of features that even they themselves can’t cogently describe. If you hear a presenter say “we can’t wait to find out what you’ll build with these APIs” to the audience of developers, chances are the team shipping this API is stuck in the “garden-worker” trap.
If I am being brutally honest, I don’t actually know if it is possible to achieve the full zen of the gardener mindset. Based on what I’ve seen, a platform team is usually either completely unaware of this mindset or is caught undulating between the two traps. Last release: “OMG, we shipped was a bunch of random stuff, let’s organize this better!” … next release: “Crap! We shipped things that nobody needs again, let’s get back to gardening, folks!” And that might be okay. Here’s my hope. By making these traps legible, I can help you, my reader, to learn how to work with them and countervail their effects.
One thought on “Builder and Gardener Mindsets”