building doghouses

This is a delightful new-to-me conceptual label for a particular kind of experimental-proof-of-concept-team-execution-construction-project: build a doghouse. Thanks go to @SarahAMcManus for the metaphor.

The primary goal is not to possess a doghouse - your goal is to learn how your team works together in building something. If your goal is to build something the size of a skyscraper together, your best bet is to build something the fractional size of a doghouse, learn and tune your design-and-build process, and then try something a bit larger. Evaluate the skills that your people are bringing, how that lines up to the needs of the doghouse project if it were scaled up. Working your way up to the skyscraper with iterative depth of skill requirements gives you a much better chance to succeed in the end than trying to learn how to build a skyscraper directly by building one right away. "Build one to throw away" can work as a cheap spike, but how many skyscrapers can you afford?

Secondarily, you do have a doghouse afterwards, which is a real thing that gathers feedback from the world in some way - it's not just a simulation. Agile methodology trainings often contain a simulation exercise of working-process iteration: Tossing balls around a circle, building a tower out of spaghetti strands and marshmallows, putting together lego widgets - you simulate a sprint in 2-10 minutes, then you retrospect and try it again a few times, trying to iterate your way to competitive success. This simulation can serve as concept introduction with a side dish of team bonding, but it is of zero real-world benefit to have a spaghetti tower. Even more importantly, you can tell yourself whatever story you like about "we did a good job" and reality doesn't care enough to smack you if you're lying to yourself. "Feedback from the world" could look like $1 in revenue, feedback surveys, clickthrough rate, anything that comes from not-your-team.

Doghouse building, perhaps even a series of doghouses, is doubly-relevant in a risky uncharted space where no one knows if a skyscraper-sized thing can possibly be built, or what the right thing to build would even be. The team that's going to discover what's possible is itself a system that needs to be built. This is a Gall's Law approach to system evolution, which fits right in with Lean Startup and Cynefin and complex system design principles. If you care too much about the experimental thing you're building, it's not a doghouse - you need to be able to focus on the team dynamics and execution. If your team is clicking, then you can start building things you care more about. If you just try to do both at the same time, the object-level thing will probably win out over the one-level-up team learnings, so don't let (ahem) the tail wag the dog there.

There's a funny triple-relevance here for me, considering how fractal and meta (codename) "intentional society" is: The way-of-being of the group working together really is the fundamental product of the group, out of which all other achievements flow. This makes the previous paragraph about separation-of-concerns pretty hard. What kind of thing will turn out to be a good doghouse? I don't quite know, even in theory - and I wouldn't want to lock in on a plan now because the fit of any prospective doghouse depends upon the composition and skills of the team that's coming together to build.