Allison Pickens' Newsletter
Allison Pickens' Podcast
Need Engineering Help for Your Support Team? Here's How to Get It.
0:00
-30:40

Need Engineering Help for Your Support Team? Here's How to Get It.

A conversation with Simon Rohrbach at Plain

Historically, customer-facing teams treasured every moment they could get with their engineering counterparts — because those moments were rare. Engineers were focused on building the core product, and any other initiative could be considered a distraction. Support teams in particular were often frustrated because they felt that Engineering wasn’t spending enough time fixing bugs, gathering customer feedback, and giving visibility into product changes. Getting Engineering’s help in building internal tools was so far from the realm of possibility that it wasn’t even on the agenda.

But today, Engineering teams are spending more time supporting Support teams. And there is a strong movement behind that.

In this post, I sat down with Simon Rohrbach, the CEO and Co-Founder at Plain — which is live on ProductHunt today and just announced their seed round from Connect Ventures and Index Ventures (and me!). Simon explains what best-in-class collaboration between Support and Engineering looks like. We discussed:

  • Why are engineers now more open to helping their colleagues in Support?

  • How can Support teams motivate Engineering teams to prioritize their projects?

  • How can CEOs encourage collaboration between the two functions?

You can listen to the podcast or else read the lightly edited transcript of the conversation below. Let's dive in!

To learn from more top CEOs about scaling your company, subscribe (for free!) here:

Leadership Roles

Here are a few leadership roles at companies that I’m excited about.

Transcript

Allison: Simon, I'm so excited to have you on the podcast today. Thank you for joining.

Simon: Thank you very much for having me. Pleasure.

A: We are here today to talk about support teams and engineering teams, and specifically how they can work more effectively together. I know there are folks of all disciplines who read this newsletter or listen to the podcast. Given my own focus on customer success historically, I imagine there are a lot of support leaders who will be reading this, and probably a lot of them are very curious to know how they can leverage their engineering teams more effectively to get great tooling for their team. I know you have a lot of perspectives on that. I'm excited to dive in.

S: Totally. Let's do it.

A: All right. I want to talk about the customer support world more broadly to start. In the support tooling world, there's been a lot of automation over the past decade. There have been multiple generations of support SaaS products, perhaps starting with Zendesk, then more recently, there were chatbots and agent assistant tools. How would you describe the phases of support tooling over time? What pain points do you think have already been solved, and what pain points do you think are still unsolved?

S: For a while you had customer support powered by these very traditional expensive systems that typically required consultancies to help you implement. That was a very expensive, very slow and often archaic process. The speed of iteration would often be measured in quarters or years, with new releases and new implementations.

Then, as you said, you have the SaaS generation of products, where everything moved to the cloud. In particular, the problem of communications in support is already fairly well understood and fairly well solved. You have amazing communications infrastructure in the space. There's companies like, for example, Twilio, who do great job letting me do phone calls or handling SMS messages for you. In addition, chat is very well established as a channel.

The problems that people are still trying to figure out how to solve is context and data. You’ll see these problems mentioned in any survey of customer service teams or any study that gets done on the space. Who are these customers who are contacting me? How do I know they are who they say they are? Who are they in my systems? They might be using a different email to get in touch with you as the email that you have in your system. What did they do right before getting in touch with us? What did they do in our products? What led them to make this query with us? Who did they talk to before? What was the interaction like at that point? What problem did we help them with? Who helped them with that problem?

All this context on what the customer's done, who they are, and how we might now be able to best help them — I think that’s still incredibly difficult to solve for. Because everything has moved online, companies have actually become more complex technologically rather than less complex, and data has gone to more places rather than fewer places. It's about pulling together all that data into one place, and when someone's calling you up or when someone emails you, giving you this single view where you can see, "Hey, what's happened with this customer?" That remains a very, very hard as a problem to solve.

A: How did you become interested in solving that problem and related ones?

S: As for my background, I'm a designer, and my co-founder, Matt, is a designer-turned-engineer. We met at Deliveroo where I joined as one of the very early employees, when the company was around 10 people. I saw it grow to around 2000 by the time that I left. We worked together at that point and bonded over a shared obsession and love for internal tooling and operational effectiveness.

