4#18 - Mikkel Dengsøe - Scaling Data Teams (Eng)

«A lot of things break with scale.»

In our latest conversation with Mikkel Dengsøe, co-founder of SYNQ and former Head of Data, Ops and Financial Crimes at Monzo Bank, we explore the secrets behind effective scaling of data teams.

Mikkel reveals surprising statistics based on his analysis of over 10,000 LinkedIn data points and valuable insights from Monzo’s scaling journey, where the data team grew from 30 to over 100 people in just two years.

We discuss the critical balance between central data teams and domain experts, the importance of career paths for individual contributors (not just managers), and how data professionals can succeed by building relationships with stakeholders who involve them early in strategic processes.

Here are our key takeaways:

 Data Teams

• There are some high-level questions you need to ask yourself when building, structuring or scaling a new data team
• This includes how big the team should be, also relatively too your organizations size and other teams, how it should be composed and structured, etc.
• A good idea is to collect data to create a benchmark.
• Benchmarks can be hard to combine and are a moving target, but they are nevertheless valueable. 
• Most importantly, you need to ask yourself: WHY do we need to scale our data team?
• Involve people actively in setting the goals based on your WHY.
• Mikkel collected over 10.000 data points from companies on Linkedin. Here’s what he found:
   
  • Median % of data people in companies out of overall staff is 1-4%.
  • Data team relative to engineering team varies between 1 data person per 10 engineers to 1 in 3.
  • From the benchmark it is evident that data governance roles only appear in lager companies.
  • In marketplace companies the effect of data on the business value is easiest to track. Therefore they seem more willing to invest In data teams.
• Investment in data means investment in your business. The consequences of not investing in data will be tangible in your business.
• Find a risk based approach to data as well. At what level can you balance investment, outcome and risk?
• Be cautious of «pseudo-data teams» - teams in a Business unit that do kind-of data work, but are not aligned with the organization.
• Be clear on the skills and competencies you need. What is a data analyst? What does a data scientist do in your organization?
• It is important to have a clear and consistent internal career ladder. Make it visible and understandable what is expected from each role on your team and don’t change these expectations too often.
• Create pulse checks to understand what people are happy about and what not.

Scaling Data Teams

• «Golden Nugget Awards» to showcase good data work every month. These were added to a database, so every new employee could evaluate them to see what good looks like.
• Write down your progression framework to get clear about your ideas and how people excel in your organization.
• You can show open what work lead to promotions. That can be engaging for people to follow in these tracks.
• Hub-n-Spoke model, where people rotate in and out of the central team and the distributed teams.
• Citizen developer programs are a way for larger organizations to scale data work. But It bears risk related to data literacy.
• Don’t try to enable everyone, but enable those that are motivated.
• «You shouldn’t necessarily force people into management to progress.»
• Senior technical careers can ensure an advanced level of quality. Which is a different way of scaling your data team.
• You need a career ladder for professionals that is independent from management careers.
• Create rituals that make good work stand out.

Transcript

Intro

Speaker 2 0:20

Dette er Metadema, en holistisk synment, som en profesjon i Nordisk. Vær så god med de kompetensene vi har, og det er grunnen til at jeg inviterer nordiske eksperter i dat og informasjonsmanagment til å snakke.

Speaker 1 0:35

Velkommen tilbake til Metadema, Og jeg er veldig glad å ha igjen en gjest fra Danmark på showen. Mikkel Denkser, Har jeg skrevet ditt navn rett? Ja, spart an. Mikkel arbeider for en kompani som heter Sync. Du er fonderen av kompanien, ikke sant? Ja, en av tre fondere? ja, Fantastisk.

Speaker 1 0:58

Og vi skal snakke om et tema som vi snakket om tidligere i denne sisen av podcasten er om datateamer, Og denne gangen skal vi snakke om hvordan man skal skale datateamer.

Speaker 1 1:07

I første sted, Og før man kan skale datateamer, må man se på hvordan man strukturerer datateamer i en konsistent måte som fungerer med strukturen av organisasjonen. Hvordan finner man sammenheng med andre deler av organisasjonen slik at other parts of your organization, so the data teams, get integrated, and then how you think about scaling those data. And a lot of talk lately, also from me is about federated systems of data teams. How do you create autonomy for data teams so they can work freely with the right authority to do the work they need to do, but at the same time adhere to some kind of larger structure of I don't want to call it governance ruling, but maybe some gravitation around a certain set of standards in the organization? So how do you make that possible that it's easy to do the right things. Easy to do the right things, And that is just one aspect of a larger organizational structural commitment you have to have towards your data teams, And this is exactly what we want to talk about. But before we do that, Mikkel, please introduce yourself.

Speaker 3 2:19

