CJ (3:04)

this podcast and you haven't liked it

Host (3:05)

yet, which really pains me. And if you're looking to hire the best finance and accounting talent, I'd love to help you. I run a recruiting service that pairs you with thoughtful qualified candidates from our warm community of really wicked smart finance leaders, people who voluntarily debate warehouse architectures and CAC definitions on weekends. If that's of interest, shoot me an email@talentmostlymetrics.com and we can talk onto today's show with Chris. Chris, thanks so much for joining me

CJ (3:30)

on the POD today.

Chris Byington (3:31)

Thanks for having me on. Appreciate it.

Host (3:33)

Let's kick things off and maybe you can tell us a bit about your role where you work.

CJ (3:37)

Now I know it's kind of like Prince the Artist formerly known as and where the analytics department sits within the larger org.

Chris Byington (3:44)

So I'm the head of data at Superhuman Mail, the most productive email app in the world. We used to be called Superhuman like you were just alluding to. Company has existed for a little bit over 10 years. We were acquired last summer by Grammarly. In October, Grammarly was rebranded to Superhuman. So Grammarly is now known as Superhuman and we are a business unit within Superhuman called Superhuman Mail. The CEO of Grammarly, Shishir Marotra, who is really great, has a funny saying. He says, like it's really hard to kind of rebrand the company. If you have a 16 year old child and an 11 year old child. It's really hard to change your 16 year old's name. It's even harder to switch their names. And so that's kind of what we've been going through as we've Been putting these companies together and developing this new corporate identity.

CJ (4:28)

That's great.

Host (4:29)

And then I know you also work

CJ (4:30)

pretty closely with Matt Hudson, friend of the pod, formerly Coda.

Chris Byington (4:33)

We do, yeah. So Matt is now the CFO of the parent company of Superhuman and he was head of Data and wore tons of different hats at Coda before they were acquired by what's known as Superhum. And so he and I, yeah, work together really closely.

CJ (4:47)

That's incredible. Well, much respect for the combined entity and what you've been able to build there. Maybe you can give us the overview of just the analytics department where it sits today within the large org.

Chris Byington (4:58)

We're a central team. The kind of remit or the mission of the team is like intentionally simple and broad. It's use data and facts to improve business outcomes for customers and for the business. Super simple. And it gives us remit to do kind of whatever data can be most helpful at doing. And we own core analytics, kind of BI reporting, product data science, things like that. But then we also own company level goal setting like, okay, we use the OKR framework and we use connecting the core analytics, the company level goal setting as part of strategic planning to the FPA process. So we have all three of those functions kind of under one roof. So they're perfectly on the same page. So that the strategy and the insights you have about customers in the business and your acquisition funnel, just for example, perfectly kind of ladder up into your FP and a ARR model, which I think has helped us grow a lot faster and make sure everybody in the company is doing things that directly drive business growth.

CJ (5:53)

That's incredible. And it's also why I was so excited to have you on the show today because you're doing analytics in a way that empowers the rest of the org and the decisions that the finance team makes. And you could call it, this is a finance thing, this is an analytics thing, this is a BI thing. But at the end of the day it's just a better decision making engine that you're, that you're creating.

Chris Byington (6:10)

Yeah, yeah, it's been really powerful because you no longer feel this tension of like, well, the goals are this. But the Data science team found this insight that's different and maybe it doesn't ladder up to the team to a particular team's KPI metric or key result that they're trying to track towards. That has been just frankly like some of the most frustrating things in my career where you think you find something so amazing, like you look in the data and you're like, oh, if only we could change this part of the funnel, if only we could change this part of the product. You try to influence and influencing is hard. You try to influence and the answer you get back is well, it's not on the roadmap or it doesn't fit or well, we're already committed to the CFO for these goals and so it can be really powerful to basically pre negotiate that by analytics team being involved in the bringing data to bear on strategic decision making. I think analytics teams have become and are typically pretty good at influencing a B test results and decisions you make about that at the day and week and sometimes month level. I think it's much more challenging and requires much more organizational buy in to have data change people's minds about strategy, about like what are we going to focus on this year and actually change those decisions. But it can be incredibly impactful and can resolve the like the core knot and the tension between the things that you see in the data with the way that people are incentivized in their key results and in their their financial model basically.

CJ (7:29)

And that's the context that the rest of this discussion is going to be based upon. We're going to ladder up to goal setting and decision support. If you'll bear with me, I'm going to throw a couple of training wheel question your way if that's cool. Many of the people listening to this podcast, they want to get more involved in analytics, they want to go up that analytics escalator. What are the lowest hanging fruits for companies who are just starting to adopt an analytics mindset?

Chris Byington (7:53)

Yeah, I think there's a lot of simple stuff that can be done that that are quick wins that basically anyone with kind of the motivation to be more fact and data driven can do. Honestly, I'm not a big fan of like the first thing you do is set up a bunch of tools or do a bunch of engineering. So that's not in the list for me.

CJ (8:09)

I don't think don't just the dashboard

Chris Byington (8:12)

