Andrew Smelser, Author at Engineering Blog

8 Simple Tips for better Communication with Customer-Facing Teams

March 27, 2019March 28, 2019

Businesses often maintain documentation as part of their product. You might be thinking of help center articles, hover text, and little anthropomorphic paper clips. But, the end user is not the only one who benefits from guidance around a product’s intended use. Customer-facing teams, like sales and customer support, also need thorough product communications.

Enabling customer-facing teams to support and sell your offerings is part of delivering a high-quality product. Development teams should be cognizant of the needs of customer-facing teams in the same way that they are the needs of their end user. In this post, I share 8 tips for communicating with customer-facing teams.

1. Real-time isn’t always best

Engineers being available for questions from customer-facing teams is a well-intentioned practice. Generally, this practice is healthy for the organization too. Yet, communication channels that enable this real-time support come with pitfalls.

If your company operates in several offices or timezones communicating in real-time may be difficult. Remote employees commonly receiving subpar communications.

It is hard for development teams to track work they are doing supporting customer-facing teams in real-time too. Not being able to track this work can make planning difficult.

Real-time communications are rarely indexed or searchable. This means you will need to do a bit of digging when you want to reference old information later. Anyone not involved in the original correspondence will struggle to find that information. You are unlikely to get any answers from an email you don’t know about, or one in someone else’s inbox!

Because of their different responsibilities, engineers and customer-facing teams also have a different context. It is often hard to know what someone else knows. It is difficult to know what information would help someone without a sense for what challenges they face.

Real-time channels are still a valuable part of communicating with customer-facing teams. Pairing real-time conversation with written documentation and maintaining FAQs is a nice mix!

2. You need to translate some communications

If your team works in more than one language, translating communications is critical. Beyond that, these communications should always leverage language that promotes shared understanding.

Reusing documentation for many stakeholders is practical. Keep in mind that customer-facing teams may not be familiar with the same jargon. Those teams also have different areas of concern. Documentation that a development team prepares for product and engineering is unlikely to be as helpful for the sales team.

Write documentation in a way that serves more than one stakeholder. If that doesn’t make sense, create more than one document. Preparing communications explicitly for customer-facing teams enables them to support your user better. This is more work up front. Yet, in the long run, this may even reduce the time and cost of cross-functional communication.

3. Good content is useless if nobody can find it

Teams should use a mix of documentation and communication strategies. For coworkers who are working with a live user, searchable information is critical. Utilizing existing searchable tools for communication is great, but devs can think bigger! Consider building tooling that aggregates and indexes internal comms. Painstakingly crafted documentation has little value without good visibility.

4. The Agile Manifesto doesn’t suggest you stop writing documentation

“Working software over comprehensive documentation” is one of the core values of Agile. Some believe it prescribes prioritizing development work at the cost of documentation. This is a misinterpretation. Teams should create documentation that adds value and doesn’t hinder progress. The Agile value actually supports thinking of communication as a product! Instead of “comprehensive documentation”, try considering communication as part of building “working software.”

5. Demos, demos, demos

Eventbrite surveyed our customer-facing employees, and this tip comes straight from the data. Recorded demos are a valuable part of our communication strategy. The issue at Eventbrite wasn’t creating demos, but making sure we distribute them. We mostly shared our demos with product and engineering. We now know that those same demos can help empower our customer-facing teams. When you create informative content, think beyond the obvious stakeholders.

I also want to call out that you should record demos whenever possible. Live demos are valuable, but recording and distributing them can broaden their visibility. This is critical to serving customer-facing teams in other timezones and locals.

6. Slide out of the DMs

This tip is one of my favorites because you can apply it at a personal level without having to get your team on board. Discuss your product’s functionality or expected behavior public channels. This is especially valuable for teams that use tools that make conversations searchable. Set clear expectations for what information is not ready for your customer. Then, have non-sensitive conversations where customer-facing can access them.

