Sergio Caredda
Organisation Design is Architecture Design might be a bold title. The sentence is not mine and is a quote by Allan Kelly, a technology consultant expert in Agile. It captures a longtime belief I have consolidated over the past few years, about the innate necessity of collaboration and co-design between people- and technology experts. The cover image of this post shows how failures can happen.
The Failure of Understanding Organisation Design
As I was writing the review of Team Topologies by Matthew Skelton and Manuel Pais, I found myself furiously writing about three pages of content that did not match, in reality, a book review. So here it is as a separate article. As I already wrote in the review, this book crystallizes the failure of Organisation Design as a discipline that HR should master. The authors ask themselves, “How much awareness does the HR department have about software systems?” Then argue that “we need to involve technical people in organization design because they understand key software design concepts. “
A significant logical connection, even more, marks the failure.
More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology – they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.Allan Kelly, Return to Conway’s Law (2006)
I think this could be seen from another perspective as well. At its highest abstraction level, an Enterprise Architecture (which an Architect should be responsible for) should be fully aligned to an organisation’s Operating Model. Which means that we should be able to turn the above quote upside down.
More than ever, I believe that someone who claims to be an HR leader needs both social and technical skills, they need to understand the technology and work within the architectural framework of the organisation. They also need a remit that is broader than pure people management.
HR and IT: Twins Separated at Birth
The above leads to a firm belief that I have been having for some time now. HR and IT as physically distinguished functions in an organisation should not be separated, at least in their organisation design sphere. Think about the definition that Skelton and Pais choose to use for the organisation:
we assume that an organization is a sociotechnical system or ecosystem that is shaped by the interaction of individuals and the teams within it; in other words, that an organization is the interaction between people and technology.Matthew Skelton and Manuel Pais, Team Topologies
How can you really design an organisation if one silo is responsible for “people” and the other for “technology” only?
If you see it solely from a technology perspective, you will notice that “significant and unnecessary technical compromises in a software system will be introduced as a result of politics, misaligned incentives, or poor communication” (Tune, 2019). Suppose, instead, you see it from the people’s perspective. In that case, you will notice unnecessary rigidity and process flows that dictate organisational set-ups, an element that often happens with back-office system implementations.
The hindering effects of the above are under the eye of everyone. If we exclude M&A, the most extensive projects impacting organisations in the last thirty years have been large ERP systems implementations. These projects were often run under the guidance of technology, with “Business Owners” that lacked the vision to build modern architectures. They were mainly focused on implementing vendor-led “best-practices” of process efficiency. The word “SAP” in most organisations is a synonym of unbearable bureaucracy.
The issues that Skelton and Pais mention about the risks that monolithic technologies play from a technology perspective in software development are the same that they play from an organisation effectiveness set. Functions developed their monolithic systems, affirming, even more, their silos orientation. Which then aligns with anti-patterns that undermine organisational sustainability, like the Accountability Protection Buffer mentioned by Tune (2019).
The Role of Conway’s Law
The more I kept reading the so-called “Conway’s Law” (Conway, 1968) that the two authors take as a driving force to be managed through organisation design, the more I fear this law applies to the entire organisational outputs. Not just software.
organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.Mel Conway, How Do Committees Invent, 1968
After all, the concept of “systems” can be intended pretty broadly. Without altering even a comma of this sentence, we can easily see it applied to a lot of other domains than the pure technology one:
- Customer Service: in many organisation mirrors not a customer-centric view of the firm, but instead its internal organisational model. Depending on the channel you brought the product, you will need to access different departments. Sometimes, the only element that holds the pieces together is a piece of technology used to route requests.
- Products: how often did you buy a product, simply to discover that you could recognise the “patterns” of the firm behind it? Cars are a perfect example of this. For ages, many traditional cars-makers would carry visible signs of their internal organisation in the design of their models—the most visible signs of which where different quality levels applied to various components of the car.
- Brands: how often did a brand failed to portray the value pushed by marketing initiatives because of internal issues which made it to the press? This is also an example of “inconsistencies” created by internal fragmentations.
- Accidents: in the second issue of the Intentional Organisation Newsletter, I have given a short analysis of the Boeing737Max findings from the US commission that analysed the facts. It’s impressive how this accident reflects the organisation’s priorities, the profit over safety culture that developed internally. It is also great learning that Organisation Design goes beyond the formal organisation model and involves all the elements we have identified in the Organisation Evolution Framework.
I’m sure you can come up also with more examples. If you would like to share, please do so in the comment section.
The Mirroring Effect
Mel Conway’s law is not much about being an actual law more to be a force that Kevlin Henney named Homomorphism (Hvatum and Kelly, 2006). Taken from Algebra, this law substantially looks at how a system replicates the structure-preserving map of another system out of which it is based. A concept that in business research is often linked to the idea of mirroring (Colfer and Baldwin, 2016). Below a passage that reinforces my view:
There is a tendency among management scholars to view technical dependencies as facts of nature and organizational ties as targets of design. There is a symmetric tendency among engineers and product developers to view the technical system as malleable while organizational ties are fixed by precedent, routines, and decisions made higher up the chain. In fact, both technical dependencies and organizational ties can be changed albeit at some cost.Furthermore, a competitive market economy will reward those combinations of technical architecture and organizational structure that deliver the greatest value at the least cost.
L. J. Colfer and C. Y. Baldwin, The Mirroring Hypothesis (Colfer and Baldwin, 2016)
Mirroring can be used positively as a way to implement change and transformation. If we define what we want to achieve (for example, an ideal customer experience), we can then mirror its effect within the organisation. This uses the idea that is often called Reverse Conway’s Law, whereby you take the result you want to obtain and organise accordingly.
However, we should move beyond the narrow view that thinks solely of the resulting software because the mirroring effect affects any company type. Again, this calls for better integration between technological and organisational design capabilities, as they, together, deliver the firm. We need to Align Architecture and Organisation (Buschmann, Henney and Schmidt, 2007, page 154) not in a way that one comes on top of the other, but as a continuous intentional design process.
As such, we need to break the forces like homomorphism, which act as reproduction machines (thus copying errors indefinitely) and radically rethink how organisation design and architecture design happens.
Let the Twins Rejoin
Organization design is system design.Allan Kelly, Conway’s Law & Organizational Change, Pipeline Conference, London 2014
If the above is true beyond software development, what are the consequences? First of all, with the current acceleration of digitalisation every company is becoming a software company. The impact of the way we architect our technology organisation will impact the way we deliver as an organisation.
This means we need to bring together our organisation design capabilities and enterprise architecture competences under one roof. Let them talk together. Act together. They both have the same challenges in terms of business understanding. And they both need to be put on a path of proper intentional design.
We need to integrate People and Technology in an Operating Model that makes sense holistically. The four-team models identified by Skelton and Pais become a great canvas to build the entire organisation, because precisely the needs that are highlighted there are the same at every level of the organisation, not just software development. Plus, elements like platforms are becoming more ubiquitous, as an element of organisation design, beyond technology.
A Conversation Effort
The biggest problem to overcome is aligning people in the two fields on a common language. Both have followed a typically siloed pattern of developing specialist words that the only appeal to the few initiated. Yet often, the terms are the same, calling to a common root and origin. Nevertheless, the fact that technologists often disregard humanists as “softies” (but the opposite holds real as well), is the biggest obstacle to start a healing process that is crucial to building the Intentional Organisation.
Why am I mentioning this? Because technology, too often, is seen as the limiting factor in our designs, instead of the enabling element it truly is. It is a domain where intentional action can have genuinely relevant ripple effects, mostly thanks to the sheer investment envelops it attracts. Digital Transformation, with its implicit necessity of organisational changes, can become the attractor of a new wave of intentional design, whereby HR and IT, formerly separated, can lead toward a more humane system.
To do so we need to bring back the sense of meaningful conversations into our organisations. We need to dismantle the artificial barriers between STEM roles and “humanistic” ones. Make Intentional Design a priority for everyone and a joint effort together. As such, the old HR and IT organisations, dismantled from the shape of siloes, could become the real engine of corporate reinvention.
The seeds are there. Agile, Lean, and consistent parts of Design Thinking are practices that technologists have used to help become faster and safer in reaching the customers’ needs. It is time to mirror these effects also internally, to ensure we build a faster and safer organisation, recognising hindering patterns.
What do you think of this article? Share your comments below.
Comments and Feedbacks
References
Buschmann, F., Henney, K. and Schmidt, D.C. (2007). Pattern-Oriented Software Architecture, Volume 5, On Patterns and Pattern Languages [electronic resource]. Wiley.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stai, M. (2013). Pattern-Oriented Software Architecture, Volume 1, A System of Patterns. 2nd Edition ed. John Wiley & Sons.
Colfer, L.J. and Baldwin, C.Y. (2016). The mirroring hypothesis: theory, evidence, and exceptions. Industrial and Corporate Change, [online] 25(5), pp.709–738. doi:https://doi.org/10.1093/icc/dtw027.
Conway, M.E. (1968). How Do Committees Invent? Datamation. [online] Apr. Available at: http://www.melconway.com/research/committees.html [Accessed 20 Sep. 2020].
Hvatum, L. and Kelly, A. (2006). What Do I Think about Conway’s Law now? - Conclusions of a EuroPLoP 2005 Focus Group. [online] EuroPLoP. Available at: http://www.allankelly.net/patterns/ConwaysLawFocusGroup.pdf [Accessed 20 Sep. 2020].
Kelly, A. (2006). Return to Conway’s Law. [online] Allan Kelly Associates. Available at: https://www.allankellyassociates.co.uk/archives/1169/return-to-conways-law/ [Accessed 20 Sep. 2020].
Skelton, M. and Pais, M. (2019). Team topologies : organizing business and technology teams for fast flow. Portland, Oregon: It Revolution.
Tune, N. (2019). Organisational Dysfunctions Mirrored as Architectural Complexity. [online] Medium. Available at: https://medium.com/nick-tune-tech-strategy-blog/organisational-dysfunctions-mirrored-as-architectural-complexity-b5a903b3f5b2 [Accessed 20 Sep. 2020].
More posts like this
