It is a crucial insight for many organizations that technical systems and products reflect the organizational structures that designed and developed them. This is an antipattern called Conway’s Law — something that happens without teams realizing it. To set up teams for success again, an Inverse-Conway-Maneuver (ICM) can be useful: Instead of systems and products reflecting the structures that developed them, organizations are shaped by the design of the products they build for customers. This improves products’ time-to-market and quality through a dedicated focus on value creation.
We applied this strategy to set up and started a transformation initiative with an international business to reshape their product development. In this piece we’ll explain how we approached the goal to increase products’ time-to-market by bringing business and tech closer together. Our goal is to offer guidance on how to avoid sandtraps of structuring, incentivising and supporting customer-centric, cross-functional, fast-moving teams.
Client story
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 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 digital 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 a selection bias where IT 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 creates 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 is to 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 capability-based, functional break-down approaches. Such approaches can lead to the dark side of 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 “Inverse-Conway-Maneuver”. By structuring an organization product-oriented, you reduce hand-offs and interfaces by decoupling teams from a system and delivery process point of view. Nevertheless, it’s important to note that tuning organizations for speed needs to be executed in phases with a pragmatic and human-centered approach. The organization and its people 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, an effective organization change management also needs 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 quickly. External support is crucial to navigate ambiguity, uncover and mend systematic errors.
Patterns for successful initiatives
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 attitude and common language
- Analyze where existing structures are hindering fast value creation - that’s for sure not for all products
- Set up a transparent product ownership cascade from goals to backlogs for the products in scope
- 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 product areas
- Focus on areas where time to market is critical — and always put the customer front and center
1. Common mindset and language
Often, the ICM is the first time business and IT teams will work together (see “Cross-functional Teams”) to build something new. This makes the first step incredibly important. Communicating a shared vision and language through assets like a common product portfolio 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 customer 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 and 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 is 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” — 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 initial organization 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.
Stay customer-centric
You are perfectly organized to create the behaviors you are currently experiencing. Hence, remember to take a holistic approach to time-to-market challenges in your organization. Use the power of the Inverse-Conway-Maneuver and center the change around the most strategically important products. Make use of an external perspective to prevent locked-in and challenge-reinforcing thinking. Create a common language between representatives from business and IT through a simplified product portfolio viewpoint and start to model product domains solving similar customer problems. Select a domain for a safe experimentation space, launch a set of teams with dedicated capacities working on the most pressing product challenges in this domain to get yourself out of the mess quickly — and leave your competition behind using fast, iterative, customer-centric learning cycles.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