7. Consider the impact on peer support channels

Customer-facing teams are resourceful. These teams create spaces to ask their peers for help. These channels are very useful when trying to improve visibility for your communication. These forums are also a perfect place to learn what questions need answering. I recommend checking-in from time to time! Use these channels to help build out FAQs.

8. Audit your processes

I would be remiss to not also share a more general tip for healthy business communication. Approach conversations with empathy and try to understand the other party’s perspective. Discuss and measure the success of your communications. Ask customer-facing folks what is working for them and where they need more support. Keep looking for opportunities to improve your communications as you do your product. Consider adding a mechanism for soliciting, recording, and leveraging feedback.

Now What?

Good cross-functional communication is often an amalgam of communication channels and strategies. The communication improvement initiative with the greatest impact will vary between organizations. What strategies have worked best for you when sharing information with customer-facing teams? Please add a comment with your insight, or reach out to me on Twitter to continue the conversation!

Rethinking quality and the engineers who protect it

November 5, 2018October 29, 2018

Testing software is an important responsibility, but testing is not a synonym for quality. At Eventbrite, we are trying to dig deeper into quality and what it means to be a QA Engineer. This article is not just for QA engineers, it is for anyone who wants to better understand how to deliver higher quality products and better utilize QA resources. If you don’t have QA resources, by the end of this article you will have a better idea of what to ask for when you look to add a QA Engineer to your team.

Rethinking the role

When I sat down to write an updated job description for our QA Engineering position, I started my research by looking at job listings from similar companies. Most of the listings agreed on one thing: QA Engineers test. The specifics vary, but the posting would always include a range of automated and manual testing tasks.

While these testing tasks are worth doing, testing software doesn’t ensure that the output is a high quality product. In practice, effective QA extends well beyond testing. QA Engineers should ensure teams develop products that work and address a targeted customer need.

The iron triangle

Being a strong advocate for quality requires understanding what could cause quality to suffer. I’d like to start this post by introducing the concept of “The Iron Triangle” The triangle is a visualization sometimes used to describe the constraints of a project, but it also works as a model for the challenges of maintaining quality.

The idea here is that we constrain the quality of a project by its scope, deadline, and budget (among other factors). Changes to one of these constraints then require balancing adjustments to the others, or quality suffers.

External quality

The team can’t control all of these constraints, but it is critical that they monitor them. These constraints directly impact the quality of work. This sort of quality is external because it is quality as understood by the customer.

Some scenarios

A project has a broad scope. The timeline for the project is likely full of feature work, with limited time left for testing tasks. Intervention can mean working to carve out time to write and perform tests, advocating for a reduction in scope, or developing a testing approach that is lean without sacrificing too much coverage.
A project has a tight budget. This type of project is likely to have even less time to spend on quality. In these cases, my preference is to establish clear goals and expectations with stakeholders for quality in the planning step. This process enables the team to pack their limited QA time with more precise and targeted testing tasks without misrepresenting how hardened our code may be when we finish the work.
A project has an open timeline. This is less common but has its own challenges to quality. When we give plenty of time to projects, they naturally move more slowly. In these situations, it is essential to test along the way, because the closing days of this project can be hectic. I like to limit final testing before release as much as possible with incremental tasks and plenty of automated testing. That way, I can protect the development team from last-minute changes, complexity, and most major bugs.

External quality is linked directly to the success of the business and is everyone’s responsibility. All arms of the business are responsible for maintaining external quality and delivering functional products.

Beyond bugs

I loosely consider an issue a bug any time the software produces an incorrect or unexpected result or behaves in unintended ways. Bugs are going to happen, and minimizing their occurrence is why we test software. However, external quality can only cover so far as we understand how the product will be used. You cannot write a test to cover a use case you don’t understand or know about