do not provide any solutions that do not have problems. There's kind of some world building to unpack about that. But basically the way that I think about and ask the data scientists on the team to think is the stakeholder should be the expert about the problem first and you should start with problems. Like a typical framework to do that in would be the jobs to be done framework is like hey, you're a customer. If the customer is your stakeholders, what are they trying to do with this information? What are they trying to accomplish. And once you have clarity on that, then it's usually pretty straightforward to figure out what the solution should be to it. Sometimes it is a dashboard, sometimes it is like a key learning. And you can have kind of a repository of learnings. Like, not everything requires a dashboard. I'm not really a believer in that. Anchoring to the problem to solve and engaging with your partner and your stakeholder at that problem level. And like, there's a saying, I forget the exact wording, but it's something like, few problems survive. Their thorough articulation is like, when you, like, fully unpack that, then you're like, okay, cool, the solution's easy. We just need one report or we need. Honestly, a lot of people just need a pivot table. Like literally just a pivot table. And I'm kind of preaching to the choir and kind of pandering because I know this is a finance podcast, but I really do believe that's true. So that's the first thing that I would say that can require some kind of training of, like, how people ask questions of data teams and of finance teams. Typically, the questions in my experience are pretty solution forward. You know, the request is, can you build this dashboard? And my answer to that every single time is, cool, happy to help. Tell me a little more what you're trying to solve for. Like, it's not so much. No, but it's like, cool, let me help you. Let's talk about the core problem. And 70 to 80% of the time, the solution ends up being different from what was originally asked. And that's perfectly, perfectly great. And then over time, you build, you can build this cultural norm where people start to just lead with the problem they're trying to solve. And they're like, cool, can you just kind of figure this out for me? And that's easier for them. No marketing person, no finance person wants to spec out a dashboard. They just want to solve it in the end. And our job is to help them do that. So going back to your question of, like, what are the training wheel things that you can do to start, I think there's a couple things in building an analytics mindset. The first one I would say is get alignment in in your company about what your company's growth model is. That's not a reporting exercise. It requires zero data science and zero statistics. But it says, do all new employees who start within the first week understand how you make money and deliver value to customers? And it says, like, what are the entities in your business? So we have you know, we acquire users on our website, then they visit, then they convert. Do you call that a user? Do you call it a seat? Do you call it a signup? Like you have to use the same language. Otherwise you spend more time swirling about what the growth model is than actually taking action to improve the levers in the growth model. Then do they get to the aha moment, Then from the aha moment, do they monetize it? If you have a free offering or you know, what's the revenue per user and if you can write that like it's one tab, 20 rows maximum on a Google sheet. But the important thing is everyone sees the world the same way. So that then when you say cool, this quarter, the most important thing to improve is activation. Because we feel good about signups, we're fixing the funnel from the bottom up. We're going to focus on activation. Everyone knows what that means and we can all be agreed that that's the most important thing in the business instead of kind of relitigating what the priority should be throughout the quarter or the year. So that's the first thing is the growth model. It's much more important that people be on the same page about what it is than for you to get it perfect. It doesn't have that many steps, to be honest. It shouldn't be complicated. The hard part is making it simple. And so have a flowchart with boxes that you can refer to in every all hands in every brainstorming exercise of the customer journey. It does need to start from the customer and then go from there. So that's the first thing, the second kind of thing to get started with an analytical mindset. When you think about analytics questions or decisions you want to make with data getting you and the analytics leader or your stakeholder into the mindset of pre negotiating the action or thing you're going to do before you see the data. That's how the scientific method works. It basically pressure tests like number one, this analytics project is worth doing because you're going to change your behavior based on it and then it tells you kind of like an a B test, what behavior, what you're going to change based on the results that you see. So for example, if you say, you know, I have a hypothesis, not to get like too technical, but I have a hypothesis that you know, the best way to fix our signup funnel is to fix like conversion at the payment stage. And you're going to say, okay, cool, we're going to map out the funnel, we're going to map each step, we're going to look at the drop off and if the drop off is biggest at the payment stage, we're going to focus there. But if it's not, I'm going to change my mind and I'm going to admit that I was wrong. I think early stage companies can often like operate more on gut feel. You move away and you're willing for your gut to be wrong. Because data is just like a proxy for facts, right? If the facts show that that is not the best area to focus and you focus your attention elsewhere, that's like, I mean, I think in my mind at the heart of being data informed or data driven is being willing to be proven wrong. And until you have that culture, it's just really hard to influence using data because people just want to go with their gut.

CJ (13:14)

Hey, thanks for listening. We'll be right back after a word from our sponsors.

Host (13:19)

Ali and the team at Tabs are building something that directly addresses one of the biggest headaches I see finance teams deal with today. Pulling data from your erp, your CRM, your FPA tools and your usage systems and actually making it all work together. If you're running usage based pricing or complex contracts, you already know how this usually plays out. Contracts live in one system, usage data lives somewhere else. Billing happens in another tool. Revrack gets layered on top at month end and finance ends up just reconciling everything by hand to close the books. This is exactly the problem Tabs was built to solve. TABS is an AI native revenue platform built for controllers and CFOs. It brings together data from your ERP, CRM and real product usage into a single system of record. From there it automates billing, collections and revenue recognition without finance having to duct tape workflows together every month. If usage based revenue is core to your business, this is the future of how billing and Revrec get done. Go check them out@tabs.com run. That's tabs.com run.

CJ (14:23)

We've all been burned.

Host (14:24)

We've all bought that enterprise planning tool that promised the world, only to realize six months later that we've basically taken on a second full time job just

CJ (14:32)

to keep the software running.

Host (14:34)

I want to talk about a company that was built specifically to kill that cycle. Abacum. I actually remember my very first conversation with with their founder and CEO Julio Martinez over three years ago. Back then they were just starting out in Spain. Fast forward to today. Julio moved the home base to NYC and they're the engine behind finance teams at Strava Replit and JG Wentworth. ABCOM doesn't turn you into a software admin. The integrations are actually self service. You don't need a $300 an hour consultant to plug in your ERP or HRIS. And they're doing AI in a way that actually impacts the things FP&A teams are doing every day. Things like creating variance summaries, building formulas and modeling scenarios. If you're scaling fast and you're trying to avoid that legacy platform trap, ABACOM is the move. They're building the future of our tech stack and they're doing it with a CFO's perspective. Go to Abacum AI to see it for yourself. That is Abacum AI.

CJ (15:30)

Well, well, well.

Host (15:31)

Here's what nobody tells you about being a CFO. You'll spend four 50% of your time on stuff that is killing your momentum. The best CFOs I know are business leaders who know how to drive growth in heroic fashion. But most of us end up spending our days buried in manual work. I'm talking about collecting receipts, reviewing expenses and manually reconciling spend.

CJ (15:52)

It's painful.

Host (15:53)