I think design and engineering are often underapplied on the supply side of a company, not on the demand side. Demand generation is very visible. A lot of people want to work on that. A lot of people want to work on the publicly-facing product or the customer-facing app or the website. It's a very well-understood thing, whereas the thing that's actually a lot less visible is the internal side of the company, what goes on behind the scenes, how do people get work done? We felt that if you are able to take something that typically takes five clicks, and you're able to turn it into one click, you've actually created a massive lever for the company. And it actually doesn't take very much. It takes a bit of engineering, but most of all, it takes it a culture around that sort of stuff to really make sure it happens.

We realized that optimizing the supply side of your company was a design and engineering problem, because your internally built systems have to speak with your customer services team, where you help people. These two things have to talk to one another. There’s a huge potential for engineering innovation where those two worlds meet.

Plus, I'm Swiss, so efficiency is in my DNA.

A: I know that there's a certain philosophy that you bring to solving this problem, which is focused on how engineering and support should work together. From my perspective, I know a lot of support teams historically have seen themselves as customers of engineering teams and often are frustratingly begging for help. I think over time engineering teams have really stepped up, so it's been interesting seeing that evolve, but probably most people believe that the collaboration is not quite there yet. I'd love to hear your perspective on how that collaboration should evolve.

S: Yeah. Broadly speaking, what's led me to really deeply believe in that collaboration is that things that previously were considered on the edges of engineering have become core areas of value creation. If you think back 10, 20 years, typically the most basic tasks today like running a server, deploying a website, building a website — all these things would consume a lot of time and attention. Over the last decade or so, all this infrastructure has become so much more advanced, and all these things actually now are very, very simple. These massive levers have enabled engineering teams to move to areas that previously were not considered core. Then can now create a lot of value where the infrastructure doesn't exist yet. What's causing this shift on the engineering side is that other problems have already been solved.

At the same time, companies now see it as a brand level differentiator to invest in operations. Nowadays engineering and support teams can have that shared view of what really matters to the company overall.

As you said, often in the past, the operational side of the business would say, "I really need help from engineering” and then struggle to get it. Engineering would say, "Well this is really hard to work on. There's not a lot of infrastructure here. The tooling is really poor, it's just very low leverage for us to actually spend time on this."

As a result, what tends to happen is you have this shadow IT world emerge on the operational side of the business. They're basically left to their own devices and end up doing a lot of hacks and Zapier integrations until those just doesn't scale anymore.

That's typically when those two sides meet and have to find a way to work together. That’s the key inflection point when the partnership starts to emerge. But they do it under a lot of pressure, because at that point the company is trying to scale, and the operational side can’t grow linearly as the company grows.

A: I’m thinking about ways to facilitate the development of that partnership. Do you think that there's a certain percentage of engineering hours that should be dedicated to supporting support teams?

S: I don't necessarily see it as a certain percentage of engineering hours. I think what’s more important is cultural change. Companies usually celebrate things that are very visible, especially on the product and engineering side. There’s an availability bias: "Oh, we've shipped this thing on the app, and it's live on the app store today, and it's super exciting. We can tell all our friends about it." The things that don't get as much exposure and don't get celebrated as much is stuff like, this person shipped a thing that saved their colleagues in operations several hours a day.

We need to celebrate examples of having real impact on the organization. These operational improvements compound in a powerful way. We should have shared alignment on, "This stuff is important and here's how we measure it." We should share, “This operational improvement has saved us many hours."

A: Would you consider you and your company to be a part of the internal tooling movement?

S: For sure. I think internal tooling has this moment right now where so many people are talking about it, which I think is fantastic. There are so many tools emerging that make it easier for engineers to build great products — less code and less hassle.

These developments are fantastic. But we believe in designing internal tools to solve workflow problems, not just data input problems, which is how a lot of existing tools see the issue.

A: What do you think are the deficiencies in the category of internal tools that have existed for a few years now for support teams?

