Ep. #146, Help Desks for Modern Teams with Brian Levine of Yetto

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line, we got Brian Levine. Brian, what's up?

Brian "Balevine" Levine: Hey, thanks for having me, good to be here.

Brian Douglas: Yeah, it's a pleasure. Yeah, as I mentioned before we hit record, we had crossed paths like avatars.

Balevine: Yeah.

Brian: At GitHub, I've seen a lot of your previous commits and your work that you've done on the support team. I'm a big fan of what you used to use day-to-day, which was Help. If you're a former Hubber or existing Hubber, you're familiar with Help, because I think it's actually, it might actually still be around. I'm not sure if they ever sunsetted that thing.

Balevine: Unfortunately, they did, and partly I am to blame for that. One of the last things I did at GitHub, when I was leading the support team, was start the transition off of Help. And just for any listener, there are two Helps out in the world.

There's the Help that I guess Atlassian bought, which is an IT help desk, which is not what GitHub was using internally. Help was our internal tool. And it's really hard to get a bunch of engineers, even a bunch of engineers at GitHub, to maintain a production help desk for a growing support team. So we ended up moving off of that in about 2020. 2021 was the final day of that.

Brian: Yeah, yeah, good time, so we jumped right in, as we do here, but do you want to introduce yourself to the listeners? Tell us what you do and how you got here?

Balevine: Yeah, so I'm Brian Levine. To make this easier with two Brians, I go by Balevine, B-A Levine, because coming from GitHub, we always refer to each other by handles.

So I'm the co-founder and CEO of Yetto, and we're building a help desk for modern support teams, which largely came about from using a help desk at GitHub, which we sort of built to our own specifications. And after leaving GitHub, a bunch of us just really missed having that kind of technology. So that's what we're building now, tools for modern teams.

Brian: Yeah, yeah, amazing, 'cause we weren't the main, like, support arm at GitHub. We were the DevRel teams, and we also supported, like, sponsorships for conferences. So all that still went through Help until it eventually got shut down.

But, like, sponsors@github.com, which I'm like, I'm doxing the email that no one wants to maintain anymore. But, if anybody wanted to sponsor a conference or wanted to do a hackathon, you'd email that if you found that email, and we would just maintain that all through Help as a shared inbox, because our team couldn't justify getting Zendesk licenses, so we just kept doing that.

But I'm curious can you explain, what's the importance for having internal help desk tracking software and why is that important?

Balevine: Yeah, for a ton of reasons.

But a large part of it is that really early on in a company, there's not a team doing support, right? It's the founders, whoever, just responding to emails as they come in from customers. And as that grows and you start building up a team around that, a shared inbox often, like in a Gmail shared inbox, isn't enough.

It's not enough to have, you know, five, 10 people managing emails in the same inbox. And support, once you build up a team, is doing more than just responding to emails from people. They're doing, you know, research on the product, on other products, trying to maintain a relationship with the engineering team and the product team, in a SaaS company at least, and you need tools to do that.

And it's really difficult to manage, that level of communication across that many teams about every product and feature that you're working on out of a shared Google inbox. And so help desks are meant to solve this kind of problem.

Brian: Yeah. Can you explain what Yetto is today and how that sort of incepted?

Balevine: Yeah, so I'm going to start pre-Yetto.

Brian: Okay.

Balevine: I'm going to start with Help actually, because this is, like, the origin story of the superhero. Help was really cool because everyone at GitHub at the time was in Help. It was a really easy way to have conversations across the organization.

So it was a shared inbox, it was easy to communicate with your customers, it was easy to communicate with other folks at the company, and it was really easy to access the data that you had on your customers because it was using the same backend product was using. And my co-founders and I all worked at GitHub back in the 2013 to 2020 era and we got spoiled by this.

And as we left and went to work for other companies, we saw that most other tools on the market did not have all of that. It seems like pretty simple features, right? I can talk to my customers, I can talk to people across the company, and I can access all the data I need to do my job. But those are three really difficult things to do in one tool.

So we all individually started hacking on this as side projects together. And what came out of it, you know, over the past, you know, it's been five, six years we've been working on this, is the current version of Yetto is a help desk that is multichannel, or omnichannel we often call it in the support world, externally, but also internally.