That's why CFOs need Brex. Brex built an intelligent finance platform that pairs corporate cards with built in expense management. Plus a team of AI agents to handle the manual finance tasks for you. That way CFOs have more time for the high impact projects that drive growth. You know, actually worthy of your CFO time. Bottom line, Brex is automating hundreds of thousands of hours of manual finance work every month across 35,000 companies like Anthropic, Coinbase and Doordash ready to spend less time buried in expenses and more time driving results. Check out Brex app brex.com metrics it is brex.com metrics please guys, how the

CJ (16:32)

hell do I have three kids in daycare?

Host (16:33)

Brex.com metrics what you said about understanding

CJ (16:37)

the growth model, that just hit me

Chris Byington (16:38)

like a ton of bricks.

Host (16:39)

Because in my experience, a lot of

CJ (16:41)

people when they build out an analytics program, it's kind of like the adage of software in search of a solution where they don't do the first order thing. Understanding how we make money so they end up gravitating towards, well, what's just interesting. And when you start to chase things that are just interesting without stress testing it against that growth model, you end up doing stuff that's just kind of. This is interesting, but it's not really impactful to anything we're doing.

Chris Byington (17:05)

Often at the Crux of like dashboards that like look cool but don't actually get being get used because the dashboard is like showing like metrics that exist. You can create lots of metrics in a dashboard, but unless we all agree about how the business works and this is showing how the performance of those exact levers that we've agreed are the most important levers and I think the dashboard's probably going to stay on the shelf. You can have reporting in your bi tool once you get that foundation set of like how many views and unique viewers. And is the CEO viewing the dashboard? That's a good proxy. I think that typically makes the difference between those, those data products that do get used a lot.

CJ (17:39)

I had this experience in my prior company. So we were a marketplace that served auto mechanic garages. So you go to get your brake pads fixed, we stood in between the supplier and then the end garage and there were really bad hurricanes if you remember a couple years ago that hit North Carolina, you know, wiped out towns like they were horrible and no one's going to get their car fixed because a you can't drive on the roads and B, the garages have been wiped out. So I remember we were trying to forecast our revenue for the southeast region of the US and somebody said well, we should look at how like weather patterns impact our sales. Instead of going through the pains of mapping out the growth model and what we were trying to identify as a lever within there, we ended up just creating these dashboards that showed how like basically how weather worked, which is not that important to a marketplace. At the end of the day we just said yeah, when there's bad weather, people don't really order as many parts. And we just ended up with all these fancy dashboards that showed basically snowstorm, you know, happen in Minnesota, flood happening in Florida, but there was nothing that we could tie back to use in a decision for the business. I want to talk for a bit about where the analytics function should sit within the org and I know if it's structured correctly it really shouldn't matter where it sits because you're business partnering with people. But if we take this from just the first order principles, if I'm getting this off the ground, does it typically start in an engineering org because it requires some technical know how or am I just making an assumption that that's not really true?

Chris Byington (19:10)

I don't think that's an unfair assumption. I think the answer here is like maybe not that satisfying, which is that it depends on the company. The three primary archetypes are number within finance reporting up into a cfo, if a CFO exists. The second one is operations, if there's a chief operating officer. And then the third, like you just said, is the more technical driven engineering focus. I think it depends probably on two things that are a little bit overlapping, but not totally. The first one is where you have a champion for data driven decision making in the company. At the executive level. I think as companies get larger, you often have a data focused executive who sits on the executive team. So that's like that's the position I'm in, as I said, on the superhuman male executive team. But superhuman male is a little bit more mature. We've been around for a little bit more than 10 years, so that makes sense. You know, I wouldn't expect that at a 50 person company, for example. So then at a smaller company or a company that's getting started with analytics, it's typically either a chief operating officer style person, head of operations, it's the same idea, or a cfo, they're kind of doing similar things. It's like a different font or a different flavor of it. The CFO is going to be more finance driven, of course, the operator is going to be more operations driven. But I think the thing that carries between them is number one, the sponsorship at the executive level to influence decision making with data, that's the same. And then two, the person who kind of has a dream to make the company more data driven overall. So that's between operations and finance. And then I think for engineering, in my mind, one thing that really matters is what the company's product is and how they use data for the product. I think the more that the product that actual customers use is informed by data as it is, like in Grammarly, now known as Superhuman. There's a lot of data that sits behind the suggestions that you get, like in the proofreader for how Grammarly works. And a lot of that is owned by the Grammarly data team. And so within Grammarly, 30 to 40% of the data team's energy is core end user features, which is amazing. And so for that reason, the Grammarly data team sits within engineering and reports into the cto.

CJ (21:18)

If we were to look at the finance function or the finance archetype, let's assume you know, everyone's equally data driven. Are there pros or cons of it rolling up into finance?

Chris Byington (21:28)

I think the pros are you have more influence and maybe more than influence, you have more control. Finance is typically the one controlling budget, depending on the company. But holding departments accountable to delivering the outcomes that they need to deliver and where KPIs and key results are kind of proxies for the outcomes. You don't run into as many challenges with like having trouble influencing without authority. Like you have the authority if you roll up into the cfo. And then the downside I think is that you have the authority is that you're seen as being part of the finance team because you are part of the finance team. A few jobs ago, I was at a company, Heroku, that had been, that had been acquired by Salesforce. The data team was just being built kind of like grassroots. There wasn't like a mission and vision for the data team, but they had hired a few analysts, including my. And they were finding value in it, which is great. And we were within the finance team. And one of the reasons that I chose to leave everybody leaves jobs eventually was that I felt we had kind of hit a ceiling and certain teams were confused about how to work with us because it felt like we were kind of data leaning finance people. And so the product team was like, what are you doing? Leave us alone. But we wanted to help with product moving away from that. One of the things that I wanted was to kind of found a team from the ground up and have a seat on the executive team. And I think that helped a lot.

CJ (22:46)

And then if you think about the operations team, can that potentially be to sales or go to market lean?

Host (22:53)

Because there are.

CJ (22:54)

You gotta use the product data, you gotta use the financial data, you gotta use the sales data. How do you think about that?

Chris Byington (22:59)

