The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/AI & Data/The Stacked Data Podcast
The Stacked Data Podcast artwork

044 - Synthesia: Data Director - Why Data Teams Should Stop Trying to Be in Every Room

The Stacked Data Podcast · 2026-06-17 · 52 min

0:00--:--

Key moments - from our scoring

Substance score

59 / 100

Five dimensions, 20 points each

Insight Density12 / 20
Originality13 / 20
Guest Caliber13 / 20
Specificity & Evidence12 / 20
Conversational Craft9 / 20

Ed Mansi, Director of Data at Synthesia (an AI video platform), makes a compelling case for reframing data teams as operational enablers rather than analytical service centers. Rather than embedding analysts across teams or becoming gatekeepers of dashboards and reports, Synthesia's approach is to build a self-serve platform that empowers business teams to answer their own questions. This strategy reflects Ed's philosophy that real business success comes from operational execution - not decision-making - and that data teams should be multipliers, not points of failure. Synthesia's structure includes a small, focused platform team (data engineers, product analytics, analytics engineers, and a new Knowledge & Enablement Manager), alongside operational roles like Rev Ops who sit within commercial teams. The company uses Fivetran, dbt, and Omni for their BI layer, with recent additions of Claude integration. Ed argues that by drawing clear boundaries around what the data team owns, they can scale with the business without becoming overwhelmed. He emphasizes that the SDR manager who independently discovered the call-to-connect problem wouldn't have been found by a data analyst - it required operational domain knowledge.

Key takeaways

  • →Data teams should focus on being operational multipliers through self-serve platforms rather than embedded analysts, to avoid becoming bottlenecks as the company scales.
  • →Success metrics should track whether business teams are actually using data to perform their jobs better and hitting their targets, not just dashboard views or ad-hoc analysis completion.
  • →Clear boundaries between what the data team owns versus what business functions own (especially operational roles like Rev Ops) prevents the data team from becoming a point of failure for rapidly growing commercial teams.
  • →The best analytical insights often come from people with deep operational domain knowledge in their role, not data analysts, so self-serve tooling enables faster, more contextual discovery.
  • →Operational hiring decisions - like ensuring commercial teams have Rev Ops staff comfortable with SQL and data tools - should be owned by those functions, not the central data team.

In this episode

  1. 1Ed Mansi's Background and Career Path
  2. 2What is Synthesia and Its AI Video Platform
  3. 3Defining the Core Purpose of Data Teams
  4. 4Measuring Data Team Success Through Operational Impact
  5. 5Operational vs Analytical Data Strategy
  6. 6Data Infrastructure When Joining Synthesia as First Hire
  7. 7Building and Scaling the Data Team Over Two Years
  8. 8Platform-Based vs Embedded Analytics Approach

Mentioned

SynthesiaOmniEd MansiGoCardlessBrandwatchSnowflakedbtFivetranMetabaseClaudePerplexity

Guests

Ed Mansi

Topics in this episode

product analyticsSnowflakeRev opsdbtFivetranSelf-serve analyticsSynthesiaOperational analyticsOmni (BI tool)Claude integration

Questions this episode answers

Why did Synthesia choose self-serve data platforms over embedding analysts in teams?

Embedded analysts become bottlenecks when commercial teams grow faster than hiring allows, making the data team a point of failure. Self-serve platforms with clear boundaries let the data team scale as a multiplier, while business teams own their own dashboards and analysis.

What should data teams measure to know if they're succeeding?

Track whether business teams are actually using data operationally in their jobs, hitting their targets, and whether utilization and user satisfaction are high (near-weekly usage for most users indicates good adoption).

How did Synthesia structure its data team after two years of growth?

A small platform team handles data engineering and infrastructure (Ed plus a data engineer), with separate specialists in product analytics, commercial analytics engineering, data science, and a new Knowledge & Enablement Manager focused on self-serve and AI tooling like Claude.

Why does Ed think SDR managers discover better insights than data analysts?

The SDR manager who identified that call-to-connect drops after 5-6 calls wouldn't have been discovered by an analyst because it requires deep operational knowledge of how the SDR role actually works - self-serve tools enable that domain expertise.

What's the role of Rev Ops in Synthesia's data strategy?

Rev Ops sits within the commercial team, handles data work including SQL and dashboarding, and acts as the business partner embedded in commercial processes, reducing the need for central data team involvement.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

12 / 20

The episode contains several genuinely non-obvious operational ideas - treating the data team as a deliberate non-embedder, the two-layer semantic model for AI, and the auto-PR feedback loop for wrong numbers - but these are diluted by extended career-advice segments, generic self-serve commentary, and sponsor content that pads the runtime.

if I say that the data team are responsible for building reports and dashboards for the commercial team, and the commercial team is growing very fast and I'm slow or hiring or something goes wrong or whatever else, I become a point of failure for the commercial team
we've now had to go through a process of rewriting the entire semantic layer, um, for AI. Um, but we've found that with cursor, we can create a new topic in 10 minutes

Originality

13 / 20

The deliberate-restraint framing - data teams should explicitly refuse ownership of dashboards and hand accountability to business users - is a contrarian and coherent position rarely argued this directly; the 'two semantic layers' concept (warehouse layer plus AI skill-file layer) is a fresh structural idea, though some surrounding points about self-serve and stakeholder respect are familiar.

I don't actually think that comes from decision making... from my experience where companies really succeed or fail is their ability to actually operate and execute well
I think my most controversial view is I think that a lot of data people, particularly semi junior data people, to be honest, I think they don't have enough respect for their stakeholders

Guest Caliber

13 / 20

Ed Mansi is a genuine practitioner who was the first data hire at a credible, high-growth AI company and previously held go-to-market analytics roles at GoCardless and Brandwatch; his cross-functional commercial background gives his operational views real grounding, though director level at a ~Series C company is solid rather than exceptional seniority.

