How long does work take?

Screenshot of LinkedIn Poll showing that 72% of respondents think doing four hours of work over four weeks means the work takes four weeks, not four hours.

72% of respondents to my LinkedIn poll think that if I do four hours of work over four weeks, then the work takes four weeks, not four hours.

Of course, both are true. It just depends on what you mean when you say “work”. And that’s what makes talking about deadlines and estimates and the time work takes so difficult.

But, is it ever possible to talk about work, and delivery, and value without also talking about time?

What’s in my bag

As part of my goal of being even more minimalist this year, I’m going to try to live out of two 35 litre bags.

Clothing

  • Hat – Warm hat
  • Shell jacket
  • Down jacket
  • Waterproof jacket
  • Fleece jacket
  • Shirt x3
  • T-shirt x3
  • Jean x3
  • Shorts x3
  • Socks x3
  • Trainers
  • Belt

Ditch pack

  • Passport
  • Bank card
  • Driving licence
  • Cash
  • Hard drive
  • Spare car key

Wash kit

  • Tooth brush
  • Tooth paste
  • Towel
  • Flannel
  • Shower gel
  • Nail clippers
  • Deordorant
  • Moisturiser
  • Hair trimmer
  • Scissors

Tech

  • Work laptop
  • Work laptop charger
  • Surface laptop
  • Surface charger
  • Phone
  • USB to USB-C cable
  • USB-C to USB-C cable
  • Kindle
  • Backup phone
  • Wall plug
  • Battery pack
  • Wired earphones

Personal

  • Glasses x2
  • Sunglasses
  • Swiss army knife
  • Car keys
  • Window tool
  • Pen
  • Notebook
  • Headtorch

What does team capacity even mean anyway?

We pretty much agree it’s not right to refer to people as resources (or at least we should). It’s disrespectful and dehumanising. It smacks of an outdated industrial mindset where people were thought of as interchangeable cogs in the machine, easily replaced by the next person in line.

So, in avoiding that problematic term, we seem to have replaced in with the term ‘capacity’. What does that mean? Is it just a different term for the same kind of thinking or is it something different?

When we say ‘capacity’, we often mean it as short-hand for ‘who does what work when’. If we take the definition of capacity as ‘the maximum amount something can contain’, then when we say, “the team is at full capacity this month”, we mean that a group of people (who) are already doing all the work they can in the time they have available. We think of the ‘who’ and the ‘what’ as fixed (throwback from the industrial mindset) and the ‘when’ as the variable. “The team might have more capacity next month”, means we expect them to have more time next month and the work they couldn’t fit in this month will have to wait till then.

But in modern digital work all those things are variable. Not just when, but who and what too.

Who might be on the cross-functional team could change, but also what skills, knowledge, time, processes and environments the people might have could also change. These things vary depending on the work. A developer using a new language and unfamiliar systems to what they are highly-skilled in will take longer.

What the work involves also changes. Understanding the work, doing the work of figuring out how to do the work, realising the problem the team thought they were tackling turns out not to be the real problem, doing the work of coordinating the work. It all has to be done. And it all changes with each new piece of work. Even the same work changes as a team gets more practiced at doing it.

What gets in the way of the work also deserves a special mention. Teams doing one piece of work that takes four days or four pieces of work that take a day each is taking the same amount of time, but in latter the work-in-progress is much higher. That’s four times the coordination required, four times the dependencies, four times the context switching, four times the amount of knowledge people have to keep in their heads. Not having the right tools or systems necessary for the work also gets in the way.

To help us understand these variables we can think about them on a sliding scale.

  • What – the type of work ranges from delivering known, fixed, repeatable outputs… to… achieving uncertain, novel outcomes.
  • What gets in the way – the amount of work-in-progress ranges from low, where the team can focus on one piece of work at a time… to… high, where the team has lots of distracting priorities.
  • Who – the people on the team range from highly-skilled, knowledgeable, have the right processes in place, etc., for the type of work … to… learning (either because they are inexperienced and haven’t developed yet or because the type of work is uncertain and new to them), setting things up, improving practices and processes.

The more we’re on the right of the scales, the more impossible it is to estimate team capacity, and in fact, the more meaningless the term becomes. We should accept that.

When we have conversations about team capacity, it’s useful for us to be clear about why we’re having those conversations, what question are we really asking. Sometimes, when we ask, “how much capacity does the team have next month”, we’re really asking, “can the team do x work next month”. That changes it from a capacity conversation to a prioritisation conversation (which isn’t necessarily any easier, but there you go).

