Opportunity at the Interface Part 4 - Conway’s Law and the T-Model
Let’s start today with a couple of customer experience anecdotes:
Appliances: This is a story from a reader of this newsletter. A brand new, brand name oven only really controls center of oven temperature and a 66°C(120°F) difference in temperature between racks!! Any baking or roasting enthusiast can tell you this is going to be a problem. The root cause of the problem was faulty insulation. When contacted the manufacturer indicated this is not a problem, and the user should just recalibrate the oven to run a little hotter in the middle.
Automotive: This one is mine where there was a vary badly engineered wiper mechanism on a car I own. I like the brand and thought I would give some feedback to the dealership and was met with a condescending response along the lines of “We are much smarter than you. You just need to use this in blah blah blah overcomplicated way”. Feedback going nowhere. Not going to buy this brand again.
I can’t help but wonder in both of these cases how much the interfaces the people inside these organization experience influences how they treat their customers. Do these people interacting directly with customers have a mushroom like interface…fed manure and kept in the dark? Do they have a job description or an employment agreement? What is the organization’s leaders worldview of customers? What playbook are they running and are they actually good enough at the secondary playbooks?
With that as a starting point that we will turn to two topics I want to look at from the world of programming, oldies but goodies:
Conway’s Law
T model of development
Conway’s law is well known in the technology / software world but not as much in the wider world:
“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.
https://www.melconway.com/Home/Committees_Paper.html
Conway’s formulation is from his 1968 piece entitled “How Do Committees Invent”. The thrust of the article is about how the structure of a design team is organized pre-determines or limits the range of outcomes possible for the output from the team. The simple fact that there is a team involved means there are interfaces, and likely delegation. The larger the team, the more momentum there is and the more difficult it will become to change directions.
Conway actually directly mentions interface in his article:
“The term interface, which is becoming popular among systems people, refers to the inter-subsystem communication path or branch represented by a line in Fig. 1.”
Conway also describes this world of man made organizational interfaces as complex. I’m a bit on the fence about this characterization. Certainly it is complicated. The structures can be mapped and a lot of outcomes are probably predictable. Complicated seems like a better term to describe it even though the humans that compose the nodes in the system are individually complex. A distinction that can be made between the complex and the complicated is that complex systems have a level of unpredictability not seen in complicated systems. Making changes to complex systems is a more fraught endeavour with uncertain results. This is an important distinction for leaders to recognize: when intervening in complex systems more caution is advisable including an incremental, reversible approach. Radical irreversible changes to complex systems can be disastrous. Think of the introduction (or simply evaluating the risk of) of invasive species into the environment. Humility is needed to recognize when we are dealing with complexity and not just complicated. Humility and caution and maybe more than a little paranoia. Since we in the land of technology let’s invoke the tech legend Grove: “only the paranoid survive”.
A couple more gems from Conway’s piece(my emphasis):
“It is an article of faith among experienced system designers that given any system design, someone someday will find a better one to do the same job. In other words, it is misleading and incorrect to speak of the design for a specific job, unless this is understood in the context of space, time, knowledge, and technology. The humility which this belief should impose on system designers is the only appropriate posture for those who read history or consult their memories.”
“To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces. The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon.”
I like the idea implicit in the above that interfaces and communication structures should be made to be flexible and suit the context: the customer, the project, the local culture, and any number of human and other environmental factors. Decentralizing authority to the maximum extent reasonable is a must.
I’d like to reframe Conway’s law into a leadership context as follows:
“The outputs from an organization, including its dysfunctions, are bound to reflect the interface framework of its leaders.”
On to the T-model: This is an idea I was introduced to about 20ish years ago in a copy of an employee handbook from Valve Corporation (the creators of the game Half-Life), who put it into practice developing their people. The basic idea is that people need breadth as well as depth in their development to be effective in a team based multi-disciplinary environment. A key to putting this into practice is the creation and nurturing of a knowledge sharing and learning culture. This starts with leading by example being excited to learn something new, especially from people that you are leading. After action exercises (what went well and would change feedback from the team) is always an opportunity for a leader to learn from their team and show respect.
So in the two anecdotes at the start, I doubt the people interacting with customers are being developed in a T-model, and I’ll bet their communication and interface structures have a direct influence on the way they successfully alienated their customers. I’ll bet their feedback on how to improve their own organizations goes precisely nowhere.
Grounded Service Cover Art
People who worked closely with me will have heard the analogy that I incorporated into the cover art for “Grounded Service” of the organization as a tree, with those people interacting with customers at the periphery of the organization as leaves, the customer as the sun, and the leaders and managers in the organization being the branches and trunk in the tree whose key functions are to support, nourish and help grow the thin new growth and leaves of the tree. It is not a perfect analogy, but the people in touch with customers directly understand just how important they are, and they are the future. This analogy also manifests in an inverted org-chart with the servant leaders appearing at the bottom of the chart.
So, closing out today, what is your conception of how you interface with the people you are leading? How is this conception impacting the design and delivery of your products or services? The experience of your people? Your customers? The willingness of your people to actually listen to the customer feedback and either take action directly or stimulate action within the organization?
I’m not done chewing on this bone yet, and next time I’m going to dive into the intersection of identity, interfaces and AI.
With gratitude for your readership and thoughts,
Nik