Growing a well-used platform developer surface is exceptionally tricky work. I’ve heard many stories of the team investing months (or years) into building a new set of APIs or protocols, only to encounter at best lackluster interest. To arrive at a more effective outcome, a practice that I’ve seen (and applied myself) is rock tumbler teams.
Rock tumbler teams start using the new stuff before it’s ready. They become the early consumers of a not-yet ready developer surface, providing continuous feedback to the makers of this surface. Ideally, they do this as part of some broader mandate, and have some skin in the game: they aren’t just prototyping and building interesting demos. Their mission is a composite of questing and scaling: they are to both build something useful and to improve the developer surface they consume.
One thing I’ve learned is that it’s important to set these expectations. A few of my attempts to apply this practice ended up in additional suffering because I either didn’t cogently describe the rock tumbler (“here’s what you’re getting into”) or didn’t continue reinforcing it over time (“don’t forget, y’all are rock tumblers”) I remember one TL cornering me in the hallway: “This crap’s not ready! Why are you selling it to me? Not cool.” I may have been overly optimistic describing the benefits of that particular crap and skimmed over the whole “you’re eating unbaked cookies” bit.
Thriving in a rock tumbler team tends to require a mindset of exploration and change. The work will feel painful, with frequent backtracking and changing direction. The leader of such a team typically builds a strong narrative around the value of the composite mission: “we’re eating unbaked cookies so that when they are ready, they are truly amazing.”
A common pitfall that I’ve seen here is the assumption that every team can be a rock tumbler team, possibly stemming from extending the practice of “dogfooding” to developer surfaces. In my experience, this tends to not end well — the additional pain of implicit rock tumbling causes teams to work around the rough edges they find, including choosing to “screw it, we’ll just build our own.”