Make sure you don’t drown your Unicorn as you grow
Building on Harry’s previous post that helped leaders value their data & analytics teams, is this advice to not drown your Unicorn.
Guest blogger, Harry Powell, is Director of Data & Analytics for Jaguar Land Rover. As well as having decades of experience in data leadership roles, Harry has shared with us before. Topics include solving the productivity puzzle & not disappointing your stakeholders.
In this post, Harry tackles the age-old problem of a great start by a data or analytics team not being sustained. Greater demand leading to the team being swamped & thus less productive. What can leaders do to avoid this fate? Over to Harry to share his experience…
The familiar story of team productivity decline
Here’s a story that those of you who have built data science or analytics teams will probably recognize.
“The team started with lots of energy, with a whirlwind of projects delivering value, recognition, and excitement across your organization. Your boss rewards you with more people, more ambition. But somehow the pace begins to drop. You can’t quite put your finger on it, but it becomes hard to get things done, even though you have more resource. You up the workload to keep the momentum, but that saps the spirit, and then you start to notice that your attrition rate is creeping up. Your boss wonders if there is a future for data science now that, obviously, all the low hanging fruit have been exploited.”
What’s going on? And what do you need to do about it?
Diagnosing the problem & finding a solution
Well everyone’s situation is different. But here are some pictures that we used to think about the problem and to find a way forward.
Figure 1 represents the allocation of resources when a team is newly formed. You set to work building data applications to address the key problems in your business. To do this you have to get and clean some data and develop some analytical technology. But it doesn’t take much time to get some results. Quite quickly you build a portfolio of applications and can show how much value they are going to add. This is represented by the yellow area. Your manager is pleased and encourages you to find more value. That’s what you do.
How you drown your unicorn in the process of growing
Figure 2 shows what happens next. The next set of projects are in new areas of the business and need the same amount of data and tech development.
You find that it is harder to deploy your applications in the business than you expected. They need to be run and used by someone, and you will need to persuade those users that that someone should be them, not you. But initially you may have decided to deploy your team to the front line to show them what a great opportunity this is. And it doesn’t take long for the users to get quite used to this free help. Even once they can see the value and decide to take on the application, your users will need to be trained in new technology and perhaps even need some help to start to thinking differently about their job. All this is very time consuming.
On the technical side, your new product will need ongoing work, not just to develop functionality, but the basics of updating data, monitoring runs, responding to changes in the environment, etc. The technical debt that would need to be addressed to fully automate and industrialise what you have built is only partly done because of the need to do new projects and show that data analytics can scale.
But you can’t scale.
It’s like the room filling up with water. Every time you build something, you have less resource to do something new. The yellow area shrinks.
The missing 3 investments to prevent drowning
The problem is that you have missed 3 key investments in your rush to show value:
- Reuse new data & technology
- Build capability you can rely on next time
- Put in place a BAU function, not just automation
You have put in big effort to develop new data and technology. You need to reuse them.
You have also worked hard to build relationships and business knowledge. You need to leave behind capability that you can rely on next time.
You are spending time turning the handle to keep it going. You need not just to automate, but put in place a business-as-usual function with a service level agreement that can run your models.
Figure 3 shows the result of this. If you do it right, you can get your team to better than linearly scalable, so that the more projects you have done in the past, the more projects you can do in the future.
How we saved the unicorn from drowning at JLR (process front)
So what did my team at JLR do, practically speaking, to address this?
When you finish a project, make sure you keep back some time to close the loop with your data; turn it from a dataset to a data asset that can be reused in future work. This will take some effort too. You’ll need to write documentation, build robust pipelines, create metadata, write tests, and maybe add a few fields while you are at it.
Ideally, you’d also sort out access so that others in your organization can benefit too. You’ll need to show your boss that this is a good investment of time, so it’s worth having a roadmap that anticipates how you are going to use this data asset in the future, and how it can grow over time into a comprehensive data platform.
Saving the technology front too
Similarly, on the technology front, we make sure that once we have implemented a project we refactor code and generalize it where appropriate so that it can be committed into a library of reusable functions. It is easy to go over the top with this and you need to be careful.
Technology is not your product, so not everything needs to be refactored. But it’s worth doing if you can, and don’t forget to do a few lunch-and-learn meetings to share your learnings with colleagues.
Saving the change (project) front too
On the change front it’s no so much a case of closing the loop as doing it right from the start. You need your stakeholders to own the product you have built, to be a proactive participant in implementation and ongoing use. They must not be dependent on your team for everything. This will require them to learn more than they may originally want to, and maybe install some analytical capability themselves.
Have the conversation early on. They need to be able to plan. The advantage is that next time, implementation will be an order of magnitude easier, quicker, and more effective. We actually have a formal “hub and spoke” federated model of analytics, and the stated aim of our engagements is that over time we want to help business functions build their own analytics capability to take over where we left off.
Your data scientists don’t want to spend their time turning the handle on legacy projects. Moreover, they probably won’t be that good at it, especially if there isn’t a proper setup within which to operate. We have built a Business as Usual team, specifically to do the industrialization of products and data assets, and their ongoing maintenance and monitoring. It turns out that this is quite a specialist area, and by creating a specialist team you get considerable productivity gains.
The benefits that come from not drowning your unicorn
All of this has meant that we can take on more work than ever before, and drive more value through the organization, sustainably. Next year looks like it will be our most profitable yet.
There’s an old riddle:
Question: Imagine you’re in a room that is filling with water. There are no windows or doors. How do you get out?
Answer: Stop imagining.
Anon
Thanks to Harry for sharing more of his practical advice in this series. Have you faced similar challenges as a data or analytics leader? Have you found the same solutions or different fixes that work? Please share your wisdom too, in the comment boxes below.