There's like maybe two flavors of operations or chief operating officer that you can think of. One of them is the business person where sales and success and maybe marketing roll up. It's basically like the head of go to market or the almost like a chief revenue officer. It sounds maybe like that's what you're referring to. And so I would agree with the shortcomings there. I think it would be uncommon for a central data team to roll up into that executive. The chief operating officer, where I think it can work is the person who is orchestrating how the company operates like Pure operates, how they do goal setting, how they do planning, who's working with the CFO on approving budget. They're the person on the executive team who's saying we need to use okrs and we need to hold people accountable to them. Just as a, as a concrete example, having that level of executive sponsorship can be really powerful for data teams because it's seen as more neutral than a cfo.

CJ (23:52)

Yeah, it is.

Chris Byington (23:53)

But it still says hey, everybody, including product, marketing and sales needs to follow this model of OKRs and hold themselves accountable. So I think that can be very powerful.

Host (24:02)

I think this is a good segue

CJ (24:04)

to talk about business partnering. Maybe you could walk us through your preferred model and how your team partners

Chris Byington (24:09)

with the rest of the org in the past in the model that we use today is like a hub and spoke model. So you have basically three layers of the analytics team. You have two that are horizontal, that are like platform and kind of company wide. One of them is the core data platform which is bringing all your business data into one place. So that when you ask the question, this account that's up for renewal next month, how many support tickets did they submit? What's their ARR and then what's their product usage? It's like really easy to have that data at your fingertips. That's surprisingly difficult to do. That's like the job of a data warehouse. So that's like serving everyone. It's like a platform team. Then the second one is BI and data enablement. That's like the last mile of making sure everyone feels confident they can self serve data. I'm like a big fan of self service but I think it's become kind of like a four letter word, so to speak.

CJ (24:56)

We're going to get to that. We're going to get to that.

Chris Byington (24:58)

I'm excited. And then the third layer instead of being horizontal is vertical which are data scientists who are embedded in individual business units. And that I think has been really powerful. That's like the spoke part of hub and spoke. So you have a data scientist, that's the marketing data scientist. You have a data scientist who's the product data scientist, a data scientist, who's the sales data scientist. And there my definition of embedding is super simple. It's that you spend 80% of your energy with that stakeholder group. You're much more member of their team than you are of the central team. You have a reporting line for like performance management and learning and stuff like that into the central team. But really you spend most of your time thinking about marketing or sales or product. It feels like a member of the team. You're going to the team's off sites, you're living in their, in their goals and you're living into, in the challenges that they have as well. So you just develop that rapport. Not a big fan of like working transactionally through tickets and stuff like that. You need to have a ticketing system. But if most of your work is going through tickets, there's a serious problem. Those embedded data scientists, they can, they can get the really rich context, they can understand the customer and they can like get fully up to speed on the growth model and really act as partners and be more proactive. That does take longer to develop those relationships in that context and to load that area of the business into your ram, so to speak. But it can be really, really impactful. So I found that be super helpful.

CJ (26:15)

Hey, thanks for listening. We'll be right back after a word from our sponsors.

Host (26:20)

You just launched your new AI product. The new pricing page looks great. I'm talking crisp but behind it last minute glued code, messy spreadsheet sheets and running ad hoc queries to figure out what to bill. Customers get invoices they can't understand Engineers are chasing billing bugs. Finance can't close the books. Well, with Metronome, you hand it all off to the real time billing infrastructure that just works. Reliable, flexible and built to grow with you. They turn raw usage events into accurate invoices, give customers bills they actually understand and keep every team in sync in real time. Whether you're launching usage based pricing, managing enterprise contracts, or rolling out new AI services, Metronome does the heavy lifting so

CJ (27:05)

you can focus on your product, not your billing.

Host (27:08)

That's why some of the fastest growing companies in the world, like OpenAI and Anthropic, run their billing on metronome. Visit metronome.com to learn more. That's metronome.com Here's a growth tax nobody talks about Every new monetization model you ship creates a nightmare for your finance team. Ad usage based pricing now you're tracking consumption against commitments. Launch product bundles. That's multiple performance obligations per contract Offer mid cycle upgrades. Good luck reallocating revenue manually. But that's exactly where RightRev shines. RightRev is the revenue recognition engine built for companies that can't afford to let accounting slow down growth. When your revreck is automated, your product team can ship new pricing without asking finance for permission. And your sales team can close creative deals without worrying about downstream chaos. To get up on my CFO soapbox for a sec, I love talking about creative pricing models, hybrid pricing credits, tiered usage. But I've seen too many companies where the sales team is celebrating a huge quarter while finance is still trying to figure out how to recognize half of it. In a world where your pricing model might change three times next year, that flexibility is everything. If you want to scale your monetization without breaking your books, visit right rev.com that's right, rev.com where modern monetization meets bulletproof accounting. Being a CFO, you know how much

CJ (28:30)

I love tools that actually make the lives of accounting and finance folks easier.

Host (28:34)

One of my favorite tools right now is Rylit, the AI native erp. Going head to head with netsuite. Yes, someone is finally doing it. I met Rillet two years ago when were they still in stealth. Since then they've absolutely taken the finance world by storm. Their mission is to make the zero day close a reality. And they're actually doing it. Customers are literally closing their books at 1:35pm on the first day of the month. They've got everything you need to scale your business. Complex revenue recognition, native integrations, custom reporting, multi entity close management and much more. They're only a few years in and are already supporting NASDAQ publicly listed companies. Yes, seriously, if you want to scale your business on an ERP that wasn't built in the 90s, you need to check out Rillet. Book a demo@rillet.com CJ oh cool, that's me. That's R-I L L E T.com CJ R I L L E-T.com CJ Tell them I sent you there.

CJ (29:39)

One of the questions I get pretty often whenever I talk about FPA partnership models or analytic partnership models is what does embedded mean? And I think you finally answered it for me.

Chris Byington (29:48)

It has to be binary, like embedded 50%, like no, like 80%'s the line like you're embedded or you're not. So that I found that helpful. It's clarifying. Yeah.

CJ (29:57)

Self service, can it actually work?

Chris Byington (29:59)