It gives us access to have conversations with our engineers in GitHub or Linear, wherever they might be working, with our customers if they're in Slack, they're in email, wherever that is, and access to our data, right? You have a bunch of data from whatever product you're supporting in your backend tool, and we want to be able to access that securely, not just have blind access to all this PII, and give support teams that overall view of how their world works.

Brian: Yeah, excellent and this is something that-- So today at OpenSauced, I'll explain our support ticket management, which is, we have an open source project and we use GitHub Issues. So if anybody who's a power user, paying attention to releases, they'll jumping in and open an issue or they'll jump in the Discord.

The Issue is like, great, because we can track that. Discord, not so much, it just happens. It's, like, sort of, like, a river, right? And then, we have GitHub Discussions. And everything's, like, disjointed in multiple different places. We also have an email hello@opensauced.pizza, and that was just thrown together as, it's a catchall.

Like, any sort of billing, and everything like that, like, we should probably build another email for that. But everything is just a dump in the hello@opensauced, and then most of the team has access to that, that comes from a Google Workspace essentially. So, like, we're already building some tech support tech stack just by default. But I think at earlier stage companies, I think it is probably the norm, which is do whatever works and we'll figure it out later.

Balevine: Absolutely.

Brian: At what point, do I start looking at, like, a Yetto, or a Zendesk, or to start centralizing these conversations?

Balevine: I'm obviously biased and I would say, "Oh, you should do it right away." Right?

Brian: Yeah.

Balevine: You know, prior to running this company, my sweet spot was joining a company at around Series A, right? When they're just starting to break everything they've been doing and they need to figure out how to make things work.

So usually it's around that point or a little earlier where you really need to find, I don't want to say a professional tech stack, right? But something a little more stable, something more unified for the team. I mean, it's terrible advice, but honestly do it when it hurts, like when you can't manage your system anymore.

You know, I've done this for a couple companies, and I've done this as a consultant for a number of startups at this point too, and you see that in a lot of places. Where they add a bunch of channels because, I think your billing example is a really good one, right? You want to add a billing email, because, well, those shouldn't end up in the same inbox as like, "Hey, I'm trying to get started on this, and how does your product work?"

But the more channels you add, the more ways people can contact you, the more chances that stuff gets lost. There are more things for you to go check on every morning or a couple times a day you have to go check every inbox, so you get to a point where it's too difficult to have everything in one place on your own.

You can't have that one hello email, one info@ is my favorite. Everyone's just using info@ for everything. But then you can't split it up into, like, 10 different ones because then things fall through the cracks. You want to be on Slack and Discord, and you're on Twitter and Threads, and you can't keep up with that. So it's at the point where that starts to fall apart. And when you can see like, "All right, six months from now, that's all going to break," that's when you should start porting things over into a unified tool.

Brian: Yeah, yeah, and I think we're probably on that six-month trajectory where we've had a lot of like, friends, I guess I would call it, earlier users who hit us up on Twitter and Discord. We're now getting random tweets of like, "Hey, OpenSauced, thing happened," or question here. So like, we're not at the point where that's, like, unmanageable at this point. But I could see that as we hit our next inflection point and sort of hit traction, folks are like, "Oh, I expected this product to do this. It's not doing it today. Let me @mention this random faceless company to fix my problem for me."

Balevine: Right, and you got four people behind the scenes scrambling to respond to every message that comes in from every channel where a customer can message you. And you could spend more money and just put more bodies behind that, right? You could have someone dedicated to responding on Twitter and all your social media, but, I mean, that's not a great use of money and time early on either.

Brian: Yeah, yeah, and it's just, like, the four people are basically all engineers that also have a whole other area to focus. So I can ask a question like, is it Series A when you think about hiring your first customer support person or customer success?

Balevine: That's such a good question. GitHub was the first tech company I worked for. I'd been working in a government job for 12 years as an aerospace engineer, totally outside the world of tech. And I joined GitHub as a tech support engineer because that seemed a more fun job. And it was absolutely more fun.

But I didn't know that GitHub was doing things differently from other companies back then, I just thought this is, like, how tech works. And GitHub hired a customer support person as their first non-founder. Like, that was employee number one.

Brian: Wow.

