Communicating Effectively with Developers and Tech Support

Text the show!

We're diving into the complex dynamics between customer support teams and developers. Buzzsprout Co-Founder, Tom Rossi, joins us to explain how strong communication between these groups significantly impacts product quality and customer experience.

In this episode, you’ll learn how strong communication between customer support and product development fosters better teamwork, ensuring support teams stay informed and confident when changes roll out. Discover strategies for improving collaboration, from setting clear expectations and sharing positive feedback to involving support in feature planning and aligning release schedules.

We want to hear from you! Share your support stories and questions with us at [e-mail]!

To learn more about Buzzsprout visit Buzzsprout.com.

Thanks for listening!

Episode Transcript

Priscilla (00:00):
Welcome to Happy to Help, a podcast about customer
support from the people atBuzzsprout.
I'm your host, Priscilla Brooke.
In this episode we'll tacklethe sometimes tricky
relationship between supportteams and developers.
We'll discuss the importance ofhaving strong communication
between teams and the strategiesfor effective communication.
Thanks for joining us.
Let's get into it.
This is a very important topicin the world of CX.

(00:26):
I feel like it's something Ihear a lot when I'm talking to
customer support professionals,so I'm really excited to jump
into it.
I figured for this conversationwe should have someone on from
the other side, from thedeveloper side of this
relationship.
I like that you called it atricky relationship.
I said sometimes trickyrelationship, sometimes tricky
relationship.
I said sometimes trickyrelationship, sometimes tricky

(00:46):
relationship.
I think it is.

Tom (00:48):
I think it's a great description, yeah.

Priscilla (00:49):
Sometimes it's not, but I do think sometimes it can
be tricky and you listen toother support professionals talk
about it and for some companiesit's really hard to navigate.
Just so everyone knows, I'mtalking to Tom Rossi, who's one

(01:09):
of the co-founders of Buzzsproutand also does work on the
product and works closely withthe support team as well, and so
I thought having Tom on wouldbe a great person to talk to us
about kind of what thatrelationship looks like, since
Tom and I, over the last severalyears, have really worked hard
at making that communicationreally intentional and effective
so that everyone's kept in theloop, and so it's just done in
the best way possible.
So that is why Tom is heretoday.
So thanks for coming, tom.

Tom (01:30):
Thanks for having me.

Priscilla (01:31):
So, before we jump into any episode, we like to ask
our guests who has made yourday recently?

Tom (01:37):
You know I knew you were going to ask this question and
so it was fun because I wasthinking back of like an
experience and this was great.
There's a restaurant that we goto for lunch a lot of times
right near us called the localand you know I I never take
credit cards anymore.
I try to always do tap to payand so I asked him if they could
do tap to pay and they took myphone to go do it.

Priscilla (01:57):
Like into the kitchen or into the back, yeah, into
the back.

Tom (02:00):
So I trust them, I give them my phone, whatever.
So then, like a week later, I'mlooking at my photos on my
phone and there's a picture ofthem all like smiling and waving
the whole the waitstaff.
And what's great is I'mreplaying in my mind like when
they brought my phone back, likethere was no giggling.

(02:21):
There was no, like they totallyknew that it would be a week
later that I would come and seethat picture and it just yeah, I
loved it, it made my day.

Priscilla (02:30):
Oh, that's so fun.
You got to see the like.
Commitment to the bit you knowwhen you bring it back and
you're like we are not going tolet it go, we're just going to
give it to him and we're justgoing to let this pay off
without us present.
Like that takes a lot, I think,like to let someone else have
the payoff without you beingable to see it.

Tom (02:47):
And I haven't deleted the photo yet, and so I can't wait.
The next time we go, I want tosee if any of the people in the
picture are working.

Priscilla (02:54):
You should like print it and have it framed and then
take it back and then they canhang it somewhere.
That is such a good idea,that's great.
I love that example becausethat's like a good way to have
fun and humor in your customerservice experience, because I
mean, you could have just takenit and scanned it and brought it
back.
But whoever it was was like,hey, I want to do something a

(03:16):
little bit outside of the boxand like they know that you come
in often, so they probablyweren't taking that much of a
risk.

Tom (03:22):
Yeah, and it solidifies the relationship.
Yeah, and it solidifies therelationship.
The brand.

Jordan (03:26):
No, that's really good.
Well, now you guys have thislike inside joke, right?
So that's just too fun.

Priscilla (03:31):
Right.
So before we jump into talkingabout specifically the
relationship between support anddevelopment, Tom, do you want
to talk a little bit about whatyour typical day looks like as
far as communicating with thedevelopers and then
communicating with?

Tom (03:45):
the support team, sure, and a little bit too, about how
it's kind of evolved, because Ithink this is what a lot of
companies run into is when youfirst start a product company
like ours, you're doingeverything.
So you're writing the code, butyou're also the one that's
responding to customers.
And then, over time, you know,you try to find that balance of
I'm spending time writing codeversus spending time working
with customers Right, and so Iin particular, I enjoy

(04:08):
interacting with customers.
I really enjoy the good and thebad.
I enjoy being able to hearfeedback of what's friction that
people are experiencing, whatare things that they love about
it, and so I really enjoy that.
But it tends to be like arelief valve almost.
So you're coding and you runinto something and you know you
just need a break.
For me, it's great for me tojust go pop over, open up

(04:31):
support and see what kind ofinteractions are in there, and
so it's totally random, I knowfor you and for the support team
.
It's weird.
It's like oh Tom's in supporttoday.

Priscilla (04:39):
What is he seeing that we're not seeing?
Yeah, right, right Like.
Why is he?

Tom (04:43):
in here.
But yeah, so it's notsystematic, it's not like I say,
oh, I try to do X number ofhours a week, as much as it's a
great relief valve for me to beable to just take a break from
whatever I'm doing, do a resetand go jump into support.
Now that's the ideal.
Now there are times, of course,when I don't have a choice
Right, and so those I try tobatch with a similar process of.

(05:03):
I know that there's somesupport cases that are waiting
for me.
I'm going to wait until there'sa natural break in the work
that I'm doing.
I just solved an issue or Ijust deployed some code.
Now I'm going to take a breakand I'm going to go knock out
the support.

Priscilla (05:15):
So a lot of times again, from your perspective,
you'll see, you know them kindof stack up, but then all of a
sudden they all get you knowanswered at once, or yeah, yeah
Well, and it's interesting overthe years, in the beginning of
having like a full supportdepartment, I was the only
person doing support and so youand I were in a lot of
communication and it was reallyeasy because it was just me and

(05:36):
it was just you, or it was youand a couple other developers.
And so it's interesting overthe last eight years to see that
grow from one support personwith a couple of developers that
have a very tight kind ofrelationship and communication
style.
I mean we were like two desksaway from each other, so it was
very easy to have thatcommunication.
But now having a larger supportteam and a larger group of

(05:57):
developers working fully remote,it just means you have to be
more intentional about thatcommunication and giving it
places to happen and then beingintentional about sharing
knowledge and having that youknow something that you said.

Tom (06:09):
I think that's key is that you and I worked together when
it was small and it was easy,and so what happened is you kind
of learned how I worked.
You kind of learned, okay, if Itell Tom this information,
there's a better chance he'sgoing to knock it out now,
versus me having to wait longer.
But you know, if I queue him upwith everything that he needs,
there's a better chance he'lljust knock it out right now.

(06:29):
You also kind of got an idea ofwhat kind of things I could do
and what kind of things Icouldn't do, right, and I think
that that really benefited thesupport team and a lot of the
things that we're going to talkabout today.
Because you're able totranslate that to new members of
the support team, you can sayhey, look, you know this is the
way that we want to do things,because it gives us the best
chance of getting the developersto be able to do this in the

(06:52):
most timely way possible for us.

Priscilla (06:54):
In a way that respects them, so that they
don't hate coming into supportwhen they have to come in and
help out with something.
Yeah, so it's interesting, Ifeel like you know, over the
years, when I've been inconversation with professionals
in the CX or customer supportspace, one of the reoccurring
like gripes maybe is a strongword, but like themes is this