I think if you expect self service to be magical and to fix things overnight just with tooling, it definitely cannot work. There's two things in self service, like heuristics for it that I have in my mind. The first one is that about 70% of questions that are asked like in the ether of data, like in the company, you can never actually measure this but because it happens, you know, in silence. But 70% of questions that are asked about data can be answered without the intervention of the data team. And that's like a good benchmark. Are you at 20? Are you at 30%? Are you at 60? Like you're pretty close. And then the second is a little bit more squishy and more subjective is like you want stakeholders and people who are making decisions to feel confident making high quality decisions based on Data and like the confident thing is weird. We evaluate that with a survey. It's just like a one to five scale, strong disagree to strong agree. Like I can confidently make impactful decisions with data. Like what's your answer to that question? Do you agree or not agree? You have to sit and think about it for a while. That is a hard metric to move. And so that's my definition of self service. Again it's about the problems, the way you go about it. There's a lot more detail there. I am a big fan of like point and click style tools. The main like Looker or we're now using Omni, which is a great tool. It's like a kind of a successor and interest to Looker. I mean tableau works. Power BI works like the key thing that point and click tools do is number one, it forces you to define like the how your data works. It's not quite the growth model, but it's close. It's like if you click a thing that says active users it means the same thing everywhere. That's really important. So you can't get two different versions of the same number and they don't match. That's always a problem. And then the second thing most important I think is it removes the need to write SQL in order to access data. Data teams who invest a lot of time in training stakeholders on writing SQL. I think that's a losing game. I don't, I don't try. Some people want to, that's fine, go for it. If you're a salesperson, if you're a marketing person, if you're an executive, you want to learn how to write SQL just to figure out how much revenue the company made yesterday. No way.

Host (32:04)

Historically I felt like there was a

CJ (32:05)

trade off with self service of you can either have it accurate but it takes a while to get or you can have it really fast. People can then go and repurpose it for their own use cases. And I don't mean that the data isn't statistically accurate. The numbers are correct but the application of it can become fuzzy or nuanced.

Host (32:24)

And that's how you end up with

CJ (32:26)

a CRO that has a different CAC payback period number than a CFO in the same meeting. But somehow they're apparently using the same data sets that they both self served.

Chris Byington (32:34)

I think that probably does come back to the growth model of the company. LTV to CAC or payback period. Those are kind of trying to get at the same thing, a similar thing. I shouldn't say the same, which is marketing efficiency. If you have that in your growth model, the growth model can also have one line that says notes and it can have like a one liner definition of the metric. Defining the metric is relatively straightforward, like aspirationally. The hard part is getting the CFO and the CMO in a room and getting them to like explicitly agree and like sign their name. On the dotted line of this is how we're going to define LTV to cac. It's funny that you mentioned that because that's like an exercise we're going through like right now. Like I had a discussion about it today within Superhuman because the Heritage Grammarly business, a huge business, 40 million daily active users, they've scaled largely through paid marketing, like world class at doing paid marketing. And so they like have a very strong opinion about how LTV is calculated, how CAC is calculated, what the thresholds are. And we're in the process of getting the different business units because there's now three companies under the same roof onto the same methodology for that metric. And that's really challenging.

CJ (33:37)

You had mentioned that you shouldn't be precious about tools.

Host (33:40)

How do you decide whether to build

CJ (33:42)

something internally versus buy it?

Chris Byington (33:44)

This is where having like a very strong engineering counterpart, whether or not they're like in data engineering, but just someone who can think through architecture is really valuable. I think when you're adopting platforms that you're going to put a lot of stuff on top of. I'm trying to avoid saying the word build. Making a mistake can be really, really costly because you have to undo it six months or nine months or 12 months later. And so I think what your jobs to be done on are, what your problems to solve are, is incredibly important so that you can make the right decision. That's like the definition of architecture for me is difficult decisions that are hard to undo later. If you can undo it later easily, don't worry about it. Just like, just like go with whatever you like and if you have to change it later, that's totally fine. That's like the two way door thing. But here I think adopting a BI tool that people are going to jump on and build a bunch of reports in, like if you get the wrong thing and it doesn't do everything you need it to do, you have a serious problem. And so just to give one example, when we were evaluating BI tools, we were deciding between two tools that kind of both vaguely look like looker because we wanted that point and click functionality. It was omni and then it was one other one that I'm not going to name because we didn't go with it. And one of the big differences that we looked at is we realized because we're so rigorous about OKRs, we preferred a tool that had like a spreadsheet style interface in it. Like imagine if Google Sheets had live data and you could point and click data in Google Sheets with Google is working on but they're not quite there yet. That was one of the main reasons that we, that we went with it. There were others about flexibility and things like that. Had we not done that we wouldn't all be in one tool. We would have the BI tool for most stuff like 80% but then we would have like this Google sheet for pacing that's like separate. You want to reduce the amount of energy that's spent debating what's true, maximize the amount of energy, debating what to do about it. That's like a serious problem in most businesses today for example, it's like an easy heuristic of success. We do not use Google Sheets or Excel for any reporting at the company, company wide period. Not one single file.

CJ (35:44)

Maybe next we could hit on how your analytics team owns metrics, OKRs and forecasting, which I think is amazing. What changes in a company when those functions all sit together.

Chris Byington (35:54)

I think the first one is people who are like boots on the ground kind of doing the day to day work. Like people who are actually moving the business forward feel a closer connection to the company metrics. I think it's, it's too common in companies that you know, the company says this is our goal or this is our metric. And then you have I don't know, 20 or 30% of the company that like doesn't feel like they're actually contributing to that.

CJ (36:16)

I've had that happen so many times. You have this one metric and the engineering team is like I have no idea how I possibly help with that.

Chris Byington (36:23)

