Shaping Your Data Team
- Boise, Idaho, May 2025This post continues one of my favorite themes, shaping a data team. You can find more articles on this topic here.
Gartner (the IT research and consulting company) continually surveys thousands of executives on topics like data strategy and data team structures, making them a good reference point for industry best practices. In his recent study, How to Create an Optimal Data & Analytics Organizational Model, Gartner analyst Jorg Heizenberg said you need 27 different jobs to build the ideal data team. But at the same time, most companies never measure up to that standard. Many combine all 27 capabilities into a small team of senior data engineers.
At worst, they look for all 27 capabilities in one person.
Just look at the Chief Data Officer job itself. Companies started adding CDOs to their corporate boardrooms about twenty years ago, tacitly acknowledging that CIOs weren’t translating data into better decisions. But today, the average tenure for a CDO is about 2.5 years, among the lowest of all C-suite staff.
With all this confusion, how do you know where to begin when forming a new data team?
Start by appreciating the word “team.” That will help you avoid building a monolithic technical team and move forward without thinking you need to hire another person for every skill. Finding the right combination of people matters most; a team with diverse, complementary personalities and talents makes all the difference.
Four Domains
A good data team should combine people with four main areas of expertise (“domains”). If I were starting a new data team, the first four people I would hire would be...
A business architect who knows your company's business processes. Their success depends on convincing people to follow standard processes and solving data problems with minimal system changes.
- A data architect who builds structures for data that make it useful for all future needs. They solve problems with their technical skills, grasp of database theory, and knowledge of best practices.
- An application architect who understands how people interact with data and how they use software—like Tableau, MS Office, and AI/ML—to meet their needs. For them, success comes from solving problems creatively with user-facing tools.
- An infrastructure architect who understands database administration, hosting alternatives, identity management, security, and how the unique workloads of analytic processing impact these areas. They’re measured by overall system performance. They’ll say “no” to solutions the system isn’t prepared to support.
Separating Roles
Don’t combine these skills into one person; the team works best when you separate these roles. Separating them means each responsibility (domain) belongs to a different person. Draw clear lines defining their roles. A business architect shouldn’t write any code, and an infrastructure architect shouldn’t create any objects in the database.
Separating roles like this creates interdependent work, and that’s the best sign of a healthy data team. Here are some benefits:
- Checks and Balances. Separating responsibilities eliminates conflicting goals. The “jack of all trades” approach that many companies use in their data team favors that person’s favorite solutions, with less focus on alternatives. As the old adage says, everything looks like a nail to someone who only owns a hammer.
- Sustainability. One of the most serious risks IT leaders face is a “single point of failure,” where all the technical knowledge for a solution or a whole system rests on one individual. This is especially common on data teams. When you separate the work like this, you’ve built shared knowledge and sustainability into every solution. Fewer people might be coding, but more people understand what that code does. Understanding the purpose of code matters a lot more than the syntax.
- Creativity. Data work requires creative vision; you’re always working toward something that doesn’t exist. Separating roles like this automatically brings more ideation to every project; people ask more questions about the problem (and its solution) because they come at it from different points of view. Everyone’s vision grows when more than one person controls the design.
If you’re not an IT leader, you might wonder if you need to know anything about the structure of a data team. Yes, you should, because IT leaders who take this counterintuitive approach to team building need your support.
If you’re a CIO, you can always take the safe route and build a purely technical team. Nobody will question you. But that won’t set your team or company up for business success. Instead, use this “domain” approach to build a team with all the perspectives needed to really make a difference in all the decision processes in your company.