«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.

«It can’t be a centralized team. That is too dangerous, because you don’t know the business domain.»

A deep dive into the complex balance between data, ethics, and commercial operations in a modern media organizations. Robert Børlum-Bach from JP/Politikens Hus takes us on a fascinating journey through the media industry's data landscape, where AI is revolutionizing journalism while simultaneously raising critical questions about democracy and public discourse.

What does data management maturity actually mean in an organization? Robert challenges traditional thinking as he explains why his team avoids using the very term "maturity" and instead focuses on visibility and understanding the real challenges faced by teams. He introduces the innovative "stamp model," which visualizes how different departments require varying levels of support on their data journey.

In a world where media organizations must balance dependence on major tech platforms with the need for editorial integrity, Robert shares practical approaches to data contracts and data products that bridge the gap between technical and business needs. We explore how JP/Politikens navigates between centralization and decentralization with a "demarcation line" that is designed to be broken when teams demonstrate higher maturity.

Whether you work in data, media, or leadership, this conversation offers new perspectives on how organizations can develop a healthy data culture that balances innovation and standardization. The most important advice? Stop telling teams they have "low maturity"—start listening to their challenges and questions instead. Because that’s where true data governance begins.

Here are some key takeaways:

Social Media

• Social media is originally not designed for news consumption. Journalists and media houses need to ensure the same quality of news on SOME.
• There is an unequal dependence between media houses and SOME platforms.
• Think about then ethical implications of driving traffic to your side and platform through click bate, or rage bate, which might nit be the way you want to present your organization.

Maturity Assessments

• If data is a support function to the business it might be strange if you demand to assess the businesses dat maturity,
• Sometimes maturity is reflected in the questions you get back from whom you are assessing.
• There is a natural variety of maturity between different parts of the business.
• Showcasing this variety can be a good step towards learning from each other.
• Start with a common baseline, but try to adjust your approach in how you support the different business units to their level of maturity.
• 4 deliverables of a maturity assessment:

1. As-is
2. To-be
3. How to close the gap between as-is and to-be?
4. Measure your progress

How to increase maturity?

• Data governance sets up the playing field, but you need to play on the field.
• Set a baseline to get a starting point. This needs to be a common determinator that is not too low and not too high, but relevant for all business units.
• «We are seeing more and more data enabling teams.»

Strategic perspective on maturity

• Maturity assessments are a snapshot in time and the world around you is constantly evolving.
• Assessments should be an organic and living thing.
• Keeping updated information on maturity should be the teams themselves.

Federated and domain oriented

• Stated with data contracts to identify producer and consumers and expectations between them.
• Understand usage, requirements, ans success criteria for data.
• Contract as skeleton and products as the flesh around it.
• Understanding roles and responsibilities is a constant challenge you need to face.

«Det at det er en team sport; det tror jeg er i hvert fall noe data verden kan lære av (software development). / The fact that it’s a team sport; that’s definitely something the data world can learn from software development.»

Software development is ahead of the data world in many ways, but what can we learn from its methods? Audun Fauchald Strand, Director of Platform and Infrastructure at NAV, shares insights from building autonomous teams and balancing freedom with governance.

Here are my key learnings:

What is a platform?

• A platform is something you build on top of. Something that eases building applications, because if a common ground layer.
• A platform reduces the need for competency, since it predefines some choices.
• The capacity for change is higher when building based on a common platform, then when buying applications.
• It’s important to find a balance in how much you should standardize through a platform and how much room for innovation should be beyond that.
• A platform can provide an «easy choice» that is the best practice way, but it should also allow for alternative, innovative ways to get jobs done.

Software Development and Data

• Software development has been a role model for data work, but they are at different stages of maturity.
• What is happening now in data platform is something Audun has experiences in Software 10 years ago.
• Yet, the principles are largely the same.
• Data is not as mature as software. There is still something to understand when it comes to use of tools and open source, etc.
• «Verden har blitt god å lage software. /The world has become real good at making software.»
• There is a certain agreement on what good looks like in software.
• Software has embraced open source in a much larger degree then data.

Data Mesh and the need for scale

• Data Mesh was a description if the data world from the perspective of a software developer.
• Change in architecture of operational environments have led to more possibilities to scale and to speed up operational data processing.
• This changes the need for speedy analytical data environments that have traditionally been built to compensated for the reduced flexibility of operational environments.
• Scaling up in a Data Mesh fashion, requires more data and analytical competency in teams.

Teams

• Working in teams, and having team ownership of products creates a certain sustainability over time.
• In software, with open source utilization, only teams can take technological decisions. Who else could decide what library to use for what purpose, then the team working hands on?
• You have to believe in autonomous teams for them to work. If not you will create dependencies that minimize their authority as a team and thereby capabilities to deliver.
• To create alignment there are some steps to take, from communicating openly, creating a tech radar to ensure alignment between team, to describing deliberate choices, rather then general principles.

5 learnings from article on alignment and autonomy:

1. Insource data expertise to ensure ownership, security, and business alignment.
2. Embed data professionals in cross-functional teams to enhance collaboration and generate actionable insights.
3. Balance team autonomy with governance by allowing flexible tool use within standardized data policies.
4. Foster continuous learning through asynchronous knowledge-sharing tools like wikis and Slack.
5. Provide clear direction with self-service data platforms to support scalability, efficiency, and governance.