Building High-Performance Data Teams Starts With People, Not Tools

1. From the Dodgeball Court to the Data Warehouse

It isn’t every day you meet a data leader who cut their teeth coaching international dodgeball teams. At first glance, the two worlds seem polar opposites. One involves physical agility and rapid-fire reflexes; the other involves sitting behind a monitor debating the merits of AWS QuickSight.

However, Sam argues that the crossover is massive. “The true nature of a coach,” Sam notes, “is building an environment and a culture where people can perform at their best.”

In data engineering, “performance” is often mismeasured by ticket velocity or uptime. In a human-centric model, performance is measured by clarity. Does the team understand the business “game plan”? Are the “egos”—which Sam jokingly admits are much easier to manage in data than in pro sports—aligned toward a common goal? When engineers view themselves as coaches of the data flow rather than just its mechanics, the output changes from “raw numbers” to “business strategy.”

---

2. The Power of the “Internal Stakeholder” (Dogfooding)

One of the most compelling insights from the conversation is Reality Mine’s approach to product development: Dogfooding. Reality Mine’s core product is data capture—monitoring online behavior with consent to provide market research. Traditionally, data engineering teams sit at the end of the line, catching whatever raw data is thrown at them. Sam’s team flipped the script. They act as the “internal client.”

“We’re actually experiencing what our clients experience firsthand,” Sam explains. If a data point is difficult to work with, or if an ETL refinement is needed to make the user journey fluid, the engineering team feels that pain immediately.

Why this matters for Data Engineering:

• The Feedback Loop: Instead of waiting for a client to complain three months later, the engineering team identifies friction in real-time.
• Empathy-Driven Development: Engineers aren’t just moving bytes; they are solving their own problems, which inherently solves the customer’s problems.
• Quality at Source: By being the first “consumer” of the raw feed, the team can feed refinements back into the capture process, ensuring the data is “born clean.”

---

3. The “Wild Intern”: Managing AI Accountability

You can’t talk about data in 2026 without talking about AI. But while many teams are rushing to fully automate their pipelines, Sam suggests a more grounded approach: The Ownership Model.

He describes AI as a “digital colleague” or, more accurately, an “intern going a bit wild.”

In a data engineering context, AI can be brilliant at spotting trends or writing boilerplate code, but it lacks the context of the “business alpha.” If an AI writes a script that miscalculates a funnel metric, the AI doesn’t lose its job—the engineer does.

“That ownership and accountability… you’re the line manager to that digital colleague. Any mistake it makes falls back to you.”

This “Human-in-the-Loop” philosophy is vital. It encourages engineers to use AI in “Ask Mode” (interrogating codebases) rather than just “Auto-pilot Mode.” It maintains the integrity of the data engineering profession by keeping the human responsible for the “Truth” of the data.

---

4. Pragmatic Tooling vs. The “Shiny Object” Syndrome

There is a controversial take in this discussion: the use of AWS QuickSight. In a world where every recruiter is looking for PowerBI or Tableau experts, Sam’s team leans into a niche stack. Why?

Because the constraints of the business dictate the tech, not the other way around.

Reality Mine handles sensitive panelist data. Their contracts often specify that data cannot leave the AWS ecosystem. While other teams might fight for a “cooler” BI tool, Sam’s team prioritizes Information Security and Contractual Integrity.

The lesson for data architects is clear: Don’t disrupt a functional ecosystem for the sake of a trend. If a tool is embedded, secure, and fit-for-purpose, the goal shouldn’t be to “rip and replace.” The goal should be to find a specialist who knows that niche tool inside out and can make it sing.

---

5. The Data Engineer as a “Detective”

Sam describes the joy of the job as being a “kid in a playground.” When you have access to data that shows the journey from an abandoned shopping basket to the next app a user opens, curiosity becomes your greatest asset.

High-performing data teams aren’t just reactive; they are inquisitive. They don’t just wait for a ticket that says “The dashboard is broken.” They ask, “Why are people abandoning their baskets in the first place, and does our current data capture reflect that reality?”

This shift—from Service Provider to Business Partner—is the hallmark of a people-centric leader.

---

Final Thoughts: Leading with Empathy

As the conversation concludes, the takeaway is that data engineering is ultimately a people business. Whether you are coaching a dodgeball team or a squad of Python developers, the principles remain:

1. Build the environment so the players can succeed.
2. Use the product you build so you understand the pain.
3. Hold the line on accountability, especially when AI is involved.
4. Prioritize the “Why” over the “What” when it comes to tooling.

In the end, the data is just a reflection of human behavior. To engineer it well, you have to understand humans first.

---

Dig Deeper 🎧

📺 Watch: https://youtu.be/XbhtO5HeFt0
👤 Connect with Sam Wrench on LinkedIn
🌐 More episodes: Matatika.com/podcasts

#Blog #Cloud Cost Optimisation #Data Engineering #DataStrategy #ETL