Growth needs to speak the language of Data and Engineering (D&E)

How to better collaborate with your D&E counterparts.

Hey there,

Welcome and if you haven’t already, you know what to do! 😃

---

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.