Ja, så meg er Mikkel. Jeg bor i Copenhagen etter å ha spist nærmest 10 år på grunn av å leve i Irland, san Francisco og London. Jeg beviste meg et par år siden og er nå satt her Og, som du sa, en av founderene av Sync, en data observasjonsplattform. Men også før det har jeg spist rundt 15 år i dataindustrien. Så jeg begynte min karriere på en skjønningskompanie i Aarhus i Danmark, og jeg husker da jeg sammenkom, de finnte ut hvor mange kjønner de skjønte ved å spørre om det var en person som kunne ta det ut av deres ERP-system fra 80-tallet. Og da, over et par år, fikk de bygge et dataverkstall og bruke Microsoft, ms SQL, sis and all that kind of stuff. And then we had these TVs hanging around the office where everybody could see in real time how many containers were shipped, and that was really my way into data.

Speaker 3 3:12

And then I went on to work at Google for almost five years, starting out as an analyst and then going on to data science and also coordinating more with management, and most recently was one of the heads of data at a place called Monzo in the UK and, if you haven så, koordinering med regjeringen. Og mest siste var jeg en av headene av data på et sted som heter Monzo i Storbritannia, og hvis du ikke har hørt om Monzo, det er en fintech start-up bank. Jeg tror at i dette kontraktet av skalende datateamer, det som er veldig interessant er at vi gikk fra 30 datatidene da jeg begynte til mer enn 100, to år senere Så de så denne hele skaling-jørningen og da ble det det gode, det bedre og det vanskelige, og det ble veldig, veldig raskt ut.

Speaker 1 3:46

Fantastisk, Så den rette personen til å snakke med om dette. men det er også noe annet som gjorde meg vilje å snakke med deg, og det er din presens på Medium. Det er mange gode artikler, mange veldig verdifulle innhold som du skriver der. Så hva gj? insights that you share there? So what does Mikkel do when he's not working.

Speaker 3 4:05

What are your hobbies? Yeah, that's a good question. I think I always had this very succinct answer to that. these are my exact hobbies, but since I moved to Copenhagen, i really just like going around with friends and my girlfriend, exploring different neighborhoods, getting good coffees. I think no matter where you go in Copenhagen, if you've been, there's an artisan bakery or a very good coffee place, so make the best of that. And then also a lot of weekend trips away. So try to get around different places in Europe. I was in Lisbon last weekend, italy, and the weekend before that, so get a lot of time around that, meeting different friends and people that I met over the last 10 years living abroad.

Speaker 1 4:43

Fantastic, And I think Copenhagen is a great city to live in and you're right, there's so many interesting stuff to explore in all the different neighborhoods.

Speaker 3 4:52

Yeah, it's really become a bit of a hotspot, i'd say the last few years, maybe even the last ten years or so. I think It kind of started with Noma, the restaurant that was the best in the world for some years in a row. And then there's this whole food scene popping up and it just spreads to that now ex-Norma-chefs are starting bakeries and burger bars and all that kind of stuff. So it's really, i think, the quality of especially food and drinks and everything is just very high.

Speaker 1 5:17

Yeah, exactly, and the quality of social life as well. Yeah, definitely recommend it if you haven't been. Sounds like a tourist recommendation podcast now. Yeah, i've got a best interest, but I like GoMain. Maybe that's a good, interesting question to explore. since you live in Copenhagen, you work in data, do you feel like there is a? I don't know if vibrant is the right word, but is there a data community that is active in Copenhagen? Yeah, i feel like it's starting to really come together.

Speaker 3 5:49

So I tried to go to all the DBT meetups, which are the main gathering of data people, and we had one a few months ago and I went there and I think I knew probably half of the people in the room And all we had before. That was actually the most well-attended DBT meetup ever. So I think that definitely goes to show that there is a lot of people with interest in data and a lot of good people to meet. But it also, on the other hand, it also feels smaller than London, where I used to live, like it is a, especially within the kind of scale-up tech community. It's much smaller. There's a lot of people in enterprise companies and so on, but if you go to a place like London or San Francisco, you have a very big group of people with very similar problems around, let's say, scaling a data team from 20 to 50 to 100, where that can be maybe harder to find in Denmark Interesting.

Speaker 1 6:43

Well, there's a question I ask every guest, and that is not just because I find it interesting, but there are so many people working in data that come from a different background that kind of get pulled into the data world. But where did your interest for data spark?

Speaker 3 6:59

Yeah, i kind of stumbled into it. I was studying finance and thought I was going to work in M&A and do that kind of stuff. But then I got that job at Unifeeder, which was a shipping company, and really I think that was my first job, so I didn't really know if it was good or bad. But then I moved to actually working on M&A company for a few years and realized that I missed pretty much everything about that previous job around really understanding an area and sticking with something for a while and this ability to give people something they hadn't had before and almost do this like Sherlock Holmes type of detective work and all that stuff I just found super interesting. And then I did the 7-8 job and then quickly realized that it was actually data. That's what I wanted to do. So then I started looking for data jobs and then superinteressant Og da gjorde jeg jobbet med det og da skjønte jeg snart at det var data som jeg ville gjøre.