And yet the engineering team is typically the biggest cost center. They're the only people actually building for customers. Like let's not be mistaken about this and like if we can't articulate that something is deeply wrong. So anyway, so that's the first thing is people feel the connection. And I do think that leads people to make better decisions if they see the through path. The ICs with boots on the ground, they're making the decisions day to day, they're adjusting their focus, they're making trade offs. Having them be able to understand the impact of their work on outcomes and again understand the growth Model. I don't mean to touch on that over and over again, but that's so important. That's the first thing. The second one is during planning, when you're talking about strategy. Strategy is like what trade offs you make in order to reach the goal. It's both the goal are we agreed that this goal is really compelling and would represent success at the end of the time period. And then that's not strategy though. It also needs to have a believable set of actions that you're taking to hit that goal. So here's the goal. We're going to work backwards from that. Here are the actions we're going to take. This is why it's going to get us there. Super, super powerful. Having the same function own those three things. The core analytics and data science, the goal setting and then FP and A allows you to make better decisions in strategy. You know, this product should exist or shouldn't exist, et cetera, et cetera. It usually starts by defining the most important outcome or metric for the company. We usually call that like the hero metric. And that says we're focusing on this and we're not focusing on a bunch of other stuff because you have to say no. So that's the second thing. And then the third thing is I think it just gets people really excited when you have like a very clear line. You have your dashboard that has every single kind of OKR and goal metric on it and it's like curated. So it's a small list and it's focused. Seeing those numbers go up and to the right. You know, you put it on the TV in your office. If you have an in person office or you publish it in a dashboard to the whole company. It's really, really energizing. And when you start to move those metrics, people pattern match about what works, you do more of what works and you accelerate growth.

CJ (38:18)

That's amazing. Sometimes you just gotta let the guest can you talk about a hero metric? Maybe a couple of examples of what a hero metric maybe an easy example

Chris Byington (38:27)

is the journey that we've been on at Superhuman over the past two years to transition from a kind of pure consumer individual user business model and growth model to a teams based business model. And so the hero metric there is the year over year growth of teams. And so from a finance perspective I think is probably appealing. The primary motivator for moving from an individual business to a teams business is net revenue retention. Because individuals kind of can't expand like NRR is expansion net of churn and Downgrade, more or less. There's a couple other things in there but like you get the idea. You can upgrade, you can, you can upsell. But we don't really have that many upsell opportunities for individuals. We have only one or two SKUs, but teams. If you land in a team and you get five users on Superhuman and the company is 100 users, that's a lot of expansion opportunity because you can add more seats. And so our net revenue retention for individuals is very poor. I'm not going to say what it is, but it's well below 100 obviously because you can only turn them or retain them in. Our net revenue retention for teams in benchmarks against the industry is excellent. You know, it's, it's in the mid to high hundreds. We spent basically all of 2024 getting NRR for teams up says like, hey, when we acquire a new team, do they grow under their own power? We were below 100% for teams in 2024, which was brutal. So we're like, well we're not going to add more teams to this bucket because it's leaky. So we worked a lot on expansion, we worked a lot on retention and our hero metric was NRR. So we got it above 100, which means when we, it's like a coin operated machine. When we add a quarter, they grow over their, over, over on their own. You know, you can imagine like the, the candy mountain charts of cohorted, you know, ARR, where like they're all stacking up on top of each other. So you basically have two growth levers. You can acquire new customers but you also grow existing customers. That's the idea. And then once we got NRR good then in 2025 our Hero metric was the year over year growth of teams. It basically gave us another lever. So one lever is net revenue retention of existing customers. The second one is adding new customers who have over a hundred nrr and then the third is just acquiring new individuals who maybe eventually turn into teams. The main trade off there is the hero metric says if we're choosing between individuals and teams, we're going to choose teams every time. And so we didn't do a lot of individual stuff. Whereas I think had we not had that, we would have had to kind of relitigate that prioritization each time.

CJ (40:48)

You weren't kidding. That truly was a journey to get there. It wasn't like you just woke up in the morning and said that's the metric.

Chris Byington (40:54)

No, they both took like a whole year to do it.

Host (40:57)

Maybe next we could talk a little

CJ (40:58)

bit about chip goals because I've heard you say that chip goals are a poor measure. Why is that?

Chris Byington (41:03)

You know what is a ship goal? It's where like the team is held accountable to like delivering something or completing an action or an activity. So for the classic one is for product is like hey ship this, this new product feature for customers and that's. And then if you've done that, you've succeeded. It's not an outcome in itself. The outcome is whatever the product is trying to accomplish for customers. And so I typically think if we're going to put a ton of engineering effort because engineers time is so valuable and so impactful, if we're going to put that into shipping a product for customers, we better understand what, how we're hoping to improve the product for customers and what behavior we want to see. It could be retention, it could be expansion, improving. It could be like CSAT which is a little bit squishier. But I think that's still, I think that's much better than a ship goal is saying we launch the product and CSAT improved or you know, there's lots of customer satisfaction metrics. It doesn't need to be csat. So anchoring to that further down the funnel and holding ourselves to a higher standard of improving outcomes for customers or for the business I think is a much better replacement than just saying did we ship the thing or not.

Host (42:08)

So what process do you use to

CJ (42:09)

set clear in quantitative goals before a team sets off to build something?

Chris Byington (42:14)