I was the first data hire there when I joined two years ago and uh, I'm responsible for the data platform as a whole, um, across product and commercial
before that I was um, managing kind of go to market analytics at GoCardless and then before that I kind of cut my teeth at uh, variety of different roles at brandwatch where I was for sort of eight years

Specificity & Evidence

12 / 20

The episode has several concrete data points - 10x Snowflake spend growth in 12 months, a July 2024 go-live that was months ahead of a January 2025 plan, 150% quota attainment attributed to an AI workflow, and a 5-minute PR turnaround - but many of the operational arguments remain at the level of illustrative anecdote rather than being backed by systematic evidence or broader benchmarks.

in a 12 month period we'd seen something like a 10x growth in the Snowflake spend
I joined in late April two years ago. So 2024 and so I imagined that we'd be going live with something in January, February 2025. We actually ran the ballpack out of Omni in July 24th

Conversational Craft

9 / 20

The host asks a few legitimately probing questions (calling out whether the self-serve model only works because Synthesia hires unusually technical people, pressing on blockers) but the pre-existing relationship, the fact that Omni is simultaneously the episode sponsor and the guest's primary tool, and a pattern of validating responses before following up all constrain genuine challenge and allow several key claims to go unexamined.

One thing I think that uh, if I was another data leader, uh, listening to this, that I might question is Synthesia is arguably one of the most exciting companies globally, hires very analytical, tech focused people across the business
I think that's an excellent um, way of framing it and yes, really good tangible both there

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Share of words spoken

  • Speaker A76%
  • Speaker B24%

Most-used words

data77team63omni27teams22responsible21wrong21commercial19synthesia18sales17build15ultimately13building12better12different11semantic11side11

Episode notes

Ed Mancey has a take that a lot of data leaders won't like - and he's got two years of results to back it up. As the data team lead at Synthesia, Ed has built his function around a single idea: the data team's job is to be a multiplier for the business, not a bottleneck. That means owning platforms and tools, not seats in strategy meetings. It means drawing hard lines on responsibility. And it means trusting your business users to actually use what you've built. In this episode, Ed breaks down how he's applied that philosophy at one of the UK's fastest-growing AI companies - from a two-year Omni implementation to enabling a sales manager to hit 150% of quota using tools his team built, without a single BI dashboard in sight.

Full transcript

52 min

Transcribed and scored by The B2B Podcast Index.

Speaker A: If I say that, uh, the data team are responsible for building reports and dashboards for the commercial team, and the commercial team is growing very fast and I'm slow or hiring or something goes wrong or whatever else, I become a point of failure for the commercial team, which is exactly what I don't want to happen. He was 150% to quota as a team last month and he says that this played a big role. Right. And that's what I mean by being operational. Right. Ultimately, we provided the tools for him and his creativity to do better at his job than he would have done before.

Speaker B: Today's episode is brought to you by Omni. Than most companies I speak to want AI analytics but are failing to put projects into production. That's where Omni is different. It's the semantic brain that grounds AI in the heart of your business logic, giving you governed answers, whilst also the depth to identify root causes. It's intelligence everywhere, from your spreadsheets to their chat feature, even within your product. Omni moves you beyond the dashboard. Don't just take my word for it. Trust teams like Perplexity and Synthesia that are already using Omni to deliver intelligence that people trust. Check out them in the show notes or visit Omni Co. That's O M N I co. Now back to the show. Hello, everyone. Um, welcome to another episode of the Stacks Data podcast. This week I'm joined by Ed Mansi, the director of data at Synthesia. Today we're actually going to jump into what a data team actually is for and m why Ed believes sometimes data teams focusing on the wrong things. We're going to unpack his view on how data should be operational and not just analytical. How he structured the team at Synthesia to reflect that and why he's deliberately drawn hard, huh, Boundaries between what the data team does own and doesn't own. We'll also touch on self service and AI and tooling and include how they're using Omni, um, to change the way that they look at data across the business and commercial teams. Ed, it's great, uh, to have you on the show today. Thanks for joining me. How are you doing?

Speaker A: Yeah, thanks for having me, Harry. Uh, I think about half of our team has come value in some form or another. So it's great to be on and to join you.

Speaker B: Excellent. Yeah, no, really looking forward. It's been a pleasure working with you and helping build the team and I think I'm, um, really keen to share more about your view on it because I think it's definitely very forward uh, looking and the type of organization that you've been in obviously at Synthesia and previously. So um, yeah, for the audience. Ed, I obviously know you well. Who are you, what's your background and how did you get to where you are now?

Speaker A: Yes, I'm Ed and I'm the director of data here at Synthesia. Um, before that I was um, managing kind of go to market analytics at GoCardless and then before that I kind of cut my teeth at uh, variety of different roles at brandwatch where I was for sort of eight years. Um, my background actually there is. I joined in the Rev Ops team at the first doing sort of like order management type stuff. So the first stuff I was doing was whenever a sales order came in, checking there was a PO number and that the address was correct and all of that kind of stuff. But there's an opportunity there to do some kind of sales analysis on the side. Um, and I think over my time at brandwatch I must have worked functionally as a marketing analyst at times. Sales analyst, finance analyst, strategy analyst, lots of different bits. Um, and so my background's definitely more on the analytical side and the kind of commercial side I guess, or the operational side. Um, but now it's Synthesia. I uh, was the first data hire there when I joined two years ago and uh, I'm responsible for the data platform as a whole, um, across product and commercial and then all of the commercial and operational ways we use data.

Speaker B: Excellent. And who asks Synthesia?

Speaker A: For those that don't know, yes, Synthesia is um, sort of an AI video platform. I um, think the way to describe it really is that uh, um, we all sort of know that video is more engaging than text. Um, but video generally is far more expensive historically to create and also to maintain. Um, Synthesia gives you the ability to have 90% of the engagement benefits of video. I mean it doesn't look exactly like something shot in the studio, but it's not too far off. But with 10% of the cost of making video. Um, examples of the kind of places where we have success would be sort of like learning development teams or other teams where they know they get a big benefit from using video but sort of can't afford to be going in a lot or something like, I don't know, an explainer for a water bill is uh, the kind of topic that actually the text needs to change very often. Um, so it's quite hard to have that be an ongoing thing that you can have on your YouTube channel, but with Synthesia, videos become living docs. So in the same way that you can update a Google Doc and it says something new, you just type in a new script and you get something new back. So if you've got something, um, like, I don't know, explaining a water bill or something, it's very good for that. Um, and so we're a tech company based in London, uh, providing AI video.

