Conway’s Law is the observation that technical systems and products reflect the organizational structures that designed and developed them. This is an antipattern — something that often happens without teams realizing it. That’s why the Inverse-Conway-Maneuver can be useful: instead of systems and products reflecting the structures that developed them, organizations are shaped by the design of the products and systems they build for customers. Doing so can improve organizational efficiency and ultimately improve the quality of the end product.
We applied the Inverse-Conway-Maneuver (ICM) as a catalyst for a transformation initiative with a client — an international business — that helped to reshape their approach to reshape product development. In this piece we’ll explain how we approached the overarching goal to increase products’ speed-to-market by bringing business and tech closer together and offer some guidance on how you can avoid some of the sandtraps of structuring, incentivising and supporting customer-centric, cross-functional, fast-moving development teams.
A marketing organization with around 150 software developers asked to migrate products and services to a viable technical platform eventually improving time-to-market speed. After a big and expensive transformation project failed, our client observed that development speed is decreasing over time. They found themselves locked-in a vicious cycle of lacking innovative power as well as increasing technical debt (link to podcast) which meant constantly slowing down in time-to-market. They were, soon about to run into serious problems with keeping up with the pace of customer expectations, business goals and competition.
What started with the hypothesis that their private cloud and consequently their software delivery teams are bottlenecks for their business, quickly evolved to revisiting and re-shaping the product delivery as a whole incl. organizational design and operating model.
Challenges in digital products are everyone’s concern
If you’re facing constant challenges in product development — interdependent teams, problems coordinating, repeated escalation, slow pace and high feature costs — it’s critical to widen your horizon to all parts of the organization. You need to resist selection bias where software development is assumed to be the primary time and cost driver. Instead, embrace a nothing’s off the table mindset; focussing transformation efforts solely on IT may lead you to neglect making substantial and long-lasting improvements by bringing everyone involved in value creation closer together.
Choose a holistic approach and prevent opportunity costs
It’s important that you don’t attempt to fix digital product challenges in isolation. Just implementing a new agile process approach or technological refit are unlikely to be effective. A broken structure can’t be fixed by new processes or tools; sometimes it can create a vicious cycle of compromises that will lead to proliferating complexity). Consequently, opportunity costs (“debt”) build up. This further decreases time to market and your ability to innovate.
The solution can be found in the prism of people, customer value, enterprise architecture and technology. This is a socio-technical view that proves more effective in organization development than departmental siloed approaches. Such approaches can lead to Conway’s Law — products and systems become imprinted with the quirks and idiosyncrasies of the structures that developed them.
To solve this problem, though, we can call on the so-called “Inverse-Conway-Maneuver” (ICM). By structuring an organization in the right way, you can help teams reduce hand-offs and interfaces, and decouple themselves from a system and delivery process. Nevertheless, it’s important to note that tuning organizations for speed needs to be executed in phases with a pragmatic and human-centered approach. You need to learn and shift while driving.
Transformation needs courage, endurance and an outside-in view
There are two main prerequisites for a successful transformation project:
- For both management and delivery teams, there needs to not only be openness to learn, change and evolve the organization, ways of working also need to be established. A sense of urgency has to be agreed upon and maintained. Often this is facilitated by market pressure and not having been able to successfully implement projects over a longer period.The earlier these signals are detected, the easier it is to minimize accidental complexity. In turn, this makes it easier to initiate the Inverse Conway Maneuver.
- Secondly, as with any service design project on the scale of an ICM, cognitive biases will affect judgements. This is a particularly pointed issue when complexity requires people to process and analyze a lot of information. External support is crucial to navigate ambiguity and uncover and mend systematic errors.
Patterns for successful Inverse-Conway-Maneuvers
When implementing the Inverse-Conway-Maneuver, check your initiative against these success patterns. We found them to be particularly important.
- Dedicate time to arrive at a shared change mindset and common language
- Analyze where existing structures are hindering fast value creation
- Set up a transparent product ownership cascade from goals to backlogs
- Approach change carefully with a pilot to learn where your particular pain points are and decide collectively to either pivot or persevere
- Be strategic and data-driven about where and how to scale to other value creation areas
- Focus on areas where time to market is critical — and always put the customer front and center
1. Common mindset & language
Often, the ICM is the first time business and IT teams will have worked together (see “Cross-functional Teams”) to build something new. This makes the first step incredibly important. Communicating a shared vision and language helps establish the foundations of the ICM implementation.. A team of influential, knowledgeable people with a shared understanding for the reason and urgency of the effort must be established to own the vision and outcome of the change. Often, organizations face the dilemma of creating such a safe space — in an innovation hub or a program — and find they aren’t able to transfer it to the broader operational structure. So defining sponsors, both outside of business and technology areas, and bringing together team members from all customer value creating parts of the organization is key. They need to be able to learn and act as organizational influencers.
2. Structures allowing for the freedom to create value fast
a. Are you running LEAN?
Together with the above-mentioned team, analyze the product areas you want to accelerate and remove “departmental blinders” that may be slowing things down. One way of doing this is to pull all necessary capacities together in a “Product Team”. A benefit of this is that the resulting team will intrinsically tend towards de-coupling itself and system architectures, ultimately reducing hand-offs and optimizing the interfaces required for product development and maintenance.
b. Are you optimized for COGNITIVE LOAD?
Let product teams focus on what they do best and provide them with X-as-a-Service offerings via platform or “internal” product teams (independent service heuristics). Ask whether reasonable heuristics are being used and if the resulting platforms are being driven by dedicated teams. Tools such as event storming, service blueprints and value stream analysis can help you identify shared potential.
c. Can you measure IMPROVEMENT?
Start building for business value and measure how the new structure and operation model works. Set up a measurement framework for both business metrics — like time-to-market or HEART metrics — and operational metrics such as the DORA.
3. Transparent direction & clear product ownership
A product transformation initiative needs clear goals, progress measurement and ownership. We recommend using a Lean Value Tree to portray goals, bets, hypotheses and measures of success. Next, define how the high-level strategy will be broken down in teams’ backlog items; this will make value for money easily visible to all stakeholders.
Equally important clearly defined ownership. If product definitions and boundaries are fuzzy and ownership distributed, make sure you draw lines of responsibilities. New roles and organizational “components” outside the current organizational structure — like an empowered product owner or distinct product teams — might be needed. Create role descriptions collaboratively so pilot product teams are aware of the scope of their work and stakeholder expectations. It can be useful to create an organizational glossary, which provides clear definitions of your operating model. Keeping an open decision-log will also make it easier for people to understand why things have been done in the way they have been.
4. Experimentation in a safe space
As you implement the ICM, your teams will enter a new product-centered structure; remember, though, that this is still a hypothesis and subject to change. It can be useful to set up a “safe space program” to build, measure, learn and adapt. Create organization-wide awareness that the ICM is a change process at core, but ensure you’re delivering tangible business value early on, so that expectations and urgency do not pile up.
You will know you're ready when new insights have been distilled from structure analysis, value domain modeling, service blueprints, roadmaps and backlog break downs. This will provide you with a foundation to distill any modernization hypotheses and cluster them along prioritization criteria such as value-add, feasibility, cost of delays, learnings involved and skills needed. The most promising product requirement will be the first small value increment delivered in the new pilot structure.
All complex endeavors involve experimentation and subsequent failure. This is why repetition is needed to ensure you reach the best possible outcome. Start small with one product domain and one to three pioneer teams to deliver and establish some initial organizational learnings.
5. Intentional growth
Your observations should be used as indicators to help you decide how fast to expand the transformation initiative to other product domains. Do you still face fundamental challenges in the pilot area? Are your metrics developing in the right direction? Can you release a pilot team into business-as-usual-mode?
Make a conscious decision about how much parallel change is feasible in your current context. Often, due to expert dependencies in organizations with between 200-500 developers, a running change initiative in one product domain is already a stretch. Respective teams should be prepared for the “new normal” in such a manner that you can remove the change support scaffolding in other areas. Remember to prioritize product domains for which you expect increased speed for development; you’re not going to transform the whole organization so don’t worry about trying!
6. Make it about customer value
Last but not least, while the nature of the ICM is to look inward, you need to be customer-centric at every step. If you’re not, you may well set the teams up for delivering something which doesn’t solve the customers’ problems. This principle is important for both end-customer-facing and internal product teams. Ultimately, your goal has to be to design an organization optimized for autonomy, flow and collaboration, so you compete in the innovation race for the best solutions for customers’ problems.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.