Imagine you’ve just stepped into a meeting room with your CEO, and she drops a bomb on you: she says your team isn’t fast enough, progress is way too slow, and frankly she’s unimpressed.

You can feel your heart rate increasing. It feels like an attack. Doesn’t she see how hard your team works? David and Emily always work late into the evenings, and Nikita was a superhero during the last sprint.

So what should you do in a situation like this?

First of all...

Perhaps the first thing to do is breathe. Almost anyone faced with this complaint is going to feel defensive. Resist the temptation to deny the problem or shift the blame. Ask questions to understand where the complaint is coming from, and listen to the answers.

When emotional, you might find it hard to listen to the answers without interrupting, or to remember the nuance of what’s being said - if so, write notes, and arrange a follow-up meeting to discuss further. These questions, for example, might help you shape your response:

• What makes you say that things feel slow?
• Are some areas particularly slow? Is this affecting certain teams? (Implicitly here it may be useful to know if particular people are complaining). Can you give some examples of when things have been (or still are) slow?
• How big a problem is this for the organisation? What would it feel like to you if things were fast?
• Are there resources available to potentially boost things along? e.g. could we hire, or spend more money, or divert people from other tasks?

It’s very hard to qualitatively and fairly measure or compare the speed of a team, and so we must recognise that this concern about speed is, at least in part, a problem of perception. Depending on the organisation, there may be politics or other context involved.

If you have a good relationship with your CEO, this is just one of many problems you’ll tackle together, so stay calm and collaborative. If you don’t have a good relationship with your CEO, then you need to understand how serious a warning you’re receiving, and use this as a chance to improve the relationship.

For more on how to manage your emotional reaction and the relationship, I'll be writing future posts entitled:

• Be Bulletproof
• ‘People fire doctors with a bad bedside manner’

For this article, we’ll focus on actions rather than the human relationships, while recognising that the human relationships may be the larger piece of the puzzle.

How to diagnose the root causes of “slow progress”

It’s easy to assume that “slow progress” is a problem of throughput - that you team simply aren’t getting enough done. But listen carefully to the answers when you ask your CEO, “Can you give some examples of when things have been (or still are) slow?” and "What would it feel like to you if things were fast?”. If you see responses like the following:

1. It feels like we’ve been working on Project X forever - it’s been sitting on the Trello board since last quarter!
2. Whenever I want to try out a new idea, even a small one, I get told that all the sprints for the next month are full. And the Customer Service team say that even important new bugs won’t get addressed until the next sprint if they weren’t part of the planning for this sprint.
3. I was told we’d be finished with Project Y two months ago, but it’s still not live.

These are legitimate complaints, but they’re not specifically a problem of throughput. Of course, if you could double throughput (i.e., if your team could work twice as fast), then that would probably help in a lot of ways. I’ll write about ways to increase throughput in a future article, but it probably won’t be easy to do. And more importantly, if you’ve misdiagnosed the problem then increasing throughput may not help as much as you think it will.

So let’s consider each of the responses in turn.

1.“It feels like we’ve been working on Project X forever - it’s been sitting on the Trello board since last quarter!”

There could be lots of reasons why Project X has been on the Trello board since last quarter. Maybe we decided to do other stuff instead. Or maybe we’ve been working on it steadily all this time in the background. Or maybe it keeps getting blocked by an external dependency, halting progress each time.

So you may be tempted to think that this isn’t a problem. Project X has been squatting like a toad on your Trello board all that time, but for good reasons!

Well, I’ve got good news and bad news for you. The bad news is that this is indeed a problem, not of throughput but of latency, and you have to fix it. The good news is that it’s a tractable one, and that everyone will appreciate it when you address it.

How to measure and improve your team’s latency

Unlike most progress in an engineering team, you can and should measure latency. How long does it take from the moment a ticket surfaces on the team’s ‘Todo’ list until it lands in ‘Done’? (And by ‘Todo’, I’m not talking about the ‘Someday Maybe Backlog’, but the ‘Committed To This And Soon’ todo list.)

You can measure the average time, but as with all latency measurements, you may find it most useful to pay attention to the worst-case offenders.

You improve (and optimise) only what you measure. As soon as you have a latency metric for your engineering organisation and talk about the importance of reducing it, your team will quickly come up with ideas and discussions about how to do that. You’ll be faced with questions such as:

• We keep choosing to de-prioritise Project X in favour of other stuff. Is that a sign that we should officially drop it from the Todo list?
• We’re juggling multiple things at once. How can we ensure we do fewer things at any given time? Will we finish them faster if we do? Will that hurt our overall throughput?
• We can reduce our latency by breaking bigger projects into smaller pieces and pushing each of those smaller pieces through faster. Is that cheating?

Some of those questions have to be answered case-by-case, or differently for each organisation. But for the most part, the beauty of this metric is that even when you try and game it, it tends to produce behaviours that you actually want. It will create pressure to work on fewer things at once; to break things into smaller pieces; to push things all the way through to deployment, rather than letting them languish in code review; to drop anything that isn’t an active priority; to reorder/minimise dependencies; and it may ultimately nudge towards a more meaningful agile approach.

Indeed, this insight about latency is the fundamental motivation behind ‘kanban’ and its emphasis on ‘work in progress’.

Now let’s look at the second potential response from our CEO.

2. “Whenever I want to try out a new idea, even a small one, I get told that all the sprints for the next month are full. And the Customer Service team say that even important new bugs won’t get addressed until the next sprint if they weren’t part of the planning for this sprint.”

Fundamentally, this is a complaint about flexibility.

As technicians (e.g., engineers and data scientists) we prefer to know what we’re going to be working on in advance, and don’t like being yanked around by ever-changing priorities. And indeed, it can be more efficient (i.e., higher throughput) to be able to decide in advance, minimise switch-costs, and stick to a pre-agreed plan.

For this reason, sometimes it’s our job as the leader of the engineering team to be a buffer against the vagaries of the outside world and the rest of the company.

But we have to balance that against the danger that we might be increasing throughput but on the wrong things - in this case, at the expense of flexibility.

How to strike that balance, how to know when to be flexible and when to stick to the plan, requires the wisdom of Solomon. But the first step towards good decisions is realising that this balance needs to be struck. And that this balance, in itself, is a sort of parameter that will need constant adjusting and fine-tuning.

3. “I was told we’d be finished with Project Y two months ago, but it’s still not live.”

This may seem like another complaint about latency. And indeed, it’s related - paying attention to latency and improving it would help here too. And it’s probably also a failure of communication - keeping stakeholders up-to-date on the status and reasons for delays will help a good deal.

But that’s not primarily what this is about. This is about predictability and reliability, about making good estimates for how long things will take and delivering on them. If things don’t finish when you say they will, it can cost you business, planning becomes much harder, the delays can cascade to other dependent projects and teams, it’s bad for morale, and it looks bad for you.

As with latency, the bad news is that predictability is indeed a problem you have to fix, but the good news is that it’s tractable and everyone will appreciate it when you do.

To sum it up:

• Concerns about your team’s speed may not really be about speed at all; asking meaningful questions will help you uncover the real problems behind why progress feels slow.
• Measuring and improving latency; striking a balance between planning and flexibility; becoming better at estimating and delivering reliably; and improving communication with stakeholders are all excellent starting points to improving progress and delivering more.