Who is Mikkel?

Speaker 3 7:47

Så da begynte jeg å se for datajobber og da gikk jeg til Google og så fortsette jeg denne veien. Men jeg tror det er en interessant sted og jeg er veldig glad at jeg valgte data, men også er jeg veldig bekymret at jeg ikke vil være den eneste. I want to be this only data Ideally look at problems from different angles and not be someone who can just look at numbers, but also think a bit more broadly.

Speaker 1 8:11

Yeah, i think that's very important to have several perspectives on the same challenges. When we talk about scaling data teams as our main topic, there are definitely different perspectives on that. You can try to tie it back to an organizational development perspective. You can tie it back to an outcome perspective. What business outcome do I want? What qualifications, what skills, what competences do I need to achieve that business outcome? Or I can look at it from and maybe that's more of the reality in most organizations. I bought a tool. Now I need to figure out how it works, kind of with that From your experience. What do you think are the first and the most important considerations to do structuring a new?

Structuring Data Teams

Speaker 3 8:58

data. Yeah, i think that I did a lot of analysis on like what I think first of all was kind of missing for a while which we also realized at Montsoy is just like how is the data team supposed to look like? So very kind of meta questions around how big should it be relative to the engineering team? How much of my organization should be in data In my data team? what's the right ratio of different roles? How many should be data scientists? How many should be analysts, data engineers and latest engineers, all these?

Speaker 3 9:23

Hvor mange bør være datasjensere? hvor mange bør være analyser, datateknikere, analytiske teknikere Alle disse spørsmålene, tror jeg, må du tenke på Og jeg har lyttet til mye statistikk rundt det ved å gå inn og få LinkedIn-data fra mange mennesker til å skabe benkmarker, så vi kan snakke litt om hva de ser ut som. Men jeg tror også at det er i begy. It's probably worth asking why you need to scale your data team. There's probably an underlying thing happening, so that could be that In the case of Monzo, maybe you're just growing like crazy and you need to scale your data team alongside other disciplines. It could also be that you realize you've underinvested in data and there's a lot of gaps. Maybe you get a new head of data in who realizes that and they create a compelling vision and strategy for why you need to hire more data people. So there's usually something externally that makes that the case.

Speaker 3 10:08

I would say, if we look at the different stats, so I can just throw a few over the counter here and you can chew on them whatever way you want. but I basically went in here and looked at LinkedIn and, i think, collected more than 10,000 data points around how different companies are structured, how different teams are set up and so on, and a few of the things that jumped out is one the median percentage of data people in a company out of the total company size is between one and four percent. So quite a big gap in terms of how big the data team is relative to the total company. But also, interestingly, when you look at the data team relative to the engineering team, that varies somewhere between one and ten. So for every 10 engineers you have 1 data person to 1 and 3, depending on the companies, and there's a lot of nuance to that that we can dig into. that, i think, is really interesting.

Speaker 1 10:54

Yeah, let's dig into that. I think that's a very interesting point. Why is there such a difference, such a variety?

Speaker 3 11:01

Yeah, i think that the big thing I realized is that when you plot er så forskjellig, så mye varier. Ja, jeg tror at det store jeg har forstått er at når du plukker de ulike teamene og data-til-ingeniør-ratioen, det som virkelig beveger hvor en kompani faller er business-modellen. Så jeg tror at jeg har gruppet min analys til B2B, fintech, b2c og så marketplace Og de kommenhengene med. I høyeste grad, de minste data-mennesker relativt til ingeniører er B2B-samlinger Og jeg tror det er fordi de er fokusert på. De har ofte ikke så mange, men store kjøpere Og data er mest ofte brukt for basicene som dashboarding og innsatser og salgsanalyser og så videre, og det er mye mer som ingeni.

Speaker 3 11:49

På den andre skala har du markedplasser som InstaB, deliveroo, void, disse slags bedrifter som tilbyr noen slags produkter hvor hvis du gjør noen ting i data, som å optimere utslippeligheten eller bli bedre på å bestemme hvordan skrivere bør distribuere ruten så vinner du på siden av. Så jeg tenker på dem som data-enablet bedrifter i en slags måte win on the bottom line. So I kind of think about them as they're almost like data-enabled companies in some way and that just really shifts the amount of data people they have.

Speaker 1 12:19

That is a very interesting point. I'm thinking about this from a different perspective. Maybe Two things right The business model itself. I understand that as a reasoning. That makes sense, but I wonder if sector and size or size Det er en forståelse for det. Men jeg spør om sektoren og størrelsen av organisasjonen også spiller en rolle. Jeg vil forstå at det er en sann forskjell om du er i en høyere reglert sektor enn en mindre reglert sektor, eller om du er i en start-up enn et utbyttet multinasjonal regulated sector. Or is it different if you are working in a startup versus established multinational?