But where this becomes really useful is in changing the conversation from ‘capacity’ to ‘ability’, from how much can the team do, to how do we help them be more able to do different things better. How do we help team’s improve on their ability to achieve uncertain or novel outcomes, to drive down their work-in-progress limit, to learn new things, to work at a sustainable pace?

We’ve gone from harmful assumptions about resource utilisation, to understanding how the variability of digital work makes capacity a meaningless term, to talking about improving a team’s ability to do good work. This is where the impactful value is for teams, leaders and organisations, not in making sure everyone is always busy or in guessing when a piece of work will be done, but continually improving team ability.

Which dates matter

Within product teams and for leaders, which date matters tells us whether the focus is on outputs or outcomes.

If when a piece of work is available to users is the date that matters, then we’re focusing on outputs.

If when we have enough data to know if the work has achieved what we wanted is the date that matters, then we’re focusing on outcomes.

If all you have is a hammer

I’m not sure about the saying, “If all you have is a hammer, everything looks like a nail”.

Even if you only have a hammer you still recognise the difference between a nail, a screw and a bolt. You know you can use your hammer pretty effectively on nails. You know using it on screws is going to be messy but might kind of work. And you know your hammer definitely isn’t going to work on bolts.

So, only having a hammer limits the problems you choose to tackle, it doesn’t mean you tackle them all in the same way.

Maybe the saying should be, “If all you have is a hammer, go find the nails that need knocking in”.

100 days of task tracking

The background

For 100 days, starting on the 1 August, I recorded every task I did in a spreadsheet. I set up the spreadsheet to count how many tasks I completed a day, which project they were for, and which of my four objectives they contributed to. All I had to do was make a note of what I did in the right cell.

I wanted to learn what I actually spend my time on. Most task management is about forward planning, and most task management systems are really bad at showing how you’re actually performing. They can only show you the tasks you had the foresight to add ahead of doing them. And whilst humans are really bad at predicting the future, spreadsheets are pretty good at tracking the reality of completed tasks.

How many tasks

Over those 100 days, I completed 1124 tasks, which averages 11.24 tasks a day.

Graph showing the number of tasks completed over 100 days.

On my least productive day I completed 2 tasks (I was on leave that day), and on my three most productive days I completed 21 tasks. On 35 days out of the 100 I completed 10, 11 or 12 tasks, which is right around the average.

Graph showing the distribution of tasks completed per day.

Mondays and Tuesdays were my most productive days with 22% of tasks completed on each of those days. 20% of tasks were completed on Wednesdays, 19% on Thursday and 17% on Fridays.

How those tasks contributed to my objectives

I have four long-running objectives that align to the purpose of my role:

  • Objective 1 had 251 (22%) tasks. This objective is about team performance and the number of tasks increased considerably for over half of the 100, but that provides an interesting comparison with the rest of the days.
  • Objective 2 had 519 (46%) tasks. This is the most obviously role-aligned objective as it’s about managing our products, so it makes sense that it has the most tasks.
  • Objective 3 had 91 (8%) tasks. This objective is long-term and organisationally-focused, so it’s the one that drops when I’m busy with the others.
  • Objective 4 had 92 (8%) tasks. This task is operational, so although there aren’t many, there is a steady stream and they have to be done fairly promptly.

I also did 171 admin, or non-objective contributing tasks, which was 15% of the tasks completed. This feels broadly right. 15% of my tasks were finance, non-project related planning, reporting, etc. If it was 15% of my time it would three quarters of a day a week, but I don’t think it’s quite that much time.

Chart showing the number of tasks completed each most from August to December 2023.

What this system doesn’t do

There’s a lot it doesn’t do, but it is pretty good at what it does. It doesn’t:

  • track how much time is spent on a task. It doesn’t matter whether a task takes two minutes or two hours, it’s counted as one task.
  • consider whether they are the right tasks. Whether the task is urgent, important, or neither. Whether it unblocks others (possibly the highest impact type of task), or is some mundane admin task (although I hope I’m pretty good at avoiding these), it’s counted as one task.
  • differentiate between planned and unplanned tasks. But that’s a fuzzy, and probably unhelpful, distinction anyway. How planned does a task have to be to be considered planned? If you know you have to do a task but you don’t know when you’ll be doing it, is it planned or unplanned?

