Self-Organizing Teams

​The best architectures, requirements, and designs emerge from self-organizing teams.​

This is one of those 12 Principles that raised doubts in my mind when I first read it. Most of the other principles seem patently valid. This one, though, begs a deeper dive. I'll give you my definitions and you're welcome to point out the flaws:

• Architecture - the structure of the underlying components of a system 
• Requirement - the description of functionality of a system 
• Design - the user's experience of a system 
• Self-Organizing Team - the set of people who decide to build a system

There's another word in this principle that give me the willies: Best. What does it mean to have the "best" architecture, the "best" requirement, or the "best" design? How do you know you have such a thing? How can we know that such a thing even exists?



Well, let's not get too philosophical about things. Just like there probably isn't a single "best" architecture for a system, there likely isn't a single "worst" one either. Give me a bad one and I can make it worse. Some suspect this has already happened. The solution set of possible architectures then is, as near as I can figure, infinite. I suspect the meaning of the term "best" here is not talking about a singular architecture for a particular system, but that for a set of systems, the outputs are among the best.

Let's assume the inverse and see how that goes:

The worst architectures, requirements, and designs emerge from mandated teams.

This, logically, makes some sense assuming that the mandated teams are improperly chosen. If the members of the team are mandated, it implies that they are "forced" to work on a particular system. It doesn't matter what they "want" to work on, they shall work on the specified system as dictated by the authorities. It doesn't matter "who" they want to work with, as that's been decided for them as well. I don't mean to imply that members of a mandated team are completely voiceless, but only that their autonomy is impaired. Having a team which is forced is certain to have some communications issues.

Imaginary Scenario: Alice, the young and ambitious web developer, doesn't like talking to Bob, the database guy. She's certain to avoid writing any optimal SQL queries against the database since that would involve...talking to Bob. Bob gets rubbed the wrong way by Chuck, the UI/UX expert, because of his preference for exotic Japanese candies over a reliable Snickers bar. Bob may avoid talking to Chuck about the most common paths the application takes which means that the database gets slammed because the tables were not properly structured. It's all bad news.

"Of course," you may think, "If the team can't get along then things are going to turn out gloomy." But that's not the point. Just like there is a spectrum of architectures which range from "Best" to "Worst," there are a set of interpersonal dynamics which span from "wonderful" to "terrible." This is clearly the bottom end, but let's not be so pessimistic.

Typical Scenario: Dan, Eve, and Frank are all on the same development team and report to the same manager. Except for Eve's slightly annoying habit to listen in on outside conversations, they all get along pretty well. The solutions that they develop are robust, clean, and effective. The work gets done, everything goes well, and there are no surprises. The customers get functional software, the business moves along, no catastrophes, no firefighting.

What's wrong with that?

Nothing, really. It's fine. No problem here. Move along. Nice weather we're having. *whistle theme to the Andy Griffith Show*

How about these questions instead:

Where's the delight?

Where's the excitement?

While these may be three very capable and competent associates they're not reaching the highest highs. There's a difference between having a group of talented "works well with others" people and a highly collaborative group. It's the difference between an Army Special Forces unit and The A-Team.

What made the A-Team great? No, not just because they were on the run, and not just because they were fictional. These things help, but that doesn't explain the dynamic between them. Their kinship is undeniable, even if they banter quite a lot. The biggest point is that they CHOSE to work together, and they CHOSE who they were going to help. Do you think they would work just as well, have just as much cunning, blow up just as many vehicles if Hannibal was just their commanding officer?

I digress. Let's talk about the trap which organizations ensnare people. Suppose that Dan, Eve, and Frank have another member of their team, Oscar. He's a decent guy and all, but doesn't really "click" with the other three. His performance suffers because he is, for lack of a better term, unhappy. Evals roll out and there are more than a few "development needed" on his sheet. Suppose he wants to go to another team doing something more up his alley with people he genuinely works well with (or at least like). It's going to be hard for his manager to give an honest recommendation, and the evidence for the other manager indicates that Oscar isn't anything special. Oscar's stuck, and will likely bow out once he's had enough. Clearly, this is not "best" for anyone, and I can only venture to guess how often it happens.

If all we expect is acceptable solutions to reasonable problems from decent team members, go ahead and dictate teams. I'd like to think that we can do better​.