Structuring Data Teams

Article written by Pete Crawford

Understanding Roles, Responsibilities and Operating Models.

How data teams organise themselves and evolve their operating model directly dictates the speed and success in delivering clearly defined value. There is often ambiguity associated over team roles – especially as tasks change in response to technology services that accelerate the ability to automate, collaborate and experiment. In these circumstances, how data teams are structured effects knowledge sharing, ownership over data initiative outcomes and alignment with business objectives.     

“Insights from Pete Crawford | Head of Data, Analytics & AI, Pete Crawford spends his day-to-day leading strategy, governance and execution over enterprise data platforms, data science and AI capabilities. Speaking at leading industry AI and data events, Pete is experienced in forming and directing multi-disciplined teams to manage enterprise information assets and deliver business outcomes through advanced analytics.”

The organising principles, or structure, of data teams can be reduced to four key elements.

1.     Leaders who can set context, navigate trade-offs and supply decision-ready data

Organisational data expectations can switch between defensive-oriented objectives (security, privacy, governance, regulation), platform-oriented objectives (infrastructure, data discovery, data quality) and offensive-oriented objectives (self-service insights activation, enterprise-wide data literacy, decision automation, partnerships, monetisation of data products). To accommodate this mix of expectations, data leaders must balance domain and technical expertise with an understanding of how to:

·      Advocate and embrace change both within the data team and at an executive level

·      Create a shared context and comfort with knowledge transition among the data team and their collaborators

·      Set an environment of ownership over decisions and accountability over outcomes 

·      Facilitate partnerships with knowledge hubs such as research institutes and open data organisations

·      Focus upfront on the challenges of operationalising data products by adopting a go-to-market mindset

2.     Assessing the state of the data team

Regardless of whether data and analytics is a new or a mature capability there are a clear set of questions that need to be regularly addressed:

People

·      What data and analytics skills are currently in the organisation?

·      How are skills and capabilities being identified?

·      How are people being recruited?

·      What career paths are available?

Processes

·      How is task prioritisation and job allocation handled?

·      Is the team assigned problems to solve or given a list of features to build?

·      How are objectives communicated and what results are measured?

·      Is there scope and incentives for training and skill development?

·      What workflow processes, collaboration tools and CI/CD practices are used?

·      How are ideas generated, assumptions validated and products tested with customers?

·      Who ensures data quality or ethical accountability over data or algorithms?

Relationships

·      What is the funding model?

·      What is the level of data expertise at the executive level (and greatly affects meaningful dialogue over the strategic engagement)?

·      What external relationships exist (SaaS vendors, post-graduate research programs, R&D audits)

·      What formal and informal mechanisms exist for empathising with customer or business problems?

3.     Role clarity

In broad terms, data team roles can be segmented into four groups:

Engineering: Data engineer; machine learning engineer; software/application developer;

Analytics: Data analyst, data scientist

Governance: Data steward (an accountability also commonly assigned to existing roles)

Complementary: Data lead/manager; data architect; product manager; project manager; business analyst; human-interactive designer (which greatly depends on the scope of ambition and funding)

Clarity over roles matters on three levels:

Firstly, the allocation of roles and relevant skillsets in relation to the sophistication, ambition and investment of analytical objectives demanded by the organisation.

Secondly, the alignment of responsibilities against key activities in the data value chain:

And thirdly, the emergence of new roles in response to rapid changes in data architecture, cloud infrastructure and tooling. This must also take into account that:

·      New titles and highly specialised skills will, over time, become more generalised.

·      Responsibilities are becoming less departmentalised and skills less mutually independent as DataOps practices mature, formalised learning grows, new data infrastructure ecosystems emerge. For instance, processes that use machine learning to automate the end-to-end development of machine learning pipelines (AutoML) are gaining greater adoption.

·      There are divergent approaches as to whether traditional data governance responsibilities or the emerging application and monitoring of ethical behaviours requires separate roles or simply describes a relationship to data and not a position.

4.     Making structural choices to optimise communication and complement capabilities  

Five models are presented which support the distribution of skills and responsibilities between data team members and across the rest of the organisation.

1.              Centrally pooled

Engineers and analytic specialists report to one data manager and consult to other business units. This model supports strong top-down governance, coordinated data management practices and inter-team knowledege sharing. It works best before operations scale.

2.              Distributed

Engineers are centralised under one reporting line while analysts report directly to business units. This model supports immersion in business operations and customised data transformations but places a heavier load on engineering capacity and consistent data interpretations. 

3.              Steamed

Engineers and analysts are managed as separate teams with separate data leaders. This model may suit organisations with large infrastructure initiatives and a set of clear strategic analytic priorities. It can also lead to weaker collaboration and knowledge sharing.

4.              Domains

Engineers and analysts are aligned to source-oriented domain data with data ownership placed into the hands of the business domains. This model is contingent on relinquishing centralised data ownership for distributed data architecture, global governance, open standards and domain-oriented data served as a product. This is similar to the Tribe model but with a formalised infrastructure layer to fully support domain ownership. It does, of course, require a very sophisticated engineering stack, API integration, deep domain knowledge and data-literate business units.   

KEY

LOOKING TO Leverage and utilise your data? REACH OUT.

Whiteark is not your average consulting firm, we have first-hand experience in delivering transformation programs for private equity and other organisations with a focus on people just as much as financial outcomes.

We understand that execution is the hardest part, and so we roll our sleeves up and work with you to ensure we can deliver the required outcomes for the business. Our co-founders have a combined experience of over 50 years’ working as Executives in organisations delivering outcomes for shareholders. Reach out for a no obligation conversation on how we can help you.

Article by Pete Crawford