Structuring Your Internal Teams & Resources

In the last part of The Complete Guide to Customer Data, we look at the best practices how to organize and structure your teams for customer data management.

First, a brief recap of the previous six guides in the series.

Parts I-III were all about deciding what data you need and how to structure it. We shared our process for creating an ideal customer profile and abstracting your customer data model. We shared how to use customer journey maps to abstract your high-level tracking plan and attribution model. Third, we discussed how to unify this data around common profiles, cleanse it, apply fallback strategies and create your golden customer record or single source of truth.

Parts IV-VI were all about deciding what tools you need and how to tie them together. We shared our model for “hiring tools for jobs-to-be-done” instead of buying tools to fix any pain. Next, we looked at the best practices in customer data integration for teams and any scale. The previous chapter looked at how to use your tools and data to orchestrate 1:1 personalization at scale, working backwards from each experience you wanted to define.

Customer data management involves aggregating and organizing customer data in order to operationalize customer processes and improve customer experiences. Good customer data management is about making your tools, teams, and data work seamlessly together.

With the best practices in tools and data already discussed, that just leaves the team.

Lesson #1: Customer data management is a cross-functional problem

Customer data is the lifeblood of every customer-facing team. Sales, marketing, support, success. But it doesn’t just stop there.

In SaaS, your customer data permeates throughout your product and engineering teams maintaining your software, through finance and operations for all things subscription. Customer data crosses dozens of different functions.

As companies begin to scale, the management of teams separates from the management of tools data. These “ops” roles support the core teams in enabling them to do their job faster and better. For instance, marketing ops and Salesforce administrators managing data instead of sales reps and marketing campaign managers. Division of management enables specialization and gains in efficiency too.

Operations teams enable each team to grow faster. Traditional sales and marketing management can focus their time and attention on growing the people-side of each team - hiring and training - instead of managing teams AND tools AND data. Imagine tools as part of your teams' organization structure.

As your SaaS startup becomes a scale-up, there’s exponential complexity in managing your teams, tools, and data. The operations teams that might have been established to support your customer-facing teams will begin to struggle to manage all the data. Here’s why and what to do about it.

Lesson #2: All data management becomes data engineering

As discussed in Part V on Customer Data Integration Best Practices at any scale, the level of complexity of managing your tools and data rises exponentially as you scale:

• Tying multiple tools to each other (everything can’t connect to everything else directly)
• Multiple “competing” sources of data for the same type of data
• More complex data models and associations
• The importance of real-time data flows

Visual workflow tools and point-and-click interfaces don’t give a complete, simple view of this complexity. Instead, you end up with dozens of different workflow tools managing individual tasks or chained together to manage more complex tasks.

Common tools like CRMs, marketing automation, enrichment, live chat, web & product analytics, and support ticketing are not designed to be interoperable. CRMs like Salesforce were not designed for large volumes and types of streaming event data.

The simplicity of graphical user interfaces becomes a barrier to progress. All of these tools are trying to manipulate data are abstractions of the “raw” data underneath. To solve complex problems, you end up building workarounds which are alien to your tools and lose the true "native” view of how your data works. You have no visibility into how your overall data flows. You need to be able to manipulate the raw data.

Code is a better interface at scale

With the level of complexity in customer data engineering, code becomes the simpler interface. You’re no longer stuck with the limitations of any graphic user interface. Most tools APIs enable you to abstract the core data models which are common between tools - people, companies, attributes, events, segments, and so on. With code, you can extract and connect data without the constraint of any one tool.

The challenge with running your data operations at a lower level is it requires more technical resource. Even if your ops teams have a solid understanding of the problem, they might lack the skillset to operate with raw data.

This moves the problem away from sales and marketing operations towards data engineering.

Data engineering increases 10X in the past three years

There’s clear evidence for the increase in the number of data engineers in companies - we've the number of "data engineers" on LinkedIn increase to over 55,000 in the past 3 years. This doesn't include the number of people with similar jobs, but slightly different titles (like "growth engineering").

Moreover, this correlates neatly with the increase in the number of available marketing tools (you’ve seen the MarTech supergraphic updated year-on-year).

Whilst not all data engineering is for stitching together martech tools, customer data is a core data integration challenge for most teams. It appears the growth in data engineering is a response to this increasing complexity across many tools.

Lesson #3: How to resource your data engineering team

Historically, marketing often gets by with internal favors, external contractors, and productized workarounds (ergo: buying tons of tools). But marketers need to look at other supporting trends around them.

Data engineering talents and even whole teams often already exist within organizations. Data warehousing and business intelligence are two core functions, often led by engineering, that are common in scaling companies. Both are examples of resources being diverted from core product engineering to work on internal data pipelines. These are often centralized functions too.

Data science is becoming a more popular discipline too, but data scientists are not data engineers. They can use and query data, but they don’t generally build and maintain data pipelines. Data scientists don’t build data pipelines like kafka workflows - like a designer to a developer, or sales rep to a Salesforce admin, they sit at opposite ends of the spectrum.

Data Scientist	Data Engineer
Designer	Developer
Sales rep	Salesforce administrator

Instead of fighting for a whole new resource, we see teams leveraging the established “natural” data engineering teams that are already established with the blessing (and resources!) of your main engineering team. You should build the case to build resources here to help manage customer data, instead of advocating for a new, siloed engineering team bolted-on to customer-facing teams.

Lesson #4: The best practice: Centralized business operations and data engineering