Speaker 3 12:54

Ja, like one example, going back to Monzo, where I worked, monzo was a fintech regulated by the FCA out of the UK, and if you're a bank, what you don't want to be when it comes to fraud and financial crime is be the worst, because if you're the bank with the worst controls, all the criminals are going to flock to you.

Speaker 3 13:10

So you could basically make the case and we also did that that if you plot us against all the other fintechs and if you say that creating things like transaction monitoring and fraud detection are largely data problems which I think they are you don't want to be the one investing much less than your competitors. So I think in that sense, if you look at industry so kind of fintech-regulated companies and you look at industry so kind of fintech regulated companies and you look at size so you've got a meaningful size then you almost need to go in and say, if we decide that we invest significantly less in data, that is not just a decision that means that our data people are going to be busy, that is also a decision that means that criminals are going to flock to us. we might get fined, we might not be able to open a new market, so it becomes a much, much bigger decision. Exactly, you don't?

Speaker 1 13:55

want to be the worst. I like the approach And it's very much something that I think we should have more of an understanding of in data teams as well. It's a risk-based approach to it. right, You don't go, oh, let's be the best in class, but let's see at what level we can balance investment and risk.

Speaker 3 14:16

Yeah, and even also I'll say probably most data teams or companies probably couldn't answer the question of like how do we benchmark? Even answering that is a good starting point for then having the discussion of if that's good enough or not. But my guess would be that most teams wouldn't be able to put themselves on how they compare.

Speaker 1 14:34

It's interesting because there are so many. There are a set of companies out there that do that professionally right, trying to benchmark within different sectors. And the interesting thing is that and we talked about this in the last episode of the podcast when we talked about data maturity assessments is that if you do a benchmark against competitors Vi snakket om dette i den siste episodeen av podcastet da vi snakket om datamaturitetsassessinger at hvis du gjør en benkjøp mot konkurrenter, så er det bare en snakke i tid. Så så snart du begynner å gjøre noen beslutninger på denne benkjøp, så er du en konkurrent.

Speaker 3 15:11

Ja, og jeg tror det går bra. I 2022 hadde vi en masse men all for me, Yeah, and I think it goes well. I brought it to what we had In 2022, we were hiring a lot of people at Montreux. It was a very fast growth time zero interest rates, but everybody else was also hiring. So getting a salary benchmark and finding out like, how do we put the salary That was actually something we had to invest a lot of time and also hire someone in to do, And also that was a moving target. It looked very different in 2032 and in 2033. So I think these benchmarks are hard to come by, but also having nothing is also not great.

Speaker 1 15:37

Let me ask you something else about and this is not me trying to depict the statistics here, but there's something about the understanding of what is a data team. Years back, i wrote a review on Jesse Andersenens book Data Teams, which I very much enjoyed, but I was a bit skeptical at first and it took me, i think, two years to really understand it, because he only talks about three different data teams. He talks about data operations, he talks about data engineering and he talks about data science, and with my data governance brain I'm thinking about. so where does data governance fit in here? Where are the data architects in here? How much of and I call it structural thinking do you need to have in an organization to really set up your data in a profitable fashion? Is that something that you can integrate in the teams And this is what Jesse suggests? right, that data governance is part of data engineering, or is it something you need above as like a more of an umbrella?

Speaker 3 16:40

Yeah, i can tell a bit about how I see the different roles and some of the pitfalls I see, and then also about data governance separately. I think one of the things I've found the hardest, also when doing analysis and when we internally at Munzo were structuring our data team, is this notion of an analyst. Like when is an analyst someone that does work, that's closer to the business and interprets dashboard, and when should they sit in the data team? And probably some of the worst data problems I've seen is when you have pseudo-data teams starting to operate a little bit like data teams but don't sit in the data discipline. So that can be the case if you have, let's say, a lending team or a domain expert team and you have a head-off that starts hiring in people that kind of do data work and then, before you know it, they start adopting their own tools, they start adopting their own standards, and that always leads to not good outcomes. So what I've seen happen is that these people should be, one way or another, absorbed into the central data team. They should use the same kind of tools. They should think about data as other people think about data. So I think there is that question to be asked like for the analyst? is it more like kind of like a strategy person working in spreadsheets, or is it actually someone who at some point might write SQL, deploy a dT model, something like that?

Buisness Models and Data

Speaker 3 17:54

And I think the second thing, when it comes to data titles, the word data science data scientist is probably the hardest one to hire for and where I made the most mistakes, because for some people, a data scientist is someone doing machine learning and statistics, a-b tests and so on, and for other people, a data scientist is doing what analysts used to do AB-test og så videre, og for andre mennesker er en datasjensisk å gjøre hva analyser brukte til å gjøre, og det ser ut til å være helt uansett i industrien.

