Modern software engineering techniques within organisations deliver “distributed features” using agile techniques. These features are distributed across different systems and integrated to provide an end-to-end experience. Traditional project delivery brings in members from different system oriented teams to deliver these features in a loose and ad-hoc fashion and dis-bands the team after a project is closed
Oriented to long-standing teams with a product focus has been shown to be more successful in delivering features which stand the test of time as software is able to evolve, maintained and optimised for new customer needs to differentiate the business from others
In this post we talk about Conway’s law as it applies to software engineering and how bringing teams together into cross-functional long standing product teams provides long term value. This act of realising product vs project orientation and building multi-system team to build software is called an inverse (reverse) Conway manoeuvre
Conway’s Law
Melvin Conway described a law where he states that the parts of a software system are directly proportional to the organisational structure
Layered Architecture Style
We can think of the modern teams oriented around the customer and end-systems to deliver integrated products in the following manner (circa 2020)
Thus, broadly speaking, teams orient around technical layers due to the cohesiveness of the “technical domain” expertise & customer’s (software client) needs.
If you have been part of similar teams in the past you must be familiar with the “layered architectural style” that gives rise to this team
Technical Teams = Technical Product
While the layered teams do a great job of grouping the teams by technical expertise, business needs for new end-to-end features are contextual, especially in a large enterprise. Things are more contextual in the real-world
While the layered team structure may work initially for one context, we find adding new features and domain contexts makes it harder to maintain software components across a layer. This leads to slower software delivery due to various reasons
It is becomes increasing difficult for a single team to know and own aspects of a technical layer used in various contexts
Conway’s law: With layered teams, we build layered software components focussed on the technical correctness vs end-to-end functionality
Techno-functional Teams = Functional Products
Applying the “reverse Conway manoeuvre” – fixing our team organisation to shape our software we break the technical teams into smaller functional teams. This process naturally builds a more “Domain Centric Product team” which can focus on functional needs and stay true to the end-to-end feature
This organisation allows for a closer relationship across technology layers as we group experts in different technical domains to deliver a common outcome and if done well, allows a smallish technical team to own a contextual solution
Pitfalls of Functional Teams
Functional teams are not the perfect solution. Functional teams are highly agile and can own a specific end-to-end solutions through the entire software lifecycle but they operate in their own bubble
When organisations have different “technical practices” within their IT with different software engineering standards (one for the Portal team, one for the Integration team, one for the CRM team etc) it becomes harder to enforce technical standards within a technical context when a member is “outsourced” to another team
Conclusion
Modern software engineering is oriented towards building networked distributed features for a highly connected and web savvy customer base in varying contexts. Traditional team structures within the enterprise have evolved from technical SME cliques as engineers who “Ate lunch together wrote Software together”
Good product strategy requires thinking about breaking up the technical groups into highly effective functional teams and keeping the “band together” through the lifecycle of the software (the end-to-end product)
Alok Mishra 