“We need less handoffs and more handshakes.” – Dionatan Moura.
In February 2022, the search term “Contact the Support team” had over 10,900,000 results on Google. The demand for support has been growing year-over-year since the beginning of Digital Transformations and the Mobile-first movement back in 2010. In spite of the rapid increase of more flexible, change-friendly digital products, many companies have continued to use projects as the vehicle for their development. The result of the project falls squarely in the lap of one area – Support.
Many organizations hand off their newly “done” products to the Support team. Silos are created and so much knowledge is lost during this process. Project teams end up focusing on delivering more outputs, whilst Support teams are forced to create workarounds to fix incidents, and not the root causes of the problems. Project thinking breaks the value stream.
The traditional fix solution for this is the popular KT: Knowledge Transfer. However, you don’t transfer real knowledge, because it is intrinsic for every human knowledge worker. You transfer only data and information. Even worse, it’s pretty hard to transfer tacit knowledge.
The subsequent improvements for users – problem fixes, technical debt or any other kind of issue resolution – won’t happen directly through the delivery team, but via the Support team. Thus, the delivery team will not measure behavioral changes for users, and won’t learn about the outcome changes.
Usually, this siloed issue is not just from the product (or project) development area, but the whole organization structure. According to Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Conway’s Law
That is why there are many companies looking for Business Agility. This means not just optimising locally in the product development area, but every business area. When you work in a silo, every handoff carries a tarrif of at least 50% knowledge waste, according to Mary & Tom Poppendieck in the book “Lean Software Development” (Mary & Tom Poppendieck, 2006). That means every knowledge transfer will cause loss of half data, information, skills, decision making and more. Two handoffs will keep just 25% of knowledge. Three handoffs – 12.5%.
Imagine an alternative scenario: when you have a real issue as a user, instead of someone from Support contacting you, someone from the product team talks with you. This is the most direct line of communication. How different might the outcome be? Your problem being solved in an innovative way by an engineer could solve a similar challenge for thousands of other users. This also has a snowball effect of preventing these other users calling the Support team.
Pattern: You build it, you own the outcome
The central idea here is to have a product development team, not just a delivery team. We can have Support people working together with developers to maintain the product, and everyone feels increased ownership of the product. This also creates the impact of learning from Support metrics – solving the root cause of user problems – thereby improving the product.
Since the 1990’s, eXtreme Programming from the world of Agile talks about the collective ownership practice. That is not just for the code or the solution, but for the whole product or service:
“Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottleneck for changes.” Source: Don Wells, 1999.
That has evolved to the well-known DevOps culture nowadays, shifting product developers right to watch and care about Operations metrics too. UX and Agile Testing worlds invite us to shift left, bringing developers greater understanding of user needs and built-in quality at every step of the process. Three-Stream learning invites us to do something in addition to this: the product team should also monitor user and business outcomes through effective and actionable metrics. They are owners of the product and the outcomes.
One final point: we have observed that this approach has led to development teams being more intrinsically motivated, with a greater sense of autonomy, mastery and purpose. These are the three key components of intrinsic motivation outlined in “Drive” by Daniel Pink. They will better understand why they are doing their job. This will lead to increased productivity and commitment to deliver the best possible outcomes for the user.
The Third Stream Book 