Whether a task is planned or unplanned doesn’t seem important. Learning whether I’m doing the right tasks, and spending the right amount of time on them, does seem useful, although I’m not sure how it would affect my decisions about what to work on.

Things I tried and failed to do

I tried to make the system work more as a planner, but it hasn’t worked yet. I tried:

  • setting monthly goals that aligned with my four objectives. I never came close to achieving them. A month is too long a time period to predict
  • setting (and am still setting) weekly goals that align with projects I’m working on. At the beginning of the week, I usually set between 3 and 5 goals and then at the end, give myself a percentage of how close I came to the goal. Across all the weeks so far, my total completion percentage is 43%. That also represents how successful I think weekly goals are. They are better than monthly goals, but they serve more as reminders of thigs to get done than as actual goals.
  • using what I completed last week to help me plan this week. I couldn’t find any helpful insight as so many other factors changed from one week to the next.

What I learned

Having the data is better than not having it. Without it, you’re just guessing at what you spend your time doing and how it contributes to goals and objectives. I’m definitely going to carry on tracking my tasks.

Recording what you actually did is far more helpful for understanding your work and how it contributes to your objectives than “planning” (AKA guessing) what you’d like to do in the future.

Medium and long term goals are better thought of as reminders rather than actual goals (especially given the point about not yet having a means of telling whether they are the right goals).

Shorter time periods are better. Planning day-by-day, I can get close to predicting what I’ll actually achieve, especially as I have historic data which tells me how many tasks I completed on similar days. Planning on a weekly basis yields less than half of the accuracy you’d expect. Monthly planning was more fantasy than fact. I can’t even imagine how planning quarterly or annually could be at all useful.


Other posts:

Digital at RNID

RNID is a digital-first charity. That means a few different things.

It means that our products and services are developed in digital ways first and only become physical when digital doesn’t work, so for example our RNID near you service which helps people fix their hearing aids. You can’t do that kind of thing online. But products like the hearing check are entirely online. This is how more than three hundred thousand people have checked their hearing and lots of those who found out they have hearing loss have gone on to get hearing aids. That kind of impact at scale would be really hard to achieve off-line.

It means we all use digital technology in our work. RNID has over two hundred different technology systems. We have more technologies than we have people. I think that shows how digital-first we are as a charity.

And it means we think and work in modern, digital ways. Ewen Stevenson, our chair of trustees, talks about how we can use technology to connect with millions of people. Digital isn’t just about websites, it’s about RNID’s entire business model for how we use digital technology to have impact at scale. If Uber can use digital to change how we travel, and Spotify to change how we listen to music, then RNID can use digital to change society for people who are deaf, have hearing loss or tinnitus.

Who we are

There are eleven of us in the Digital team at the moment. We’re made up of four specialities:

Delivery – Help the whole of RNID figure out better ways of working and how we deliver value to our communities in impactful and agile ways.

Design – Includes service design, interaction design and content design. Use collaborative, user-centred thinking, to design products and services with subject matter experts from across RNID.

IT & data – Do the complicated technical work to make sure our systems and technologies are working.

Product – Develop and manage our suite of products, including things like the website and hearing check.

What we do

Deliver technical projects, like CRM systems, and essential business systems.

Develop new products, like the Hearing Loops Map which lets people update Google Maps about where hearing loops are installed.

Improve existing services, like creating a self-serve option for people looking for information so the Contact Centre can focus on supporting people that really need their help.

Support teams all across RNID with things like analytics and digital skills.

How we do it

Matrix – We work in matrix teams. That means we bring together skills and expertise from across RNID to work on all kinds problems. The hearing check team, for example, has a programme lead with experience of behaviour change, a content designer, web developer, interaction designer and product manager. We all work together, bringing our different perspectives and skills, to make the hearing the best it can be.

User-centred – We do lots of research to figure what the people who will be using the products and services ned from them.

Sprints – We generally work in fixed time-boxes of a week, fortnight or month. This helps us focus on the work that brings the most value for our communities the soonest.

Feedback and continuous improvement – We get lots of feedback on how people are using RNID’s products and services. This includes user interviews, satisfaction surveys and usage analytics. We use all of this to make sure we’re improving the products and services in ways that matter to our communities.

How I use my task tracker to know if I’m achieving my objectives