(07:15):
idea that the support team is soseparated from the company as a
whole, but from developmentspecifically, but from
development specifically.
And so there's all this like oh, I found out after the fact
that this was rolling out and noone told the support team.
Or we're in the middle of somekind of a crisis, there's a bug
and the support team is talkingto customers, but the

(07:36):
development team isn'tcommunicating with the support
team.
And I'm sure that there's truthon the other side too, that
developers are like I didn'teven know this was a problem,
that was happening because thesupport team isn't communicating
with us feedback in that way,and so I think that there's got
to be some of that on both sides.
But it's interesting to mebecause when I sit in these
conversations with people, Idon't feel that I feel very out
of place, because I'm like, Iactually think we do a really

(07:59):
good job at communicating withthe development team, and I
think what you were just sayingis a big part of that is because
we kind of started small andthe people who started small are
still here, and so there isthat strong relationship.
And so I think that a big wayto make your product better, to
make your service better, is tohave a really good, strong

(08:20):
communication between these twodepartments specifically, but
really all departments ingeneral, and so that's what I
want to talk about is theimportance of it and then shift
into some strategies about howto do that in an effective way
that respects all parties.

Tom (08:33):
Yeah, let me add a little bit of color to that dynamic as
well.
I actually tweeted about thisas a joke.
This was a joke, but I feellike it is a bit of a.
Developers can have thismentality and what I said was
our product would be so muchbetter if it wasn't for all the
customers, like our softwarewould run so much better if it
wasn't for all the customers.
And there's some level ofthinking that way as a developer

(08:56):
, where you're like well, don'tclick on that, why are you
clicking on that?
If you click on that, of courseit's going to do something.
You know what I mean, right?
And I think that someorganizations that actually
penetrates their culture.
Yeah, so that it's arelationship where you're at
odds.
You're literally at odds withthe people that are paying your
salary.
You're literally at odds withthe users of your software.

(09:17):
And I think that we've beenfortunate that you know we were
small and we could.
We appreciated every one of ourcustomers and we've been able
to scale up and continue tovalue all those customers.
But you can definitely see thatin other development cultures
where it's like what I said as ajoke actually becomes real.

Priscilla (09:34):
People think, yeah, well, it's funny because if you
look at the support side ofthings, a lot of times what you
hear in support is you would benowhere without your customers.
Your customers are the reasonthat you have success, and
that's true to an extent becauseyou're also successful because
you make a really good product,and so there's kind of this like
balance there a little bitneeded that, hey, you want to
make sure you're respecting yourcustomers and that you are

(09:57):
listening to them and takingtheir feedback and letting that
impact the way that you build aproduct.
But it shouldn't be the drivingforce necessarily.
But you shouldn't go to theother side of the spectrum where
it's like we don't listen tothem at all.
So there's kind of like anecessary relationship there,
but without one necessarilybeing like the only voice.

Tom (10:15):
Yeah, there's another dynamic too in that typically,
when there are supportinteractions as a developer, a
lot of those are a result of thestuff that you did as a
developer and it could be a bug,and so, even though it might
not be a bug, there's adefensiveness.
There's like a pride in thatthere's a pride in the work that
you did, and so that's anotherthing that adds the somewhat

(10:36):
tricky relationship betweensupport and the developers,
because the developer is notnecessarily hearing it from.
Oh, there's a customer who'sexperiencing a pain as much as
they're hearing.
Hey, you did something wrong.
Yeah, you know.

Priscilla (10:47):
Well and it's funny because I think I run into that
a lot because I will see a bugor something that's just not
working as it's intended to workin support from a customer.
And then I'll just turn to adeveloper and say, hey, this is
what's happening.
And they immediately push backand I go, oh, I'm not connecting
this with work that you did,I'm connecting this with paying
the customer's feeling.
But you, because you built it,have personal investment in it

(11:12):
and so you do feel thatdefensiveness, and so it's
worthwhile to think about itfrom both sides and, as a
support professional, think, ok,I want to make sure I'm doing
this with some tact when Irespond or pass this off to a
developer, because they mightfeel personally responsible or a
little bit embarrassed orwhatever it is, and so you want
to be respectful of that.
And then, as a developer, thereis probably some benefit in

(11:33):
stepping back and detaching fromit as much as you can when
something like that comes up.
Because sometimes I'll say bugand like.
Tom, I know you've been likeit's not a bug and I'm like well
, I didn't mean that in a meanway.

Tom (11:45):
I just mean that it's not working.
That's a great example.
That's a great example of likehey, there's a bug with this,
and then a developer mightrespond and say it's not
actually a bug, it's user errorbecause they did this or that.

Jordan (11:55):
You know what I mean.

Tom (11:56):
Well actually you could say it's a because you've allowed
them to do this thing.
You know Right.

Priscilla (12:03):
Yeah, exactly Okay.
So as far as importance of itgoes, I think we both agree that
it's important.
But I want to talk through somespecific reasons why it's
important to focus on thiscommunication specifically and
strengthening it.
So the first thing you knowwe've been talking about is that
the support team and thedevelopment team overlap a lot.
You know your development teamis developing a product that

(12:23):
your support team is supportingand your support team is
supporting a product that isdeveloped by your development
team.
It's like super simple, butyou have to be hand in hand
because you are helping eachother out in those ways, and so
I think that sometimes you cansee them as totally separate,
but the reality is I think Iwork most with the development
team than any other team inBuzzsprout because we are so

(12:45):
hand in hand.
So having a strongcommunication there is going to
make your product better andit's going to make the service
that you're providing yourcustomers better, which is just
going to enhance everything.
So that's like number one.
Those two teams overlap a ton.
I also think you know wetalked about a second but
communication.
Having that like strongcommunication is going to enable
that feedback loop to beshorter for customers' feedback

(13:08):
to get to your developers easier.
And you know you can putprocesses in place that are
these big, long processes thatallow customer feedback to get
logged in a certain way and thenthat logged feedback goes
through this system and thenthat system gets over into
developer and then two monthslater someone on the development
team sees it.
But having a good, strongcommunication on like a regular

(13:31):
daily basis can shorten that, sothat really what's happening is
you hear this feedback from acustomer and you're able to
pretty quickly get it in frontof a developer and see if it
needs to be something that's abug or something that's the
intention of the feature.

Tom (13:45):
I think, the relationship that we have with our customers.
As developers, we want to getinput, but it's input.
It's not necessarily this iswhat we have to do, and
sometimes people overcorrect andit becomes well, everything
gets logged.
Like you were saying,everything gets logged and then
developers get assigned to itand then they have to go address
it.
Obviously, if it's a bug,that's one thing, yeah, but a

(14:07):
lot of times it's more of justsomething that might be hard for
customers to be able tonavigate and we want to come up
with a new solution for it,versus, you know, just move a
button because of something, andso it's figuring out how the
customers have input into thedevelopment, not necessarily
demanding it.
It's not a sign of anunhealthy product to have
interactions with your customers.

(14:28):
Yeah, one of the things that welearned over time was when the
product is healthy and growing,you have a spike in your
customer support because peopleare first, they're first coming
onto the platform, they're goingto interact with it and you
know that's not a bad thing.
If we look at support, asanytime we get support, oh,
that's a bad thing.

(14:48):
That's because there's bugs,it's because there's something
that's wrong.
That's not always the case.
Yeah, it can be, but it's notalways the case, and so I think
that all plays into why thatcommunication is important and
how you have to figure out as anorganization how are you going
to process that feedback?
For us, it turns into thesupport team making pitches for

(15:09):
things that the development teamshould consider adding to the
product, but other organizationsmight have different ways.
But there is a feedback loop,like you said, and it's an
important communication becausethat's the only way you're going
to hear from your customers.

Priscilla (15:22):
Yeah, well, and the other thing you know, with new
customers that are coming in andhaving that support, it can be
really beneficial to hear frompeople who are new to the
product, who haven't beenworking in it for years and
years and years, because they'regoing to have a different
perspective on how things workand they might have some idea or
some thought about somethingthat we hadn't thought through
because we've been working in itfor 15 years or something, and