Speaker B: Amazing. Yeah, no, I think, um, one of the coolest sort of AI companies coming out of the UK for sure. And if not, um, the. The world. So check them out. Um, okay. So, Ed, taking a step back, I suppose, what, what's your view on what a data team is actually for? Why, why do you actually exist, in your opinion?

Speaker A: I think data teams exist to sort of help people in the company do sort of their jobs and ideally any job where sort of data might or might not be useful. So, um, that might be, I, uh, don't know, like, um, uh, a manager for an SDR team needs to understand in detail the performance of each of their reports to give them more support. Or it might be, um, a member of the customer success team needs to, um, you know, tailor the outreach to a specific client based off their recent usage. Or it might be, um, how do we sort of like programmatically make sure that the sort of the right lead goes to the right person. So at its core, data itself is like, I think, quite a tangible thing. Right. Every sort of like row or record in a database. It represents something in the real world. Um, and so the data team is taking those representations and making it kind of structured and clear and whatever else, but then making it as easy as possible for people to then use that on an ongoing basis, uh, for their role.

Speaker B: Excellent. And how do you measure success? I think that's the thing that most teams are looking at. What are the signals that, uh, you should be tracking and maybe what are the signals that you shouldn't be tracking for the success?

Speaker A: Um, for us, I think that the main thing I think about is that there is a lack of, um, sort of like a combination of people in the company are doing their job, using data and they're happy. Right. Ultimately, particularly for our commercial teams, if our commercial teams hit target, we're doing well, and if they don't, we're not. Right. And that we should hold ourselves to that and be like, fully aligned with that. Um, and so you want success stories and whatever else that happening, and we have a lot of those. Um, and then it's a basis of then providing a platform to that and how successful it is. So do people have access to the data they need? Right. Like is the data modeled in a way where they'd expect it? Are all the business systems they need lined up? Is it kind of seamless and easy for them to do? Right. So it's almost like the user satisfaction and we can see that in things like um, we have very high utilization of Omni as an example. Um, I think that we've grown that steadily and significantly and we have almost no users who don't use us on a weekly basis. Which is a really good example that we're doing something well and baking something in into a workflow rather than a kind of a one off piece. Um, and where it is frustrating and we had some issues recently around uh, our customer success team being frustrated with the amount of product usage data they had. That's an example of where you know you're failing, right? Because ultimately there's someone saying I would like this piece of data to do my job better and I don't have it available to me.

Speaker B: You said something really interesting though obviously about embedding into workflows and I think that's something that you've spoken about a lot about data being primarily operational um, and systems focused rather than just this sort of ad hoc analysis type of work. Can you help sort of explain your thoughts and beliefs around them? Points?

Speaker A: Yeah, I think that as a team you're looking to drive kind of business impact and to be aligned with a successful company. And um, in general I don't actually think that comes from decision making. I like it's obviously important for companies to like make the right decisions and have a big bet. But um, from my experience where companies really succeed or fail is their ability to actually operate and execute well. Um, and if you can play a bigger role in that, I think that you're going to like have more leverage and be more successful. Instead of the question is not sort of like are the people you're working with making the right decisions. It's like, are they performing well in their jobs? And if everybody's performing well in their jobs, the company's going to do well. So you should hold yourself accountable to what you're accountable for and let others hold themselves accountable for what they're accountable for. But make sure that whenever they sort of need your support, you're kind of giving it in that way.

Speaker B: Interesting. Something I think I'm um, keen to unpack a bit later in a bit more detail Particularly I think with your career, um, uh, path as well. But it would be good to understand. When you joined Synthesia you said you first data hire. What was the landscape of data? Was uh, that all in? How was it perceived within the business? And then. Yeah. What have you set out to build from there?

Speaker A: Yeah, when I joined there was something which had been built sort of like jointly by the uh, head of Rev Ops and the head of product at the time. So there's a, a DBT pipeline on top of Snowflake 5 transfer ingestion. Um, there was no BI tooling at all actually. Um, and it sort of, it worked well enough in that sort of for the right power user, it got the right output but it definitely wasn't structured in the way a data person would structure it. Um, uh, and I think as an example the DBC pipelines were kind of slow and they failed a lot and they, they weren't reliable or um, they use metabases to be I tool and you know in every single uh, SQL query in Metabase there would be sort of like a CTE that calculates segment as an example. Right. And that's obviously something that actually you want to standardize in your etl, right. So that everybody's seeing segment in the same way. So it was a bit, it was a bit all over the place. Um, and the lack of a BI tool was particularly sort of concerning for me knowing the growth it was about to go through and it served a very small number of very technical users very well. Um, but it didn't serve the broader business at all who had very little access to be able to self serve on data. Right. Everything had to go through um, a Rev Ops person or ah, kind of a product person because you know there was no it's going to self serve tooling. Um so for me that's kind of the first thing to do which is it seemed obvious was to try and rebuild and we started from scratch the DBT pipelines in a way which would scale, which would be easy to maintain and where um, you know we, I just spinned off all the old code and kind of started again from scratch. And then the other thing is knowing my strengths and weaknesses, it was to bring in a data engineer. Um, because in a 12 month period we'd seen something like a 10x growth in the Snowflake spend which happens when you don't have optimized pipelines. You've got a fast growing company. Whatever else it's like well we need to get that under control. And again understanding that the risks to data generally being something that can be used a lot is actually the platform falling over. Right. So the first thing to do is to bring someone in to solve that problem.

Speaker B: And um, now two years later, how's it started to sort of all piece together? You started with yourself stripping back all of the code, bringing in uh, a data engineer. What's the makeup sort of two years later and what have been some of the biggest challenges along the way?

