Considerations

Project Attrition

Don't encourage turnover

Once an organization puts a data team in place, leadership should do their best to prevent staff attrition. One starting point: the “Russian Winter” of boring projects that push staff through an inhospitable wasteland of tedious tasks.

Leaders should assess the amount of specialization needed for each business unit with an embedded data team. If the level of domain specialization isn’t prohibitively high, or if much of it is transferable to other business units, leaders should consider rotating data team members across different business units and possibly back into the central data team. Rotations break up monotony and keep data teams engaged.^xxxii

Figure 14 Speaking of data science, Edward Tufte, a giant in the world of quantitative visualizations, once said, "It may well be the best statistical graphic ever drawn," referring to this 1869 visualization of Napoleon's disastrous Russian Campaign by Charles Minard.^xxxiii

Enterprises must also prioritize the availability of data. At large organizations, providing access to data can take months. Management should plan for this before hiring the first engineer and make sure their team has access on day one. In fact, most new data teams will benefit from having a data engineer as the first hire to set up data pipelines—otherwise, the rest of the data team will wait idly for access, or frustrated data scientists will engineer subpar data pipelines. Poor planning here can cause attrition via boredom and frustration.^xxxiv

When the team is in place, executives should choose the correct first projects. If the issue lacks relevance to the business, the resulting data project will likely die on the vine, and that could create frustration in the data team. Similarly, if leadership assigns the data team a technically unfeasible task, the team may get discouraged. Ill-conceived strategies, poor governance, or vanity projects can cause staff to resign before the team has a chance to get off the ground.^xxxv

Internal vs. External Talent

The right candidates are hard to find and hard to train

When most large companies decide to build a data team, they will typically have small data, data analysis, and business intelligence (BI) teams in place. Pragmatic executives may think they can save time and reduce search costs by using existing staff for the initial data team. Cutting corners here often fails due to the chasm between small and big data skills.

Yes, data analysis and BI team members work with data and have the math and statistics skills. But many will lack critical skills needed for the data science team. Most people in these roles have no programming experience, need to be taught how to develop and deploy machine learning models, and typically need more advanced training in math and statistics than what they use for analytics and BI work.^xxxvi

Hiring data engineers from internal IT staff may work better, although existing data warehouse teams and database administrators rarely fit the bill. These teams work with small data and the domain language SQL, whereas programming distributed systems requires a much more complex skill set. Internal software engineers are more likely to have the ability to learn distributed systems, although the company should look for engineers with a particular interest in distributed systems. If hiring internally, the first hire should still be a veteran data engineer from the outside to get the data team off to a critical strong start.^xxxvii

Organizations will have an easier time staffing operations teams by hiring internally and externally. If hiring internally, leadership should provide the resources and time necessary to learn the differences of operations on this area. Talented candidates for operations teams often work in existing small data operations and DevOps teams.^xxxviii