Speaker 3 18:19

Så jeg vil like å se denne ordet eller titlen forandre eller noe slik å bli klart opp. Og på det punktet av datagoverning, tror jeg det er en vanskelig rolle og ikke I think it's a difficult role and not one I've had that much experience with myself. I'd say in the statistics I ran that the one thing that stood out is that they typically only appear in larger companies. So company size is very much a consequence of if you have a data governance team I don't know if you've, is that what you've seen as well? How have you seen data governance play out?

Speaker 1 18:49

Oh, definitely, and I think that I mean I'm deep diving into governance And it's interesting because you get to a certain point where you look at governance from different perspectives and different angles and you realize that you kind of get detached from the reality of organizations, because most organizations don't have anything And we are talking about it on an entirely different level, for de fleste organisasjoner har ikke noe. Vi snakker om det på en helt annen nivå. Jeg har forstått at når du ser på nordiske organisasjoner, så er du absolutt rett. Dette handler om størrelse og sektor. Et størrelse en multinasjonal gasskampanje med 20-23 000 mennesker. Det different story than if you are in a local mid-sized business somewhere in northern Norway, right. And then the other thing is about sector right. If you are in a highly regulated sector, the demand for governance is much larger, compliance-driven, than in other organizations.

Speaker 3 19:49

Yeah, i would say that we now work with a lot of data governance teams at Munster, at Sync, and I've spoken to quite a few as well, and the one thing I would say looks like a common challenge is that for most data governance teams, as I can see, they're not the ones writing the code, they're not the ones actually doing the implementation, but they're more thinking about process and structure and so on. And the thing to really be very often all the time push up against is these like drawn out processes where you start thinking about, let's say, you want to implement domains or ownership. I've seen some data governance teams sit on a document for a year and plan everything out, and I think often times it's better to flip it on its head, start with the most impactful domain, get it done, get some learnings and then iterate. So it's really yeah, they're really up against this process. That I think the digital science.

Speaker 1 20:39

I think maybe this is a picture that is due to there's a bike race coming up here where I live, but I've been thinking about this from that perspective and this is not going on data governance only, but centralized data services. If you think of it like a bike race where all the business units are racing, then you have two possibilities right. Either you have stations where they need to stop and then can refuel and get some water, get some electrolytes and then continue on their journey, or you can have a motorbike that goes, drives along with the bike race and provides you water and everything you need on the fly. I think that's more of a picture we want to go towards when we talk about centralized data teams, rather than that everything needs to stop up, wait for the centralized team and then continue.

Speaker 3 21:30

Yeah, I like that analogy. I think that makes tons of sense.

Speaker 1 21:33

So there is something about setting up data teams in a greenfield setting. If you are a startup, you have different possibilities. You can think about it differently than if you are an established organization that has been running for a couple of years, where you are very much in a brownfield setting. How would you address data teams, the data team ratio, correctly setting up and structuring data teams in a brownfield?

Speaker 3 21:58

Yeah, so a brownfield means there's already something in place. You're not starting out from scratch. Exactly, yeah, i think that there's probably not one answer to that question, but there's definitely stuff to look out for. And one thing is if you start renaming data roles let's say you have a data scientist and data analyst but you realize there should be just one title. Simply renaming someone from being a data scientist to being a data analyst is not always something they like very much, so I'd say you have to be very cautious of how you approach that.

Speaker 3 22:25

And one thing I saw work incredibly well at Monzo is we had this progression framework where each level so we had from level nivå 6, hvor nivå 1 er en junior dataingeniør eller en nivå 6 er en staff-nivå data person, og bare veldig, veldig klart skrive opp for hver av disse nivåene hva som ser bra ut? bremse det nedover en impakt. Så starte across an impact. So start with the impact, like what impact do people have in that role that are doing well, technical skills and also behaviors And then, if you really get that written out, i think you set this precedent that everybody will be held to the same benchmark and also everybody can come in and actually see what the expectations are and good examples of that, so that's a very good way of getting everybody on the same page in terms of how to think about what goods look like and what expectations are for different roles And, i'd say, for the actual structure.

Speaker 3 23:21

One thing I found incredibly useful is to do a survey of different leaders in the organization and then ask them questions such as how heavy are you with self-serve, how heavy are you with self-serve? How heavy are you with the data quality in your area? How heavy are you with your team's performance? What you then get from that is you get this map that you can color, code and plot in Excel, where you can see what domains score low, what areas score low, and if you see that things like data quality or speed of your dashboarding tool is scoring low, you might need to invest centrally, get data platform people in or data architects. If you see that it's more that people are unhappy about the value that data is being used for the insights that they get, maybe you need more data analysts or data scientists closer to that area.

Speaker 1 24:08

That is a fantastic, smart way of doing it. The interesting thing here is how do you get the right buying to do something like that, to do this analysis in the right way and get management aligned?