(15:43):
so that can be really valuablefeedback.
To get like right at thebeginning of someone.
It's like when you bringsomeone new on your team and you
do a 90 day review and you'relike, hey, you're new.
What is it about how we workthat you want to tell us before
you're fully indoctrinated andnow you're thinking the way we
think?
We want to hear your outsideopinions to help us grow.

Tom (16:00):
That's a great analogy because, exactly like you said,
somebody who's been withBuzzsprout for a long time we've
gradually added so manyfeatures.
Buzzsprout has grown so muchin the last whatever five years.
We've added so many featuresand so somebody that's been
through that whole process it'sprobably not overwhelming for
them, because it was one thinghere and there.
But for somebody who justsigned up today there is the

(16:21):
chance that they're like a deercaught in headlights and they
don't know where to go next.
And you would never hear thatperspective if you aren't
interacting with those newercustomers.

Priscilla (16:30):
And then that perspective can go back to your
development team, who can buildsomething or introduce some
education in the UI that helpsnew customers navigate through
those things.
So I think it can be a really,really cool way to shorten that
feedback loop.
Another thing I think that's areason why you should really
focus on this kind ofcommunication is because it
shows value for your supportteam.
I mean, it shows value for thedevelopers too.

(16:52):
But I think it's pretty commonin a lot of especially bigger
companies that your support teamis kind of this sectioned off
group of people that support theproduct but they're not really
in the day to day, they're notnecessarily at the table with
the rest of the development orthe designers or marketing.
Even they're like on their own.
And so I think that this kindof intention behind the

(17:16):
communication helps you bringthat support team into the fold
a little bit more and shows themthat they're valued as
important members of the teamand then just gives them that I
don't know reassurance that thework they're doing is valuable
and not like, oh, you're overthere in the support team and
we'll tell you what we want totell you, but we're not going to
spend the time investing andmaking sure all that

(17:37):
communication is there.

Tom (17:38):
Yeah, but I think it goes both ways Absolutely.
I think, the opportunity for adeveloper to go into a dark
space and write code and neverknow the impact that it has on
customers, and if all they everhear is the negative, all they
ever hear is the issues, thesupport cases that come in,
versus the positive experiencesthat you hear, and so something

(18:00):
that, at Buzzsprout, our supportteam does a really good job of
highlighting positive feedbackfrom our customers.
And that really motivatesdevelopers so that they feel
valued.
Yeah, that's right.
I spent all this time writingthis code and solving this
problem.
It's great to hear from ourcustomers that they value it.
I think that it communicatesvalues both for the support team

(18:20):
, the developer and the customer, so all three feel valued if
that communication is strong.

Jordan (18:25):
And that would wear anyone down to just consistently
hear negative feedback andnever hear the good feedback.
You know, if that's all youknow is the bad, then you're
going to think wow, I'm reallybad at this.

Priscilla (18:37):
at some point, Well, one of the benefits of working
in support is that you arehearing positive feedback, but
you're also hearing negativefeedback from customers too, and
you have to kind of hold bothof those, and so being a
developer on the other side andnot hearing anything or only
hearing negative can be reallydifficult.
We at least get those likedopamine hits of, like the

(18:58):
positive things I mean.
In Buzzsprout it's a regularbasis.
I'm sure with some othercompanies it might not be as
regular, but that's why we tryto be really intentional about
when someone says a good thingabout the product and the way
the product works or the designof the UI or something like that
.
We want to share that.
Just the other day someonewrote in something nice about

(19:19):
our newsletter and so I sharedthat with the marketing team
because I want to make sure thatthey're getting those positive
feedback, the positivereinforcement there, so that
they're encouraged, because whenyour work is good and someone
gives you praise for it, itmotivates you to do a good job
tomorrow and to just keepputting your all into it and
keeping your standards high andall of that and it just makes
you feel good.

Tom (19:39):
And if you think about how cultures go sideways in this
area.
You'll hear a lot of timeswhere support turns into tickets
.
Tickets get assigned todevelopers and that's the
communication that's happeningthere and a lot of times it's.
We want to make sure that thedevelopers aren't wasting time.
You know these nerds areexpensive.
Man Like you just gotta yougotta make sure like you gotta

(20:00):
make sure that we're we'rereally respectful of their time,
but what they end up doing isthe only interactions they're
having are tickets that arebeing created for things for
them to go fix, versus beingable to hear those positive
interactions as well.
And so you can see how thatwould make a culture go sideways
, where all of a sudden now, asa developer, there's a
resentment, because the onlytime you ever hear from support
is when they've got, you know,stuff that you've got to go do,

(20:20):
and it's reflected because theytake that approach of oh, we
want to just make sure we'relimiting the communication
between the two teams.

Priscilla (20:28):
And developers have feelings too, you know you want
to make sure that you're sharingthat though, because it really
is important, and I mean, I'm avery extroverted person, so to
think of someone who is superintroverted, who really feels
comfortable working in code andbeing alone at their computer,
like, even that person wants tohear those positive
reinforcement.

(20:49):
They want to hear that positivefeedback.
So I think that's reallyimportant.
Another thing that I was justthinking about is that strong,
clear communication encouragesconfidence in your work.
As a support professional, youare expected to kind of be the
expert on the entire productthat you're supporting, and so,
depending on what that productis, it can be a lot of
information, and so if somethingnew comes out or if an update

(21:12):
gets pushed out or something,not having that communication
can really be a hit on yourconfidence as someone in support
who's trying to field questions, and so if you have that clear
communication when new thingsroll out or when updates are
made, then it really puts thatconfidence back in the hands of
the support team and they canfeel really secure in the
knowledge that they have, andhaving that clear, easy

(21:34):
communication between developersand support professionals allow
this like easy relationship forthe support team to go.
Hey, I have a question aboutthis very specific thing that I
am not sure of and I want to askyou about it.
And I feel comfortable comingto you and asking you about it
quickly because we have thisrelationship and now I can go
back and answer this questionwith confidence, instead of
feeling like, well, now I haveto assign this ticket to this

(21:56):
person because I'm not sureabout this, and then it becomes
a much bigger thing than justhopping over and asking a quick
question and then going back andfinishing it.

Tom (22:05):
And if you don't have that strong communication, then what
can happen is you assign theticket, right, you give it to
the developer, the developerfixes it.
Well, what happened?
What happened?
What'd you do?
Yeah, and so this is somethingthat you know.
I communicate a lot with you,where you know I might send you
a ping and say hey, here'ssomething that you should know,
Right?
I see whatever five or sixreplies that show wait, there's

(22:25):
this little piece of informationthat maybe you don't know, or
the support team doesn't know,that I want to share.
Sometimes that turns into amessage that we post onto the
support base camp so that wayeverybody can see it.
Right, but the idea ofinvesting in the support team so
that they have the confidenceto be able to answer those
questions and understand howthings work and what's funny is
it goes the other direction.
Sometimes, too, where we won'teven remember how a certain

(22:47):
feature works because we builtit forever ago.
We may have to go to thesupport team and ask hey, wait,
what is this supposed to do?

Jordan (22:53):
Or what are?

Tom (22:54):
customers doing with this thing Right, and you might say,
oh, nobody uses that.
You might say, oh no, we hearabout it all the time, like yeah
.
So I think that that's a goodpoint about having confidence.
The support team has confidenceand that happens.
The developers can help buildthat confidence by sharing
information with a support teamin such a way that they could oh
, that's why we do it this way,this is why we, you know, do the

(23:16):
things that we do.

Priscilla (23:17):
Right.
Well, and it comes back to.
You know we're talking aboutfeedback and sharing that when
someone requests an update thatwe know is never going to happen
, it allows us because we knowit's not going to happen.
We know why it's not going tohappen.
We know why we're not going togo down this path that they're
asking for.
It gives us confidence insaying no, and doing it, of
course, in a respectful and kindway, but being clear about hey,

(23:39):
this isn't a feature that'sgoing to happen, but here's why
I have information.
I know why we're not going downthis path because I've talked
to John about why he developedit this way or why we've decided
not to include this option orwhatever it is, and I think that
also leads back to thatconfidence of that's better
support being able to say nowhen it's a no versus saying

