Uncovering the Source of Truth: A Deep Dive into Knowledge Management

Meet Brian Levine founder of Yetto, a cutting-edge help desk platform currently in alpha and seeking early design partners. With a rich background, Brian served as the VP of support at GitHub, headed support at Plaid, and offered consulting expertise in managing support teams for various Series A, Series B, and SaaS startups before venturing into Yetto's development approximately a year and a half ago.

Check out this video featuring Brian Levine our upcoming speaker for October’s Expo where he discusses the importance of establishing and maintaining a source of truth in knowledge management, emphasizing the need for clarity, data accuracy, and cross-functional alignment within organizations. Get a sneak peek of his compelling ideas before he takes the stage in Las Vegas, NV.

---

Neal: This is a conversation with Brian from Yetto, who's speaking at the SD Expo to share their connection to building and maintaining a source of truth, within knowledge management, and the importance of that.

 I'm Neal. I work from the Academy to Innovate HR. Currently I'm the support and admissions manager running the support team over there. Brian, can you tell me a little bit about yourself?

Brian: Yeah, I'm Brian Levine. I am the founder of a company called Yetto.

We're building a new help desk and we're still in alpha right now and looking for early design partners, if anyone is interested in testing out a very early help desk. Previously, I was VP of support at GitHub. I was the head of support at Plaid, and then I did a bunch of consulting and contract work running support teams for other like Series A, Series B, SaaS startups. Until starting Yetto about a year and a half ago.

Neal: That sounds like quite the exciting journey in terms of really going from a full suite of everything. What would you say is the biggest problems that people have around knowledge management and what motivated you to speak about this topic?

Brian: Oh man. I have so much, if you're asking like what the problems are, that's a whole days worth of talks. And I think that's what really spurred me to talk about this. I think when it comes to sources of truth and getting the knowledge within a company together, there are a lot of misconceptions about what those sources of truth can be about, what knowledge management is, or how it's done from leadership at companies that's putting a lot of stress on teams. As a consultant, I ran into this a lot. I'd come into a company and they'd say, Oh, we want this team to maintain this source of truth. And they were talking about something that was not a source of truth at all. And maintainership was not really maintaining anything.

And it was really frustrating, for the teams at the company. And then I see a lot of vendors position their product as a source of truth for blah, blah, blah. And that's a really great thing for the vendor because if they're the source of truth for something important at a company you're not going to want to rip that out, right?

This is their staying power. But that's not necessarily good for the team or the company. So I got really angry about this. A little while ago, I was doing some consulting work helping a series B company figure out the source of truth for their customer data.

I was just coming in to help with their customer support and success teams, try to organize everything. And they said, we need a source of truth for who all our customers are. This is a really common thing, who are all our customers, what's the source of truth on who they are, what they do, what they've purchased.

Who's maintaining that? They're like, the support team. I thought well, why would the support team maintain a source of truth unless you're selling a tool where everyone needs to talk to support as the first point of contact This doesn't really make sense and it just got really out of hand where every team thought the customer list was different. Sales team was using Salesforce, support team was using Zendesk.

I think that it's really depends on the product and the company and the teams that you're working with. For example, if you're an e commerce company and you want to know your customer base as your source of truth, the thing you're most interested in, I think for support teams is a really good example. For e commerce teams that source of truth is often whoever is putting an order, whoever's purchased something. So whatever your ordering system is if you're I worked with one company that shipped a lot of hardware and their logistics software should really be their source of truth, right?

If you want to know who all your customers are, you should dig through all the places that a customer needs to touch and find the one that is not only the one every customer touches, but the one they touch first. What is everyone's introduction into your collection of systems? And then how do you expose that to all of your other systems?

A source of truth isn't useful if, my ordering system is tucked away, inaccessible to my help desk or my sales system, my marketing email list, things like that. I've got all this data that's the source of truth that needs to get out. So really the uncovering is twofold. It's finding, for your product and your team and your needs at the time, what is the source of truth and then figuring out how to expose that to the rest of the company.

Neal: Yeah, that makes a lot of sense. I think really identifying the customer journey and where they're touching and really going through that full journey is the kind of best way to start the uncovering journey.

You mentioned it's also not like a source of truth is not something that people should be going to input data in manually going through and throwing it all in the information. But you did mention it should be something that we're cleaning and we're keeping up to date as a source of truth. I often find that, for example, my support team is now three people.

We're running very all hands on deck kind of solution where we're also doing a lot of operations. We're doing sales ops and things and CRM cleaning and records management is really important for us to make sure that we're maintaining that. Do you think that responsibility lies specifically in a certain role or is that lie with everyone?