Speaker 3 24:20

The good news is, people always like to, even if they're unhappy. if they just get to say it out loud and get the feeling that you're listening to them which hopefully you also actually do that takes off a bit of the steam. So I don't think you need to, i don't think you need to ask for much permissions to do a survey like that. I think that should be well within your scope to do and to roll out, and the main two things would then be to one, make sure you actually summarize the findings and present that back to your leadership team, to the different areas, to show that you've actually listened to it. And the second piece is that you run it again six months later and you can show that, based on the things you learned and the initiatives you then kicked off, because of that, some things have improved.

Consistency in data teams

Speaker 1 25:04

This is very much about consistency and I've been looking at it from a different perspective, and maybe that's because of oil and gas. but what oil and gas is really good at, and has throughout the last decades, is a safety culture. There's a certain understanding of what you need to do and what you should not do to create a safe working world, especially offshore. The thing that has been happening throughout the last decades is a continuous measurement And you're measuring the same things over and over and over to see a progression And that stability in measurement. I think that's very much en basis for suksess.

Speaker 3 25:41

Ja, 100%, og jeg tror det er også veldig unnbrant for en datateam å komme og presentere data om datateamet selv.

Speaker 1 25:49

Så en ting som er interessant her, og dette er også om hvordan data er akseptet i organisasjonen som et asett eller en kommoditet. Men hvordan gjør du det? utfordringen av å organisation as an asset or is it a commodity? But how do you tackle that challenge of aligning peer-to-peer in your organisation with those that are not data people?

Speaker 3 26:06

Yes, you mean peer-to-peer in terms of people who are working with data-like tasks or more with the broader management.

Speaker 1 26:14

There's two perspectives on that right. There's the people that work with data-like tasks. On the one side, it could be IT, det kunne være teknikk, det kunne være R&D eller ingeniør, eller og det er den andre perspektiven på managermennet hvordan du alignerer med managere som ikke er datamanager.

Speaker 3 26:32

Ja, jeg tror at hvis vi begynner med managermannet, det er sannsynligvis det viktigste for performansen av en datap. That's probably the most important thing for the performance of any given data person and the happiness of your day-to-day work. It's like how you think data people, like everybody else, want to have impact work on stuff that matters. They don't want to be these kind of people who get a ticket and then just provide data with no context. So I think it starts with that As much as possible.

Speaker 3 26:55

Data people should be part of setting goals very, very early on.

Speaker 3 27:01

A good example of that when I worked at Google, i was the lead analyst for an area and the director of that area.

Speaker 3 27:07

He previously worked in data, so it was excellent to work with And he even invited me to come join the leadership off-site. So we had a three-day leadership off-site in New York with the management team and I got to be part of that to understand how the goals came to be and even chip in on it and really, really get bought into that. This is what we were going to do, and I even felt like I had a say in it, and that meant that when it then came to tracking these goals and creating dashboards. I was 100% bought in because I was like this is my goals as much as it's the management team's goals. And, yeah, the contrast of that would be that they had gone away. Someone had came back with a spreadsheet where they listed I need this different chart, no reason why I need them, and I think that is night and day for a data person, like if you're part of this understanding the why, setting the goals, or if you just handed a spreadsheet with a set of empty fields to fill in.

Speaker 1 28:00

There is one risk that I've talked about before, on the podcast as well, and it's what I call the business disengagement risk, and that is when you come to well, you talk about yourself as a data-driven company, for example, but your business leadership doesn't really understand data decision, doesn't really understand how it technically came about, and they disengage from it because of that lack of understanding, knowledge gap. And what happens then is that these decisions that are to be made are made by technical teams instead of business leaders, which then again creates a huge risk of strategic misalignment av businessleidere, som igjen skaper en stor risiko for strategisk misalignelse. Og så ender du med den tekniske siloen som gjør det, datadrivende beslutningene, som faktisk er business-decisjoner, og du har det business-teamet, som ikke er med.

Speaker 1 28:54

Ja i det perfekte verdenet hører du inn?

Speaker 3 28:57

mennesker som i? senior-management-rollene? You hire in people who, in senior management roles, are pretty data proficient. But the perfect role does not always exist And I'd say, if I put myself in my own shoes 10 years ago and was to give advice, i'd say even more important than the relationship with your direct manager is the relationship with your main stakeholder as a data person, and that's really the thing that you can take it so far. But if they just don't think strategically about data or bring you in early, or if they don't really get it, there's only so much you can do And I think you should actually you should almost put it on yourself to find your way to be aligned with someone who gets it, and that is a much faster progression if you're a data person.

Speaker 1 29:37

And that brings us to the other perspective and that is the bottom up. but how do you align as a data person with people that on the IT side, for example, or engineers in the business? and well, the main way of reasoning about it the last years is well, let's go for embedded teams, embed data people into business teams to create that value. But when does that make sense and when does it not make sense?

