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

Although Cloudspace works mostly with startups (which are small almost by definition), this principle is worth commenting on as a general rule. As startups grow in size, this rule becomes increasingly relevant.

The people who make the best decisions are the ones who are closest to the causes and effects of that decision. If you're a part of a team, working in the thick of it, you'll make a better decision than someone removed from the situation. You can see this principle applied in our rule that we have engineers estimating work -- they're closest to the code so they make better decisions on how long it will take to change things. This also applies to product changes -- community managers can help make informed decisions because they are close to the users who are experiencing pain points.

Believing in this principle implies that if you're not on the team designing a system or a process, you should avoid imposing rules or demands whenever possible. You have to sell people on your ideas, and convince them that what you're proposing is good. If you can't convince them, then you need to consider that you might have been wrong, or change the way you're explaining it.

An example of this is at Apple. Apple's OS is composed of a number of components, each built by a separate team. The OS project managers don't dictate any project-wide processes. From version control to code standards to testing -- there are no externally imposed rules on teams. As long as they deliver good results, they can work in any manner they want. If a project manager wants a team to change their process, it's up to them to convince the teams one at a time. They don't impose mandates because mandates don't work.

This principle isn't to say that teams can't take any input from the outside -- obviously external forces (like the client and users) shape the direction of the project. They provide the broad strokes, and the team fills in the details. Strategy vs Execution.

The point is to focus on the true requirements, not how they are done. It's helpful to think about things in terms of "I don't care as long as SIMPLE_OUTCOME_HERE". For example, one of our requirements is that the process for deploying/redeploying be quickly reproducible. This usually means automated deployments, runbooks, and notes. But, the teams are able to use whatever solution that fits the projects needs. Usually these are the same across many of our projects, but there are exceptions, and self-organizing teams handle them well. In this case, I don't care as long as code can get pushed to the server quickly and reliably.

This ties back into the issue of trust. Communication makes sure that the teams organize correctly, but there has to be trust, and the confidence of understanding that there are many ways to solve the same problem.

There's a quote from General Patton that I like. Patton was a man whose ability to get results from a team speaks for itself. He said "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity."