SELECT video_content FROM LIBRARY WHERE SLUG='002-data-as-a-growth-engine-inside-cleo-s-winning-playbook-w-conor-o-kane'
002: Data as a Growth Engine: Inside Cleo's Winning Playbook w/ Conor O'Kane
Loading video player...
Hey, everyone. Welcome to More Than Numbers live, a data show focused on turning data teams from support function into engines of growth. I'm Ollie Hughes. I'm one of the cofounders of cam dot co, a canvas based BI tool. We love turning data teams from being dashboard factories into their organizations, problem solvers. Every week, I have the joy of interviewing an industry leader to understand how they're drawing value from data in their organization. And this week, I'm joined by Connor Kane. Connor is the head of analytics at Clio. Clio is an AI based money assistant. It's one of the fastest growing startups in the UK, tipped to be one of Forbes' next billion dollar startups. And Connor has been there for over five years. He's been there since the company was thirty people, leading and growing the analytics organization pretty much from scratch. Connor, it's great to have you here. You're gonna be helping us understand how data works at Clio and how it's a driving force of change. Thank you so much. Great to be here. Happy to come on and talk about data teams. I think we've got a great one. So Yeah. You too. You definitely do. We can impart. The light I should say to all the audience that Connor I have a performance for Connor and the team at Clear because they're one of the earliest companies that lead it heavily with count, and we never haven't been more grateful to them before. And so, yeah, there's there's a I have a lot of love for this team. I wanted to get you on as one of my earliest guests. And kinda before we get to know you a bit more, I wanna ask you up. To get to know a bit more, I wanna ask you an icebreaker question. I want to know what was the first BI tool that you used other than Excel in your so you started out your daily career. It's a great way to get a sense of how old you are really, to be honest. Yeah, you're taking me right back to the days of being a junior analyst. Yeah, a bit of a trip down memory in this one. I think my first foray into what you might call a classic BI tool was with Qlik Sense, but don't know if you know it. Qlik Sense. Well, it yes. So it was Qlik and then Qlik Sense. Maybe it still exists, I don't even know. And then Qlik Sense. Yeah. So maybe Qlik Sense. A classic, enterprise dashboarding build. So I was working, at a large IT consultancy working for enterprise clients, building databases, and then dashboarding suites on top. And it was our our tool of choice that we use for those. It was one of those delight to consume and absolute pain to develop in. So it's it's USP was this associative data model. So under the hood, it it linked all the categories, and it did a really, really nice job of surfacing them in this standard color scheme of green, white, gray. So green being what was selected, white being, like, the possible values that remain after your selections, and gray being those that were excluded. And it was really set up for drill down and drill through. And it was a really useful tool for people for doing, you know, descriptive analysis, some basic diagnostics. But it was it was a real pain to work in it at this clunky domain specific language. You had to develop locally. You had to publish it to a server. You had scheduled reloads. Access was really, really locked out. And I guess it really goes against the grain of what you've got in the modern data stack where you deal with democratization and permissiveness is sort of what is, what is optimized for. So, yeah, if I look back and think about what it what it was like and whether I'd ever use a tool like that again, I do I think a hundred percent, it just it just wouldn't work for the time kind of company that Clio is because it is so slow to develop in. I think it's something that is often underappreciated in analytics is the importance of speed. Speed is like the great multiplier. The more questions you can ask, the more answers you get, and the more answers you get, the more likely you are to get to an answer that is gonna give you the answer you need, that is gonna be that thing that pushes you forward. So any tool, no matter how good the end output is, if it's if it's slow to develop, then it's not gonna be something Yeah. Then that works. You know what? I I love asking this question because you you've you've it was clear the way you answered it. Like, you have a special fondness for that tool because the first thing you got, you really dinging in. Right? But it you know, it's it's it's already standing on the shoulders of giants. At the time, it was amazing, and it gave you that flexibility, but, yeah, it's not right for now. I think that's all Beautiful. Knowledge. Yeah. Dashboards. Yeah. Beautiful dashboards that people loved using. But if it takes three days to do it, it's, the time is better spent elsewhere. I also like, I love the idea that it how the color scheme was, like, green, like, basically the click color scheme. Yeah. I'm not sure we get away with that account having only our brand colors partly because it's pretty pretty bold pink and blue. Not sure we could get away with only having the color schemes, for very long. We need to have more. Things have things have evolved in terms of people who are on this now as well. That's a great start. So that's where you started. Let's talk about where you are, Clio, now. Clio is, you know, a wonderful organization. You you actually serve primarily the US market, but your the whole team, I think, is pretty much based in the UK, very dynamic. Maybe you could just paint a bit about the org, how big it is, maybe how fast it's growing, and then let's talk about the data stack, the data team. I think we all know really, like, how data's set up for you, but maybe start high level, and we can work down into more of your org. So we we've got a pretty sizable data team at Clio. So the whole company's three hundred people, and the data org is about sixty, of which we can broadly break that down into data science, data engineering, and analytics. So analytics is a team that sits under under my brief. So we've got product analysts and analytics engineers. So the product analysts are the, you know, the sort of the Swiss army knife, the the people who are there working very, very closely to the teams, helping the teams move faster, make better decisions, understand what to be built, you know, what success looks like, how they are tracking towards success, where the opportunities are. And the analytic engineers are, you know, everyone's best friend sitting one step higher up in the data stack, building the amazing data models that organize the knowledge that allow us to ask those kind of questions and and find those answers. So, yeah, in total, that analytics team is thirty five. So it's quite a it's quite a sizable team. I think it speaks to the extent to which Clio values data as just like Yeah. A little more ways more than twenty percent. Ten percent is is analytics, and then you've got a wider twenty percent of the function is of the of the company is data as a whole. It's pretty it's a pretty big ratio, actually, isn't it? I think that's pretty unusual. Of course, you know, machine learning and AI sits under the hood of a lot of the product that is served. So as well as analytics and the more operational function of the company, we invest heavily in machine learning engineering as actually part of the product that is served to the users. Sure. That's good. We'll come back to the there's a lot I wanna talk about having a bit of a a bit of a, insight to how you work about exactly the way that your team, particularly the analytics team, actually work with the rest of the business. But let's talk about your data stack first. Just just ground people a bit about what you're, what you're using and how it's set up. It's a reasonably classic data stack, you know, like data warehouse, DBT doing the transformation with Fivetran as our ingestion tool and then, a a slit that fills in the consumption layer. So we've got Vipram, Redshift, DBT transforming back from and back into Redshift and then in the consumption layer, mode as our primary dashboarding tool, client as our, you know, data exploration, data analysis tool, and then growth book as a specialist, AB testing, yeah, BI tool for really, really for, like, self serve analytics on on that end. Yeah. So it's it's pretty standard stack. It's mostly very much the classic modern data stack stack. I wanna, like I've obviously got vested interest in this, but despite my interest, like, how do you see that stack evolving? Are you what's the thing which you're most, as a team, you're most excited by or you think you've got what you need? Do you see any complain there's a lot of discussion nowadays about consolidation, but I actually wonder how much you really care about consolidation rather than having the right tools for the right job. Yeah, certainly what we're optimizing towards is speed. I think in all of those choices, we're thinking about the things that help us move fast, and it's fast in different ways. So mode, if you compare it to all of the different dashboarding tools that exist out there, its USP is in its speed, essentially, in its speed of, like, filtering, its speed of how you can go through and play around with the dashboards. And really that's because it's leveraging memory during query execution. Someone once said to me, you know, when we were working through different dashboarding tools with different stakeholders in the business, someone said to me, if it if it doesn't load in three seconds, then it doesn't load. If it doesn't work that quickly, then it doesn't work at all. And that that really resonated with me, and and that sort of sits speaks to the mindset that we have as a company. I know it can't do something very similar with the dark DB integration that you have. So then count count is probably the tool that we use the most. It's very much the go to sandbox, really, of our analysts. It just like the the way that you can explore in a really, really fast nonlinear sense, that sort of seamless integration of SQL and Python, the multispecial nature of it. It just sort of lends itself to the the analytic mindset. And really, that's where day to day the analysts the analysts live. And then growth book is just something that has been built, as a niche tool for, you know, a Bayesian framework, AB testing. And it really works for us out of the box. It really just, like, reduces a lot of the overhead to producing the analysis to an extent where the engineers can do a lot of the setup and the analysis themselves. So that's really why we have those. In terms of consolidation, I'm there's a lot of debate in the industry about whether the explosion of the number of data tools was a product of the the Zirp era. You know? This this this VC explosion You've got a rebounded data stack, to be fair. Like, there's a lot of companies out there with a lot of middleware. Like, there's a lot of observability stuff sitting in the middle of that stack, which is just all over the place. So you're actually not too bad anyway. The reason is, yeah, we steered away from adding extra layers because, again, that's the kind of thing that, slows you down. But I think there's there's a little bit of mental overhead of knowing what tool to jump to and from in order to find the answers. But I think you get used to that and you learn that quite quickly. So in terms of consolidation, it's not something that I expect to see too much of because what you're then talking about is some very large, all purpose enterprise tool. But if it's able to do the things that we need it to do, if it's able to meet our niche needs, then it's probably going to be built to meet a whole host of other needs. And then that will be functionality that we'll be paying for that I think we don't really want to pay for. And then you just have like a slow, clunky enterprise tool that really you see very little improvement and from quarter to quarter. So it's not something that I see changing anytime soon. Of course, the the great unknown is is AI. Right? There's a lot of talk that AI will become this whole purpose, interface for answering all of your questions, and you won't necessarily need to have, like, the setup and the complicated user interfaces that we we have today. I'm not I'm I haven't seen that yet. I haven't seen Right. An interface for AI that's super compelling yet. So, I know that's fair. I mean, I actually feel quite bullish about our campus interface because it's like it's most flexible and gives AI the most power to play, but I'm with you. It's an evolving space. What I want I mean, the thing I most heard from you here is just about speed. Like, you everything you're talking about, every decision you're making is speed focused. And I don't think that means you mentioned it as a query time, but, actually, I think it sounds like it's more than just the speed of querying. It's the speed of decision. It's the speed of the ability to be able to act, which is the fundamental driver. And I I I wonder if that's a thing which it's is that kind of, like, the fundamental one of the fundamental pillars of the way you think about your org structure and how analysts sit? Because it is quite unique the way as we'll go into we're talking about more about the way that your analytics function sits with the organization is incredibly close. I think it's I wonder if that is that all about speed as well? Is it just about that kind of speed to speed the decision? So our analytics function is embedded or our our product analysts are embedded. So the typical model would be to have one analyst sitting in a cross functional squad that owns a certain part of the code base that is building certain user facing features, and you have one analyst embedded in that team. Those teams will be grouped into pillars, and you'll have a lead analyst who operates across that pillar. So they'll be responsible for coordinating joined up analytic efforts between everyone in the pillar. They'll be doing their own ecosystem analysis, and they'll be performance managing the individuals in the in the pillar. Our analytic engineers, they sit in a in a centralized team. So when the people will often discuss the pros and the cons of embedded teams versus centralized teams. For me, it's really a simple case of knowledge share. It's the type of knowledge share that you need to optimize towards. So if you ever got a centralized team, you have excellent knowledge share between individuals in the team. They all know what each other are working on. They're sort of absorbing from each other. You know? And they're much it's much easier to learn from your peers in that environment because you really are sitting in a stand up with them every morning, hearing them talk about what they're working on, maybe picking up some of the work that they had worked on previously. Whereas if you're embedded, you've got great knowledge share with actually what is happening on the ground with the engineers, with the designers, with the product managers, the the people who are, like, building the product that the that the users will use. And because of what we want the analytic role to be, which is very much a strategic one rather than an executional one, they really are responsible for uncovering opportunities that drive the company forward. It is paramount for those individuals to have the maximum knowledge share of what the, you know, business goals are, what performance looks like, what the usual problems are, what that opportunity space is. So they are embedded into that space. So is it a question of is it a question of speed? Perhaps not directly. It's it's more one of the the sort of the deep product knowledge that they really need to understand in order to be able to actually work as a thought partner for the for a product manager, as someone who can really work closely with engineering and design and help them understand how they can, like, build better and build faster. Yeah. Yeah. I I'm just it I think if we we obviously, Conor, you've been involved with us. We've been building out the tenants of a high impact data team, and I think a lot of what your analysts are doing in that cross functional group is very much delivering those tenants. So the tenants being driving operational clarity, make sure everyone's clear exactly what the performance is, problem solving as, like, the structure and the problem solve, time to decision, helping collaborate, and getting to a point of con of conviction, and then, obviously, just doing it in a measured way. I think I what I've seen, I think your the way your team does that is so great. And it's such a unique I just one of the questions I wanted to ask was just about, is how you've got to that point. Like, obviously, you've grown the team from basically just pretty much you, I think, at start off with a very few people, and now you've got a team of thirty. And I just wondered, like, how have you instilled this idea that the data analyst, the product analyst role isn't isn't tactical. It is strategic. How have you how has that happened? Right? And how have you maintained that that they're basically the kind of they're they're a core part of the squad of delivering product value? So I think it's it's origin probably sits in our CEO, being a former data scientist. So that really, you know, in an instilled a data led culture into the company for it from its inception, and a lot of the early hires on the the product side and the engineering side were all incredibly data literate. So it just became part and parcel in those early days when there were very few of us of how the company operated. In terms of then how do you maintain that over time as you bring in lots of new people, I think it is something you need to work very hard at. So we we work really hard to build a a skills framework for our analysts that really sits at the center of how we direct their work and also how we reward their work. And I think I think that's incredibly critical in analytics. It's it's critical in in any function, but product analytics really is quite undeveloped as a discipline, which I guess it doesn't rise to me when it's been around now really for ten or fifteen years. But you'll see very little literature on what great product analytics look like. Very few examples of great work. There are no conferences really that talk about analytics as a craft as opposed to tooling, very little in the way of of meetups. So a lot of analysts come in, and I don't think they necessarily understand straight off the bat what is expected of them. So we have to put a whole lot of work into that. So our skills framework, that is publicly available. Yeah. I I was just gonna say, you you showed me the link. And if you wanna get access to that, I would hundred percent recommend everyone who looks at that skills framework. You can find it in the show notes. It's it's a really amazing document, and it just outlines a much broader role for an analyst than just simply being kind of it it it broadens that role wonderfully. Sorry to cut. Yeah. No. Not not a problem at all. Yeah. It's incredibly valuable, asset that we have, and we really try and put it at the center of career development and performance review. So when it comes to the performance review cycles, we're really judging people against the the skills and the deliverables and the impact that is that is listed there. And then we're very regularly every couple of months doing check ins with people, helping them understand where they are against their level. When we're talking about promotions, really sort of saying like, this is where you are and this is what the next level looks like. This is where you're great. This is where you're last great. This is where you want to push on a little bit. Let's set some goals that help you get there. And just I mean, the other thing about it, the simplest thing about it, it sounds so ridiculous when I say it, is, like, there is progression within the discipline. It is like product analysts can be incredibly highly valued, incredibly highly paid, and the path to get there is clear. It isn't nebulous, and I think that just, it makes it as it's of strategic value to business rather than being the place you go before you become a data engineer. If that alone was given in half, it's such a powerful thing. There's a there's a lot of there's a lot of ways that one can go with in in the analytics role. And I think partly that's because of the the nature of the individuals that tend to be attracted towards analytics. They are both technical and business minded, so they can both they can go down those paths and they can take a linear path within analytics. They look to become managers, leaders. They can stay as, like, really specialist ICs. They can look to become leaders in in a certain domain function. So there's lots of ways that we can do that. But before you get there, you sort of have to hone your craft and go up through those skill levels. So having a document like that is important because it gives people those clarity of expectations, but also the right incentives, right? You know, people follow incentives. So if you say to people, like, this is what you're gonna be judged on, then very quickly, you'll find that they start behaving that way, and that's that's kind of what we need from them as a company. And and what do you and just to give you a flavor of what's in there, like, what would you say in that framework is a skill or a a aptitude which you find a new person who's been an analyst before somewhere else comes in and is like, oh, that's different. This role is definitely different to an analyst role I've had before. Like, can you give us a sense of, like, what is in the framework, which is a core differentiator to, like, a normal analyst maybe before you see coming in? Like, you have to help them with that transition. Yeah. I I think it's that ask of our analyst to be someone who drives forward product decisions and helps uncover new opportunities. So there's lots of stuff in there in terms of the soft and the technical skills that you would expect of an analyst today, I imagine, are are pretty boilerplate and pretty transferrable across lots of companies. But often when people when people join Clio, I'll often hear them say, oh, wow. I've I've never had analysts that work as closely with me as the analyst does. Now I have never seen analysts that take this kind of a role before where really they are thought partners for product where they are given a lot of autonomy in terms of setting the work that they do and what they work on. So I I'll often say to analysts when they first join, if if the the PM is turning to you and saying, this is what I want you to do, the the relationship is not working. You're you're doing an okay job, but not a great one. If you want the PM turning to you with the trust to say, hey. What is it you think we should do? And you coming back with ideas and the PM saying, brilliant. Yes. You know, let's let's do it. So it's really that. So with that autonomy comes responsibility, and that is to really be someone who makes a difference, who really gets in there and uncovers problems. When when product analytics is done right, it's a super fun discipline. You're really getting in there and you're problem solving. It's it's finding that age. Right? It's like, what's that thing that we we don't understand? What's that growth lever that we haven't uncovered? What's the, you know, a list of ideas that we could break down in size and try and try and interrogate to see what can, you know, push us forward towards the the business goals and the user goals that we have? So when it's working well, it's a super it's a super exciting, and a super rewarding, and a super impactful discipline. So I think those are the things that are different in our progression framework, the extent to which those are called out at the top. This is where you have impact. This is expected of you. You're expected to be someone, who is very influential in the in the direction of your team. I think that's great. I mean and the results speak for themselves. Right? The speed at which Clear was growing, is amazing, and it's driven by the fact you've got that that kind of relationship set up that adding value. I can't tell good enough to go look at that progression framework. It's absolutely brilliant. Okay. I I feel there's so much more I wanna touch on this. We're going to come back to speak to you a lot of time. There's there's more to discuss here. I'm so grateful for sharing some of that stuff already and actually making your your framework for progression is that framework of skills is is available in open source. You made it something everyone can actually use, and I would encourage people to dig in. I'm gonna move on now. I wanna talk to you about just some advice. So, like, obviously, you've done been at Clay for five years. You've been, like, a management consultant and analytics, and data before that. What's the one piece of advice you'd give to someone who is coming into data or is earlier on their career than you? Like, what's the one thing that you would give yourself that advice to to help them go faster? What's that one thing you you wish you knew? Yeah. It's I it took me a little while to to think about this one because there's always a risk of being super reductionist in any of these kinds of bits of advice. But I think what the the the single most important decision you can make is the kind of company you join because from that flows everything else. So you can imagine putting together, you know, the the perfect personal development or learning plan for how you're going to upskill yourself towards, you know, the desired career. Imagine spending your evenings and your weekends working on all of those things. If you get to a company and they're super forward thinking and they want to support your development and they say, hey, you can have ten percent of your time to be working on these like alternative projects, it's still only ten percent of your time. The most of the time that you will spend growing within your career is through the process of the job you actually do. So if you join a company where, you know, there are loads of people that you will learn from, who you're working closely with and who know more than you in some direction, then you will be pushed and you will grow. Growing by working closely with other people who know more than you is just by a distant, you know, the best way that you can learn. It's kind of, it's almost small end mentorship, right? It's not mentorship where you have a formalized mentor. It's just like being around people where just by osmosis, you kind of see what they're doing. You think, wow. I I never thought to do that before. That's really amazing. I'm gonna do it like that the next time. So, you know, being in that kind of company where you're surrounded by people, that's super important. If there's ever been an advert for joining Clio, I think it was this one, your HR arbitrage, there we go. And Clio's hiring everyone, I get to use count. What more could you possibly want out of your analytics career? Just one more point about Megan Miles is growth. This is something that I've learned a lot in my career. I think when you're working in tech, it's very unlike someone who works in, you know, a finance career or an accounting career where there's almost a very defined growth path where every two years you move from junior associate to associate to senior associate. In tech, it's a lot more like you just suddenly get these step jumps where you get thrown into the deep end and your your career suddenly accelerates. And the single greatest way other than your own talent and your own hard work is being at a company that's growing. If you are at a company that's growing, the problems are changing all the time. The scale at which those problems are being applied is changing all the time. Suddenly, the company is bigger. There is more responsibility. And by virtue of having been there, that responsibility is thrust upon you. And whether you're ready for it or not, you will just grow by the process of having it. To joining a company that is growing and is going to serve you well in terms of your personal growth is so much more important than whether it's something you think you'll, you know, enjoy in the very instance of today or what the salary is. I often say to people, you know, be long term greedy, you know? Yeah. Yeah. Yes. Be selfish. Yes. Be self interested. But think about that in five years' time. What's going to be the company and what's going to be the role that just keeps you growing so that you're in that, you know, super I love it. Senior, super well paid job in five years' time. I love it. Thank you so much. Okay. We have time. We have three minutes left, and I'll make sure we get you to one more question. We I actually told people while speaking to you, a few weeks ago, they gave me a few questions I wanted to ask you about particularly, and I've got one here. It's called it's anonymous, but here it is. A very simple question. What are the key results that Connor owns in Clio, and how does he come up with them? Then we've got a two minute answer, Connor, if you can do it that quickly. This is an interesting one. The short answer is not many. So as I spoke before, product analytics are thought partners for product. So their their goals are our goals. We we succeed and fail together. So the product analysts are embedded. So their their goals individually is to succeed and feel with the team, hopefully, to succeed. Certainly, I I personally have responsibility in owning our, I guess, our understanding of retention. So retention is kind of the everything metric. No one squad can ever be put in charge with of of retention. I've I've seen it done, and and it's complete folly because everything ladders up into retention. Do you use just local product? Do they then stick around? So I'm responsible working with the leadership team for, like, the understanding, the reporting for that, holding teams accountable against their subset of what we understand will ladder up to overall retention, setting actions that are passed down over to the squads. But we're not I'm not myself or the analytics team isn't responsible per se for actually hitting that retention goal. It's it's an accumulation of the different squads that as a business, we understand will will ladder up to to retention. That's awesome. Thank you so much. This has been an amazing conversation. Thank you so much for being open and honest about where you are with Clio. You've told us about the power of being embedded, the power of a career framework, and even just there, talking about the way that you own the targets and what how you're accountable to delivery. It's been really great. Thank you so much, Connor, for being here. I hope it's been good fun for you. If you Connor Connor said Clio are hiring, you should definitely check them out. Check out the the show notes at cal dot co slash m t n, for access to their progression, progression framework if you can't find online. Also check out cal dot co, to look at more about what CALD is about. Thank you so much, Connor. Really appreciate it. Speak to everyone soon. Thanks, everyone. Bye bye. Bye.