Speaker 3 30:06

Yeah, it depends a lot on the organization.

Speaker 3 30:08

So at Munster we bought into this I think it's called the Spotify model where you have matrix disciplines.

Speaker 3 30:13

So you've got collectives, which could be marketing or finance, and then you've got disciplines like data or engineering, and at the intersection of a collective and a discipline you might have a squad That could be a product squad working on improving customer onboarding, and that squad might then consist of a handful of engineers, a designer, a data person and a product manager.

Speaker 3 30:34

And if that's the case, then if you're the data manager, you can almost just leave that person alone if they're senior enough, because they'll be part of all the rituals, they'll be part of the offsides, they'll be in the same Slack or Teams channels, they'll be in the same stand-ups and they'll have all the context. So that is a perfectly aligned setup where you really kind of distribute the ownership and the goal setting to that product team, to the product manager and the data person. That works really well I think in many, especially in many more old companies. I can imagine in your cases, where you don't always have these perfectly set up product squads and it becomes a little bit more blurry what you actually should do, and I think that can also be okay, but maybe you can still use some of the same principles.

Speaker 1 31:20

Right, yeah, And that brings us to the last part of our discussion, and it is about so you have set up your data team, you have achieved a certain level of alignment beyond the team as well, but how do you scale it from there? What are the biggest challenges you face when trying to scale a data team?

Scaling Data Teams

Speaker 3 31:38

Yeah, we wrote up this old VP ofata-admin. Så Dimitri skrev opp jeg tror det var åtte prinsipper for hvordan data fungerer, da vi var 30 mennesker og jeg tror bare en eller to prinsipper stod til test av tid og vi var 100 mennesker. Så bare en del ting skjønner med skala og jeg of what those could be. I think one is the how do you just set a stamp out that's high and how do you build that into the culture? So one thing we did was we created what's called the Golden Nuggets Award. So every month we had a committee among senior data people. They would pick out of all the analysis and data work that was done which ones was the three best And then they would be presented at the all hands and they got a little award and we added them to the database. So that meant that over the course of a year or two years, if you were a new start-up, you could go in and find the 50 best analysis that had been done by a team of 100 people and that gives you a very, very good idea around what does good look like in a almost crowdsourced way. So I thought that was an excellent idea.

Speaker 3 32:43

The other thing is just writing down this progression framework, getting very clear on what are the different levels, what does good look like, what are specific examples, and, when people get promoted, refer back to that progression framework, mention the work they did and say why that caused them to get promoted, and that'll also have everybody then look at these behaviors and look at these traits and work, why that caused them to get promoted, and that will also have everybody then look at these behaviors and look at these traits and work towards that as well. And so those are two things that come to mind when you scale. The other one is that at a certain scale, managing things centrally can get very difficult, like with a hundred people, for instance. Not necessarily a question of decentralized or embedded and central. It can also be a mix. So we would call it hub and spoke med 100 mennesker, for eksempel.

Speaker 3 33:20

Ikke nødvendigvis en spørsmål om om det er desentralisert eller embeddet og sentralt. Det kan også være en miks. Så vi kaller det hopp og spåk, hvor, hvis du tar vår analytisk ingeniørteam i Monzo, vi hadde i tiderne rundt 10 analytiske ingeniører og i ettergiv og vi hadde en handfull som ble embedt i ulike teamer Og så hver 6 måneder roterte de og nye mennesker gikk inn og satt sentralt, og det betyr at du har dette hoppet, hvor mennesker kommer sammen, skjønner best praktikk, og så går de inn i ulike områder som marketing eller finans og de sørger for at alle standards. So I think that's a very good way of making sure that you don't have one team somewhere that has very high bar of data quality and another team that thinks about it very differently.

Speaker 1 34:06

These are fantastic tips and very practical. I like that. I've been thinking about different ways of scaling data teams. right, It's not just about adding more people to it. One way of scaling, especially in large companies, that has been around since we talked about low-code tooling, but now even accelerated through AI agents, is about citizen development. and how do you get people that are not data natives or are part of a data team to get engaged in data work and do data? There's a certain risk of offer that, obviously, But how do you think about that as a way of scaling your data competence?

Speaker 3 34:48

Yeah, I think it's a very interesting area And I think what often happens is that data team realizes they're bogged down by the same requests ad hoc requests and then they get sold on self-serve and they then open up, let's say, looker and LookML and so on, to many more stakeholders. But then they realize it doesn't quite work and people create all kind of nonsense, cuts and segments of the data and then they come back to not having that much self-serve. So I don't think you can necessarily completely get rid of that problem and empower people en masse. What you can do is you can empower people who are motivated.

Speaker 3 35:26

