Customer experience is pivotal to an application’s success, however, many engineering and developer teams are organized in a way that creates pain points for their end users. The problem stems from Conway’s Law, which is a principle stating that an organization’s design and output mirrors its internal communication structure. Often, its execution creates suboptimal, friction-filled customer experiences that do not truly focus on the customer’s problem. 

The following article will explore the challenges inherent in traditionally organized teams and introduce practical steps to implement a possible alternative.

The challenge with traditionally organized teams 

Traditionally, teams are organized based on a product module, or functional areas, e.g. front end and back end, etc. Per Conway’s Law, the end-result application (or any final product) will reflect these divisions — which can negatively affect customer experience. For example, consider an engineering organization that splits its teams into functional areas, such as UI and server-side teams. Logically it makes sense to divide the workload this way. 

However, this strategy eventually results in customers seeing this split in their day-to-day experience with the software, leading to a disconnected user experience. Customers may end up struggling to get the support they need when things break, such as needing to figure out front-end application versions and back-end systems issues separately. Customers today, who are used to seamless experiences with mobile apps, can become frustrated when they have to bounce between multiple support teams trying to diagnose and resolve the issue at hand. This could easily result in unwanted customer churn. 

Many other traditional organizational design approaches suffer from this issue as well. For example, teams organized by a siloed product definition will end up with customers forced to sort out each product’s UI quirks and internal intricacies, such as where log files are stored. Under most approaches to organizational design, instead of solving a customer’s problem, teams wind up creating new problems for customers to work through.

The alternative: customer-centric organized teams 

To avoid the trappings of organizational division, organizations should consider the problem’s definition to their own advantage. This is often called by different names, such as the “Reverse Conway” or “Inverse Conway Maneuver” approach. What it really refers to is a customer-centric organizational design. Customer-centric approaches turn the problem on its head, intentionally mirroring the organizational structure with the experience that companies want the customers to see. In other words, teams are evolved to mirror the desired reference architecture for customer experience. However, implementing this requires a three-step strategy:

Step 1: Define the end-state and desired customer experience

Adopting a customer-centric organizational design strategy begins with one simple question: what is the desired end-state customer experience (CX) goal? I.e. Define your CX vision. Like most worthwhile investments, it’s time-consuming. Doing it correctly can require some organizations to undergo rigorous customer exploration journeys, ethnographic research or user experience research to understand how customers work or what their specific needs are. 

However, this time and effort is well spent because it brings engineers and developers closer to their customers. Research like this gives software development teams a crystal-clear definition of what they’re building and what its value proposition to customers is. If done correctly, this strategy will align every team member around a specific charter or goal outcome. 

Step 2: Design the organization with clear charters and ownership

When a company has clearly defined their ideal end-state customer experience goal, the next step is to organize the teams centered around the problem domains they’re trying to solve. For example, a company providing intelligent connectivity to help businesses solve automation needs may organize themselves with teams centered around their key value proposition e.g. data readiness, pervasive connectivity, and enabling user engagement. To keep everyone in lock step, each team creates, clarifies, and owns their goals and charter. For example, a team assigned to enabling a seamless user engagement wouldn’t simply be divided by a front end and back end. Instead, they’d work towards a charter of “customer journey,” and will embed all the skills needed to deliver it.

One common issue with this approach however is possible duplication of hard-to-find, niche skills in multiple teams. To avoid this, organizations can set up shared enablement teams, chartered to serve engineering teams responsible for features. For example, shared teams can own UX, Site Reliability automation, Quality Engineer Automation, Developer Operations and Continuous Integration/Continuous Development, and drive “guilds” to socialize learnings. At first, this approach may seem a bit unorthodox, however, customers will notice the difference between bolted-on software pieces vs. software that is deliberately engineered to a singular customer-centric goal. 

Step 3: Communicate (and manage) the change

Implementing a customer-centric organizational change may not only be hard to do, but also difficult to communicate to teams. Successful SaaS teams live and die by their delivery speed, quality, and agility. In a hundred-mile-an-hour environment with many things going on in parallel, the last thing anyone wants to hear is more change. Change can be hard. It can be uncomfortable. However, managing this change is not optional.

Supporting the successful adoption of customer-centric organizational design comes down to one word: accountability. Once teams are set with their charter and roles, the product and engineering managers should be accountable for keeping the team on track. Team check-ins and status updates should be done regularly, focused on tracking how they’ve delivered business value. Use metrics to track product and engineering KPIs holistically, including work categories (e.g. features, tech debt, maintenance etc.), and team agility, with pivoting roadmaps that take into account market shifts or new customer demand. 

In summary, a customer-centric approach provides an optimal way for organizations to deliver on customer value, adapting and leveraging Conway’s law to their advantage. When developer teams are arranged in direct relation to customer experience, they’re essentially directly aligned with their organization’s vision and goals. When thinking about organization with a customer-centric perspective, maybe a “Reverse Conway” approach doesn’t seem backwards at all.