Speaker A: Yeah so the makeup now is that we've got quite a mature team. Um so uh, on the sort of data engineering and platform side as myself and a data engineer and we're bringing other data engineering um, we've got on the kind of a bit separate to us on the product side we've got a product analytics team who's kind of of server product, individual product needs very well. Um and then we also have on the kind of commercial side someone who does all of an analytics engineer who uh, does all this sort of the business logic, um uh data scientist who um, does some really cool interesting stuff actually about uh, you know building models for kind of commercial benefit. And then we recently brought in someone who's sort of fully focused on the front end. So the title's AI Knowledge and Analytics Manager or Knowledge and Enablement Manager something like that. Um but really it's uh, we're moving to a new world where people are going to want to interact with these tools differently. We think it's right to have someone full time on that self serve experience. Um so it's still quite a small team and I like that, I like that, that kind of way of working where there's no kind of task management, we can sort of trust each other um, and work pretty fast. Um and things are fairly stable for our old stack which is 5tran dbt omni for our bi tool. Um but we only this week launched Omni and Claude and I think there's a kind of a new stack and a way of working which um, we'll see. And we've also brought in someone on the finance side for a data engineer. So that's a team structure.

Speaker B: Nice. Excellent. And yeah, I mean you mentioned obviously this AI knowledge analytics manager uh, um lady called Gina uh that we, we brought on board and we're actually going to be recording an episode to dive deep on her role uh as this sort of AI knowledge manager and owning the self serve uh, um a lot deeper. I think one thing that's clear is that you've sort of focused in on Building um, the platform that is enabling self serve at scale rather than the embedded type approach, which I imagine is probably more familiar than companies like GoCardless, um, has that been the right call? What made you make that decision to build more of a platform that is a bigger enabler rather than this embedded, um approach we see so often over the years?

Speaker A: It was definitely the right decision for us. M. And I think that for, uh, sort of two reasons. One is, uh, you need to draw a line between what you're responsible for and what you're not responsible for. And once you decide you're responsible for that thing, you need to live up to that and be responsible for it. Right. And that means that you need to resource against it. And more importantly, if you're not able to deliver that, that becomes a blocker to the business's growth. So if I say that the data team are responsible for building reports and dashboards for the commercial team, and the commercial team is growing very fast and I'm slower hiring or something goes wrong or whatever else, I become a point of failure for the commercial team, which is exactly what I don't want to happen. Right. So the more that I can say what am I going to actually be able to scale and deliver and draw that line and really focus on that? The more that I can make sure that I'm a multiplier for the rest of the business rather than a potential point of failure. And you kind of scale the business in a weird way. And suddenly when you have a data team and I think we've all worked on them and you now have like 20 analysts or something, it all kind of changes and it's very, it's very difficult. Right. And hard to run in the same way. And it becomes a point of contention. And on the other side, um, I think you really get worse outputs where say, um, I don't know. We have a quite a big SDR team and one of the SDR managers was able to build a dashboard looking at um, call to connect and how that was changing. And in their investigation they found that um, after we call a number five or six times, it's very, very unlikely it's going to be connected. Sounds obvious, but they were able to do that and understand that the reason why the call to connect was dropping is because we weren't providing enough new phone numbers to the team and they were re ringing the same numbers too many times. Um, that isn't. Now I explain it to you, it's kind of an obvious thing to look at, but I Just don't think it's anything that any data analyst I've ever worked at, worked with, would look at. Actually when you take a step back it requires quite deep operational knowledge of that job. Um, and so I also think that you get a much better set of analytical answers and responses when you take a step back and you pass it on to the team and you say, look, your job is to use this operationally. Right now I will provide you with uh, tooling, I'll make it as easy as possible for you to use, I'll provide you with the training and enablement, I'll support you if you have any questions on how to do anything or not. But ultimately it's not my job to build reports and dashboards for you. That's your job, right? Because you're going to use it. So it needs to be as tightly bound to the way you work as possible. Um, and so that's why we've really focused on being that multiplier, on making it as easy for the end user as possible and giving them as much freedom as possible. And also saying, and this is probably the hardest thing, like if I'm not responsible, then I'm not responsible. What that means is that like if you go and you build a measure and it's looking at the business in the wrong way, that's your problem, right. And your problem to fix. And that uh, everybody is comfortable with that and that's how we work and that's fine. And showing that restraint is important, right? Because once you start involving yourself again, you become responsible and then you're the blocker on the business. Right. And we've grown incredibly quickly while I've been here. Um, and I don't think we would have been able to support that kind of growth if we also decided we needed to be embedded in all of the teams.

Speaker B: It's a really, really interesting point and something, yes, AI is becoming more and more prolific and smarter than um, we can imagine. I think it's all about the framing of the problem and asking the right question. Um, as we move into this AI analytics era. I get what you're saying, that the business um, stakeholders, the people that are in the teams and dealing in their day to day challenges, they're the ones that can hopefully ask the better questions maybe than the analysts. Is that sort of the, the idea?

Speaker A: Yeah, definitely. And I think that um, like you have to come at it with a, ah, kind of a humbleness and respect of other people's world. Right. Like you know, I remember I've had times in my career where someone more senior who's not worked in data has said, oh, you know, like, can we change our tool stack in this way or get this or whatever else. Right. And I felt um, a bit insulted by someone telling me how to do their job. But also I felt like just in general not made the right choice, they've not had the right information in front of them. Right. They don't know. And that there's uh, something the same with, like if you bring in someone who's ultimately a data person first and you ask them to build a sales dashboard, they're not a salesperson or sales manager. And so they just don't know or quite know in quite the same way. And there are subtle things they would or wouldn't look at, but I think those are important. Um, and so I think you have to take the craft of other people's experience seriously and you have to accept that they ought to be running their teams and they're responsible for the ultimate outcome. And so they should therefore be given the kind of the freedom to work as they want.

Speaker B: One thing I think that uh, if I was another data leader, uh, listening to this, that I might question is Synthesia is arguably one of the most exciting companies globally, hires very analytical, tech focused people across the business. I would imagine what you're talking about is putting quite a lot of onus on obviously the other teams. How have you found that enabling them and their uptick on um, building dashboards being a bit more technical? Um, yeah. Has there been any blockers there? Because I know there's definitely organizations where the stakeholders wouldn't have the. Know how to maybe do that.

Speaker A: Yeah, I think it's like identifying the bits of the business which you need to work with closely. So um, there are definitely people who wouldn't be able to build dashboards and reports. And I love Omni. I think it's a great tool. I don't think there's any bi tool that's easy for the wrong set of users to use. Um, but then I think it's identifying and making the case for those teams to then be responsible for resourcing against it. So we have a very strong Rev Ops team here. Um, I think all of the Rev Ops team are comfortable writing SQL and working with Dazedra and whatever else and they build out a lot of it. But they are the business partners of commercial uh, team. Most of them have worked in commercial roles before, before and they sit in on all the commercial stuff in a way that we Don't. Right. So like from my perspective, if, if I have someone who's joining all the forecast calls, who works on sales training and enablement, who used to be a salesperson, who is actually the sales ops person, for me, that's not like they can build a dashboard. Fine. Right. The point is that like it's up to the sales team to decide do they want a sales ops person doing that or do they want the sales managers doing, doing that or whatever. But that's their choice to make. Right? And if I'm in a function, if I'm in a place where no one in that department has that skill set. So if it's the case that uh, I'm, I don't know, I'm uh, a, I'm a data leader and I'm working with a commercial team and none of the commercial leaders feel comfortable working with data and also there's no operational function working with data there, then I think my job is to try and make the case that they need to hire an operational person who has a skill set rather than that person, be a data person. Right. And at a start there might be dotted lines and whatever else, but they kind of have to really live on that side of the house, right. Not be sort of seconded over there or like a spoke. They really are a member of that team first and foremost.

Speaker B: Interesting how um, pan out at uh, Synthesia, ah, is like, is this something that you pitched and sort of, Is this sort of the vision you had from day one or is this something that sort of grow, um, sort of embryonically or you know, and how would you position that? Uh, again if you uh, you said, obviously, you know, you doused that other team to make a hire in that space. I'm thinking about how would other leaders, maybe they're listening and thinking what you're saying sounds really relevant, but how'd you actually get there?

Speaker A: I mean I'm lucky that Tony, who's uh, sort of the senior director of Rev Ops here, he's very technically minded and also wants to work that way and also wants all the members of his team to be able to work that way. Um, and then I think the other thing is, I was very clear about this from day one, right. That like, this is what I think I am and I'm not responsible for. Um, and in a weird way people quite like it when you're quite direct about what you're not going to do. Right. Particularly if you say alongside it. And you know, I don't want this resource I don't want this, I don't want whatever else. Right. Like I'm not saying, um, just look, I'm not responsible for this. I'm not going to do it. I'm saying, you know, if you want me to be responsible for dashboards and reports and whatever else you need to hide, hire me a team of six analysts or whatever. But I don't think that's a good use of my time or your time or whatever else. And the right way to do it, I want to run a small team and have that live outside. Right. So I think, I think you've got to uh, give up some headcount and give it some resource to do it. Right. Because you are ultimately saying you're responsible for less, um, and then make the case that those people fit better on the other side. And um, in general I find that people are quite receptive to it because people want to own their own number. Right. Like if you're um, a sales leader, kind of. Nothing is more frustrating than you having a view on the business and someone else telling you that actually their view is to view on the business and is correct and not yours. Right. That must be incredibly infuriating. So I think people actually are very happy for the people who have the view on the business and who support them to be very close to them.

Speaker B: I think that's an excellent um, way of framing it and yes, really good tangible both there. Actually we've mentioned a few times about your stack and your Omni's come up um, uh, quite a bit. Um, you've been a customer for two years or so now as well as what I say one of the first things you got in, um, how has Omni changed how you guys and the business interacts with data and particularly as you know we move into this sort of AI analytics space, um, um, and the self service that that can unlock. It'd be good to help understand what, what transformation that's been.