S: Many internal tools look at individual use cases separately and make it easier to build products to address them. But the problem in customer service tends to be a very end-to-end problem.

Literally, it starts the moment someone calls you up, and you need to figure out who they are, verify that they are who they say they are, and then establish what the problem is, figure out which tool to use for that, find the right data for it, etc.

Plug-in’s that you can add on top of the platform that you already have will only get you so far. They’ll never address the underlying disconnect that often happens between your own systems and the customer service tool you’re using.

A: Diving in a bit more into these best practices, I'm wondering are there certain ways in which you think support teams and engineering teams should interact? For example, are there certain meetings they should have on the calendar, certain Slack channels, certain other types of regular touch points?

S: I'd say there's two or three things that I've seen work really well. The first is alignment on the metrics. There's a lot of metrics every customer's support team will track. There's also a lot of metrics any product team or engineering team that's working on retention or working on company effectiveness or whatever you might call it will track. It's very, very important that those are the same.

Otherwise, you can have situations where an engineering team might work on something and say, "That was really successful; we made a massive improvement," and their counterpart in operations might show up and say, "Actually, that doesn't solve the problem at all.”

The second best practice is what I would call local autonomy. I think it's one thing for a VP of engineering and the VP of operations or customer service to agree on what matters. It's a different thing for junior team members to get aligned. Have an engineer or designer sit next to someone in customer service and say, "Show me what you do, and let me take a few calls myself.” It builds empathy. The moment someone on the product side has gone through it themselves and seen the pain firsthand, it becomes a lot easier for them to say, “The solution's very simple. We can fix it very quickly. It will take me half-an-hour."

The third best practice is when engineering and product do some data gathering about what’s happening for their customer service team. Typically, when the product doesn't do something, it tends to be customer service that hears about it first. When you have an engineering and customer service advisor pair up and solve problems together, you create a feedback loop about what customers are experiencing. What do customers call in about? What do they complain about? What issues do they have?

Companies spend all this time and love on their core product, polishing every single pixel of it. But when people have a bad experience with the product, if you're not investing in the tooling that people encounter when they contact customer service, they'll end up having an even worse experience. That's actually when it matters the most. You have the opportunity to retain someone or lose them.

A: I've seen a few companies adopt provocative measures to ensure that engineering teams develop that kind of empathy for support. One is that, in addition to having engineers shadow support people, they actually have newly hired engineers join the support team for the first few weeks that they're on the job. I've also seen, particularly in earlier stage companies, support teams report into the product and engineering org. What do you think about those measures? Under what circumstances do you think they would make sense?

S: One of the best examples that I've seen of that kind of pairing is engineers, product managers, and designers spending the first couple of weeks on the job, as you say, helping customers. Firstly, because they’ll see the source of truth of what's actually happening: How well is a actually product doing? Are people happy with it?

There's no better way of onboarding new hires than to do that. It can be intimidating, it can be a bit scary, there can be a bit of organizational resistance. You can also start with small wins, like pairing people up on a Friday afternoon and doing it very informally.

Another really effective thing that I've seen is to make it something where it becomes almost like a social activity for the company. Every other Friday or once a month, you have a ritual where you say, "On Fridays, we all solve a couple of tickets together," or, "We all jump into this together and everyone helps out across the whole company." When I was at Deliveroo, one of the best things that I saw really moved to needle in terms of company-wide empathy for what we were doing was people going out on bikes themselves during Friday lunch times and delivering orders. It was one of the best things that I think we were able to do for company culture. Making sure everyone had a deep understanding of the real world that underlies the slide decks, reports and analytics dashboards.

In addition, make the data that you collect in customer service and operations really easy to access, almost having it as a heartbeat to the organization. Every morning at 9am, show everyone the key metrics that you track — on Slack or an email that’s sent to you, not a pdf or a link you have to click, but literally right there in your inbox, easy for everyone to see.

A: Great ideas. Do you have any other tips for companies that are looking to motivate their best engineers to work on solving problems for support teams?