Some of the best data hires I made at Monser were actually people who worked in customer support or different parts of the organization and then we had them on as a 20% role of really understanding how data worked, not just an ad hoc, sporadic, but every week working with data, learning how the data team worked. That's one, and I say the other one is especially for technical people like product managers and engineers. Some of them can just with a little bit of getting their hands dirty. They can just really grasp the tools. They can understand DBT, they already know SQL, they can even follow how data comes in from different systems and they can actually very easily become self-sufficient. I think where it's harder is this kind of non-technical stakeholder who want to do their own analysis. But can you really let them off and do that? I'm not 100% sure.

Speaker 1 36:16

No, i tend to agree with you on that one. There's another way of scaling You. Jeg tenker at du er rett på det. Det er en annen måte å skale. Du har jo sagt det. Men det handler ikke om å skale volym, men om å skale kvalitet. Hvordan kan du sikre at du har en sikker karriereprogresjon, en sikker skilleprogresjon i dine data?

Speaker 3 36:35

En viktig ting er at du ikke nødvendigvis bør forstå at folk skal gå inn i regjeringen for å forgrønne. Så vi forstod ganske senere i måneden at vi trengte en IC, en individuell kontribusjonsladder som følgte regjeringsrouten. Så i stedet for å være regjering direktor og VP, kunne man faktisk gå av å være en staff av data-sciences. Det er principale datasjensere Og det, tror jeg, er så viktig. For annet risikerer du at alle går inn i regjeringen uten at det er deres kjærlighet Og du lurer også mye kompetanse. La oss si at noen som kan bygge en AB-testingsframverk som alle kan bruke det skulle ikke hende med halvdelen av deres tid som du har spist på å jobbe and managing and so on. So, unless you have a very good reason not to, i think you should have an IC letter that roughly follows the people manager letter, both in terms of salary and expectations and so on.

Speaker 1 37:29

Oh yes, I full heartedly agree with you on that one. You need to have a professional development letter and a career possibility, And that's also. I mean, there are so many jobs out there for qualified data people that you need to have something that keeps your staff motivated over time.

Speaker 3 37:51

What's your take? I know you spoke to a lot of people. Is that something that's still quite novel, or do many companies have an IC progression framework?

Career progression as individual contributor in Data

Speaker 1 37:59

I think it's getting much more appreciated, eller har mange bedrifter en IC-progressiv framgang? Jeg tror det blir mye mer opptatt. Jeg tror store bedrifter har vært jeg vil ikke si en frontrunner, men de har tittet på dette fra en perspektiv for en tid. Og du er rett, ikke sant? Hvorfor skulle jeg, når jeg har en jobber som er fantastisk og har tekniske kapabiliteter, hvorfor skulle jeg ha dem til administrativt tål? Det gjør bare ikke noe. At samme tid og det er kanskje det andre argumentet er at hvis du er i en regjeringsroll, du krever, særlig i data, en certain forståelse av hva du er. Ja, vi har sett statistikk om hvor lenge det tar for en datamann som får en regjeringsroll å forløpe kontakt med datamann. Det er interessant. Jeg tror det er en treårig timeline på det. Etter tre år er du utdateret.

Speaker 3 38:58

Det er også derfor det er vanske å være data-manager eller data-leder, fordi du må virkelig forandre mindsetet fra å være i møter og jobbe med din team til å ha noen finger på pulsen når det kommer til å kunne gjøre data-verk, for å forstå toolene, for å forstå det nede-gride av hva andre mennesker gjør.

Speaker 1 39:16

Så vi er allerede på slutten, men som alltid, har du noen kjærlige takk, noen kall til aksjon, noe som du vil at folk fokuserer på, på grunn av det vi snakket om om å skale data.

Speaker 3 39:29

Ja, det er en del av det. Hvis du lurer på og er en data-opplever, eller hvis du lurer på og er en data-IC, jeg tror at hvis du er en data head of data. Two things have fanned out. One is get that benchmark for your data team. Understand where you fall, whether that's in terms of the data team size, the ratio or salary, or serving your stakeholders. To understand weak areas. Get that kind of get that benchmark and don't be afraid to use that to then say where you want to get to.

Speaker 3 39:56

And the second one is when it comes to progression and scaling, put in place things such as a progression framework the very, very that IC should also be able to progress and then think about stuff like the golden nuggets. So what are ways where you can, without actually being involved yourself, create some rituals that make good work stand out and that helps reinforce them? As a IC, my key takeaway is that the most important person for your progression and probably everyday joy is your most close stakeholder, And I'm sure you are aware of some that are good and some that are less good to work with, but what good looks like is that they involve you early on. They might even bring you into the goal settings and it feels like you're part of the division and part of the team. And if your work doesn't feel like that at all, maybe look around and see if there's other stakeholders you can align yourself to.

Speaker 1 40:50

That was a fantastic call to add. Thank you so much and thank you for the conversation. Thank you very much.