Balevine: In their first 10 hires, they had two support engineers. So I think it really depends on the product that you're supporting, and the type of customers you have, what their expectations are, and what your team is capable of doing.

But I think people often wait far too long to hire their first support person, success person. I generally tell people that if you've got 15 people and you don't have a support/success role already at your company, you're probably in pain. And you don't know how much it hurts until you bring that person on and feel the relief of someone doing that work.

Brian: Yeah, that's cool. And then, I wanted to ask the question around, so GitHub is a strong culture in open source. Though the product itself is not open source the entire open source community has chosen GitHub as the place to support that.

But we're also seeing a different trend that even when GitHub started in 2008, which is there's a lot more open-source-first companies as well. So I want to take a step out and look at this sort of realm where open-source-first company already using GitHub Issues, already using GitHub, and probably maybe even a Linear or some other, like, project management software, do you see an inflection point of the need of getting some sort of tech support, or I forgot what the term you called it, but the tech stack itself, for support?

Balevine: Like, the help desk. I mean, it's more than a help desk, right? I like referring to it as a support tech stack, like getting that tech stack set up for an open source team.

Brian: Yeah, would you imagine that comes in earlier? Because I'm looking at some tweets from the Nuxt team, and Nuxt adjacent, in the JavaScript space. And that it's not a complaint, it's more of waxing poetic of, like, "Should I turn off issues for six months while we focus on a release?"

And that's actually come up multiple times for open source projects in open source companies. And, OpenSauced, we just did it again the last quarter. We weren't heads down, we didn't turn off issues, but we did stop responding to some community stuff, because we knew we had to ship the last feature we shipped last week. So, yeah, I'm curious does that even pre-Series A, pre-15 people, like, do you think the tech stack for support comes in earlier just because of volume?

Balevine: I do, and I think the open source scenario is really interesting and unique, right? And actually the first version of what became Yetto, I think the first product we built that we called Yetto was specifically a tool that interacted via GitHub Issues. It's one of my favorite products ever, still. I use GitHub Issues for everything.

And the product that we imagined was something where, all right, instead of opening up any issue for this open source product team, they'll have an email address, right? Like help@opensauced.pizza or something. And instead of getting an email and checking my Gmail inbox, I want to see that as a GitHub Issue, because I'm in GitHub every day anyway, so I don't have to check a different tool.

Then I want to respond to the GitHub Issue and that'll get sent back out to the user. So it was, like, the opposite, right? It was a way for users to email, but you, as the open source maintainer, can stay in GitHub Issues.

Brian: Yeah.

Balevine: We did see some traction initially with that among open source maintainers. We had a couple of big projects using it. Ultimately, it wasn't the thing we wanted to build, we wanted to build something more tailored towards support teams, not towards open source developers.

But I still really love that idea that open source developers and project maintainers should be using a modern support tech stack also, right? You shouldn't just have Linear projects or GitHub Issues. GitHub Discussions are wonderful, but so much noise for open source maintainers. T here's not a lot of tooling on the market right now to help make sense of all that for people who have a lot of stuff coming in.

And so that's how Yetto was born, right? So we wanted to integrate, and our current product does integrate directly with, like, GitHub and Linear, so that you can have conversations across tools without feeling like your attention is constantly divided. Because that's ultimately the problem, right?

You're trying to build something and your attention is constantly getting pulled away by these issues getting opened up, and you want to shut that down for a week, a month, a year, just stop the noise. But that's also a bad idea, because those are your users. Those are the people who love your product and you don't want to, like, not hear from them.

Brian: Yeah, I was talking to Brendan Burns who's at Microsoft now, and co-creator of Kubernetes. And early days Kubernetes, so the story of Kubernetes, started in Google as another name, another project, but for orchestration of tons of servers. And they decided to open source it, and they started looking at issues and PRs getting opened. And the way he sort of, like, distilled this, which I stand on, I keep mentioning this in other conversations, which issues is interest, pull request, or adoption.

Balevine: Oh yeah.

Brian: And this is looking at external interest and external adoption. And I think that your little control plane of connecting Yetto directly to Issues where you can then just be in the space you're already used to as a GitHub Issue for open source maintainer makes a ton of sense, because then you start getting these issues from these random people who work at random companies that you've never heard of.

