Pillars of Support – Part 3: Building Quality

This post is part of our Pillars of Support: A section from our internal SomewhereWarm Manual that describes the function and principles of our Support team.

As we saw in the previous post, our support-driven engineering approach relies on fostering a product mindset among our Support team that allows it to recognize, collect, and share product insights. However, in addition to having an active role in the prioritization phase of every development cycle, our Support Engineers are encouraged to bring the customer perspective to the validation (QA) phase, as well.

Every software engineering team that follows a continuous delivery approach typically validates its work at:

1. The design phase — assuming that the need for building a new feature has been validated already, the next step is to build design prototypes, validate them, and iterate as needed.
2. The development phase — every time a change is committed to a source control repository, the code is tested using a series of automated and manual techniques before it can be marked as production-ready.

Small teams practicing agile engineering principles should immediately see the opportunities that open up here. Support Engineers are naturally eager to take up tasks that give them an opportunity to advocate for customers and help them succeed. We believe that quality assurance work falls into this category.

At SomewhereWarm, our Support team is encouraged to participate in validation tasks, such as:

• commenting on early design prototypes;
• conducting manual acceptance tests;
• collecting feedback from customers on finalized features and fixes;
• learning more about test automation.

To make this possible, we:

1. Make sure that the team is sized in a way that ensures it can always stay on top of the queue, even during peaks. This means everyone has ample time to develop new skills, including those required to take up validation tasks.
2. Encourage knowledge sharing with every opportunity and develop internal training projects for those Support Engineers interested in helping us ship better code.

Some of the positive effects we’ve seen:

• Initial design feedback does not need to involve users, as Support Engineers have a highly developed sense of customer expectations. This is especially true when evaluating design work on previously requested features.
• When validation from users is necessary, our Support team can involve more customers, and more feedback can be relayed to our Product and Engineering teams.
• Issues are uncovered earlier, as our Support team has a strong interest in helping our Engineering team ship bug-free products: A critical bug may require only a few minutes of an Engineer’s time to fix, but will always create extra Support work for hours, or even days.
• Close-knit, cross-pollinating teams: Our Engineers learn to appreciate the work of their Support peers. The role of Support is no longer limited to submitting issue reports and exerting pressure on Engineers to get them fixed — Support is actively helping Engineers ship quality releases.
• A heightened sense of purpose: At SomewhereWarm, Support Engineers get a more holistic view of their role, and feel more empowered knowing that they can contribute not only to building the right things, but also to building them right.