S: Celebrate it very visibly. No amount of saying "This really matters" can compare with saying, "It was awesome how you took the initiative on helping that team," or publicly saying, “This person went above and beyond to help that team help their colleagues in customer service and as a result saved them X, Y, Z hours," or "Helped improve CSAT.”

If you don't celebrate and recognize those wins, then nothing else really matters. It has to be a cultural thing that you embed at that level. Otherwise, engineers feel a bit second-class to their colleagues who are working on externally-facing stuff, because that's what gets typically all the attention. You have to counterbalance that. Make it a cultural expectation.

A: As our last topic, I would love to talk about company values. I know you and your co-founder spent a lot of time thinking about your values. Can you talk about how you approached the decision about which values to select? And why it was so important to you to dedicate time to this?

S: Values are very frequently abused. Often people get hit over the head with them in performance reviews. It can be very, very toxic. Values can be misinterpreted very easily. The worst scenario is if they don't mean anything, if they're so generic that it's just what any decent human being would do. For example, if honesty is one of your values, it's a bit like, "Well, if you've hired the right people then hopefully, you don't have to state that." Values can become meaningless and performative.

I firmly believe that values should guide your decisions. You should be able to say as a founder choosing between A and B: "Choosing B over A helps us move closer to that thing that we really care about as a company." This can make decisions very, very easy.

So my cofounder Matt and I said, “Let's make sure the first thing that we do is write down our values, because they will guide everything else that happens afterwards: who we hire, how we decide things, how we build the product."

As example, we wrote down our desire to stay small. This is not often heard in startup land, but we said, "We want to build an intentionally and proudly small team." Small means relative to the size of the market, the vision, and the ambition that we have. I wanted to build a small company with an outsized impact.

This enforces good rigor. It forces you to really think through every single hire and go, "Is this the right hire? Does this person bring what we need?" That's a value that we've come back to every single time we've had to make any decision about growing the team.

We've even made a lot of our technology choices by asking ourselves, "Will these technology enable us to stay small, to keep a small team? Will it enable us stay effective?"

Another value that has guided everything we've done is, we want to build a business, not utopia. Many companies oftentimes will have a very noble ambition to change the world. But that can give you an excuse to ignore what's actually happening in your company right now. The reality might be, "We're unprofitable, we need to make money, nothing else matters if we don't do that. If we don't exist, then everything else is just for nothing."

So for us, that guides everything. We need to be a business. Everything that we do should lead towards that. This mindset has changed how we feel about things, how we’ve made decisions day-to-day, and who we hire. This is why you pick values on day one, because they change how you build a company. I'd highly recommend doing this before anything else, if you're thinking of starting a company.

A: Simon, I think we now have the subject of our next conversation, which we will have to publish on this Substack, all about company values. I'm regretting having left this topic for the end. So much of what you said was super powerful. I love the idea of focusing your values on the things that make you distinctive and that are not obvious, because it should be taken for granted, for example, that people should be good people and respect each other and do the basic things that a lot of values tend to point to, and therefore, the values tend to become meaningless. Often as you said, they're used as the tip of a spear in a political battle, which is never the intention of the founder when they're designing them.

It's helpful, I think, to focus the values on what makes you distinctive, because then it can actually help inform decision-making in some of the most difficult times you have.

The ones that you mentioned in particular are very interesting. The desire to remain small — what a powerful statement! So often, especially in the market we've seen over the last couple of years, founders have celebrated when they've hired someone new — in other words, they celebrate when they spend money. Of course, I think a lot of folks are regretting that now in this new macro environment, but regardless of macro environment, that focus on nimbleness will serve you well going forward.

S: For sure. I’ll share one criterion that I think that has served us well in terms of values and picking them. Someone said to me ages ago something that will stick with me forever: this idea that your values should be something that other companies can credibly disagree with. You should be able to point out another company that's really successful and that you admire and say, "They have different values from ours,” but you’ll still stick with your values, because they actually make you, you.

A: Thank you so much for taking the time to chat, Simon.

S: Thank you so much.

If you enjoyed this post, feel free to share it!

Share