(24:00):
maybe I'll log it as a featurerequest, knowing it's never
gonna happen.
The better experience isactually getting the no and
getting a workaround orsomething that's gonna help you
accomplish what you wannaaccomplish.
It's worse support to say yesbecause you're not sure or say
maybe because you're not sureand then leave someone on the
hook like that.

Jordan (24:17):
I've actually seen this in our community group, because
support explains the why behindthe things that we do or the
features that we provide.
I will see people post aquestion in a community group
and then other members of ourcommunity will comment oh yeah,
they're not going to do this andhere's why.
And so our community membersare jumping in and explaining it

(24:39):
to others, and so it kind oflike lightens the load for the
support team too.

Priscilla (24:43):
Well, and it helps people that are using the
product understand, like why webuilt it the way we built it.
It strengthens thatrelationship because you know, I
don't know it's like if yourparent decides to punish you and
they don't tell you why they'repunishing you, like they don't
tell you why they're punishingyou, like they don't tell you
what it is that you've donewrong.
You're like, ok, well, I guessI'm just going to have to live
with this because I don'tunderstand it.
And they're not taking the timeto explain but taking the time

(25:05):
to educate someone on why you'vebuilt something a certain way
as much as you can.
I think gets buy in from them.
And if, ultimately, they decidethis is not the way you built,
it is not the way I want to useit, well then that's fine and
they can find somewhere thatworks for them.
But like having thatunderstanding of why that really
comes from the developers whodeveloped it and came up with

(25:25):
that, passing it on to thesupport team and having buy-in
from that, I think can be areally strong experience for
customers.

Tom (25:34):
Yeah, and it helps build better product, because if all
we do is say yes, becauseeveryone asked for it, then
you're not going to have a greatproduct.
But if you have, you know wetalk about like a mantra, like
we're going to be the bestproduct to help you start
podcasting and keep podcasting.
And any feature goes through alot of debate before it gets
built.
We let the support team intothat debate conversation so that

(25:56):
they understand how we approachbuilding features, so that you
can share that with customers.
So when they ask for somethingthat's maybe not in line with
where we're going, rather thankeeping them on the hook and
thinking, oh well, maybe one daywe'll do that, we articulate no
, this is what we're about, thisis what Buzzsprout is about,
and I think that that'ssomething that's always been
important to us.

(26:16):
And what the support team hasdone way better than we did at
the beginning is communicatethat message in a way that's you
know, it used to be way moredirect like, oh, you should go
somewhere else.
Here are three of ourcompetitors and you know now you
know you're much better at it,but even we had that.
We had a case this week wheresomebody was leaving and we were
very friendly and like how, howto leave and making

(26:38):
recommendations, and it wasalmost like they received it as
a negative to like well, whyaren't you trying to keep me on
the hook?
Look, you already said you'releaving, right, like hey, what
we want to do is make it thebest experience possible for you
to leave Like, and I think thatthat's something that the
support team has added, thatreally it's a deposit in those
customers.

Priscilla (26:55):
Yeah, and we have a lot of faith in our product.
We really believe that this isthe best way to start podcasting
and keep podcasting, and wehave reasoning behind that.
And so when you say to someone,if this doesn't work for you,
we would love to help you findwhat will work for you, knowing
that it's possible you gosomewhere else and realize that,
oh, actually I like the waythey did it back at Buzzsprout,

(27:17):
and we don't want you to leavewith a negative taste in your
mouth.
We want you to leave with apositive taste so that if, in
the future, you realize that youdidn't actually need that thing
that was a deal breaker beforeyou can come back knowing that
we're going to treat you withrespect and kindness, regardless
of whether you're going to payus or not.

Jordan (27:32):
Yeah.

Priscilla (27:33):
So I feel like the most common communication
between these two teams show upin kind of two scenarios
escalating support questions orcomments that come in, or like
fixing bugs that's like one, andthen the other is rolling out
new features and updates.
So I kind of want to talk aboutthem in two separate
conversations.
So the first one is thiseffectively escalating

(27:53):
conversations to development,like what strategies can we use
as a support team to do that ina way that will encourage the
developers to want to enter inand do their best work and
support, but also be effectivewith time and respectful of each
other's jobs, when we know thatthe developers are not being
hired specifically to be insupport right, they have other

(28:15):
things going on in their daysand so how do we be respectful
of that?
I have a couple strategies.
I'm sure, tom, you have somestrategies and some perspectives
from your side as well, but Ithink the most important thing
is when you're starting thisconversation, when you're
figuring out what that's goingto look like.
Start by setting expectations.
Writes in to support.

(28:40):
Has a question that has to goto a developer.
What are those timeexpectations going to be, so
that we're all on the same page?
Is it three days?
Is it 24 hours, is it a week?
And finding an expectation thatworks for the developers, so
that they're not getting taggedin an email that they have to
answer in 20 minutes, and thatalso respects the support team,
who's having to kind of hold onto this conversation with a
customer, and setting thatreally clearly in the beginning

(29:01):
is really helpful.

Tom (29:02):
Absolutely.
That was one of the firstconversations we had when we
started really having a supportteam.
Right when you were, you werelike I need to know, because we
are very protective of our timeand attention and we want people
to be able to go into a deepfocus mode when they're, when
they're writing code or whenthey're answering support or
when whatever work they're doing.
We don't want them to feellike someone's tapping them on

(29:22):
the shoulder and interruptingthem, which is the way that
support used to be.
As a developer was literallylike looking at your email and
seeing somebody's writing inwith this question and you know,
kind of an interruption, and sothat was one of the one of the
things that we talked about waswhat expectations are realistic
for us to set so that way I cango to a place where I can close

(29:43):
all my windows and all I have todo is work on the thing that
I'm working on.
But I want to be respectful ofthe support team and I want to
be respectful of the customer,and so I think setting that
expectation and it could bedifferent for every company- oh
yeah, it'll be different fordays, sometimes like days of the
week.

Priscilla (30:00):
One thing we run into , like we right now have an
expectation of a 24-hourturnaround.
So once a developer gets taggedin an email or assigned an
email, they basically have 24hours to make that first
connection with the customer orget an answer back to a support
specialist.
That's a 24-hour window.
We're going to tell people onMonday that there's a 24-hour
window, but on Friday we're notgoing to say there's a 24 hour

(30:20):
window because now the window isMonday, because I'm not going
to have a developer held to a 24hour turnaround time starting
at 4 pm on a Friday.
That's not a respectful thingto do to someone who doesn't
work on a Saturday and a Sunday.
And if you're a supportprofessional, you might work on
the Saturday and the Sunday, andso you have to be aware of that
, and so I think when you'resetting those expectations, take
into consideration people'sschedules.

(30:42):
Not everyone is going to work anine to five Like.
You might have developers thatare working odd hours, and so
you might want to keep that inmind.
So it might be differentdepending on the developer you
assign to, as long as it'sdefined and agreed to on both
ends.
That's the most important thingis that the support team is on
board with it being a goodexpectation and the developers

(31:04):
feel good about it, and then ifit's a deadline that keeps
getting missed, then maybe youneed to revisit it and go hey,
this isn't a good expectationbecause no one's meeting this
expectation.
We need to change it and makesure that that's communicated.

Tom (31:15):
And customers respond well to that, like whenever I've seen
those interactions where, hey,you know somebody will be back
in touch with you within 24hours, nobody writes back and is
like, oh, that's horrible.

Priscilla (31:26):
Right.
I don't think I've ever seensomeone respond to an
expectation of a 24 hourturnaround with anything but
thanks.

Tom (31:34):
This is surprising and great, because one thing that we
realize as well is thedeveloper has to respond within
24 hours, but not necessarilysolve the issue.
Yes, and so sometimes when theyhear back from a developer and
you say, look, I'm the developerlooking at this, I'm whatever,
I'm trying to figure it out andI'll let you know when I figure
something out, yeah, but theylove that they're talking to the