Speaker A: Yeah, at first uh, Omni was what enabled us to really scale out super fast. So um, what I love about working at Synthesia is the kind of the freedom and the pace and I was used to a slower environment and when I joined I put a roadmap ah, together for bi tooling. Um, and I imagined I'd spend a couple of months, you know, getting all of the requirements or whatever else and then a couple of months doing vendor evaluation and then probably three months to six months of onboarding. So um, I joined in late April two years ago. So 2024 and so I imagined that we'd be going live with something in January, February 2025. We actually ran the ballpack out of Omni in July 24th. So like you know, we just went straight in super deep. Um, and that's because part of saying to the rest of the business is you uh, you're responsible. Is it saying that the, the Mars layer or your kind of, your, your sort of like your warehouse obviously belongs to the data team and that's clean. But then metric definition, that in general actually lives with the business. Right. Like I don't really care when we're, when we look at our um, time to close here, we take it and we compare the sales qualified date to the close date and we only look at opportunities above a certain minimum threshold. Um, and we also exclude certain deal types and whatever else. Right. And like I couldn't care less about that. Right. Like I don't care whether or not the right threshold is 0 or 1,000 or 5,000 or 10,000. I don't care if we blend new business and upsell or not, whatever else. It's not my problem. Right. Um, that ultimately is however the sales team want to do it so that they can understand their business. Right. It better. Right. Obviously um, finance might have a different opinion, but that is for finance and sales to negotiate and sort out right. Like it's not my role to play parent there and choose one. That's right. Or whatever else. Um, and so Omni, where it's different to other tools is it gives the end business user the ability to edit the semantic layer. And that meant that particularly with ah, uh, the kind of a data literate rev ops and finance teams we have that we could say look, here are the end assets. You go build what you need, build a semantic layer and then in time I'll sort of incorporate it from the edges into the center. Um, and so we're able to in that way mobilize the entire business into building out Omni rather than it being a data team problem and that people know they're responsible for their own parts of a semantic layer. Um, and it lets you move very fast, right. And also means that you end up with a semantic layer that's very tightly bound to what is actually being used. Right. Like people, it's not, you know, the way it used to work with Looker is that we would go and say oh, what are all the things that we think we need to look at for contacts or opportunities, whatever else, and build that out and then it wouldn't be quite Right. And there's a slow process of feedback and whatever else, and it's just this big ongoing mess. And then somebody wants to add a new, I don't know, they want to add a measure for, um, MQLs from tier one countries and in some, someone who's got to do it. Whereas here it just kind of happens at the edge. It happens very fast. Um, but as you say, with AI tooling, things are changing. So the challenge with that and um, it definitely fit us at the time and this was also before sort of AI tooling, like coding and stuff really took off, um, at least in our team is you had. The challenge is you end up with a very messy semantic layer. Right. And in a way I don't care about that because, um, the benefit to a clean semantic layer is just that it's clean. Right. Like the most important thing is that it's used. Right. And the people are in the tool and we have very little in our business that happens in spreadsheets. Almost nothing happens in spreadsheets, which is pretty rare. Um, but with an AI tool that AI needs better context and it needs essentially also access to everything and everything's not to be in a shared model. So if you've not used Omni, if someone goes and creates their own measure, they don't actually have to create a PR and promote it, they might just keep it in their workbook and that's kind of fine for them, but the AI doesn't know that exists. Right. So we've now had to go through a process of rewriting the entire semantic layer, um, for AI. Um, but we've found that with cursor, we can create a new topic in 10 minutes. And actually with this entire existing base of reports that are heavily used, it's very easy to work out what we should be building. So we were able to rewrite pretty much our entire semantic layer in a few weeks, um, which is nice.

Speaker B: That's crazy. Yeah. And it sounds like these. I think one of the other things that you brought up to me as well is this bias to speed over, uh, um, 100% accuracy and guardrails and not being like you referred to earlier, not being, ah, a blocker. How does that, how has AI been an enabler of that and what challenges has it caused? Because I think some data teams obviously are very cautious about letting their stakeholders self serve and getting the wrong numbers. What's been your view on that?

Speaker A: Yes, I mean it's. Let us go very fast. Um, I think that, um, people are always going to find the wrong numbers. And so actually it's like, what happens when they find the wrong numbers. Both, like, you can have a culture of sort of blame and anger and whatever else, or you can kind of lift it out and be that it's normal. And like, one thing we really try and do is have a very open sharing culture and one where, like, if someone's got the wrong numbers, that's fine, They've got the wrong numbers. Right? Right. We'll get them the right numbers. And there's sort of try and take. There's some anxiety and some stress and some tension and some conflict that can be there. And the earlier the wrong number surfaces and the less people use or whatever else that isn't there. Right. Like, obviously, if a sales leader spends two weeks preparing a deck and a finance leader spends two weeks preparing a deck, and they have very different conclusions and they turn up to a meeting and one of them's wrong, that is an issue. Right. But that's an organizational issue about these two people not speaking to each other. Each other. And an issue like that isn't actually a wrong number issue, in my opinion. Right. A lot of other things have gone wrong. That's not something that we face, by the way. But like, it's, you know, the kind of story you hear. Um, but so I think it's partly like an organization thing about how you react. But then something that we're trying is in Claude, you can kind of speak to Omni using our connector. Uh, and what happens when you get something wrong or you ask it to be different or whatever else. We've got a Claude skill that prompts you to change the AI context and then raises a PR with a data team. Right. So, um, I had one yesterday, which, um, it completely, I don't know, blew my mind. Right. So we use the Salesforce case object a lot, and different teams use it very differently. So there's sort of managed onboarding cases which one team is using the kind of a deal desk are using it for deal reviews, and they're using it in their own way. And then we've got a proposals team that use it. So proposals team, they're the people, uh, who deal with things like RFPs. Um, and in general, you use the close date for when the case was closed or completed. Right, that makes sense. Um, so that's kind of how we built it out. And then we launched Omni and Claude, and one of our proposal managers said, hey, um, how many RFPs did we complete in March? And he got the Wrong number because for his team, for whatever reason and you know, it's not the decision I would make, but it's not my decision to make. They used the created date, not the close date. So he got the wrong number, right? And the skill auto fired off and it said, you know, well what should it be? It should be the created date. And it raised a PR and a linear ticket for us and said, you know, we've changed the AI context for. We're like, oh well we need multiple topics because the data is different. So we'll have a topic for the proposals team. It's separate to the topic that the dldesk team use. And in the proposals teams topic, the AI context will say when someone asks for the number completed, use the created date. Um, and so that's the other thing with the wrong numbers. It's like can we surface that fast? And then can we have the user in a way that doesn't cause them any pain, tell us what needs to change and, and then that way at the edge, hopefully it just gets cleaner and cleaner.

Speaker B: Right, that's a fascinating story and I think another sort of link to the systems and the process that you've built in, um, to the team and the technology to be able to have that agility as well, to be able to get that flagged automatic PR sent and to make them changes ultimately. Sounds like in what, minutes?

Speaker A: Yeah, it took five minutes. Yeah.

Speaker B: Amazing. Really interesting Ed. Um, I suppose one of the other areas which I was keen to touch on with you and it's sort of what we've been alluding to but your. Is career development. Um, you've had quite a, ah, interesting career and have got this view I think, which is really relevant about where data is going. Um, if you are sort of someone in their career today, say starting out as a, as an analyst, as a, as an engineer, where are the, what the areas that you'd most sort of advise someone to really push and develop, um, to help them excel in their uh, career?

