Is your team structure hurting your customer experience?

Austin Turner
Delivering Software
3 min readAug 3, 2017

Many software teams adopt cross-functional team structures. I thought we had structured our teams well, but then we discovered a big problem.

What used to happen

As we have gone on our product development journey, we have seen fantastic improvements where different people with different skills and experience work together collaboratively on a product. For example, designers and developers building interfaces together, analysts and QA engineers working together before code is even written.

However we were following what we considered a more popular, functional team approach for customer support, because how else would you do it? While we think this “Support Team” allows efficiency and coverage improvements, unfortunately it lead to a significant disconnect between the people designing, building and delivering software from the customers who are asking questions, experiencing issues and ultimately are the only reason we do what we do.

Support engineers were the team members who were by far the most intimately connected to the overall experience of our customers. Having meetings and chatting in #support wasn’t providing our teams sufficient understanding their customer’s experience.

What we do now

To improve the ability of teams to not just build, but support and run their products, we asked our support engineers to move desks and join a product team full time. In this structure, the team has shared responsibility for ensuring customers have a great experience and derive value from the products that they build. It also ensures the team has the resources and skills to do so. Everyone was asked to work with their new team member/s to identify and deliver deep, ongoing improvements in the experience of our users and to cover for them when they were absent or over loaded.

Having done this, we are starting to understand that we must design and engineer support and guidance into the applications, rather than relying on others to place band-aids on the product in the form of help documents, training courses and template answers to support calls.

While doing this, we also surfaced the problem that there were more products than there were delivery teams, this meant some products had very little chance of receiving sufficient maintenance as it was only really owned by support. Ultimately each maintained product will now be assigned to a delivery team to own and manage, always trying to have a team focus on a particular user group. This will help to avoid orphaned products and allow teams to manage their product life-cycle and upgrade support for the users they understand most deeply.

We will continue to have functional support and guidance through our line management structure, mentoring and guild/ chapter meetings that allow people doing similar work to learn from others and advance in their chosen craft. Our support manager will continue to lead the measurement, design and implementation of an improved customer experience.

Build it, run it and own the customer experience.

--

--

Austin Turner
Delivering Software

Software product and technology leader, occaisonal woodworker and gardener