A Plan for Empowerment and Scale
- Frictionless Decisions brings you counterintuitive, original, jargon-free ideas for connecting data to decisions. Every week.
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?
Four Leadership Domains
I 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.
A good data team should combine people with expertise across four main areas (“domains”). If I were starting a new data team, the first four people I would hire would be…
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.
- 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, andknowledge of best practices.
- 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 fromsolving problems creatively with user-facing tools.
- Infrastructure architect who understands system administration, hosting alternatives, identity management, security, and how the unique workloads of analytic processing impact these areas. They’re measured by overall system performance, how it runs day to day. They’ll say “no” to solutions the system isn’t prepared to support.
Separating Roles
Intentionally draw clear lines defining each role. A business architect shouldn’t write any code, and an infrastructure architect shouldn’t create any objects in the database. Define clear quality control workflows for your project development. Your database architect, for example, should approve all development projects that include data pipeline code.
Here are some benefits of separating roles like this:
Checks and Balances.
Separating responsibilities eliminates conflicting goals. The “jack of all trades” approach that many companies use for their data team favors one 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 an entire system rests with 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 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.
Interdependence.
Separating roles like this creates what I call “interdependence”; people are forced to work together.
For example, they share technologies. You might notice that I haven’t said much about the specific software technologies your data team uses. In my management model, the whole team owns and uses all of the technology platforms. For example, every member of the data team knows how to use Tableau dashboards and SQL Server Integration Services; everyone has access to the development tools and understands their purpose within the platform architecture.
You avoid aligning tools with specific people and creating a single point of failure when things go wrong. When everyone uses a tool, the team can find more use cases for it. It makes tool selection a shared decision. Many data teams accumulate more and more software platforms over time, eventually owning almost every data management platform on the market.
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 intentionally build a team with all the perspectives needed to truly make a difference across your company’s decision-making processes.
To remind you of this week’s data concept, enjoy Making Plans for Nigel, by XTC, from the Frictionless Data Spotify playlist.
For the full story about making data flow faster and better, check out Frictionless Data on Amazon.
