Can you solve the Productivity Puzzle for Analytics teams?
Many data & analytics leaders face something of a productivity puzzle.
Often they have joined a new business or inherited a team & are unsure how to improve productivity. Individuals appear to be working hard, but progress can be slow and quality questionable.
If this is not addressed then it can become toxic to the team’s reputation in that business. People soon learn where to go to “get things done” and if that is not seen as the Data/Analytics/Insight team then they will go elsewhere.
So, I’m delighted to welcome back guest blogger Harry Powell to share his thoughts & model. Harry himself has changed role since he last blogged on an Alan Turing Institute lecture. He is now Director of Data & Analytics for Jaguar Land Rover. Having worked across businesses as different from JLR as Barclays & Betfair, he knows what he is talking about.
When I first read Harry’s model to achieve improved productivity, I liked its practical application. Akin to my own focus on Softer Skills needed by Analysts, it focusses on 6 aspects that each analyst can apply. Perhaps there is also a need for greater focus on visualisation, commerciality & working with stakeholders – but there is much to gain from looking at your team through Harry’s model.
Over to Harry to explain his thinking (see if you relate to his challenges)…
Failing to impress – how to improve productivity?
When I joined as Director of the JLR Data & Analytics team a year and a half ago, I was faced with a conundrum. We had lots of people working hard on a number of projects, but progress was slow and quality was low. Nothing ever seemed to be delivered, even as MVP and stakeholders were questioning the value that analytics could bring to their business.
At a time when we were under pressure to make a big contribution to the firm’s profits (read the papers), we were struggling to get on the scoreboard. And there were other side effects too. As velocity and quality falter, projects tend to absorb ever more people to develop features and sort bugs. All this leaves a manager like me without the resources to take on new projects and diversify risk.
We had to increase productivity.
But it wasn’t that the team wasn’t working hard. There was a steady stream of activity, with tickets moving steadily across the Kanban board into the Done column. An energised young team pushing hard to deliver on time (albeit always failing). And it wasn’t that the work was slapdash.
Although they didn’t have a proper version control system or automated testing framework, they took pride in what they were doing and did their best to make sure that the output was as good as possible. Just somehow the stakeholders always seemed to find errors that the team had missed.
How are your Velocity & Quality?
On closer inspection, velocity and quality seemed to be the symptoms of an underlying malaise.
Progress was slow because the teams were pursuing multiple paths and kept changing which path took priority. Features were being added faster than they could be implemented. Individual workstreams moved at pace, but the overall goal never came much closer.
The quality issues seemed to be driven by a divergence of expectations between the team members on what the stakeholder really wanted and needed. By the difficulty in eliminating errors in a continually changing codebase.
Because I was new I had the luxury of being able to take time to talk to the teams and get to know them. I was struck by the lack of clarity over what each thought they were doing, and how they were contributing to the overall goal. Few of them could give a 30-second user-story for either. And those that could often contradic others working on the same project.
Now partly this was caused by an unfortunate feature of our organisational design, where generalist colleagues from a different function were able to micromanage the analytical work, but with little understanding of how their behaviour and changing requirements would affect the overall implementation. But there was also a fault on our side. We needed to get clarity on what we were doing and how the team was thinking about their project. If we could do this we would be well on our way to solving the productivity puzzle.
The critical need for Clarity
Clarity drives velocity because the whole team is able to work to a common goal. When faced with challenges they can compare options to a set of clear agreed criteria to determine a new direction. Without clarity, any agreement on the direction is meaningless, because each party may be agreeing to a different thing.
And clarity drives quality because not only do both the stakeholders and the team have a shared expectation of what can be delivered, but there will be fewer opportunities for undetected errors to creep in as scope evolves in the closing stages of the project.
But clarity (having shared unambiguous user stories for your project at all levels of detail) can seem an abstract far-off goal. How do you achieve it? What practical steps can you give your team to do to get there?
Well, eventually we put in place a process which addresses the issue of clarity amongst other things. I’ll write about that in a later post. But I needed something we could put in place quickly and this is what we came up with.
Velocity and Quality are driven by Clarity. Clarity is in turn driven by Simplicity, Challenge and Ownership. To represent that relationship I cam up with the “Productivity DAG” (see below).
The power of Simplicity
Simplicity – keep everything as simple as possible. This is actually quite hard. People talk about a minimum viable product or “the Pareto” but it’s always tempting to add in a twist of complexity. After all, how much can one extra tweak really hurt? A lot, in my experience.
Be ruthlessly simple, not just in what you are trying to build but in how you behave, how you plan, how you measure etc. Do as little as possible to achieve your aim. When things are simple, they may not always be intuitive but they will at least be easy to describe and to explain. They are necessarily clear.
Your need for Challenge
The process to get to simplicity is through relentless challenging. It is hard to hold yourself to account so the team needs to get used to challenging each other. Is the goal clear? Is the ticket simple enough? Is the new feature being proposed really needed?
Challenge needs to be respectful, and itself needs to be simple and focused on the goal (long indulgent philosophical discussions may be challenging, but they are inconsistent with the first law). Challenge might look like it slows things down, and impatient old-school managers may hate it, but it is well worth the investment.
Who is taking Ownership?
Delivery of a project is a collective endeavour for which everyone must take responsibility jointly. At planning meetings (or Agile Standups) everyone present should be thinking about each ticket and challenging if it isn’t simple and clear enough. If you aren’t satisfied by a response to the challenge, keep going, irrespective of hierarchy.
Once you are satisfied that you now are clear on what is to be done, write it down so that you don’t have to go through the same process again. This is an inherently non-hierarchical thing, and it took time for the more junior team members to feel comfortable with it. But it is essential. If the team is to pull together it must be genuinely going in the same direction
Putting it all into practice
Once you have these things, then anyone in your team can express what you are trying to do with clarity. So, you are more likely to get there quickly and with high quality.
What was the result? Well, we had one project that had been occupying half of the team (20 people!) for 9 months and still hadn’t delivered. The problem had been inconsistent micromanagement that had magnified complexity and driven out challenge and ownership from the analytical team. By introducing the Productivity DAG (and using my new position to break the habits of micromanagement) we managed to reduce the size of the team to 6 and then 3 people while delivering results that the stakeholders needed and generating £20 million in incremental profit.
Reading this back, I guess it’s not rocket science, but we have found the Productivity DAG a practical way of thinking about velocity and quality. It doesn’t replace working hard and checking your work, but without it you’ll never work hard enough or check enough.
How is your struggle with the Productivity Puzzle?
Many thanks to Harry for sharing his model & more importantly
What has worked for you? Have you used something akin to Harry’s Productivity DAG, or a totally different approach? I know Harry is keen to receive feedback (and of course challenge), so please do comment below.
I’d love to hear from anyone else who has a model or practical tips for improving productivity & getting what matters most delivered.