Speaker A: Um, I think you've got to ultimately, if you want to grow your career, it's about taking responsibility for things. And so you've got to be looking at things you can do in parts of the business and outcomes that you're responsible for and growing those outcomes and then being able to demonstrate that those outcomes are kind of going well. Right. And so I think ah, that's quite different to um, a lot of people want to sort of like be in the room with senior people or sort of like. And that's Fun and interesting, exciting. And I definitely learned a lot from doing that. So I think that there's definitely a big upside to that and your understanding of a business and how it works and whatever else. But there's a kind of a natural limit to trying to be senior by being around senior people and sort of like being in the conversation actually if you can turn around and say I'm responsible for this and this is what happened, then I think you will sort of go far. People want to give you more responsibility. Right. And in that way also just taking the initiative. Right. And like trying to play on the front foot. And that means understanding what the kind of practical applications of a data set or a data kind of stack might look like and then proactively saying right, well this is where we're going to grow our capabilities, uh, this month or this quarter or whatever else and doing it and measuring yourself by that. Like how have the capabilities of what you've done changed? Right? How, how can people in the business act now and where they couldn't act before? And if you can answer those questions well then you're adding value to the business and you'll ultimately be rewarded I

Speaker B: think more and I think um, tracking that change in capabilities and the outputs that you talked about is ultimately what you're going to then be able to bring up in ebo, your performance review or further interviews. I think that's something that we're definitely seeing missing in the. A lot of people and in the industry is lacking in general is ability to talk about the impact that they've had um, uh, on an organization as ah, a, as a data professional. Flipping that there, that was obviously for someone that's sort of in there, you know, in the weeds of starting their career and developing their career early on. What if you're a head of data or a director or VP that's tried to increase their sort of team, teams leverage in the business um, and impact that they're having. Where would you actually be putting your energy and what should they maybe stop focusing on in your opinion?

Speaker A: I think it's starting with um, sort of what are people doing in the business. Right. And that like, as you sort of like if you're ahead of data or VP or whatever else or you should have a, a good working knowledge of like how, how a business functions and operates and, and what, what is kind of happening. Um, and then from there it's, it's about identifying opportunities for, for people to use data, for the data itself to play a big role. Not even necessarily Your team. Right. But as a whole, and then I think building that platform. Right and sometimes this is making the case to someone else that they should do something differently. It might be championing a culture where people are sharing the examples of what they're doing well or whatever else. Um, but understanding, you know like you, you have an opinion about how data could be used. So I think it's taking that and making that case. Um, and then in terms of your own work that the reliability of the platform and the scalability of the it. Right. Like that, that idea that like you are not the blocker is something which is kind of table stakes but I think definitely slows a lot of teams down. Um, if they're kind of focusing too much on the sort of interesting projects.

Speaker B: Excellent. So before we wrap up Ed, I think um, it'd be great to just touch on sort of Synthesia and where you guys are ah, going what, what does the roadmap for data look like over the next stuff? Um, yeah, I suppose years, years to come.

Speaker A: Yeah, it's, it's hard. I think that um, AI tooling is really going to change the data world and I haven't quite worked out in my own mind and I don't think anyone else has quite how this works. But I think there's sort of two big changes that are kind of happening on their way to happening. So one is a massive increase in unstructured data and sort of documents and stuff and that like um, when, I don't know, uh, we have um, one of our CSMs m built something which um, reads through old customer value stories in the slide decks and the notion and then it goes to Omni and it gets muted usage data and then it goes through emails to get sort of like other bits of information. It puts it all together to put like a draft value story in place for a customer and send it out and it's really cool and really impressive. Um, I think how we programmatically structure those Google Slides which have all the value stories in and tag them and whatever else for like fast retro like retrieval is like a really interesting data problem. Like almost like search as a data problem. I guess I'm not exactly sure what the right answer is but I think that's one big focus for us. Um, because I think it will unlock a lot of value like you know, every time I know we have a monthly performance review for our go to market teams we should be when we're building that like actively querying all of the previous ones. Right. And understand it In a way that we kind of are right now, but do a lot better. Um, and similarly I think that the other big thing I think is the skills files or equivalent for um, AI tools. So it's almost like we now have two semantic layers. So we have one semantic layer which is how Omni speaks to Snowflake, but there's a second one which is how Claude speaks to Omni. And we've got, as I mentioned, you know, we've got a skill file that automatically suggests changes to the code base when Omni's struggling. Um, we've got one skill file that kind of teaches Omni how to, you know, try a second time if it finds the wrong answer or whatever else. Right. Like if somebody um, asks to find out about, I don't know, Omni, um, example, like, um, I don't know if they're a customer of ours or not, but uh, you have um, some sort of European companies which have got kind of accents in their name. So if you search for Nestle, well the Nestle's actually got a little kind of hyphen above E, right? So a search for Nestle might pull up nothing. It will be in the skill file that it knows to kind of ask that again when it gets it wrong and find it and whatever else. And there's probably something similar with how it interacts with Notion or whatever else. And that at the moment I find that the process around building, maintaining, scaling, all of that is kind of a bit broken as well. Right. Like all of those skill files should live in a repo. There should be standards for how you make them. They should be, you know, these are important parts of a stack. There should be kind of PR reviews in order to kind of change whatever else. Right. So um, I think for us, uh, the big bit is how we handle all of that. And then finally this isn't trust, but I think we'll need to support is we've let people go crazy in Claude and they're doing really cool stuff and um, we've got something where um. Actually I suppose it does affect us in a way. Now I think about it where, I don't know, one of our SDR managers, he's got something that runs for three or four hours and it ends up producing amazing one to one notes and notion with all of his team with not just sort of how they're doing in the quarter, but like which of their peers are like particularly great in different areas where they might partner together, which accounts based off the accounts that have been successful recently. Should they be working whatever else? And it's having really good um, effects like he is. He was 150% to quota as a team last month and he says that this played a big role. Right. And that's what I mean by being operational. Right. Ultimately we provided the tools for him and his creator creativity to do better at his job than he would have done before. Right. Like, I can't say that that particular sales qualified opportunity is due to my team, but I can say that some percentage of them must be right. If my team weren't there, weren't working the same way, it wouldn't have happened. Um, but if that runs for a few hours every single time, I'm almost certain that like it's either like hammering Snowflake somewhere or it's hammering Claude somewhere or some of AI tool. And I think the other thing is like how do we let people go crazy and uh, sort of do all of this, but then at some point, say like in a Sable state, this is, this is how something is scalable. Right. And apply data engineering theories and practices to how we use AI tools to set it, like our token spend and whatever else is under control. So those are some of the things we're thinking about. Um, hopefully with AI tooling we can do that with a pretty lean team.

