As part of the build up to the Study of Enterprise Agility Conference (SEACON) in November, I caught up with Matthew Skelton and Manuel Pais, DevOps specialists and authors of Team Topologies, and asked them a few questions.
At SEACON, Matthew and Manuel will be presenting in the morning DevOps track.
Here's what they had to say...
What will you be talking about at SEACON?
We will be sharing some insights into organization dynamics for software delivery based on the work we've done recently and contained in our 2019 book Team Topologies. Many organizations assume that simply adopting a team structure (such as the famous Spotify Model) will solve most or all of their software delivery challenges, but - as you'd expect - this is far from true.
One of the key things we've found working with our clients over the past 10+ years is that most organizations fail to consider crucial dimensions like team interactions, cognitive load, and the effect of Conway's Law. Organizational structure alone will not make software delivery magically work.
You both have referred to Conway’s Law (I.e. Organisations are constrained to produce systems which are copies of their communication structures) a lot over the years. Does this still hold true or are some enterprises able to work beyond these constraints now?
There has been an increasing body of evidence emerge over the past 10, 20 years to support the "mirroring hypothesis" (or "homomorphic force", as Allan Kelly calls it) that Conway's Law articulates.
Studies in aerospace, automotive, and other physical manufacturing industries, as well as with software, show that there is indeed a tendency for the things that we build to reflect the communication structures within organizations. However, instead of seeing this mirroring tendency as a constraint to be overcome, we like to think of this as a guideline for design that helps us to build sustainable, evolvable organizations: "work with the grain" rather than against it.
The work of Ruth Malan has been really influential for us here. It's also worth reading the original 1968 paper from Mel Conway because there are many additional insights to gain. For instance, Conway identifies the current structure as a constraint on the solution search space for organizations; that is, your current org structure is almost certainly limiting the kinds of solutions you can discover. This is of C-level, strategic importance.
Organisation dynamics clearly play an important role in a successful enterprise, but as you point out so do internal team dynamics. How can large organisations encourage a culture or collaboration and co-operation as opposed to internal conflict and competition?
An important way to avoid conflict between teams is to establish both clear boundaries of responsibility (when the interfaces are known) and also clear team interaction modes to help teams work together effectively with the most appropriate behaviours. In the Team Topologies book, we identify three kinds of interaction modes that teams can use to work more effectively as a whole: Collaboration (time-bound working together to discover a new pattern or solution); X-as-a-Service (producing or consuming something with a service-like wrapper, be it a component, documentation, a build tool, or an API); and Facilitating (helping or being helped to increase a capability within a team, detecting poor UX and missing tools). With these well-defined interaction modes, organizations can use problems in team interactions as an organizational sensing mechanism to self-steer towards better solutions.
DevOps as a name is 10 years old this year, the benefits are clear to see yet many organisations (or rather, their leadership) still aren’t completely buying into it. How can these “late to party” organisations be encouraged to get onboard?
Part of what we did with the well-known DevOps Topologies patterns - and what we have done further with Team Topologies - is to provide clear patterns for effective modern software delivery. This has helped many organizations - including Netflix and Condé Nast International - to reconsider their team relationships and organizational assumptions and move forward with a better operating model.
Now that the industry has discovered and documented good patterns for software delivery, we think that laggards can look to these known effective patterns and (with some help) adopt these without having to discover all the anti-patterns themselves.