In general, I think this does come back to the cultural shift of the training wheels. Getting started with the analytics, of calling your shot with data before you actually see the data. I think that's a really healthy practice here. It starts with the expectation that if we're going to undergo a large project, whether it's an engineering and product project or sales or client success or marketing marketing, then we like we should have a goal for it and more importantly we should understand what it will deliver for the business. Again it's like if there's a solution but we don't know the problem it solves, we probably just shouldn't do it until that becomes clear like what problem it solves is starting with that expectation. Then typically it's helpful for the analytics person to work with whoever is leading the project. We can just continue talking about like a product development example. So this, that would typically be a product manager to talk about okay, what's the motivation for this? What pain point do we think we're solving for customers, how do we think we're going to be solving it? And then what, like, outcome will it deliver for customers? Something that we launched about a year and a half ago was the ability to collaborate within Superhumans, who is no longer single player. You can, like, comment with people on your team so that if you have an external thread with like a prospect, if you're a salesperson, you can comment back between, like the analytics person and the salesperson and have a conversation. You can see the emails come in on the email thread, but your prospect doesn't see the conversation. And that way you don't need to keep sharing screenshots in Slack or something like that. That's what we're trying to solve with that. So it's like, hey, what's the problem we're trying to solve? What outcome will it deliver? And then like, when you have the outcome, if you're very crisp on that, then you can work backwards from that to figure out, like, the proxies for the outcome, which are usually the metrics. Metrics are just proxies for outcomes. Right. And so there we thought about two main buckets of outcomes, just to use that example. The first one was we want to see people using the thing and we want it to be helpful to them. And the proxy for that was usage, adoption and then retention of the feature. There's lots of user interviews that we're doing as well, but those are less quantitative. But the core of it is like, hey, are people getting value from it and continuing to use it? It's not that complicated. And you can use industry benchmarks to understand what good retention is, because that's always the question is like, you're not going to get 100% retention. It's like, what's good enough? And so you can set a goal like that. And setting the threshold is arguably as important or more than the metric itself. You're announcing to the company we have 5% week four retention. That's amazing. It's like, is it? I don't think it is, actually. So you need to be able to say whether it's green, yellow, red. If you can't say that, then you might as well not do it, in my opinion. Then the second metric that we had is like, in a different theme, which was expansion. It actually gets to the net revenue retention point I was mentioning just now. Now, we did have, like an ulterior motive for building this product, which was we were trying to go through a team's transformation and building core product value. That was that that had network effects, where the definition of network effects is the more people in your company are using the product, the more valuable it becomes. We wanted to drive expansion in order to drive net revenue retention. So our metric specifically was do teams collaborating expand faster than teams not collaborating? And we had an expansion target that the product manager owned, which was great. And so that's like an example of how to play it through. And then once you, you have to set your thresholds of what you want to accomplish and once you launch, you have a plan for like, cool. Will we be able to measure this? One week, two weeks out, one month out and that way people have an expectation of when they'll be able to learn whether the thing is working. I typically find an anti pattern for data teams as they get brought in just to like read into the question a little bit that they get brought in like the day before launch, it's like, hey, can you help us measure this? It's like no. Like the answer is no to that. Bring us in six to eight weeks before at least for a large launch so we can figure that out so we can set the metrics so we can get the capture the data. You don't get the data for free. It needs to be captured. And then you can set the expectations for when you'll be able to, you know, report out on what so that you don't get that dreaded ping from the CEO 12 hours after launch. Like, how's it going? It's like, I don't know, like it's only been 12 hours, you tell me. Exactly. And the only way to get around that is to proactively set expectations for what you can learn when. And so I think that's been really powerful as well.

CJ (46:29)

You said my favorite two letter word that I'm trying to use more often. No. You have a high powered team. How do you get better at saying no? Because you have to prioritize what they work on. You can't just throw them at everything.

Chris Byington (46:40)

Number one is if you have the goal system, then projects that don't contribute to the goals are an automatic no. The second one does come back to self service I think is if you are at a point where 70, 60 to 70% of questions are answerable without intervention by the Data team, then 60 to 70% of questions are answerable without intervention by the data team. It only works if it's done to a high degree of quality. So you need to invest a lot upfront in setting those systems up in the point and click and choosing the tools, that's really complicated and it's not trivial but that's really, really important so that people are getting their own data and you can focus more of your team's energy on the stuff that only your team can solve and that other people can't. It's like the 30% to the 70% basically. And then the third thing I think is for the questions that come in, if you anchor really deeply to the problems to be solved, then you can basically stack rank them by the impact that they would unlock on the company goals. It's like, hey, does this help you do sales targeting better to help us hit our sales goal? Does this help you build better product for customers? Customers, because we have an OKR around CSAT or things like that. And you can start to use the company level goals framework to understand the team's contribution to those goals, even if it's primarily through the intermediary of helping the sales team have more impact, helping the customer team do more impact. And I think that's like a really important thing for data teams and finance teams to remember, which can kind of be a hard pill to swallow, is that we don't build any customer facing product and we're not salespeople, so we're actually not customer facing. So our job is to kind of be king makers and help everybody else do a better job. And if you can swallow that with your ego, then you'll go pretty far because you can just help people do a better job.

Host (48:20)

Well, maybe, maybe you can say more about that because I asked you how to say no.

CJ (48:23)

I want to ask the opposite of that question which you started to hit on there. It's how do you encourage your team to be easy to work with?

Chris Byington (48:29)

I think it's about reducing friction, but I also think it's just about how people feel when they work with you and whether they're going to go seek you out. Because that's a lot of what influence is about is like being invited into rooms where your presence is not required but someone's advocating for you. Number one is I do try to myself and with the team, encourage them to start sentences with yes. Like just the word yes. If there's a question like, and this kind of like is that tension with the no thing that you were just talking about? If the question is like hey, can I have this? Much better to say like yes. And if you're familiar with that yes and kind of kind of approach like yes, we actually have 80% of that in our self serve BI tool. How do you feel about taking a stab at that yourself? Here, here's the training for it. That's actually a no. Just to be super clear. You can do that yourself and most people want to do it themselves to be honest. They want to be self sufficient and they're going to get answers way quicker if they can do it themselves. Whether they're in an airport, you know, at 7:00am and they just pull the report really quickly like the constraint is on them rather than needing to wait to hear back from the data team. So then the second thing I think is make sure we're always offering a solution even if the, even if the answer is like not exactly what the person is asking for. So for example if the question is you know, can we build this report or whatever it is, you know and what the, what the data scientist has in their mind is like well my, my plate is full this week. Like I, I can't, I don't have time for it and it's not the right prioritization decision. One way to answer that would be say no, sorry my plate's full. That like that's the whole answer. It's like that kind of sucks and that's like not a good answer. A better one would be yeah absolutely. Happy to help with this. Just so you know I'm working on these other things. Here's what they are, here's why I think that they need to you know stay in this week and then here's the alternative for how we can get this done for you. Either I'll look at it next week or you can do it self service or we have like these little for example these little like pressure release valves. We have like a weekly analytics office hours for an hour where people can drop in and like get little questions answered. That's like again like an ulterior motive of like helping people learn and like do co do kind of working sessions on using self service data but it's also like a place to put all the requests that we don't want to do frankly. And it helps people learn as well and people feel heard because it's one hour, that's kind of time box.