(31:55):
actual developer.
Yeah, you know like it buysyou time and goodwill with them,
right that it's like, oh,they're taking me seriously as a
customer, right?
Like you're never going to getthat from Google okay, you're
never going to get that from alot of companies that I could
name, but having the actualperson write you back that
communicates, oh man, theyreally they're taking this
serious.

Priscilla (32:24):
They're going to get back to me.
We say this in supportsometimes, where if something's
taking you a long time to figureout, or if you need to pass it
on to a developer and have themdig into it more, you always
want to respond to the personwho's writing in and let them
know what to expect.
So what we will say is hey,I've looked through this, I'm
stumped, or maybe everythingfrom my end looks good.
I want to get a perspectivefrom a developer and we will be
in touch in 24 hours.
It's kind of like you know youwant to get the credit for doing

(32:44):
that, for passing it on andescalating it to someone who is
developing the product.
Like that makes you feel like aVIP.
We were.
When we were first settingthese expectations up, we were
very intentional about the wordswe used to describe the
development team, Because atfirst it was tech support and we
thought, well, that just soundslike I'm going to send you off

(33:05):
to an IT person.
It doesn't make you feelspecial.
And we thought, well, what arethe titles of the people who are
going to be the ones answeringthese emails?
They are developers of theproduct.
So if I tell a customer, I'mgoing to get a perspective or
pass you off to a person whodevelops the product that you're
using.
It really makes you feel likeyou're getting an inside track,
and so we are really intentionalabout that wording, because

(33:26):
that's what's happening and wewant to get the credit for it.
I mean, I know it sounds alittle bit like I don't know, it
might sound a little bit likenefarious, be like we want the
credit, but I think it's likehey, if I'm working on this, the
problem is you're workingagainst all the poor support
that's out there.

Tom (33:41):
Yeah, exactly, and so what you're trying to do is
differentiate yourself and saylook, I know you've heard from
other people that they'veescalated it and it didn't mean
anything to you, but we'retelling you that we actually
have a developer that's going tobe looking at this.

Priscilla (33:59):
And so it's kind of like you're trying to
communicate it in a differentway so that they believe you
that this is going to bedifferent, exactly.
Well, and then if the developerresponds within that 24 hour
period even if they don't solveit, like you were saying, but
they respond and say hey, myname is John, I'm working on
this, I have this follow upquestion that I need information
about, or something.
It's like hey, we're working onit.
The 24 hours isn't a mark ofhey, we're going to start
working on it Through this, 24hours is when we're working on
it.
So it's kind of like we'retaking care of you, we're taking

(34:21):
care of this question and we'retaking it seriously.
I think that communication withthe customer is really
important, because you couldwork on something for four days,
not tell the customer you'reworking on it.
The customer is going to thinkyou've forgotten about them.

Tom (34:33):
They're not going to think, yes, I haven't heard anything,
but I trust that the developeris working on this because they
told me after a couple of daysthey're not going to think that
they're a priority and so thatcommunication can be really good
, and I think for us the waythat we work could be different
than other companies.
I'm sure it's different fromother people.
Having that kind of access todevelopers, like that's
important to us and we're smalland nimble enough that we can do

(34:55):
that.
For other companies, though, Istill think the application can
be the same, which is you canstill set realistic time
expectations and you can stillcommunicate in a way that is
different enough that they feelvalued, that they believe you,
that you're going to dosomething.
Whatever the thing is in yourorganization of what that next
level is going to be, youcommunicate it.
For us it's developers, but forsomebody else it could be other

(35:17):
things.

Priscilla (35:18):
Yeah, when you're talking directly to a customer
and something's about to getescalated, tell them what you've
done, Like tell them whatyou've already looked into.
Like I know sometimes I'llwrite into a support team and
ask a question and then theirresponse is I'm going to
escalate this to tech and I'mlike okay, but did you take a
swing first, Like before youmoved this on to another
department?
And so I think for support, itcan be really again like

(35:41):
honoring to the customer to sayhere are the things that I have
looked through.
Everything in this looks good,Everything here looks good.
At this point, I think the beststep is to move it to one of
our developers so that I can gettheir perspective on it, and
that, like transparency with thecustomer, again reinforces this
idea that the customer is beingcared for and that they feel

(36:01):
like they're in good hands withyour team.

Tom (36:04):
It's also great for the developer, because the developer
sees what you've tried and theydon't they don't feel like you.
Just, oh, that was acomplicated question.
I'm just going to give it to adeveloper, versus trying
something on your own.
You know what I mean.

Priscilla (36:17):
Like yeah, and I think that that's valuable as a
developer to be able to see thatthe support team they're trying
, they're trying to figure thisout Right.
Well, and on top of that, itstarts when the developer gets
to the question.
There's already been afoundation of a relationship
with the customer and thesupport professional before it
gets to a developer.
So when they get to it, thecustomer isn't going to be angry

(36:38):
because they're already feelingcared for, you know.
And so it almost like alsogives them this foundation of
like.
You're starting on a healthy,like.
I've already gotten us to thislike healthy place and now you
can come in and torch it andmake their day.

Tom (36:51):
Like make it great, did I say torch it?

Priscilla (36:53):
I don't know what you said.
I couldn't really hear youConnection was bad.

Tom (36:56):
We don't let the nerds speak to the customers.
That's the way that we work.

Priscilla (37:03):
Sometimes the customers are nerds and they
want to speak to the nerds,exactly.

Tom (37:07):
Those escalate directly, just to give it right to the
developer.

Priscilla (37:10):
I think another really important thing when
you're figuring out thatcommunication with the customer
piece of it is to not overpromise.
So when you're a supportprofessional, you're working
with someone you don'tnecessarily know what the
outcome will be.
You don't know if the thingthey're trying to do can be done
.
Sometimes it can't, and so youjust want to be careful that
you're not backing yourdevelopers into a corner that

(37:31):
they can't get out of withoutbeing the bad guy.
And so a lot of times I'll saythings like you.
And so a lot of times I'll saythings like you know, I can't
make any promises but we'll seewhat we can do.
Or I want to get theirperspective on this instead of
saying like I'm going to passthis to John and he's going to
fix this for you within 24 hours.
That puts a lot of pressure onJohn to find an answer in 24
hours and also just to find ananswer.
It's possible that what theywant can't be done or can't be

(37:54):
done quickly, and it's a part ofa bigger thing that has to be
solved in a different way.
So I think it's just reallyimportant when you're passing
that along and you'recommunicating with your customer
, you just want to make sure youdon't back your developers into
a corner, because there'snothing worse than coming in as
a developer and then being like,wow, you promised that I could
do something that.
I can't do and you didn't knowthat I couldn't do this, but

(38:14):
you know, so just be carefulabout that wording.
And then, tom, you talkedabout like what information to
share with the developer.
I think this is probably likemy favorite thing about the
communication between thedevelopment team and the support
team, because the way we workin Help Scout and so we use
notes in emails to communicateback and forth.
So, depending on what you'reusing, you might have a
different process for that, butwhenever someone on the support

(38:37):
team assigns an email to adeveloper, they leave a note and
in that note we are veryspecific about the information
that has to be included in thenote and it's all intended to
make the developer's life easier.
That is the full intention ofthe note, because you could
easily just assign an email, notgive any context, and let the
developer go to town.

(38:58):
But what's that going to do?
It's going to make thedeveloper have to do extra work,
which is going to take moretime, and then over time they're
going to resent having to comein the inbox just the reality of
it.
So, like Tom was saying, likeearly on, I learned strategies
that I could use that would makeit easier for Tom to answer a
question for me, which in turn,got me a faster answer and got

(39:19):
the customer a faster answer.

Tom (39:21):
And so.

Priscilla (39:21):
I just want to talk about some of the things that we
do that are intentional.
So the first thing we do is wesummarize the context of the
conversation.
We want to be thorough, but wedon't want to be lengthy
unnecessarily, so it's like abalance of being thorough in the
context and being concise.
No developer wants to read fiveparagraphs about what's going
on, but they also don't want toread 14 emails back and forth

