Competing With Data & Analytics
What to Read Next
Headlines and anecdotes paint a bleak picture for organizations that need analytical talent. Demand for talent currently far exceeds the supply. It may be difficult and painful until we reach an equilibrium. In the meantime, how can organizations best take advantage of analytics with limited access to the best analytics talent?
This situation is similar in many respects to the talent shortfall that accompanied the Internet’s growth in the late 1990s. The lessons are similar, too: as the Internet exploded more than a decade ago, demand for talented web developers far exceeded supply. Compensation for skilled technical talent soared as exuberant investors poured capital into a wide range of unprofitable online companies. Many organizations were unable to attract and retain people with necessary talents. In the middle of technology booms, human resources can become bottlenecks.
Our not-too-distant past offers insights to guide organizations. Here are seven of them:
1. Remaining short-handed may be better than finding talent that’s a poor fit for your needs.
Ideally, every need is filled with the right person. However, it is better to be short-handed than take on dysfunctional team members — the kind of employees you see in sitcoms and Dilbert strips. In the dot-com boom, startups compromised on qualifications, favoring pedigree over prowess and “who you know” over “what you know.”
Even well-intentioned but unqualified staff can drain time and resources. In 1975, Fred Brooks’s Mythical Man-Month influenced a generation of project managers with its argument that adding new people imposes costs on the existing people, and may delay rather than expedite projects. The Mythical Man-Month is as true now as it was in 1975. Don’t add staff to fill a slot; be sure that adding people to your organization’s analytics team will add value quickly.
2. Don’t let fear of competition encourage a “for now” mentality.
Faced with time pressures, temptations to take shortcuts are inevitable. Hungry to gain first-mover advantage and to capitalize on network effects, many companies in the dot-com boom built digital houses of cards. Complete overhaul was then required to scale. For example, in analytics, it may be quicker to manually clean data “for now” rather than build a process — but any short-term savings quickly erode when the process becomes routine. Inevitably, shortcuts done “for now” unintentionally become “forever.” Companies who want to avoid this trap should set up the equivalent of the swear jar for using “for now” when they use a stop-gap process by insisting that any team choosing a “for now” method set aside time and resources to develop a long-term process that will achieve the same goal more sustainably and efficiently. It’s also important that this process development be done sooner rather than later — so set a due date.
3. Build processes based on real needs.
Taking shortcut avoidance to an extreme, however, may be equally devastating to scarce human resources. Intellectual curiosity or desire for challenge may tempt analysts to address unlikely hypothetical situations, to build unnecessary complexity, or to embellish with features beyond business requirements. The dot-com era led to many anti-patterns of development, such as gold plating and inner platform effect. Kim Holmes, SVP, Global Head of Strategic Analytics from the XL Group describes hiring “some really, really smart people — and they tend to get distracted by shiny objects — who are eager to do great things but at risk to lose focus on what our business really needs. We always have to remind ourselves to keep focused on the business and keep it simple. … We don’t need to build a Ferrari when a Volkswagen will do.” Instead, confine projects to business requirements so that analytical talent is applied where needed.
4. Pick your battles when it comes to managing complexity.
Web development in the dot-com era was a mess of rapidly evolving infrastructure, tools, and culture. Some of the chaos that arose was an unavoidable byproduct of newness, but a lot of it was simply that the complexity of the new infrastructure was challenging. Analytics projects as a rule are complex combinations of data management, statistics, machine learning, creativity, visualization, project management, infrastructure, and software development. That means that analytics projects will inevitably be a little messy because of their complexity — but Brooks distinguishes between accidental and essential complexity. Accidental complexity results from poorly considered decisions under managerial control; certainly, these can and should be minimized.
Much of the complexity in analytics, however, falls into the category of “essential”; the context is inherently hard and, given the current state of technology, managers may have little opportunity to reduce it. From this perspective, the dot-com era (based largely on markup, scripting, and database) seems like a far simpler time than now, when we have statistics, econometric modeling, and machine learning on top of massive unstructured storage. It may not be possible to reduce this essential complexity without reducing projects. Instead, it’s wise to pick your battles — making compromises in scope or using incremental approaches may be required to reduce essential complexity.
5. Don’t look for that one person who can do it all (you won’t find one).
In hindsight, the web development toolset seems narrow. Now, analytics requires managerial, organizational, and technical depth. Because of the breadth of roles in analytical projects, even a knave of all trades may be difficult to find. Instead, build teams with defined roles.
For example, Brooks suggested “surgical teams” to focus skills and maximize the benefits from scarce, specialized talent resources. If machine-learning skills are your organization’s bottleneck, then every minute that a staff member with those skills spends doing anything other than exercising these skills reduces that employee’s overall effectiveness. The solution, therefore, is to assign the employee to perform that task, and only that task, within the team setting, in the same way medical professionals divide up tasks during a surgery.
Furthermore, these surgical teams may include resources not currently in analytical teams. So if analytical teams are the bottleneck, time-consuming selection, preprocessing, and transformation steps can instead rely more heavily on traditional IT resources.
6. Be skeptical of silver bullets.
Faced with demand and limited supply, you may be tempted to look for the shiny silver bullets that solve all problems with one shot. It is worth keeping in mind that, of the many development frameworks, certifications, and products from the dot-com era, few remain. Vendors naturally offer easy solutions; be wary. Yes, new advances may offer nice solutions to shrink essential complexity or to reduce demands on people through technology. However, most things that seem too good to be true are too good to be true. No technology in the dot-com era transmogrified casual users into wizards capable of developing scalable, clustered, asynchronous web applications. Instead, while they purport to save time or replace people, they may just introduce a new tool chain to learn, adding to the essential complexity rather than diminishing it.
7. Make many small wins add up to big progress.
Large projects have historically had high risk. Many ambitious dot-com projects were never finished despite burning up capital and human resources — while other projects started small, grew, and continue today. Brooks advocated incremental approaches; it is also a core tenet of modern agile programming. Analytics projects should adopt this approach as a more successful method to meet long-term, large-scale goals.
Four years into her time at the XL Group, Kim Holmes attributes much of their success to continual building. She notes, “To me, it’s about having a small team, getting your governance structure going, hitting something — a couple of things — out of the park, proving the value, and then growing from there.”