Measuring Impact As A Data Engineer

I need your help. Take a minute to answer a 3-question survey to tell me how I can help you outside this blog. All responses receive a free gift.

The 1 Data Point We Don’t Have

For data engineering, a discipline whose product is precise and tangible, it’s surprisingly difficult to gauge your work’s impact.

It shouldn’t be that surprising that data engineering’s output often flies under the organizational radar, especially since few even know exactly what a data engineer does.

Although a data engineering team’s product is, well, data, we’re essentially mining a raw material; while it is easy to determine its origins, it is difficult to claim ownership of any resulting product.

Like an oil refinery, we take our hours of hard, brain-frying work and simply hand it off to the individual who does something with it — and, by the way, gets the credit.

Data analysts can measure the accuracy or utility of their reports.

Data scientists can measure the precision and ROI of their ML models.

Data engineers can measure things too:

• Gigabytes
• Load times
• Slack/Teams’ threads with stakeholder requests

Consequently, when it comes to measuring output and impact, data engineers need to examine some more unconventional metrics.

The Smartest Data Teams Focus On This One Overlooked Metric

For data teams serving internal organizational stakeholders, there is one metric you should live and die by.

Customer satisfaction metrics.

Before we even discuss tangible measurements of data deliverability like downtime and dashboard load times, we have to talk about your number one success metric: Your customers’ feelings about your output.

While data analysts and data scientists also serve internal stakeholders, data engineers literally architect the data infrastructure of a company.

And where do those directives come from?

The many, many requests your faithful (and possibly only) customers submit.

While, to measure individual contribution to a data engineering team, quantitative data is important, qualitative data trumps quantitive when it comes to fulfilling requests.

Instead of focusing on technical metrics, you should consider:

• How proactive was this engineer in not only fulfilling, but anticipating our requests?
• What different solutions did the engineer propose and how clearly did they explain them to non-technical stakeholders?
• How communicative was the engineer (and team) regarding timelines for deliverables and setting deadlines?

Stakeholder feedback is perhaps the most important first-party data point you can collect.

Pardon the interruption: For more Python, SQL and cloud computing walkthroughs, follow Pipeline: Your Data Engineering Resource.

To receive my latest writing, you can follow me as well.

Data Engineering Is All About The (Revenue) Dollars

The best case scenario for determining concrete impact on an organization’s revenue generation is working on a proprietary data product that is directly responsible for recurring revenue.

If you’re a data engineer at Netflix working on search, you probably have a decent idea how many hours watched the recommendation engine generated and, by extension, how much $ per subscriber netted.

But, say, you’re more of an analytic engineer and your work primarily fuels dashboards.

How do you measure that?

In the second scenario, OKRs are particularly helpful.

But anecdotal data can also give you an idea about the scale of impact your work has.

For instance, maybe a C-Suite leader gives a presentation using a dashboard generated from your data source.

Or maybe your sales team just smashed records using your data to create data-driven customer profiles that generated millions in recurring revenue.

At this scale, it may be hard to put a dollar amount on your work, but what it accomplishes is certainly impactful.

If You Can’t Make Your Org Money, Save It Big Bucks

One of the challenges newer data engineers face is the fact that they’re not yet trusted with flagship, revenue-generating projects.

If you’re unlucky, you’ll spend a probationary period writing documentation and doing code touch-ups.

If you’re a bit luckier, you’ll be trusted with lower-stakes connections where you still might not be bringing in the big bucks.

If you can’t have an impact making your organization money, you can have a massive effect by saving it hundreds or thousands.

Data engineer impact can be tangibly measured by cost savings data.

For instance, early in my tenure, I helped design an automated auditing process that identified little-used tables.

Hundreds of thousands of gigabytes later, I saved my org five figures in annual storage costs.

Cost savings is perhaps the easiest metric to measure because cloud service providers like Google literally provide pricing break downs.

These pricing formulas can then be used to programmatically calculate resource allocation and usage.

Having an awareness of cost also helps data engineers optimize processes for both performance and cost.

Managers like to hear: “We reduced run time from 1 hour to 1 minute.”

Managers love to hear: “We reduced run time from 1 hour to 1 minute AND saved $2,000 on monthly compute costs.”

Takeaway

While metrics are important in data engineering, our impact goes beyond downtime and run time.

Unlike data analysts and data scientists, data engineers are uniquely poised to play an active role in the data strategy of an organization.

At the same time, because our data becomes so pervasive, the impact of our work also becomes harder to track.

Data engineers working at organizations that develop proprietary data products have the luxury of contributing directly to revenue.

If data engineers can’t actively generate revenue, they can optimize processes for both performance and cost.

Instead of focusing on traditional metrics, one of the most important measures of data engineering impact is the feedback from our customers.

Because in data even if the data isn’t always right, the customer is.

Create a job-worthy data portfolio. Learn how with my free project guide.