(39:43):
either, and so finding thatbalance of here's the context
you need I'm not including allthe fluff that I waded through.
I'm just going to give you thecontext that you need to handle
this, and it might be that theyneed more and that you don't
know what they need, and so theymight have to read through the
email, but at least giving thema shot to say here's the context

(40:04):
that I know is important.
I'm going to give you thisright off the bat.
The second thing that we alwaysmake sure we include is all of
the account information that'snecessary.
So it might be the email that'slinked to the account, or maybe
it's account IDs, or maybe it'sowner names or something like
that.
Whatever it is for yourproduct, don't make your
developers have to track all ofthat down as the support
professional.
Just throw that in there.

(40:25):
You've already tracked it down,so just put it in there so it's
easier for the developer.
It takes one less thing off oftheir plate for them to have to
do.
And then I always say, like, bereally clear about what you
need from them.
You know what's the questionthat you're trying to answer.
Do you need them to tell yousomething so that you can go and
respond?
Is that what you need, or doyou need them to accomplish a
certain task?
Like, be really clear aboutwhat the outcome is that you

(40:48):
want as the support professional, so that your developer knows
what's expected of them in theresponse that they give, whether
they're going to respond orwhether they're not going to
respond to all of that.
I think all of that helps keepthat process streamlined and
shows respect for yourdevelopers, respect for their
time and, like Tom was saying,their deep work and all of that.
Like you want to make sure thatyou're aware of that.

Tom (41:09):
And you've already done the work.
The reality is you've alreadydone the work.
If you don't do that, thedeveloper then has to go do the
work that you just did, right?
So, for example, for us, one ofthe most critical things that
support does is they provide uswith a podcast ID, right, the
customer number.
Well, it doesn't take us thatlong, right, to go find it.
But sometimes it can take alittle bit of time because

(41:31):
you're trying to figure out.
Oh, actually they wrote in froma different email than the
email that they used on theiraccount.
Well, the support team alreadyfigured that out.
They've already nailed downwhat podcast that they're
supporting them on.
But you've already done thework, and so by sharing that
podcast ID, it doesn't take thatmuch more time from the support
team, but it saves the time forthe developer.
And again, if you go back tohow we work not I'm not saying

(41:52):
that all companies work this way, but the way that we work our
developers you know it might beI want to take a break from
writing code I'm going to goknock out a support ticket.
Well, if I go and I look at thesupport ticket and I've got to
read 14 emails and I can'tfigure out the podcast ID and
whatever.
Well, I'm just not going to doit.
I'm going to go back to my code, like, okay, I think, okay,

(42:13):
this is going to be a pain, I'lldeal with it later.
And then I go back and I writecode.
But if I go over there andthere's a podcast ID and I need
you to move these episodes fromone podcast to the other, and
here are the IDs that you need,well, that's, that'll only take
me a couple of minutes.
I can do that.
Yeah, but if I have to go doall the investigation,

(42:41):
no-transcript.

Priscilla (42:45):
Hey, John, will you take a look at this and let me
know what you think.
Yeah Right, that's horribleand then you're like, whoa, okay
, there's just a lot of theweight put on John then to do
that, whereas if you say, here'sthe outline of what just
happened, here's what I've tried, here's where I'm stuck, here's
the account information.
Can you give me yourperspective?
It's completely different andit feels like way less of a

(43:06):
burden on John.
And if you want John to come tosupport because he's trying to
like get out of the code holethat he's in and like come over
into support, you don't want tomake that uncomfortable.
You want him to like it,because if people like coming
into support, then they're goingto do it more often and they're
going to do it with moreenjoyment, which is just going
to be a higher standard andeveryone will win.

(43:26):
The other thing that I thinkis really important is to make
responding easy.
We've talked about this alittle bit, but you know, people
who are really good in customersupport, really know how to
talk with people that are fromall different walks of life,
right, that's one of the reasonswe do the job that we do,
because we love communicatingwith people.
So if you're working withsomeone who's a developer, it's

(43:49):
very possible they're like Tomand they love communicating with
people and they get the ticketand they figure it out and then
they respond because they lovetalking with people.
But it's very possible that youget someone you know in your
development team or tech supportwho doesn't like talking to
people.
And you want to be respectfulof the expectations when it
comes to responding.
I always try to say I mean, we, I think, have a pretty unique

(44:12):
situation where most of thepeople in our development team
are pretty personable and enjoyresponding to podcasters, and so
that makes it easy for us.
But if you work with a bunch ofdevelopers who are like I do
not like talking to people,that's why I chose this
profession, I don't want to beresponding Then sometimes it can
be really nice for them to havethe option of not responding

(44:36):
directly but just giving you thedetails and letting you do the
responding.
Then, as the support person,you can say, hey, I discussed
this with our lead developer,john, and here are the things
that he recommends, and then youcan still get the credit for
them looking at it, still makethe customer feel like a VIP,
but then you're doing thecommunicating instead of making
someone who really doesn't feelcomfortable in that space doing

(44:58):
that part.

Tom (44:59):
Yeah, there's times when I'll look at a.
It'll get assigned to me andI'll see this long conversation
that's been going on with oneperson.
So let's say that they've beengoing back and forth with Kate
and then it gets assigned to me.
Well, they have therelationship with Kate, yeah,
and so I think it can be a goodexperience for them to hear back
from Kate, who they've beentalking to, versus somebody else

(45:20):
writing them back, which a lotof people receive.
That in a negative way.
It's really not a negativething on our support team, but
in other companies it certainlyis where they feel like I'm
starting over.
There's a new person here.
Okay, now Tom's writing me, butI've been talking to Kate this
whole time.
Tom's writing me, but I've beentalking to Kate this whole time
.
And so there's times when I'llsee a long history and I'll just
be like, okay, I'm not going torespond, I'm going to let Kate

(45:40):
respond, because I think that'llbe a better experience for this
particular customer.
You know, and I think sometimesthat's true- that's a good
point.

Priscilla (45:46):
Yeah, I think it is a really good point.
I think it's a case by casebasis too, and one way that you
that feeling of like oh, I'mbeing passed off to another
person, that's just like somerandom person, is when you're
the developer and you're cominginto an email that might have
some back and forth with asupport specialist.
Introduce yourself, you're nowentering the conversation and so

(46:06):
say like, hey, I'm Tom, I'm adeveloper for Buzzsprout.
Kate asked me to look into this.
It starts that relationshipbetween you and the customer a
little bit, because sometimes ifyou just come in and the only
place they see your name is inyour signature at the very end,
that can feel like I don't evenreally know who I'm talking to
now, and I've been talking toKate but now I'm talking to

(46:27):
someone else and I don't knowwho it is until the very end.

Tom (46:29):
That's a really good point If you respond and say hey, this
is Tom.
Kate shared everything thaty'all have been talking about
and I'm here to you.
Know, do this thing.
I think that's a really goodway of mitigating the thought of
oh well, now there's a newperson I got to start over.
Well, no, I just told you,kate's already shared everything
with me and yeah, and it againgives you the credit.

Priscilla (46:47):
Right, you're like we did all the work, we did all of
the sharing of information, andso now I'm going to tell you
that we've done the sharing ofinformation, because, if you,
don't say that Because theydon't see those notes Exactly.
They don't see the notes andso you want to make sure that
that's clear.
Another thing that can bereally helpful when you're
working on this communicationand getting this set up is if
you have a tone for your supportteam.
It doesn't hurt to take yourdevelopers and do a mini tone

(47:11):
review at the beginning of aperiod or something.
They don't need to be like yoursupport team experts and
writing in the tone, but havingan idea of what that tone is or
how you've said it can help thembe intentional about how they
write.
Just because you know, if yousay, hey, we don't talk in a
super, super professional way,we're really conversational, we

(47:32):
try to be very personable, andthen you get someone who isn't
used to coming into support andthey go OK, how do you talk like
a support person?
That's what I want to do.
Then it's going to feel verydifferent.
But if they go, oh, I can bemyself, because that's part of
the tone is being conversationaland friendly.
That can help me take some ofthe pressure off when I'm
responding, and so I thinkgiving some training or some

