Building the Data Team That Delivers the Roadmap

In early 2024, Brandon Nelson at a paid performance marketing agency and I started designing what a data engineering team would look like for their product roadmap. Over the next eighteen months we hired six people: a data engineer, three analytics engineers, a QA engineer and team lead, and a project manager. Together we built a data-intensive product that intersected with at least two other teams’ work across the company, and that product would go on to serve over 200 brand clients with multiple stakeholders at each brand logging into the tool daily. Along the way I learned a lot about what it takes to go from a blank org chart to a team that has real momentum.

This is about that process: how we decided what roles to hire, how we onboarded people, and the value that creating a team brought to the organization and to the work itself.

Learning through patterns, not instructions

The first engineers we onboarded were junior. The question was how to get them productive on dbt transformations without slowing down the core modeling work Brandon and I were doing.

I told them: what do you do when you don’t know what to do? You try to find an example of what’s already been done. We pointed them at completed models, told them to study the patterns, and let them try to replicate the structure on a new data source. Iterative progress over perfection. The first model would go slow. The second one would go faster.

We built a library of examples and paired new people with someone who could answer questions when the example ran out. That teaching approach carried through the entire engagement.

Hire for fundamentals, decide fast on fit

Not every early hire worked out. We interviewed for fundamentals of course, but it’s hard to see how deep someone’s abilities really are until the work starts. One engineer cleared the interview but struggled once the models got complex. A few weeks in, the pattern was visible: we’d talk through an approach, provide a direction to explore, and nothing concrete would materialize. We made the call early and reassigned the work.

With a roadmap and leadership expectations to meet, you can’t afford a long evaluation period. Someone who isn’t contributing by week four probably isn’t going to find their footing by week eight. Better to make the decision early and get the right person in the seat.

The next hire was a different story. Brandon introduced him to the team with a note about his dbt experience and how he’d help with design aspects and foundational work. He was productive within a week. The fundamentals were already there, so onboarding was about giving him context on our specific data sources and modeling patterns, not teaching him the craft. That distinction matters when you’re building against a roadmap.

When the team outgrows the first process

A few months in we brought on several people at once: David, Amanda, and a couple of others. The team went from a handful of people who all knew each other to a distributed group across time zones. The onboarding approach that worked at three or four didn’t hold at six or seven.

We formalized. Structured onboarding sessions during the first week. Pairing assignments so new people were working alongside someone on a real model, not just reading documentation. Amanda and David ramped up through visual data flow diagramming, actually mapping the pipeline before writing any code. That visual approach turned out to be one of the better decisions we made, because it gave new engineers a mental model of the whole system before they touched any piece of it.

Process is one of those things that’s easy to defer because the team is small enough to coordinate informally. By the time we formalized standups, sprint cadence, and a leads-only sync, we probably should have done it a quarter earlier. Investing in process before it feels necessary is almost always the right call.

The decision-maker bottleneck

As the team grew, Brandon became the bottleneck. Not because he was slow, but because he was the only person who could approve modeling decisions, answer architecture questions, and make calls on client-facing priorities. He was trying to be IC, tech lead, and manager simultaneously.

He was honest about it. On one call he described the friction of a tool migration they were going through: “It’s like we’ve completely started over, first day back.” That kind of openness from a team leader built more trust than if he’d pretended everything was smooth.

The fix was structural. We restructured reporting lines, moved team members under David, and established leads-only Monday syncs so Brandon wasn’t in every conversation. By early 2025 we were discussing hiring an additional manager to distribute the load. The lesson was that the person who built the team is usually the last to see they can’t run it alone anymore, and the sooner you address it the better the team gets.

Balancing specialists and shared knowledge

We made deliberate hiring choices around specialization. Each hire unblocked a specific constraint in the roadmap.

The tradeoff with specialists is that they don’t share knowledge the way generalists do. When one person owns the API layer and another owns the modeling layer, the team gets faster but more fragile. We addressed this through peer code review as a standard part of the workflow and documentation requirements where any new pipeline or model had to be documented well enough for someone else to maintain it. Over time, the team built enough cross-coverage that no single person’s absence could stop the work.

People and process over tools

One of the most fulfilling parts of this engagement was watching the team develop its own momentum. Early on, the energy came from Brandon and me driving the roadmap. By mid-2025, the team had its own cadence, its own decision-making patterns, and enough shared context that conversations moved faster.

The problems we were working on by that point weren’t tooling problems. They were about data quality, trust between teams, and getting stakeholders aligned on what the metrics meant. That’s the work that actually matters, and it’s the work that only happens when you have a team that trusts each other enough to have the hard conversations. Building that trust, working with a group of people toward something concrete, watching them grow into the roles, that’s the part of the work I find most meaningful.

What I’d carry forward

The things that worked: hiring for fundamentals over hype, teaching through patterns rather than instructions, investing in process before it feels necessary, and creating structure early so the team can scale without depending on any one person.

What I’d do differently: formalize process at four or five people instead of waiting until six or seven, address the single-decision-maker bottleneck sooner, and build documentation into the daily workflow from the start instead of adding it later.

The best teams I’ve been part of are the ones where the work compounds. Each person makes the next person more effective, the processes get smoother, and the data products get better. That’s what we built here, and it’s the part I’m most proud of.