GUEST VIEW by Rajesh Raheja

Rajesh Raheja is SVP and Head of Engineering at Boomi.

Customer experience is pivotal to an application ’ s success; however, many engineering 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.

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 Thesuccessfuladoptionof areas, s teams. uch as UI Logically and serve it makes r-side sense customer-centricorganiza- to divide the However, workload this way. this strategy eventutionaldesigncomesdownto ally results in customers seeing oneword:accountability. this split in rience with their the day-to-day expesoftware, leading to a disconnected user experience. 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.

To avoid the trappings of organizational division, organizations should consider the problem ’ s definition to their own advantage. What it really refers to is a customer-centric organizational design that turns the problem on its head, intentionally mirroring the organizational structure with the experience that companies want the customers to see. However, implementing this requires a three-step strategy:

tomer experience. 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.

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. A team assigned to enabling a seamless user engagement, for instance, 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.

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. 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. z