Since customer data is cross-functional, data engineering teams often sit inbetween multiple parts of the business and serve as an internal service - technical integrations, data warehousing, business intelligence, and so on. If operations are the primary user of data engineering, then the best practice is for operations to centralize operations too. “Business operations”.

Functional operations teams abstract the problems of managing tools and data away from individual sales reps, marketing managers, and so on. This means an individual sales rep can focus on their task at hand, not wrangling data and diving through workarounds.

As data becomes more complex to manage (a data engineering problem), the same abstraction needs to occur between operations and data engineering. Marketing operations, Salesforce administrators, and the operational layer all need data engineering resources so they can focus on their task at hand, not getting stuck with complex data engineering.

This doesn’t apply to all the jobs of functional operations teams. Some of the jobs of operations still need to be tied closely to the “end” users such as sales enablement creating content and coaching for sales reps.

We’re seeing business operations become the owner of key tools in the customer data layer, including Salesforce, Hull, and the data warehousing projects.

Centralization matters for customer data management matters for several reasons:

Pooled budget

Sales operations or marketing operations alone might not be able to dedicate the budget to fund dedicated data engineers for their own functional needs. By centralizing data ops, budget and resourcing become easier for data engineering, data science, and so on.

Dedicated resources

Instead of poaching engineers from product-focused tasks or being dependent on favors and “goodwill” to build and maintain core data flows, centralized data. It’s easier to go from zero-to-one dedicated engineer and continue to build the team there.

This is also radically more attractive to engineers - joining a dedicated data team vs. being shoehorned into a non-technical team as glorified IT support.

Deeper understanding

Operations teams have the understanding. Engineers “borrowed” from product engineering might have the technical skills, but lack the problem-specific, tool-specific understanding of the problems to be solved. This often leads to friction and frustration - what is built is not quite what is needed.

Removes data management from other teams

If data engineering is done properly, then none of your customer-facing teams should be struggling anymore with managing their data. This can radically improve team efficiency across the company as they have less data to manage. It should also enable you to find more opportunities to grow.

Lesson #5: Go on the offensive: Data engineering should create new opportunities to grow

Most data engineering teams are on the defensive. They’re trying to wrap their arms around existing data flows. Their focus is on adding visibility, reliable, and security. But this just scratched the surface of what is possible with your customer data.

In Part V, we discussed the difference between OLAP and OLTP. Most data engineering is OLAP (analytical). It is about using ETL tools to aggregate data in a data warehouse to lay a business intelligence tool over (like Tableau or Looker).

There’s a difference between using data to pull insights and using data to trigger action.

Data engineering should enable your go-to-market teams to take opportunities they’d otherwise miss. As your leads move through the buyer's journey, you should be able to do things like:

• Trigger personalized emails from sales and marketing
• Engage entire accounts with ads
• Personalize your website and live chat
• Personalize lead nurturing across multiple channels

Part VI discusses how to orchestrate 1:1 personalization at scale with your tools, teams, and data. This is exactly the kind of thinking that your data engineering team needs to be at the heart of.

To do this, your operations and data engineering team needs to be able to compute a single source of truth in real-time, and use this to build their customer data integration strategy to all your data sources.

By enabling real-time updates, it means your tools and teams can “react” to your leads and customers actions as they move through the buyer's journey. With more engagement and more personalized engagement, you can accelerate the buying cycle. Customer data management becomes a competitive advantage - go on the offensive.

Lesson #6: Where do data engineers come from?

The best growth and data engineers combine both technical expertise in building and maintaining data pipelines with a deep understanding of the business problem. But these people don’t naturally occur in the wild.

At Hull, we see these growth-focused engineers come from one of two sources:

Formal or professional background in engineering

They might have studied computer science or otherwise learnt to code. By applying their problem-solving mindset to technical business problems, they might be the source of favors for sales and marketing teams. Eventually, they might join a revenue-focused team, implement their own ideas, and later own a revenue-generating metric.

Professional background in marketing

They might have come from a marketing background but have been drawn towards more technical challenges. Graphical workflow tools nurture the line of “if this then that” thinking. Basic HTML & CSS gives confidence in code syntax and might lead to learning SQL, simple scripts, and API calls. Eventually, this confidence might result in shipping production-quality code to solve marketing challenges.

By understanding the sources of these engineers and the jobs-to-be-done, you can understand where to source data engineers from — whilst they’re more abundant in 2018, they’re still mostly being sourced from tangential fields.

You cannot compromise on the engineering skillset. However, there are levels to the engineering skill needed for different jobs to be done.

1. Infrastructure - building and maintaining data pipelines. “Data DevOps”
2. Scripts - manipulating data between tools
3. Operations - speccing data needs according to team needs

Infrastructure for data engineering

Your data engineering team needs infrastructure to build on top of. Data warehouses, ETL tools, and customer data platforms all provide elements of this core infrastructure to enable customer data management.

The more advanced your customer data infrastructure, the more capable your data engineering teams will be, and the smaller the engineering resource to achieve the same result will be. For example, instead of engineering a streaming workflow in Kafka, use a real-time customer data platform.

Learn how teams engineer growth with their customer data in Spotted.

Spotted is our series sharing the latest trends, tactics, and techniques in customer data management on Hull and beyond.

Since Hull sits at the customer data layer, we see exactly how SaaS teams organize their data and orchestrate their tools & teams. Spotted takes these unique insights and shares with our own subscribers (together with any interested subscribers).

Previous Spotted posts have highlighted the latest trends in:

• Email personalization at scale
• Sales & marketing alignment
• Multi-touch attribution modeling
• Lead scoring & signals