I spend quite a bit of time thinking about how teams build software. Specifically, I'm sensitive to the coordination costs of communication across a team as it scales.
In teams of 2-7, communication can be dispersed naturally through osmosis. The number of connections in a small circle still works with ad-hoc personal discussions. Understanding permeates the group to establish enough of a shared understanding of current operations and future vision.
As teams and organizations grow beyond 10, the coordination costs of communication increase significantly. Often, teams cannot sustain the high quality of shared understanding, and due to the increase coordination costs, group understanding suffers.
Changing the structure of communication can reduce coordination costs. Rather than relying on direct point to point communication, building knowledge in a centralized location is the way to leverage the most knowledge for all employees. (In general, I defer to all the potential benefits of a wiki here).
In the diagram below, I sketched out my thoughts on some of the major things a software product team handles on a regular basis. The process of building software is worthy of introspection and adjustment as much as writing code or designing the details of a user experience. I always have my eye toward reducing the distance between thought (intention) and the product (application). Engineering is an evolving art form, but the interface between Ideas and Product remains.
Illustrated
