Growth Needs to Speak the Language of Data and Engineering

As growth professionals, it’s crucial for us to understand the data and engineering workflows that have a direct impact on the data that powers the reports we rely on (inside analytics tools) and the experiments we run (inside activation tools). 

In other words, we have to know how the teams we collaborate with operate and how their everyday workflows affect the data we use to derive insights and drive growth. Also, knowing the differences between the respective workflows and priorities of D&E teams helps set realistic expectations, deal with conflicts, and collaborate more effectively with each of our counterparts.

Before I led growth at Integromat (now Make.com), I had collaborated with software engineers on many projects, including a previous startup. I had a good understanding of application data modeling and was also very comfortable navigating and running queries on MongoDB, a NoSQL database.

However, I had never worked with data engineers, and in fact, I took it for granted that software engineers inherently understood data engineering workflows.

I realized that was a myth only after working with two ace software engineers on setting up the customer data infrastructure during my time at Integromat. 

The engineers who worked with me – let’s call them Dom and Pete – were capable of building anything. Dom had built a microservice that would collect and sync event data from our web app (the core product) to all the tools in our stack. Pete, amongst other things, had built the email preference center that gave users granular control over the types of emails they’d like to receive from us (preferences could be configured at the account level allowing users to turn off specific types of email notifications for specific accounts).

However, it wasn’t obvious to them why I wanted them to implement data collection with so much granularity and how I intended to use the data to drive growth. In hindsight, this makes complete sense as it was their first time implementing analytical data workflows.

But back then, it didn’t occur to me that their primary concern was building a robust system – the web application being one of the core components of the system. They didn’t need to think about capturing application data beyond what was necessary to monitor the system and make sure it worked as expected (they used Datadog for this). Application data or product usage data to understand user behavior wasn’t something they needed to worry about, and understandably so.

That said, we were all passionate about the product, and Dom and Pete were curious to understand how their efforts would help accelerate growth. Therefore, it was easy to explain to them that the data collection project we were about to embark upon would serve two key purposes: 

1. We will be able to use the data in our event analytics tool (Mixpanel) to figure out where in the product were new users getting stuck and dropping off.
2. We will be able to use most of the same data in our activation tools to trigger in-app tours (Userflow) and emails (Customer.io) to guide users toward the activation milestone.

The engineering duo’s outlook towards instrumentation (data collection) completely changed once it became clear to them how the data would be used by the growth team to improve product adoption and increase activation.

My biggest takeaway from this experience is this:

Software engineers certainly have the technical knowledge to build data pipelines, but they don’t inherently understand why growth teams need so much data from so many different sources to be made available in so many different downstream systems.  

Someone must keep both Engineering and Data apprised about the data use cases of growth teams as well as the subsequent impact on business growth. This person will also ideally gather inputs from the engineers, answer their questions, and document everything.

As the Head of Growth, I was this person at Integromat and in our case, Engineering doubled up as Data.

Software engineers and data engineers don’t speak the same language  

Today, the skill gap between the two professions is diminishing – data engineering is moving closer to software engineering – and it’s becoming increasingly common for software engineers to move into data engineering roles.

But despite the overlap in their technical skills, data engineers tend to have a better understanding of the data needs of growth teams. This is because the data team operates right between the engineering team and the growth team.

When you find yourself working with both Data and Engineering – which is bound to happen – understanding the difference between their interpretation of common terminology is a big step toward having better conversations with both teams regarding what data needs to be collected, where it originates, and where it needs to be sent.

For instance, when you mention “data modeling”, a software engineer will likely assume you’re referring to Application Data Modeling – the process of designing the foundation of a software application.

On the other hand, a data engineer will think you’re talking about Analytical Data Modeling – the process of defining what data needs to be made available in what shape for analysis or activation purposes. 

Looking up the term data modeling reveals that search engines too behave like software engineers, which I find surprising because the chatter around the importance and impact of data has never been louder, and analytical data modeling is one of the key activities that data teams spend time on (or at least they should) to make data usable for growth teams.

Data modeling doesn’t get talked about enough in the context of growth. However, once you grasp it, everything becomes easier – you’re able to ask better questions of the data and collaborate more effectively with your D&E counterparts.

I’ll cover the differences and the relationship between application and analytical data modeling in a future post.

Pause to ponder 🤔  

Think about the last time you spoke to an engineer about your data needs and ask yourself the following questions:

• Did you know whether you were talking to a data engineer, a software engineer, or someone who doubled up as both? 
• If you’ve worked with both types of engineers in the past, did you notice any difference in how your requests were perceived this time? 
• Did you find yourself explaining something that you took for granted the engineer would know?