(47:54):
tone expectations to yourdevelopers can be really helpful
.
And then another thing I liketo do is say, like, if you want
me to review a response thatyou've written before you send
it.
Anyone on the support team ishappy to do that.
We have one of our developerswho it's funny because he's
always the person who's askingus to review his responses and
his responses are probably thebest of all of the developers.

Jordan (48:14):
He's so good, I'm sorry, I know.

Priscilla (48:19):
He's so good.
I'm sorry.
I know he's so good.
He's so personable and kind andunderstanding and he is always
the one who's like, hey, willyou just this is a really
technical thing Will you justreview my email before I send it
?
I want to make sure that it'scoming across correctly, Giving
your developers the knowledgethat, hey, at any point.
If you don't feel comfortableresponding or you want us to
review one of your responses,we're totally happy to do that,
Just ask.
I think can also take thatpressure off that might cause

(48:41):
people to not want to get into asupport inbox.
Ok, so the other side ofthings is when new features are
rolling out and thatcommunication so it's not
necessarily inside of thesupport queue, but just in the
company conversation when newfeatures or new updates get
rolled out, what does thatcommunication look like?
Recently, sometime last year,I heard something from a support

(49:02):
professional that was about howa feature had been rolled out
and they didn't know about ituntil a customer emailed them
about it, and that was bafflingto me that a feature would get
rolled out and your support teamwouldn't be fully aware of that
before it happened.
And so I think it's morecommon than I realize that
developers, or just you know,products in general, will push

(49:25):
things out and not clue in theentire support team.
So establish a way for yoursupport team to communicate with
your developers and for yourdevelopers to communicate with
your support team, and so wejust have a chat that is a
podcaster success chat that allof the developers can get in I
mean, anyone from the companycan get in and it's open to
everyone.
So if someone throws a questionin there, everyone has access

(49:47):
to it, and so we use that a lotto kind of give support a heads
up like hey, we're pushing out anew feature this afternoon,
here's the details you needabout it.
Or sometimes our infrastructureteam will post something and
say we're going to work onsomething tonight.
We broke something Be aware,or yeah, something broke and
we're fixing it, but kind oflike that communication.
Having that be a clear andaccessible way to communicate

(50:11):
between the teams can be really,really helpful for the support
team to stay in the loop.
Another thing that we've donewith big rollouts is we'll do
like a new feature training typeof thing, where someone from
the development team will eitherprepare something
asynchronously so maybe it'slike a document or it's an FAQ
or something like that that theypost internally for the support

(50:32):
team to see and access, orreally for everyone to access,
but the support team uses it alot a support team to see and
access, or really for everyoneto access, but the support team
uses it a lot.
Or we'll plan a deep divetogether with some people from
the development team and somepeople from the support team to
get together before something'srolled out so that we can
understand the workings of itbefore we're asked to support it
.

Tom (50:50):
Yeah, this is something that's more recent.
I feel like it used to be.
We would just roll it out andsee what happens, and now we're
way more intentional aboutcommunicating with the support
team to make sure that they knowthat adding a new button that
does something cool, that couldresult in a bunch of emails, and
you don't want the support team.

Priscilla (51:08):
That's how they learned about it.

Tom (51:10):
That's how I learned about it was the customer wrote in.
Oh, I didn't even know this washere, right?

Priscilla (51:13):
Well, and it can be as easy as saying one of the
developers who built the featurejumping on a screen share with
one person in support to crossthat knowledge over and let them
ask their questions, and thenthe support specialist going
back to the team and saying, ok,here's a rundown, like it
doesn't have to be this.
Ok, we got to plan a meeting.
Everyone has to be availablefor it.

(51:34):
We all have to be in the sameroom and do this huge knowledge
dump.
It can be a quick thing or itcan be asynchronous.
You can write something up andpost it for everyone to get to,
and it's nice because when youdo it asynchronously, you can go
back and leave comments onwhatever that is and ask
questions specifically aboutthis feature, and then that

(51:54):
information is shared publiclywithin the company so that
anyone else on the support teamcan access that when they run
into a similar question.
So I think that having thatpiece of it really helps the
rollout go much smoother,especially in the support side.
I'm interested to hear what yousay about this, tom, but
consider support rhythms whenyou're planning rollouts.
We all know that.
You know with developers thereis an internal timeline that the

(52:16):
development team is working on.
Obviously, they're developingthis really cool thing that they
want to push out.
But sometimes I think we've allbeen in a place where it's like
Friday afternoon and thedevelopers are like, yeah, we're
going to push out this newthing, we're so excited about it
, and the support team is like,well, we're about to sign off
for the weekend.
Who's going to take care of thecustomers that see this?

(52:37):
And so I think just taking intoconsideration support rhythms
before you plan that or whileyou're planning that, can be a
huge benefit to your customers,because then when they have a
question about this new thingthat just rolled out, they're
going to get an answer quicklyand your support team who's
going to feel like they don'thave to now be tied to their
computers all weekend becausethis new feature went out on

(52:57):
Friday at 4.30.

Tom (52:59):
Yeah.

Priscilla (52:59):
There's a lot of truth to that.

Tom (53:00):
This is something again that I feel like as you mature,
you learn and you start to apply, but we used to be way more
aggressive about deploying onFridays.
And now not so much.
Now we will deploy fixes, sure,we'll push code on Fridays, for
sure, but a new feature wewouldn't launch on a Friday.
Yeah, like there's sometimesyou launch a feature that you
know is going to result insupport.
People are going to havequestions about this new thing

(53:23):
and so those in particular.
We will communicate withsupport and make sure that we've
got enough people on coverageand enough time to be able to
respond to all the differentpeople that might write in.

Priscilla (53:32):
Right, and it's not just weekends, it's you know,
busy times.
So maybe I don't want to do iton a Monday morning or oh, half
of the team is on PTO tomorrow,so our coverage is really low.
Even though it's a Wednesday,it's going to be a really light
coverage day, so we don't wantto overwhelm those people that
are working.
So it's just kind of liketaking into consideration those
rhythms and then allowing needto be the dictator.

(53:54):
Sometimes you need to roll itout even if you have light
coverage in the support team.
But avoiding that when you can,I think just shows everyone
that we value you as a personand we don't want to overload
you with all this work and wewant to give the shot to have
the best rollout possible.
When something is in crisis asa development team, don't

(54:19):
forget your support team.
We have an episode about crisismanagement and how the support
team is kind of standing in thegap between your customer and
your product and making surethat when you're setting up
these strategies to make thatstrong communication between
your development team and yoursupport team, to make that
strong communication betweenyour development team and your
support team, keep in mind thatwhen something happens, like a
fire or a crisis or somethinglike that, you want to make sure

(54:42):
you have a clear path in thatmoment to allow communication to
flow.
And so just be proactive aboutsetting that up before you're in
the middle of it, so that yoursupport team can feel like they
are in the know and are able tocommunicate well with customers
what they can communicate andthen what they aren't supposed
to put in front of the customers.

Tom (55:02):
You have to have a plan for that.
Those lines of communicationhave to be open before the
crisis happens.
And we say crisis, I mean likewe've had issues where there's
just a slowdown.
You know we were doing somechanges to our infrastructure
and the infrastructure team wentand posted on the support.
Hey, just so you know you mightsee a slowdown and people might
write in about that.
It's respectful to the supportteam and it's better for the

(55:22):
customer Customers, I mean.
I don't know if it's justBuzzsprout customers, but when
we tell them, oh look, we'redoing some infrastructure
upgrades, you know, that's whyyou might've seen, you know this
thing, they're super graciousabout it.
It's if you go gaslight themand say, no, you didn't.
Or if you don't respond like,yeah, that's, that's not going
to land well, but if you writeback and like, yeah, oh, I'm
sorry you ran into this, this iswhat it was like, it just goes

(55:44):
a long way.

Priscilla (55:50):
Yeah, absolutely All right.
So question for you, tom what,from your side, as a developer,
would you say that thedevelopment team can do today or
tomorrow to start improvingthis communication?