And then, we realized these are companies that are funded with lots of interest into whatever you're building. And a lot of those conversations are all disjointed across different repos. And I'm a big fan, I mean, I did DevRel at GitHub, so I'm a big fan of building on top of GitHub's API, on top of the product, as a platform.

And OpenSauced similarly started as an idea where I had too many PRs in multiple projects, and I needed a CRM to maintain what state my PRs were in. So if I got a comment from another maintainer, I was like, cool, the entire board looks like this, and I can sort of cross-collaborate and see when this gets merged in.

I can go update the docs here, and then go finish building the thing I originally opened the PR for to work on it downstream. But I love that sort of organic story and journey of Yetto, and now what it's become today, which I'm curious, like, what is the outlook of Yetto right now? And, like, what's the product look like, and what stage are you guys at?

Balevine: Yeah, so we're super early right now. We've got a very small handful of very small companies using it. There's a support conference coming up in a week, and we plan on taking our initial beta version there to debut for the world. So that's where we are, like, in our journey, we're about to release our closed beta of this.

And at this point, it's a fully functioning help desk with integrations to a couple of other tools, right? So, you know, Slack, and GitHub, and Linear especially. But, at the core of it, the big change for us, the big pivot for us about a year ago was to build this more as a platform for a help desk.

We think of it like a switchboard, right? So you're trying to communicate with people all over the place. Your customers are all over the place, your internal teams are all over the place, and Yetto is the switchboard connecting all of those things.

So we built the platform for that, and now we're building, I mean, you know, product building every week is a new feature you got to build out. But also all the different plugs to plug into that switchboard, all the integrations, that we're building out month over month. That's sort of where we are now, getting our first batch of early beta customers to design partners to kick the tires on this.

And, you know, we're looking for feedback on how the product works, but also what people are looking to integrate. Like, where are they talking to their teammates? Where are their engineers working? Initially, we thought, you know, Jira was going to be super important. Everyone uses Jira as much as, you know, some of us may hate it. But it turns out everyone's moving to Linear now. Right?

Brian: Yeah.

Balevine: Everyone's moving to GitHub and Linear, and Jira's losing popularity in the market that we're looking at. So that's kind of our current state, is just building as much as we can, as fast as we can, and trying to onboard folks now.

Brian: Cool, and if folks want to be, like, a design partner, early adopter, like, how do they reach out?

Balevine: Yeah, so, you know, you can reach out to me, brian.levine@yetto.app or support@yetto.app, and we're getting back to people over the next couple weeks and starting to do live demos and onboarding.

Brian: Excellent, cool, well, folks, definitely check out Yetto, and I want to transition us to the picks. So these are Jam Picks, things that we're jamming on, appreciate the conversation on early days, GitHub support and, honestly, I think this is a perfect inflection point into the market for folks looking to establish support in their early teams.

But Jam Picks, let me go back to that. These are things that we're jamming on, could be music, could be food related, could be tech related, all of the above is on the board. And if you don't mind, I'll go first. I've actually got one pick today and it's a book actually I sped read recently.

So a couple weeks ago, Cal Newport released a new book. Cal Newport's got actually quite a few books that folks are kind of, like, are big fans of, I've read one of them, I forgot which one it was, so that's not my pick. But my actual pick is "Slow Productivity." So that came out a couple weeks ago.

This is a book that actually came out post-pandemic, and kind of really, really hyper focusing on the world that we went into, which was everyone went remote. So whether you worked at GitHub or not, you were remote, everyone had to figure it out.

And then, if you're a knowledge worker where you're just answering emails, handling tickets, et cetera, the 9-to-5 really got obliterated, because you had unlimited access to employees, to Zoom meetings, so then you're at Zooms all day. And we saw a lot of folks quiet quitting and burning out, and then Gen Z opting out from going to traditional jobs to then becoming influencers.

But the book, it talks about that in the first half. The second half talks about how folks could do slow productivity in the sense of you don't have to always be on. One of the examples was Ian Fleming came out of the war and I think on his honeymoon, took time to basically just chill.

