What if we thought of management as an objective rather than a group of people?
Management includes the activities of setting the strategy of an organization and coordinating the efforts of its employees… (source wikipedia).
Mel Conway observed the phenomenon we know as Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
If you want to change your architecture, you’re going to have change your people structure. Your communication structure will eat your architectural aspirations for breakfast.
If you want Flow and to de-risk your work, you tend to gravitate towards cross-functional teams. When developers have to wait days for responses from Design or Product, that’s days of lead time you’re adding to your customers’ perception of your business. Raise your hand if you’ve seen a “6-week” project take a year and a half and not deliver even a quarter of what was promised. ✋
When there is an objective to be met, what we’ve learned is to form a team that contains the necessary skills to complete the job, soup to nuts.
Yet, we disregard this when it comes to management.
Those involved in management are typically strictly the ones who carry the HR responsibility of direct reports, and this is certainly a critical aspect of “coordinating the efforts of [the organization’s] employees”. But if a system is bound to mirror the organization’s communication structure, then there is a tight interplay between the people and the technology. Indeed, they cannot be separated.
Atomizing the management function into a separate team of single-function experts will produce the same results as atomizing the technical aspects of building a software product (e.g. Design, Development, Security, Operations, UX): batching/queueing; core, chronic conflict; misunderstanding; and degradation of quality.
The best cross-functional teams embrace the notion of T-shaped persons: each person with a deep expertise but also at least conversant in the expertise of the other members of the team. Developers are not oblivious to testing, and testers are capable of writing code, even if they’re not personally John Carmack.
When a team trying to accomplish an objective is missing key skills at the moment decisions are made, whether it’s managing the development efforts or developing the product itself, the team is forced back into after-the-fact inspection and review. And as Deming observed:
Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.” (Out of the Crisis, p. 29)
The management objective needs to bring together those specialized in a broad view of people (the role typically named “manager”) as well as those specialized in a broad view of technology systems (the role typically named “architect”), each bringing cross-training in the other acting as partners towards the same objective.
This is probably even more important at inflection points when the cost of delay and miscommunication is highest.