Tom (56:04):
I mean as a leader of developers.
I would think you would want toarticulate a strategy for how
do we bring support into thefold of what we do right.
Like being able to articulatethis is our strategy.
Like support, they will give uspitches for improvement.
They will communicate clearlywhen there's issues with
customers that they're going toescalate and that we're going to
go troubleshoot for them, butbeing able to just communicate
that strategy to the developersin a way that reflects the

(56:25):
values of the organization.
Hopefully, you're anorganization that values
customers, and so that will comethrough in the way that you
communicate to your developerswhat that relationship should
look like with the support team.

Priscilla (56:36):
Yeah, you know I'm on the support side.
So if I'm thinking of somethingyou can do tomorrow to start
making this communicationstronger, I would say, like, get
the development team and getthe support team together so
they know each other.
It doesn't even have to be workrelated, it can be a lunch,
like let's all go to lunch andlet's get to know each other a
little bit more.
I think one of the big reasonswhy this communication is not

(56:59):
strong is when departments don'tknow people in the other
department.
So when you don't know thedevelopment team, you're much
more likely to say hey, brian,can I get your help on this, or
can I pass this off to you, orcan you take a look at this, or

(57:23):
something like that.
I think bridging that gapbetween the teams because I
think a lot of times they're sodivided that you don't even know
the people on the other side.
At least when I talk to othersupport professionals that are
in bigger companies, there's alot of that.
Like well, I know there's a guyover there named Frank.
I don't know much of what hedoes, and so if you kind of get
everyone together and startbuilding those relationships

(57:44):
within the company, I think thatwill really strengthen the
communication when you get to aplace where you're in a crisis
or when they're rolling out anew update and you have that
relationship to build on.
I think it can really buy you alot of trust there.

Tom (57:58):
Yeah, and I think it's easier said than done, right,
like depending on the size ofthe team and how you work.
Like, for us we're remote, butwhat you articulated is one of
the reasons that we do regularmeetups.

Jordan (58:09):
Yeah.

Tom (58:10):
The opportunity to be able to get together at least once a
year the whole team to be ableto see face-to and interact with
one another.
But it's expensive.
It's an investment.
You have to be strategic in howyou do it, but that's one of
the reasons why it's importantand you should do it as a remote
team If you're all working inthe same office.
Well gosh, you got no excuse.
Just go to lunch.
That should be easy.

Priscilla (58:29):
Well, and if you're remote, it could be as simple as
jumping on a Zoom call at theend of the day or toward the end
of the day, everyone having adrink and just chatting.
And sometimes that can feelforced and you have to be honest
about why you're doing it andsay, hey guys, we're going to
all get together because we wantto know each other, so our
communication can be stronger.
Like I wouldn't try to pass itoff as, hey guys, this is happy

(58:52):
hour and we're just going tohang out and have fun, Like no,
the goal is that you get to knoweach other.
The goal is to be able to makethat communication stronger,
and so I think if you're honestwith people about that, then
hopefully it makes it a littleless awkward.
But yeah, that is one of thestruggles with remote work is
finding ways to have thatpersonal relationships between
coworkers in a real, authenticway that doesn't feel forced.

(59:13):
I think at the end of the day,you know, the relationship
between support and developmentis a really important one, and
it impacts your team and impactsyour customers every day.
So taking the time now to setup clear communication
strategies will go a long way inthe health of your product and
the service that you're offeringyour customers, and then just

(59:35):
in the health of your employeesas they're working together and
communicating.
So I hope that some of thesestrategies that we've talked
through will be beneficial toyou as you try to be intentional
about that communication, andhopefully it'll ultimately make
your customers more loyal andyour communication stronger.
So it's time for Support inReal Life, our segment where we

(59:58):
discuss real life supportexperiences.
So what do you have for ustoday, jordan?

Jordan (01:00:02):
All right.
So today we have a questionfrom Reddit.
I lead a small customer supportteam.
We are considering providingdedicated support specialists to
our customers.
Do you recommend dedicatedspecialists or have the whole
team support all customers?

Priscilla (01:00:16):
Ooh, that's a good question.
Yeah, it's funny because we areat a place right now where we
do whole company support, so wedon't have dedicated specialists
.
There are probably two or threecustomers that have dedicated
specialists, although I don'tthink they know that.
Oh, and it's just because theyhave unique situations that we
want to make sure that they'regetting good quality service

(01:00:38):
every time, due to whatever itis that you know their situation
is, and so having someone learnthe context every time can be
hard.
Exactly, but for the most part,we do just have everyone answer
everything, and I think thatthere are pros and cons to both
of these strategies of havingdedicated specialists for
clients or having whole companysupport for clients.

(01:00:59):
I mean, you think aboutcompanies that are like in
insurance or in health carethose products.
You might want to havededicated support specialists
because you want to make surethat the information that's
being shared is staying torelatively small number of
people, possibly like, dependingon what's being shared.
You might have, over time,these strong relationships and

(01:01:20):
having a individual person thatyou go to every time can help
strengthen those.
But then there's also the sideof OK, well, if you have
dedicated support specialists,you're going to have a longer
turnaround time?
Yeah, Because you only got oneperson and so you might email
someone and they're out of theoffice for three days and you
might not get an answer backuntil they come back and so
that's a longer turnaround timeand so it kind of depends on

(01:01:43):
what it is that your customersneed.
Like, some of the benefits,pros and cons for doing whole
company support is you have afaster turnaround time because
anyone on your team can jump inand help out, on your team can
jump in and help out.
It allows you to balance yourteam a little bit better,
because you can strategicallyschedule people to be in the
inbox and kind of have coveragemore.
So you feel a little bit moreof a balanced kind of carrying

(01:02:05):
of the inbox or the phone callsor however that is.
But it also does give you theneed to schedule people then,
because now you're workingtogether in something and so
it's a little bit lessindividual.
So now you're working togetherin something and so it's a
little bit less individual.
So now you're working more asa team, so you have to be aware
of scheduling.
That can be a little bit moreof a burden depending on how big
your team is, but you also getthe shared expertise.

(01:02:27):
So you might have someone who'sreally great in one area and if
they're not the dedicatedperson for that client, can they
come in and share theirexpertise or not, or are they
supposed to stay in their ownlane?
And so I think that there'sjust benefits on both sides, and
I think it really just dependson what it is that your clients
value and what it is that you asa team value, and how are you

(01:02:51):
going to provide that for yourcustomers.
So that's what I would start bydoing like step back and look
at the most important things foryour customers.

Jordan (01:02:58):
Yeah, I think that's a good point.

Priscilla (01:02:59):
And then I think from there you can make a decision
on okay, this is how it works,and then, if you find that in a
couple months it's just notworking well, you can try the
other option.
We went through a phase backwhen we were just a team of two
or three where we tried toassign out emails because we
were, you know, we were noticingthat reading the context was
slowing us down, and so if wedidn't have to read the context

(01:03:20):
every time, it could help usmove quicker.
And so we started assigning outemails, and it did not help us
move faster.
Really it slowed us down.
Yeah, it really did.
Now we were a small team, Ithink we were two or three
people, so it wasn't a lot, butit really did not make things
better for us.
So we probably did that for amonth, maybe two, and then went
back to sharing the inbox loadand I think that knowing that

(01:03:42):
you can make that change andthen go back on it without
feeling like, oh, we failed,that's OK.

Jordan (01:03:47):
Just give yourself permission to experiment.

Priscilla (01:03:49):
Yeah, exactly, and you'll find out what's the most
important to your customers.
Doing that, that's true, andthen you can make the best
decision for your team and yourcustomers and balance that.
If you have a question or asupport story or a situation
that you want us to discuss orshout out, you can email us at
happy to help at buzzsproutcom,or text the show using the link
in the description.

(01:04:10):
It says send us a text orsomething along those lines and
that text will come straight toJordan and I and we might shout
you out on a future episode withthose texts.
So feel free to reach out, asalways.
If you liked this show, pleaseshare it with someone that works
in the customer supportindustry, or leave us a review
on Apple Podcasts, or do bothboth would be great yeah, and I

(01:04:30):
want to thank Tom for being hereand sharing his perspective
from the developer side.
that was really awesome for usto learn from that, and thank
you all for listening.
Now go and make someone's day.