| Credit to my colleagues B, B, P, and S for the insights below. Herding cats. A pointless task. You get ahold of one cat, and the other 19 run off in their own directions. Before you get any cat where you want it, you’ve got to be chasing the other cats that’re getting away. Even if you have ten or twenty friends helping, it’s just you and your doofus friends tripping over cats. It’s an impossible problem… …unless… …you put each cat in its own bag. That’s the break through! Once each cat is in its own bag (yes yes yes well accoutremented with snacks, toys, and other cat knick knacks), you can focus on each cat one by one, because the others will stay where they need to be in the meantime. You pick up its bag, move it from one place to the next, and you don’t have to be worrying about what they other cats are doing. They’re happy in their bags! When you go to get the other cats, the first cat stays nice in its toy filled happy-bag. Or, if you want to move things along quickly, you can have your friends each take a bag and move the cats simultaneously, in parallel. In fact, if you don’t want all the cats in the same place, it doesn’t matter. Put one cat here, the other cat there. The bag for the cats is the answer to all your cat-herding problems, but how does this matter in practice? Cats in bags is what industry leaders do with two-pizza teams, APIs, and containers and all the other tactics of partitioning big problems into many small, manageable pieces. If you have a team so big that you need twenty pizzas to feed it, then you’ll end up spending so much time coordinating who’s doing what when, how everyone’ll be impacted by what someone else is doing, and how an action here will affect an action there, that you’ll have no time to get anything done. In fact…it better not to get anything done because heaven only knows what the spillover effects will be if anyone actually acts! Big teams? With many and conflicting objectives? You’re herding cats. However…limit your team size to two pizzas, then you’ve pulled way in the size of problems that each team can tackle, you’ve pulled way in the number of people who have to be coordinated across, and you pull way in the amount of human intellect spent trying to coordinate so that same human intellect can be used to do real work. Two pizza teams? Cats in bags. Now, if you’ve got two pizza teams, and you want to free people from having to do all this coordinating, then you need (and will benefit from) having clear boundary conditions about how, about what, and when those adjacent teams communicate and coordinate. (Make sure it’s clear about which cat gets which bag, in other words.) Maintain discipline about those boundaries, and each team can work more or less independently, with only periodic checks that they’re aligned with the system overall (like your cat-bag carrying friends). That’s why APIs become so important. And containerization has a similar ‘modularizing’ effect on the engineered-object, making it way easier for each team to advance its own work without getting overwhelmed with coordinating with all the other teams.  What’s the long and short on this? How we architect the engineering ‘objects’ into which we invest our intellectual energies, determines how effective those investments will be. Like Churchill is to have said, we architect our buildings and then they architect us. We architect our engineered-systems and then they are architecting us. (or, who is really herding whom? Is it us herding the cats or the cats herding us?). Create systems that are all integrated, intertwined, and otherwise not decomposable, you’ve got a cat herding problem. On the other hand, create systems that are modular, nested, and otherwise partitionable, and you’ve created the potential for phenomenal productivity. [For a different metaphorical take on the power of partitioning, see the clock maker example in Carliss Baldwin and Kim Clark’s book, Design Rules.] For more on how to design our systems (both the engineered systems on which we work and the enterprise processes in which we’re embedded) so our intellects are freed to be productive on valuable things, please enjoy Gene Kim and my recent preso, What is Architecture, and Why It Matters – IT Revolution | DevOps Enterprise Summit Europe 2022. How we design systems (both engineered systems on which we focus on collaboration and the systems through which we collaborate) has a HUGE impact on how well we can put our individual and collective talents to good and productive use. |
| Steven Spear DBA MS MS Principal, See to Solve LLC Senior Lecturer, MIT Sloan School of Management Senior Fellow, Institute for Healthcare Improvement Author, The High Velocity Edge |
| Click here for sample chapters from The High Velocity Edge • leadership and crisis recovery (chapters 9 and 10) • accelerating development of break through technologies (chapter 5) |