Speaker B: Still sounds like there's a lot, still a lot to do ahead and just at the start of the building, which is super exciting. Um, I think the final thing to touch upon on Synthesia, we're hiring at the moment. Uh, I'm sure you're going to continue to hire. Who's the type of person that, that really fits in and thrives, uh, at Synthesia, um, at least within, under, under, you know, your, your data team, I

Speaker A: think you've gotta really be able to embrace the autonomy and the sort of the chaos almost. Right. Like um, we, the way we work is to give people a lot of freedom and to uh, sort of like have them just go at it. And some people love that and some people don't. And um, if you need to be tracking your tickets or whatever else and you need a lot of structure and you, you need to know for certainty what you're working on in the month. It's not the right place for you. Um, and then also you need to be able to let go. Right. Like our business users are going to go and um, build a report with the wrong data in. Right. And, and that's fine. That happens. Right. And if that makes uh, you too anxious that you Feel the need to go and correct it and whatever else, it's not going to work. So you need to be able to respect the boundaries we're setting up as a team and really trust and business users and have a mindset that says, you know, like, they're responsible for what they do, and I really want to see them succeed, but if they fail, they fail, and that's on them. Right. Rather than like, uh, feeling that you sort of know better and that you, you want to involve yourself.

Speaker B: Amazing. I think that's a really good, good summary of the people that you've got in the team and why they're doing so, so well. So, um, Ed, before I let you go, it's been a pleasure to speak with you and get your views. Um, what would you say is probably one of your most controversial views on the data industry that maybe most don't, uh, agree with and that might be maybe where you think it's going or challenges that it has currently?

Speaker A: Um, I mean, we've touched on it, but I think my most controversial view is I think that a lot of data people, particularly semi junior data people, to be honest, I think they don't have enough respect for their stakeholders. M. And I think they kind of think because, you know, if you're doing well in data, you've probably been pretty smart and done pretty well and whatever else, I think that they, they look at a sales leader and they see someone who they think isn't, isn't as smart as good at them. And they think because they understand something on the dashboard, they think they kind of get it and get it better. And, um, I think a lot of data people imagine themselves as many CEOs or something, and I think that it really holds them back. So, um, I think that working well with stakeholders means really treating them with respect and, uh, what they're good at, with respect. Um, so that would be my controversial opinion. Far too often I see people who don't do that.

Speaker B: I think that's a excellent one. And, um, so we've touched upon a lot in the podcast over the three seasons that we've been running now is the ability to partner well with a stakeholder is a true differentiator. And what you've mentioned about having that respect and empathy for what they do is ultimately what is what built people build trust on a relationship and a partnership on. So, um, controversial, but I think very, um, very true. So, um, yeah, it's been a real pleasure. Thanks so much for joining me. It's been a long time Coming. Um, so, yeah, thank you again.

Speaker A: Cheers. Thanks, Harry. Always great to chat.

Speaker B: Brilliant. And, um, that's it for this week, folks. We will be joined by Gina, also from Synthesia, at a later date to really take a deep dive more into Omniai and Claud, uh, all of the stuff, uh, that Ed's mentioned as well, on a much deeper level. So keep your eyes peeled for that one. But for now, thank you and goodbye. Hi, everyone. Just a quick one from me. If you've enjoyed today's episode, I'd be so grateful if you could hit that follow button or leave us a rating. Even better, pass the show on to a friend who might also get some insight from it. It really helps us grow the community and continue to share, uh, amazing conversations. I also wanted to take a minute to talk to you about Cognify. For those of you that don't know, Cognify is the leading recruitment partner for modern data teams. We help some of the world's best organizations scale data and drive real value from the hires that they make. If you're thinking about building a team or making a hire and you're struggling with talent or just want some insights on the market, then I'd love to jump on a call with you and tell you a bit more. Equally, if you're looking for a job and want to find your next dream role, then reach out to myself or any of the Cognify team. We'd be happy to see if there's anything on our books that we can help you with and give you general advice on the industry. Finally, a big thank you to Omni, this season's sponsor. If you'd like to learn more about the AI analytics that Omni can deliver, you then check out the link in the show notes or come speak to me. I can happily point you in the right direction. Again, thanks for listening and look forward to seeing you in a few weeks time.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • Why Your Marketing Attribution Breaks on MarketplacesMarketing Analytics with Fexingo · on Snowflake92 / 100
  • 183: Why Trusted Data is the New AI Moat (w/ Rick Kranz @ AI Marketing Automation Lab)Move The Needle · on Rev ops91 / 100
  • The Real AI Advantage Isn't What You ThinkAI Proving Ground Podcast · on Snowflake91 / 100
  • Is Your AI Actually Worth What You're Spending? with Parker ConradStrictlyVC Download · on Snowflake86 / 100
  • Orchestrating data across 30 companies at ittiThe Data Flowcast · on dbt81 / 100
  • How airfocus Is Rebuilding Product Ops Around AI AgentsProduct Team Success · on Claude integration80 / 100

More from The Stacked Data Podcast

All episodes →
  • 043 - Building Aurora: How Moneybox shipped an AI financial assistant inside a regulated fintech
  • 042 - The First Head of AI in English Football | Reading FC
  • 041 - Data as a Product: How to Drive Real Business Value
  • 040 - Why Most AI Projects Fail (And How to Get Them Right)
  • 039 - The Data Science Identity Crisis
Explore the best B2B AI & Data podcasts →
All The Stacked Data Podcast episodes →