Brian: Oh, I love that question. I think as support teams and success teams and often sales teams, we're put in a position where we're told to maintain your customer lists, your order forms, all this stuff because we often do touch it, right? We are the ones interacting with the customer. But again, it really depends on how your product operates, how your interaction with customers typically goes. If you're a very hands off, it doesn't necessarily make sense to have a support team be in charge of things that go past that.

Often it should be maybe the engineering team. I've products where the real source of truth is a database that the engineering team maintains or the infrastructure team maintains within a company, and they're not even aware that everyone else is looking for this data. Who all of our customers are, who has signed up, who has unsubscribed that data exists there.

And maybe it should be on them to make sure that's available to everyone else. Or maybe there should be another operations team created to access that data and make sure it's sent out to the finance team and marketing teams as needed. It really depends on how the company is structured, who maintains it and how the data itself is structured

Neal: For us as a personal story, we have as we're scaling company, we're growing super fast.

We went from eight people to now 80 people in the last four years. And one of the biggest problems that we're facing now, we just started revenue operations last year. And now one of the big things is cross functional alignment and really making sure that everybody is aligned.

And for us, our customer experience lies with everyone. And we hold very much that belief. We realized as we're scaling and growing, we're all building our own reports. We're siloed. We're really looking at all of this data as individuals. But without this source of truth or this, we are now creating a data lake, for example, where we can unify all of this data and information.

We're noticing that, hey, product is using reporting on refunds, and so is sales, but their metrics are different. How much alignment and cross-functional enablements do you try to encourage within companies to have around unifying the source of truth?

Brian: Yeah, I think that's the key to the whole thing.

It's not a source of truth if different teams are using different sources of truth. A source of truth means that it's the kernel that everyone is drawing from in some way. So I think the real key to uncovering and maintaining a correct source of truth is that all of the teams agree that this source of data is the one we want access to.

A common one ,if we're talking about revenue data, is going directly to the source of where the revenue comes in. Can we expose Stripe data? For example, if we're using Stripe as our payment processor, nothing is going to be more accurate than actual processed payments. So why is maybe sales using some data that they got in Salesforce and support using some data that they got through Help Scout while the finance team is the only one with access to Stripe directly?

Is there a way to make sure everyone has access to that correct data, or at least the most correct data available? Because at some point, every data is inaccurate. So we have to accept some of that. But we don't have to accept the differences that come from every team using their own tool and their own method.

So the first step when I approached this problem when I was working with this company was getting all the teams together and asking them, what are you all using? Like with the support team had our source of truth for customer data. What did the shipping team have?

What did the payments team have? What was finance looking at getting all of that in one place and then finding of those, which was the most accurate and if it wasn't accurate because it was missing data that another team had, how do we import that data into the the primary now source of truth.

How do we make it as accurate as possible? And this is where cleaning that data comes in. We don't want people sitting there manually typing in numbers from one spreadsheet into another. But if data comes in through Salesforce that doesn't come in through Stripe, for some reason, we need that to update it to Stripe.

 How do we do that? How do we get those teams talking to each other so they know that this is a better way for their team to work? I don't want a team to ever do this thinking that they're doing it for someone else. They need to do it for themselves and they need to understand it's to everyone's individual benefit.

Neal: Yeah, I can't count how many times I've said you can't actually use that number because it's not exactly where the fuller information lies.

Brian: And I think that actually surprised me when I was talking to this company that I had this horror story with, I was like this is terrible. How did we even get in this position? And then I work with all these other companies and find out, everyone is in this position to some extent in smaller ways often, but I find so many other teams are dealing with the same problem and maybe they don't know that it's a larger problem that is solvable. They think, Oh sales just hates to work with support or, we don't like working with engineering. This is a larger problem than just not liking some people on another team. This is a real data issue that I think as an industry, tech teams seems to have, but I've seen it outside of tech also.

Neal: Yeah. I think every company at some point has those growing pains of silos. When we're really small, scrappy startup, we have really small, scrappy information. Everybody's talking to everybody. The more you grow, the less you actually interact on a day to day basis with the people who are actually using the different data and information there.

You mentioned that Yetto is now in super early stages and kind of alpha and really building the product. Can you tell me a little bit more about Yetto and what you guys are doing there? And then also how you're looking at source of truth data and information around what you're building for?