If something works as expected but fails to meet the user’s need, this is still an issue of quality. However, this is not a bug. The QA team should bring knowledge of the product and the user to the entire development process. If QA is involved in the planning phase, and the testing phase of development, they can help with more than just finding bugs. They can help ensure developers more thoroughly understand how users employ the products they are building.

Internal quality

That said, there is also an internal, procedural component to quality. Writing code and building products in a way that minimizes technical debt and mitigates risk maintains internal quality. Being good at managing external quality does not make an organization good at managing internal quality.

A new scenario

The development team is wrapping up a project and is ready to execute their test plan. Through testing, they uncover some bugs and edge cases that they didn’t think of when writing requirements for the project. To fix these issues, they need to add cyclomatic complexity. This could reduce internal quality and has downstream effects on external quality too. This issue could have been curtailed by involving QA in the writing of product requirements, or by being more deliberate when considering edge cases and architecting the feature.

Balancing external and internal quality

Good external quality is not an indication of good internal quality. Since QA Engineers are driving external quality, they need to be cognizant of increased complexity as an output of testing. Testing uncovers more than bugs, it also uncovers where the product we are building may be failing to meet user needs. Addressing these gaps is critical to quality, but can have a significant impact on timeline, budget, and scope. Our compromises are likely to produce technical debt

Technical debt

Technical debt should be a conscious compromise. The development team can give up some internal quality to make the project work within other constraints. Future work to pay off that technical debt often competes for the same development time as work done to fix a bug, and both issues concern overall quality. This can be a confusing number of plates to keep spinning at once. We should neglect neither type of quality work for the other, and understanding their relation to one another is crucial to preserving high overall quality.

One final scenario

The business asks for a feature with very narrow scope, a small budget, and a tight deadline. The feature will require new development work on an old, neglected part of the codebase. The development team is worried about losing time to cleaning up technical debt around their integration points and bringing the old code in line with new standards and practices. Testing time for the new feature work is already tight, and the business wants the development team to prioritize keeping the existing feature set healthy. The team needs to make certain compromises to meet their target release date. One of those compromises is balancing investment in internal quality against the external quality of this new feature and the old code.

Protecting quality

While it is critical to be understanding and compromise during development, QA Engineers should remain biased toward quality. The organization has managers charged with protecting budget, scope, and deadlines – but quality should have an advocate too. QA Engineers should spend time encouraging and coaching development teams on bugs and testing tasks, but the real goal should be to encourage those teams to take ownership of quality.

When the user-need and gravity of testing is well-communicated and well-understood by developers, they write higher quality code. Developers that understand their users write better tests that leverage user stories, rather than the developer’s expectation for what their code does. Beyond testing functionality, they are making sure that what they have developed aligns with how the product is addressing targeted need.

Engaged developers make the best testers

To be clear, I am advocating that developers do their testing and own their quality. Outsourcing your testing to automation engineers or manual testers is an option, but comes with drawbacks. Developers bring vital skills for driving quality into the product at speed. Engineers are also uniquely positioned to solve problems with their code, and developers that write their tests are more vested in fixing them when they fail.

The QA team can and should assist with this process. They can help developers deliver higher quality products by making sure the project is testable upfront, and making sure the approach to testing is thorough and considerate of other constraints to development. Beyond just saying that “quality should be high”, the team should set expectations for quality within the context of other constraints. These expectations serve two purposes. Foremost, they helps with estimation. If you fail to consider QA tasks during estimation, then you have not made time for quality. Secondly, it binds quality to the development process, fostering ownership within the team. Teams that take ownership of their work are more invested in delivering higher quality products.

The new job description

QA Engineers should protect overall quality. They should work with teams to find the right balance of testing for each unique project. To do this, a good QA Engineer understands quality in the context of other constraints to development and is willing to compromise, but will never allow the business to concede quality. When a business delivers low-quality products, it fails.

What strategies do your teams use to assure quality? How do you leverage your QA team beyond testing? Tell us about it in the comments and drop me a line on Twitter @aqualityhuman.