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.
A couple of weeks ago I became fascinated by personal websites that have “Hi, I’m…” on the home page, but I wasn’t sure why. There’s something different about a website that speaks in the first person.
Having thought about it some more, I think it’s about how we anthropomorphise technology and how it intermediates relationships between people, especially those we don’t know.
We say, “Hey, Alexa” to speak to voice assistants as if there is a person listening and waiting for us.
Phones mediate how we talk to each other.
And, a website that speaks in the first person creates a different kind of connection between people.
We observe the world around us, the situations we find ourselves and our users in. We look at the market our organisation operates in, and at the others who operate there too. And societal and cultural trends too.
But we don’t observe passively. We observe with curiosity and intent. We are looking for unexplored opportunities, for unsolved problems.
Then we research.
We want to understand our observations. We need to understand our environment and how others understand it. We want to know what effects the things we observed, what makes them how they are.
Which leads us to hypotheses.
How could we change what we see? Where could we intervene in the system? What if we changed that user’s behaviour. If we do this, we think that will happen.
Next, we experiment.
We test those hypotheses in the real world. We try out ways of helping people to do things differently, or do different things. We make changes to systems and we measure the consequences.
And then we analyse.
We look for patterns. We see the cause and effect. We connect and correlate this thing with that thing.
Which leads us to conclusions.
Now we know. We know with varying degrees of validity, and never with absolute certainty, but we know more than we did before. Now we have something else to observe.
Sometimes, it’s easier to focus on introducing a new method for product teams in an attempt to change more fundamental things about how the team or organisation works. But any method or technique can only succeed if it has the right environment.
OKR’s is one popular method for setting goals. Looked at in isolation, it offers a great technique for communicating what you want to accomplish (the objective) and how you’ll know whether you’re getting closer (the key results).
But what might it look like if we mapped some of the behaviours that might happen outside of the OKR framework.
Key:
Orange = The easy bit.
Blue = The really hard bits surrounding the easy bit.
Setting OKR’s is the easy bit in the middle. Sure, it takes some time and some discussion, but there’s plenty to read that helps guide teams towards doing OKR’s well.
Then what happens?
If work that doesn’t contribute to the KR’s is explicitly prioritised or implicitly incentivised, then that work is done ahead of work that does contribute. This leads to reporting that the KR’s haven’t changed, and often without calling out that the reason was because other work came first. This can lead to setting new OKR’s (because the old one’s must have been wrong), continuing to do work that doesn’t contribute to the KR’s (creating a self-reinforcing loop), or no one takes any notice because the KR’s didn’t matter anyway.
If the work that can contribute to the KR is done, then one of two things can follow, either the change is reported or it isn’t. If the change isn’t reported, either no one will notice (which signals that no one cares about the OKR’s) or someone will notice and ask for the report. If the report shows no change, this can lead to prioritising work that doesn’t contribute to the KR’s and setting new OKR’s.
Of course, there are an infinity of variations in how these things can play out in real life.
I’m not picking on OKR’s specifically, that’s just for illustrative purposes. I want to show why introducing a new method or technique fails. If the environment isn’t also changed to create the conditions for success, in this example, tackling prioritisation and incentives, the culture around measurement, and the attention of leaders, new methods don’t stand a chance.
System maps can also help us design the consequences too. What should happen if non-contributing work happens? Or if change isn’t reported? Who does something about it? Consequences are the checks and balances that help keep the whole system optimised. Without them, or at least without intentional consequences, parts of the system will tend towards local optimisation.
So, if you want to improve prioritisation, incentives, measurement and leadership, don’t start by introducing a new method.
I used to start the day with a short planning session to pull together a list of the things I wanted to do that day. Sometimes I’d get everything done, most times I wouldn’t. New things would pop up, older things would be become irrelevant. But the problem wasn’t whether or not I got stuff done, it was that I had no feedback loop to tell me whether I was doing the right things. So I redesigned my entire approach.
We humans are pretty terrible at predicting the future and estimating how long a task will take, so this approach focuses on recording what I actually did and then trying to correlate it back to whether I’m achieving what I want to. From this I can learn how to set better goals and make sure I do the work to achieve them.
This is how it works.
Three questions
The whole point of this system is to answer three questions:
Did I work on the right things?
Did I do the right amount of work on those things?
Is the work I’m doing taking me towards my goal?
I try to answer those questions over three different timescales; daily, weekly and monthly. I hope this gives a more balanced view of the answers to those questions and doesn’t favour one over another.
Monthly
At the start of the month, I write a goal for each of the projects I’m working on.
At the end of the month, I review whether I achieved the goals or not and colour code them to make it easy to tell. I use green for completed, orange for progressed, and red for didn’t achieve.
This is the longest of the loops for the biggest goals. It’s the hardest to connect with the daily work.
Weekly
At the start of a week, I write a short description of what I want to do over the week for each project. In fact, I started with doing this for five projects, partly because I know they are moving quickly and I have clearer idea about their direction, and partly to start small.
At the end of the week, I review whether I achieved what I set out to or not and colour-code in the same way as the monthly goals.
This is the middle-sized loop. It’s easy to see whether the work done this week has achieved the weekly goal. I use this to help me write the right goals next week.
Daily
Each morning I check my tasks list and yesterday’s done list for things I should do today. Some are things that have to be done, other’s are more flexible and I’ll get to them if I get time. This gives me a bit of short-term guidance and helps me not miss things.
Throughout the day, I make a note of each thing I work on for each project. Sometimes it’s a small thing like a quick chat, sometimes it’s a meeting, sometimes it’s a bigger thing like spending a few hours writing a document.
A formula in my spreadsheet counts these and displays them on a heatmap of tasks done for each project each day.
At the end of the day I do a quick check on which projects I worked on, how many things I did, and how it compares to the average. This is the shortest feedback loop and helps me answer my three questions.
What have I learned
I’ve been doing this for a month, or 22 working days.
I averaged 8 and a half tasks a day. 17 on my busiest day and 3 on my least busy days.
It’s easy to see which projects haven’t had much done on them – they are the long lines of red and low total. You can also see where there have been spikes of activity on a project with a few things getting done in one day. This helps me understand whether I’m focusing my efforts on the right things.
Some projects show constant activity and others a weekly pulse of activity. This helps me understand how different projects require focus at different times.
There’s also a weekly pattern of Monday’s being busiest and tapering off over the week. This helps me think about when to do certain types of work – Monday’s for syncing type work, Friday’s for deep work.
Did I work on the right things?
I would say yes, I am working on the right things. The average number of tasks per project is 13.8 and the 50% of projects that are above that are the ones that are higher priority (each for different reasons, but higher priority still) than the bottom half. This seems like a good, although pretty blunt, measure to show.
Did I do the right amount of work on those things?
Thinking about what the table tells me about whether I spent the right amount of time on the right projects, I’d say that it broadly does but only because I have additional knowledge about the projects such as which are higher priority, which have dependencies, and which I could become a blocker on. Maybe I should think about including that contextual information.
Is the work I’m doing taking me towards my goal?
Over the past two weeks I completed 1 thing, progressed 7 things, and didn’t complete 3 things. Given that I only managed a 10% success rate in the last fortnight, I’d say there isn’t a strong connection between the tasks I’m doing each day and the goals I set at the beginning of the week.
This goes back to the point above about not being very good at predicting the future, not having enough time for five projects (let alone 15). There’s also an important point about some projects being more dependent on other people who are also busy on other things, and doing work that unblocks them but doesn’t achieve my goals.
Lots more thinking required to properly connect the daily work to the bigger goals.
How I might improve it in the future
Measuring average tasks per project
Using the average number of tasks across all projects as the middle benchmark and then ranking projects by how far above or below average they are might give a quick way of seeing if the number of tasks correlates with the priority of the project.
Controlling WIP
I started and ended the month with the same projects, so nothing new was added. That is a bit of a WIP control, even if the overall number is too high. That some projects don’t get much done but stay on the list shows that there are too many projects to make meaningful, regular progress.
Maybe the table needs a way to differentiate between projects that are in progress but not having any work done and projects that are complete, as at the moment they both show as red.
Recording time
I’ve decided not to do this so far because I think it’ll drive the wrong behaviour. It’ll make the work more quantifiable and that’s too easy to mistake for value. Sometimes a couple of chat messages that take three minutes is more valuable than three hours spent analysing data. So, if I do start tracking my time I’ll have to think carefully about the right way to do it.
There’s no shortage of frameworks and processes, models and methods in product management. And they are all good thinking tools, conversation starters, and learning opportunities for teams to develop their practices. But as teams develop those practices it’s good for them to hold onto the lessons they learned from using the frameworks but be freed from following a fixed process.
Good products teams learn to play jazz.
They don’t need orchestration. They don’t have a central controlling role. No one leads the team or assigns the work. The team does this themselves. They decide together.
They don’t need a plan. They have the confidence to develop the next step based on what they doing together now. They bounce off each other, develop new ideas, try things, drop things that fail, get out of sync and back in sync. They adapt their work as things change.
They don’t work in isolation. They understand each other’s skills and perspective, share what they’re working on and change it as others change what they’re doing. Their ability to actively respond to each, to adapt, comes from a mutual respect and encouraging interplay. They jam together.
They don’t ever stop practicing. They are constantly learning, improving their skills and their understanding of each other’s skills. They revisit foundational knowledge and introduce new opportunities to learn. They turn to guiding principles rather than strict rules. Their knowledge becomes intuition.
It’s this ability to improv that shows the maturity of a team better than any output metric. Because the ability to improv only evolves with psychological safety, team cohesion, and all the other things that are necessary for good teams, it is the best indicator of a mature and successful product team.
Why is the Give Blood app so bad? I don’t know, but here are some improvements I’d make.
Home
Make the phone number a tel link so I can call with a click.
Home
Is this the most important information I need to see every time I open the app? Don’t think so. Move it to the About you section.
Earliest donation date should be replaced with a ‘You can donate now’ message.
Home
What’s the primary call to action here? It should be to ‘Book an appointment’ but ‘See why you’re a First Responder’ is more prominent. And I read it, so why do I need to see it on the home screen every time I log in?
Appointments
Hide the ‘Your upcoming appointments’ if I don’t have any upcoming appointments. It’s a distraction from getting me to book an appointment.
Find a donation venue near you
Minor detail I know, but the search box and button should be the same height.
Donation venues filtering
Venues can be filtered by dates but even when ordered by nearest there is no way to change the default distance for the search (which seems to be 10 miles).
Location map
Every venue has a ‘View on a map’ link which opens Google maps in a browser and uses the coordinates to find the place. This is where the link from the venue ‘Aylesbury Methodist Church’ goes, to Elsinore House. That’s confusing.
Choose a date range
Another example of how text behaves badly when the device text size is zoomed.
No dates available
Even though a venue is shown in the search results, when going to pick pick an appointment time it shows as having no dates available. Don’t show it in the search results.
Viewing appointments
This screen introduces a new user interaction – the plus/minus reveal that doesn’t look like something to interact with. All the other screens with blue text links open another screen, this is the only one that expands on the same screen, so it’s a bit inconsistent.
Date range and number of venues
With the dates set from 29 August 2023 to 1 December 2023 there are 19 venues with appointments, but…
Date range and number of venues
… if I expand the date to 31 August 2024, there are only 7 venues with available appointments. How can there be fewer venues with appointments for a shorter time period?
Your donation history
Always test how text behaves when the device has font size zoom set high.
Your donation history
And always allow your text to line break.
Previous attendance
No previous donations are shown, which is fine but hide the heading.
Stop work on the thing that is dependent until the dependency is removed. Deliver no value during this time. Learn nothing during this time. Start the work again when the dependency is removed.
This way is efficient as it only does work that will be kept, nothing gets thrown away.
The effective way
Separate the work from thing it is dependent on. Do the work in another way. Deliver value sooner. Learn more. Redo the work when the dependency is removed.
This way is effective as it enables users to get value and the team to learn.