Brian: Yeoo is building a new help desk primarily because in working with all these other companies and the past 10 years of doing support I have found, my co founders have found, the tools we're using don't feel like they were built by support teams, by people who really understand what the day to day work of answering tickets and solving problems with customers and interacting with other teams internally, what that really looks like from day to day, week to week. But also like minute to minute, like the actual work of helping people is really cloudy I think in a lot of tools, and we want to try to solve that and the source of truth actually ties in pretty deeply with it. One of our core tenants is we don't think we need to be the source of truth. For your customer data, for example, or your refund data a lot of tools want to be the source of truth.

Like I said, I think that's good for them. It locks you in to using their tool. Once you become the source of truth for anything within a company, you don't really want to lose that. But we take a different approach. We don't know what your source of truth on customer data is on your refunds on payment schedules, things like that.

And we don't think your support tool should be that source of truth. We want to make it as easy as possible to get your data out of Yetto into whatever tool you should be using and your data that is a source of truth, you might need that data while answering tickets. So we want to give you tools that make it easy to get that data back into Yetto when you need it. It's time sensitive, it needs to be accurate. It can't be some data that's synced once a week because it's too difficult to get some data lake to cross over with your help desk. We want data that's reliable and accurate and in the right place. And maybe this sounds like a terrible thing for a vendor to say, but we don't think we should be your source of truth.

We don't want to lock you in because we tricked you into thinking that. I like to say, and my co founder Nick has caught onto it as well, it's like the reverse Anna Karenina story for support. All happy support teams are happy for totally different reasons and all miserable support teams are unhappy for roughly the same reasons. And we can fix a lot of those. As a community, I think a lot of these are solvable problems. But we want to give you the flexibility to find happiness the way your team needs it.

We want to give you the tools that do away with the things that are making us all miserable and solving problems as easily as possible. While giving you the ways to get data where you need it when you need it to whom you need it. A lot of issues we see are with support teams. You talk about silos. This is the big thing that caused us to create Yetto in the first place, was feeling like support was really siloed from all these other teams and we wanted a way to connect to the engineering teams, product teams, payment teams across the company without jumping into everyone else's tool and without expecting them to jump into ours.

We don't want every finance person to have a seat in Yetto just so that they can look for refund tickets every month and reconcile their data. That's just a terrible way to work. And so we want to give people the tools that we always wanted.

Neal: I heard this one sentiment long before, "yeah, I sent an email to support, but then it's gone. I don't know where it is." I don't know what happened because they just don't have seats in the support to be able to have the visibility and the clarity that they need. So really giving support members the tools they need to focus on the customer, which is the most important thing, having all the information that they need in a simple, flexible and agile format.

What do you think that people can expect to get out of your talk at the expo?

Brian: That this is an actual issue that has solutions and one of those solutions being able to go back to your team the next Monday morning and say, all right here's what we have and here's how we can clean it up. Here's like the next step to make this process better. I think a lot of teams are doing this for things like we mentioned, payments and refunds. Your customer list is just who your customers are, customer activity is a big one that support is often faced with I think these folks who hear this talk and go back to their teams next week and start digging through that data and uncovering better sources of truth that are easier to maintain and easier to distribute through their company that cause less overhead for them, right?

Less frustration, less administrative time going through spreadsheets. Every week, every month, I think the big thing if one person can leave this talk and not use a Google spreadsheet as their source of truth for something, I think I've won.

Neal: Yeah I was having a conversation today with our VP of tech as well. And he's so can you rely on this data? Is it really something that is something we can use? And I was like if I walk through the actual process of how we got this information in the first place, there's too many manual steps to say, Hey, this is good.

So I definitely resonate with that sentiment of Hey, sometimes we need to realize that what we believe is the source of truth or what we've really been putting a lot of energy into isn't necessarily the best source of truth. And we shouldn't necessarily rely on that. And sometimes we should take information at face value and we can touch and understand, Hey we can't rely on in the future as well. Thank you so much for walking me through your beliefs around really maintaining a source of truth, what that is, and letting the people who are going to be coming to the expo know about what they can expect to get out of your talk.

And I could talk about this all day with you. It's really interesting topic. But if you, the viewer, wants to know more about Brian's topic and the speech, where can they reach out to you to talk to you about that?

Brian: So i'm in support driven Slack. So that's always the best place to get in touch with me I believe a lot of people pronounce it bail vine in Slack also on LinkedIn and twitter or whatever. They're calling twitter now. You can find me at brian a levine on Just about all

Check out this video now featuring Brian Levine our upcoming speaker for October’s Expo. Be sure to watch and get a taste of what's to come!