Is it exploratory, meant to inform but not be decisive, or meant to provide a clear direction forward?Notice what is not on that list: telling the data science team how to arrive at the end result.
That’s because as a business representative you are an expert on each of the 3 items laid out above — you’re not an expert on data science.
It’s tempting to want to insert a component 2-and-a-half that says “analyze this using X model that I read about recently”, but these types of directions tend to be red herrings.
The data science team now needs to develop a proposal for why X is not appropriate but Y model is.
If you’re going to receive that email and say “great — thanks”, don’t bother sending them down path X to begin with.
There may be situations when as a business representative you’ve read about a fascinating practical application and suspect that it is unknown to your data science team.
In those situations it’s helpful to say “could we use Z method, linked here”, or “I just read about Z method, can you tell me how this applies to our situations”.
The goal is to allow the data science team to do what they’re good at, and avoid creating a situation where they spend extra time getting buy-off on modeling decisions that you don’t have expertise in, and didn’t care about to begin with.
It’s a small change of wording, but can help to save time and also help build rapport with your data science team.
Knowing that they’re responsible for everything involved in turning components 1 and 2 into a finished 3 promotes personal accountability and ownership.
Pitfall # 2: Not Investing In Infrastructure/EngineeringI’ve sometimes compared working in data to being a bathroom janitor: nobody notices when bathrooms are particularly clean, only when they are at varying ranges of dirty, and nobody ever sees the cleaning guy to thank him, but they’ll call him if he didn’t do his job well.
The comparison is intentionally dramatic, but organizations can fall into this type of trap with data teams: assuming that robust analytics are always on-hand, and not being particularly attentive to how the analytics get there.
In fact, a significant portion of time is spent compiling, organizing, and cleaning data.
Finding ways to reduce this “tax” on analytics is the most effective way to create a more agile [and happy] analytics environment, but it’s not always the easiest.
Working a few extra hours, making simplifying assumptions, or using work-arounds gets you the immediate result more quickly, but over time this technical debt builds up and becomes overbearing.
Ask your data scientists if they have the tools they need to do their jobs best.
It may be that a distributed computing environment would speed up their models significantly, or a large time investment into organizing a commonly-used database would yield significant dividends down the road.
Weigh this input heavily.
Be attentive to avoiding zero-sum logic in reviewing these proposals.
Your data scientists may say “if we took X months and $Y to clean up this database, we’d save Z% of time on all future projects”, which in some environments becomes a math equation to justify the ROI.
What they might add, but should certainly be part of the discussion, is that you hired smart data scientists to provide business value — dealing with messy data doesn’t further that goal, but dealing with messy data does allow your smart data scientists to spend more time providing business value.
Saving Z% of their time doesn’t mean you need Z% fewer data scientists you had before, it means they can do Z% more work.
It’s still okay to do an ROI calculation, but make sure to factor in the benefits you’ll get from a more agile data science team.
Pitfall #3: “This Is Urgent”I’ve never been able to re-find this quote, but somewhere Peter Drucker said something to the effect that “the recurrent crisis is the result of slovenliness”.
In less eloquent English — if you’re experiencing the same urgent situation repeatedly, it’s because you were too lazy to clean it up the first time it happened.
I like this framework because it maintains accountability to an end result and urgency getting there, while also enforcing accountability to an appropriate process.
It’s fine to ask your data science team to be heros every once and a while, but be attentive to what you can do to reduce this, because for whatever reason data science can often be at the losing end of urgent situations.
Some strategies to think about:Establish a cadence for recurring reports.
Your data science team may build their back-end processes differently if they know they need to update something monthly vs.
if they think it’s a one-time project.
Similarly, knowing that time every month needs to be spent on a report allows them to budget other work so that everything gets done on time.
Use the “70% Rule of Delegating”.
This means that if you are responsible for a high-level task and want to delegate a part of it (such as needing to present a product proposal that will have analyses from your data science team included), you are allowed to use 30% of the time you have to delegate the work.
So for example if you have 20 days notice ahead of the presentation, you’re allowed 20 * 30% = 6 days before you send the work to the data science team (i.
e.
they get at least 14 days to work on it).
It’s not a hard and fast rule for every situation, but this type of framework is a helpful heuristic.
Include your data science team as early as possible.
Maybe before you even know what analysis needs to be done, invite them to tag along to meetings to get the framework clear in their minds.
They’ll be able to jump into an analysis much quicker with this background, and may even be able to suggest new analyses, saving you that step.
Pitfall #4: Cogs vs.
ConsultantsData science is still a relatively new field — in due time it will become a standardized business function with clear inputs and outputs and relatively wide awareness about it’s function, but for now that organizational glue isn’t present.
Rather your data scientists have a lot of tools that your organization hasn’t seen, and you have a lot of business knowledge that the data scientists are not privy to.
Organizational glue allows for a “cog” model: hands off, one part in a chain of work, simple inputs/simple outputs.
Without that glue you need to adopt a “consultant” model: high-communication, full-scope and end-to-end process involvement, complex inputs/complex outputs.
Easy ways to maximize your data science team’s effectiveness in a consultant model:Include them throughout a process.
As mentioned above, even if you don’t know what needs to be done yet, include them in discussions so they can get an idea of the framework.
Being at the table also allows your data science team to suggest new analyses or ways they can contribute, to provide early recommendations on ways the business can structure a product rollout or A/B experiment that will be conducive to post-hoc analyses.
Ask questions, don’t give directives.
Be careful to not unwittingly constrain your final product by being overly directive in your instructions (per Pitfal #1 above).
It’s okay to say “how can we produce an analysis to prove the value of this product” — you don’t need to have developed the metrics or the reporting framework already.
If doing that work is appropriate, go ahead, but be aware that your data science team is closer to that work, and might have a better idea than you.
More is More.
You hired smart data scientists for a reason — if you can’t trust them to attend a client call with you or to tag along on a product discussion, you hired the wrong guys.
You want to be able to foster an environment where more data science involvement is only productive, not destructive.
The more present data science is, the more use you’ll get out of it.
A quick way to begin this process is to distribute their work more widely — with many types of analytics, reporting can beg more questions than it answers, so distributing the work is tantamount to asking for questions from a wider group.
Those questions can be the seeds of fruitful collaboration across your organization.
ConclusionBusinesses finding ways to use their data science teams more effectively out to take note of common pitfalls and adopt more productive behaviors.
Many of the insights shared in this article are equally applicable, in a reserve sense, to data science teams — don’t let yourselves become cogs, work hard to secure appropriate investment in infrastructure, etc.
To quote another aphorism “work smarter, not harder”.
.