I previous wrote about my system for tracking work and checking where I’m focusing. Like all good systems, it is constantly evolving. Most task management system expect the user to predict when they’ll do a task, but this one tracks what I actually did and gives me the data to figure out if I’m doing the right things.

Connecting daily tasks to long-standing objectives

I have four long-standing objectives, ongoing outcomes that will never be achieved but which guide what I work on. They used to seem a bit vague as I had no way of connecting them to the work I do.

I grouped all the things I work on under each of the four objectives to make it easier to count tasks for each objective. It only one that doesn’t fit is Admin tasks. These are about 10% of the things I do, which means 90% of my work contributes to my objectives.

Task tracker dashboard showing how many tasks were completed on each day between the beginning of August and 20th October.

I set-up a tab for reporting on my four objectives by number of tasks, and, more interestingly, by percentage. This is the most useful part as it helps me ask myself if I’m focusing on the right work, and whether I should do more for an objective.

Table showing percentage of tasks and number of tasks completed each month.

Finding out who I work with

As an experiment, I’m going to track how many times I interact with different people. This should show me two things; the number of different people I talk to, and how much I talk to each of them. I’m expecting to see that there are some people I spend lots of time with and others I speak to only occasionally. One of my objectives depends on spending time with more people across the organisation, so this should give me some data on how to improve on achieving that.

Monthly priorities

I used to set a few goals for each project at the start of the month, but things would change so much over those weeks that I’d almost never achieve them. Instead, I’m going to switch my monthly planning to be about priorities rather than goals, and about the four objectives rather than each of the sixteen projects. These aren’t trackable yet, but I review them at the end of each month a colour them green, amber or red for how much I actually focused on them.

Weekly goals

I always start the week by thinking about achievable goals. Just like the monthly priorities, these are trackable yet but are reviewed and colour-coded. I’m still pretty poor at choosing goals that are actually achievable but I’m going to keep doing it to see what else I can learn and how I might be able to connect them to the daily tasks.

What next?

Make it open – I could create a Google Docs version in case anyone else wants to try it.

Team sport – It occurred to me that this type of tracker could be used by a team just as easily as by one person. I doubt I’ll put it into practice but I might think a bit more about how it would work.

Wrong images on websites

Why do websites have images? They up space on pages, take time to download, and are costly to create.

The reason is, I think, because our brains process images far faster than text.

An ecommerce website selling red and blue shoes has text to tell you which is which, but they also have images. They know that we make really quick, snap decisions when we process information visually.

Images on ecommerce websites are an easy and obvious example, but images serve other purposes too. They can help set the emotional tone of the website, direct people’s attention, and provide information. But overall, all images on websites serve the same purpose; they provide mental shortcuts.

So, what might happen if we put the wrong images on a web page? Obviously wrong images, like red shoes on the blue shoes listing, might create confusion. More subtly wrong images might create harder to grasp dissonances that feel wrong in ways we can’t explain. Images of people smiling on a web page about funerals, for example.

Balancing failure

I’ve often thought that the role of the manager is to balance opposites. One of those balances I’ve been pondering recently is between ensuring the success of a project and giving people the opportunity to learn from failure.

With the benefit of experience, I can see where projects are going wrong, where teams have gaps in their thinking, where processes are creating unintended consequences. But I only have that knowledge and experience because others have let me fail and learn from it.

So, how to approach the balancing between projects succeeding in the short-term and people succeeding in the long-term?

Let’s start at the extremes.

Focusing only on the success of the project would see managers taking a more directive role, telling people what to do, and so preventing any learning that means those people can lead successful projects in the future. We don’t want that.

Focusing only on giving people learning opportunities means managers accepting lots of failure. Project success is important. It brings opportunities. If every project fails, pretty quickly new projects don’t get started, and those learning opportunities are lost. We don’t want that either.

Where’s the balance?

Maybe it’s in the practices a manager works on with the project team. Practices that create the right kind of learning environment, one that helps people identify the gaps in their knowledge in find ways to fill them, and help people deliver successful projects.

Here’s three practices managers can try:

Make the work small, and make it visible. Think of these small pieces of work as safe-to-fail experiments, so that if they do fail they have minimal impact on the overall project.

Give and help people get regular, fast feedback. This should be person-to-person feedback, but just as important is feedback from users on the work. The best feedback helps us understand if we’re achieving the outcomes we want.

Encourage everyone to share their knowledge and experience, not only within their job role but also bring perspectives from their life experiences. This helps everyone learn from each other.