Over the years, as part of the consulting team at InCycle, I have seen many large organizations struggling to find the best organizational structure for their development teams. I came to this conclusion about the ultimate organizational structure:
There is none!
The world is not linear
The first point to consider is that development teams usually lives in a multi-dimensional world with many axis defining it, such as:
- Technology Stack: ASP.Net, SQL, JAVA, SharePoint, Legacy Systems,…
- Functional discipline: Developer, Tester, Architect, Project Manager,…
- Business area: Accounting, Sales & marketing, any specific domain really.
There is often a belief that the organizational structure will take care of all management requirements, It won’t. It will take care of one axis and the two others need to be managed by other complementary mechanisms.
If an organization bases its structure on one of the dimensions and leaves the others unmanaged, eventually one of these unmanaged axis will become problematic. Different teams coding the same thing on different projects; different teams using different tools and practices; stakeholders having to re-explain the same basic business context and requirements to multiple teams are all symptoms of unmanaged axis. It is not rare for organization to “re-org” along a problematic axis and quickly go back to neglecting the other two, keeping the re-organization yo-yo going in full swing.
So, when we make org. structure decisions, we need to keep in mind that a given mechanism will only manage one of the dimensions directly. We need to introduce additional mechanisms to manage the other aspects. Like in many other aspects of software development, there is no silver bullet solutions, only a combination of trade-offs that one needs to weigh to come to a solution that works for them. Organizational structure is just one management mechanism among others.
For example, Agile teams are organized by business area. That axis is very well covered. The team is generally multi-disciplinary and more or less all the requirements for one or many products that the team handles are put together in a backlog making managing prioritization, value delivery and communication with the business work very well. It will not, however, manage the technology and functional axis for you. How do you ensure that the practice and tools between team 3 and 8 are common where they should be? How do you make sure that the technologies selected by each project will interact well?
Introducing roles that worry about architecture and user experience standards across teams as well as dev support and DevOps roles will complement the first axis to provide a full organizational answer. Architecture groups, manned by people coming in and out of the various teams, centers of excellence, methodology/practice/tools support groups are other types of complementary mechanisms to consider implementing with your basic structure.
This concept is important and actually drove the addition of an organizational structure review step in BluePrint our change management framework for ALM adoption. You can get more info about it here.