CJ (50:51)

I love how you said pressure valve there and time boxing it as well. That's definitely a tactic that others can steal who are listening to this gearing towards a close. I want to talk about proving impact. How do you know your analytics team is helping the company make better decisions?

Chris Byington (51:05)

I do think the thought experiment overall is like a grand ab test that people should have in their mind when they think about the work that they do and making sure they're having the appropriate level of impact is like, hey, in a scenario where the control is we have no data team and the treatment group is we have a data team, like, how different are those worlds? They better be super different. Like if you can't answer that, like, hell yeah, they're way different. Then like, I think you have a serious problem. There's a couple things. One of them is self service and like data driven decision making survey that I mentioned is like sending that survey to the company, getting those answers back. And you can also often get a lot of qualitative feedback from people on how you can improve as a team. And then you have the survey responses that you can point to and say, we scored a 4.3 out of 5 or whatever it is on average to that question. You know, I can confidently make impactful database decisions in my day to day job. The second one is if you're influencing strategic decisions, like at the, at the company level, you can point to the decisions that are made because there aren't that many strategic decisions in a year that are made at the company level. It's like, do you focus on teams versus individuals? Do you have a sales team or not? Like evaluating sales productivity? And if you're proactively affronting those existential questions, teams versus individuals is a good one. Then you can point to them as like, hey, we changed our mind based on the impact that the data team has had. And then the third one I think is more fuzzy or squishy is like, is there a pull? If you were to go to each person on the executive team and say like, hey, just so you know, I've decided to take this person who's embedded with your team and pull them back to the core team, do they say like, okay, like, sorry to see them go, or do they see, like, wait, stop. Like what can we do? Like, can we fund it from my budget? Like, that's probably a good heuristic. Obviously you want it to be the latter case.

CJ (52:56)

That's an amazing explanation. And I couldn't agree more about the poll part. You can't totally measure that. But if some, if you, you went,

Host (53:03)

I always say, if you turned off

CJ (53:04)

that system, would people scream? Would they notice? Same thing if I said, hey, I'm going to take that FP and a analyst away from your team. If they say, oh man, well, well, thanks. The contributions, it's like, ooh, oh. But if they say, oh, wait, can

Host (53:18)

I give you budget Back for something else.

CJ (53:19)

We cannot have like Kyle leave.

Chris Byington (53:21)

Exactly.

CJ (53:22)

I want to take you into what we call our long ass lightning round. So every successful leader I have on the podcast, Chris, I asked them to give me one example of something they've screwed up on the job before. It could be this role or any other.

Chris Byington (53:34)

Let's see. My first job, I had a report that was due by a very solid like, like deadline that couldn't be moved. And I was working directly with the like most senior partner which was like a big stretch for me when I was early in my career. And I opted towards getting all of the crossing the T's and crossing and dotting all of the I's. But that caused the report to be delayed and to miss the deadline and he was not happy. You know, done is better than perfect and you need to gauge the balance of urgency versus versus polish.

CJ (54:04)

That's a good one because like I came from a consulting background and everything had to be perfect. Like our product was what we sold. There was no, there was no widget in the factory. Right. There was no software. It was like our PowerPoint decks. I remember getting in like this tiff with my manager at the time of the Shade of Green because I was at the mind like well I did it and she's like, well we don't

Host (54:24)

have anything else to sell.

CJ (54:24)

Like if this isn't right then we have nothing thing. Then I went over to the other side where I was an operator and there are no style points for the deck. You want it to look well, you want it to present your own personal brand well and the company well.

Host (54:37)

But you still just need it to

CJ (54:39)

be shipped at some point. And I know we talked about ship goals, but like you gotta get shit done in order for there to be any sort of revenue at a company. Next question I got for you here. If you could give your younger self advice, knowing what you know today, what would you tell them?

Chris Byington (54:53)

Don't take work so seriously. Maybe it's not all about work. I think, I think people who are passionate, I think it's tough to disentangle and to like not have so much of your of yourself wrapped up in work. Because people like I love my job. Like, I kind of can't believe that I get paid to do this, to be honest. But I think there's been plenty of times, especially now having, having kids that like, I need to dial it back.

CJ (55:14)

And for the benefit of listeners, Chris and I, we probably cut it out. Chris and I both have had children try to break into the room. Next one more of a technical one. Can you walk us through your tech stack? What tools does your team use to get the job done?

Chris Byington (55:26)

The relatively standard like modern data stack as it's known. So the center of our data warehouse is Google BigQuery, which is a column store database. We get data into it with fivetran, which is just off the shelf software for etl. We like massage and transform the data with dbt which is an open source data transformation framework. And then we report on things with Omni, which is a third party BI tool.

CJ (55:53)

Awesome. What's the most recent tool you bought?

Chris Byington (55:56)

Omni. We. We transitioned to Omni about 10 months ago.

CJ (55:59)

Last one I got for you. Best advice for getting promoted.

Chris Byington (56:03)

Stop trying to get promoted. I think like focus on the things that your manager cares about and particularly that contribute to the company. And then the promotion is the exhaust, not the goal.

CJ (56:13)

Chris, this has been an excellent conversation. I really appreciate you carving out time for us.

Chris Byington (56:17)

Yeah, thanks for having me on. Appreciate it. It's been great.

CJ (56:19)

Run the Numbers is a mostly media production.

Host (56:22)

Yelling an intro by Fat Joe. Artwork by Meg delesandro.

CJ (56:26)

Show is executive produced by Ben Hillman.

Host (56:28)

Nothing said on this podcast is intended to be business or investment advice. It's the sole opinion of me, a guy who feeds his dog way too much ice cream and has a history of net operating losses. If you like this podcast, hit subscribe and give us five stars. It will take like two seconds and our algorithm overlords love it. Drink water, call your mom and have a great day.

Chris Byington (56:47)

Peace.