Like, he felt like he always had to do something, and what he did was he ended up writing a book. So he took his honeymoon in Jamaica, wrote a book, which is "Casino Royale," which is the first James Bond book. And, basically, it was because he had time to sit and think and write maybe a page a day, he ended up writing up quite a few books on his first honeymoon, and he eventually built the entire James Bond franchise.

But going back to this idea of slow productivity, like, you don't need to give yourself you got to crush it and grind all the time. Sometimes you just give yourself one goal a week and just accomplish that goal, and try to accomplish the hardest goal first.

So I actually came through burnout during the pandemic. Post-pandemic, left my job at GitHub to start a company to then continue to grind. But things I've been learning from this is that it's okay to, like, just hyper focus on one thing, but also, like, end work at five or maybe take a half day.

Balevine: Yeah.

Brian: I'm super inspired by this book and I really encourage anybody to check out this book, "Slow Productivity." But I don't know if you had a similar experience, Brian.

Balevine: I love that, man, I had this backwards experience where I worked at the government where no one grinds, where everyone is slow, nonproductive, and then joining the tech world in 2013 where everyone is just grinding all the time. I was not ready for that. You know, that was, like, a big change.

I was putting in, like, 80-hour weeks for years. And now, you know, 12 years later, thank God, I learned my lesson through, you know, through several stages of burnout several times over to get there. But, yeah, I'm going to go buy this and read this today. This is right up my alley.

Brian: Yeah, I highly recommend it. I felt very inspired after reading it. And I've been doing this thing, I read a book a week as my goal, to essentially just give myself some time away from work to focus at least an hour a day, like, just read.

And it's been super helpful, because I don't currently pay for a therapist, so like, I feel like, it's a bit of my therapy where I could just, like, walk away from work or walk away from anything and just go and sit and do a thing that's not binge Netflix.

Balevine: Yeah, same, I'm a big reader also. Probably not a book a week. I'm not a fast reader. Similarly, I also have a book pick. Actually, I just bought this book, I'm going to recommend a book that I have not even read yet.

It's a book by Mercer Smith who works for a company called PartnerHero. They're a BPO, business process outsourcing, company. It's called "CXOXO." It's all about building support teams and walking through her thought process on how to do this.

And I've known her for a little while and I've spoken to her about this stuff, and so I'm going to recommend her book having read five pages of it. If anyone wants to know what it's like to build a support team and what goes into the thought process of building a team, and picking your tools, and deciding how to support your customers, this is a great person to learn from.

And it's primarily written with support leadership in mind, right? But I think it's super valuable for people tangential to support, right? For engineers, product leaders, marketing folks, CEOs especially, to read this and see what goes into actually supporting customers and how to do that well.

Brain: Cool, yeah, I'm actually going to put this in my list. I love reading, I guess business books. I don't know if this is a business book, but yeah. I've been reading a lot of product books recently. I'll save this for a future picks on the podcast.

But I love expanding stuff I don't have a lot of context into, and, like, support being one of them, a lot of product operation stuff that I'm just not quite up to speed on, and, yeah, so I definitely put this in my backlog for sure.

Balevine: Nice, I had a secondary pick of a book I have read, which I'm going to bring up GitHub again, because I'm talking to an ex-Hubber, like, we're obsessed with this.

Brian: Yeah, I mean, it's a life-changing company.

Balevine: It really is.

Brian: Great place to work.

Balevine: Yeah, an executive there recommended this book to me, like, pretty early on, and it seemed very odd for an exec to recommend a book by David Graeber called "The Utopia of Rules," which is all about our modern, primarily European/North American approach to bureaucracy and why we do it, right?

He's an anthropologist and an anarchist writing about modern bureaucracy. And I think it's enlightening, probably a little aggravating at times. But if you want some insight into how office culture works and why, and the things that we get upset about offices, and I know in tech we rail against big office culture and corporate professionalism and all that.

And there's a reason it exists and there's a reason fighting it the way we fight it is not going to work. Any book by David Graeber is great, but "The Utopia of Rules" really changed the way I think about work.

Brian: Nice, yeah, another one would be added to the list. I'm going to grab it on Kindle today.

Yeah, appreciate the picks, Brian. I think we're in similar wavelengths, not because we're both former Hubbers, but as founders, I'm happy that we connected, and looking forward to checking out Yetto. And, listeners, keep spreading the Jam.