Product managers should champion user needs within the team and within the organisation. They aren’t the only ones, of course, everyone should, but product managers can bring together multiple perspectives on meeting user needs because they don’t represent a specialist discipline.
User needs can be general and specific. So, whilst the specific user needs might be for a user researcher to discover and champion, it’s for a product manager to champion the general user needs. These are the kinds of things user’s need but a user researcher wouldn’t find out; things like making a product accessibility, making it work on various devices, how secure their account should be, etc., etc. In old money, they used to call these Non Functional Requirements, but for modern, user-centred product teams that term is too loaded with tech-first organisational needs, so better that we remind ourselves that it’s our users that need these things by calling them user needs.
Because product managers often think at scale, these general user needs have to be expressed in more generalisable terms. This is where standards, concepts and theories such as cognitive load theory, WCAG, COM-B behaviour change model, OWASP top ten, etc., become an important part of meeting those general user needs.
Championing these general user needs means working with the team to internalise them to the point where they are a given. When the team designs and builds accessibility, security, etc., in from the start, then they are meeting those general user needs. Then they are being user-centred. Then the product manager knows they’ve done the job of championing user needs.
George Stephenson pioneered a standard gauge of 4 feet 8.5 inches for railways with the Liverpool & Manchester line in 1829. In 1845, the Royal Commissioner recommended the standard gauge, and in 1846, the British Parliament passed a bill requiring all railroads to use standard rails in the future. Before that, railway lines had many different widths, but as the standard was exported from Britain to Europe and the United States it allowed railways to work as interconnected networks rather than individual lines.
Standardising the track gauge made train cars interchangeable and made railways interoperable. This brought commercial benefit to railway manufacturers and convenience to passengers. It’s why you can get a single train from St Pancras to Marseille or travel by train from New York City to San Francisco, if you’re into that sort of thing.
Although railways standardised track gauge, they didn’t standardise engine design. Between the 1820’s and WWII, steam engines increased rapidly in size and power. Being able to innovate led to experiments with stronger materials and new technologies, better cylinder design allowed for more efficient fuel usage and improvements in lubrication which increased running time. Without innovation and improvement, it might never have become viable for trains to travel such long distances to realise the benefits of interoperability.
So here’s the lesson: standardise where interoperability is required, otherwise optimise for innovation.
We should apply that same lesson to product management and beware of standardising the role in ways that prevents innovation. Product management is a highly contextual role and the demands organisations are placing on it are changing too quickly for it to become standardised.
However, organisations, sometimes unthinkingly, default to standardising things on the assumption that it makes them more efficient. If everyone works in the same way and uses the same tools, the assumption goes, then their outputs will be the same, which is more efficient. This might have been true when manufacturing steam trains, but it isn’t when tackling complex problems. As product manager KP Frahm, once told me, “Get effective first, then efficient. If you get efficient first, you’ll never get to be effective.”
This is the problem with product management capability frameworks, role-based skill descriptions, and standardised levels for what is expected of product managers; for organisations wanting to improve their product function – they seem like a good idea. They seek to standardise the knowledge and skills expected of product managers, which seems like it should improve the quality of product management. But those frameworks are built on the idea of interoperable product managers that can fit into a product team in exactly the same way as the product manager leaving the team, and carry on working in the same way with minimal disruption. Interoperability is great for physical systems like railway tracks and for digital systems like railway timetables. Without the ISO 8601 international standard allowing any computer anywhere in the world to exchange date and time-related data with any other computer, you’d probably miss that train to Marseille. But human beings aren’t like that. They are unique. And trying to make them interoperable is a bad idea.
The lesson of the railways is true for product management. Making choices about what to standardise and, just as importantly, what not to standardise, is important for optimising performance of an entire system. A product management function needs to have some things standardised, where there is a need for interoperability, but product managers need to have non-standardised freedom to respond to change and innovate in how they work. Without this, product managers will not be able to manage products, they’ll simply be building the same railway as everyone else.
There are better ways to improve the quality of product management in an organisation. There are ways that focus on effectiveness over efficiency, ways that allow product managers to develop areas of specialist knowledge in economics or payment systems or behaviour change techniques or network effects or marketing, ways to support and coach product managers to lean into their uniqueness.
No two product managers should be the same, and they shouldn’t develop the same product in the same way. If they did, what would be the point of product managers? The point should be for each product manager to bring their own knowledge, skills and experience to their role and use them to tackle complex problems in unique and innovative ways. The point should be for organisations to maximise innovation in product management as a competitive advantage. The point should be for the discipline of product management to evolve at pace in a changing world.
A short introductory session to Objectives and Key Results.
What does OKRs stand for?
Orca’s Keep Rollin’ – watch out for those aquatic mammal gangstas.
Organophosphate Keratinization Roentgenography – I don’t even know what that is.
OK, Roger – Yeah, whatever, move on.
Or is it Objectives & Key Results?
Yep, you guessed it, OKRs stands for Objectives and Key Results. So if you’re here for the talk on Organophosphate Keratinization Roentgenography, you’re in the wrong meeting.
Objectives & Key Results
OKRs are a goal-setting method that enables teams to focus on what matters most, and make changes when they don’t yet know how to achieve the goal.
There are two important bits to remember there:
Focusing on what matters, and not knowing how you’ll achieve the goal.
This is what makes OKRs different to other goal-setting techniques, and what we’ll revisit a few times in this talk. OKRs aren’t about recording and tracking all the work your team is doing, only the most important work, the stuff that contributes to the big OU strategy and priorities.
And they aren’t about defining the work you’ll do upfront, when you know least about how you might achieve the goal you’ve set. You should figure out the work later, and be open to changing what work you do to achieve your objective.
History of OKRs
OKRs were introduced to Intel in the 1970s.
And Google adopted them in 1999, and has been using them ever since.
They are also used by LinkedIn, Twitter, Uber, Microsoft and thousands of other organisations around the world.
Why does this matter? So you know that OKRs aren’t some funky new fad. They have a long history, and have been developed in lots of organisations. Books have been written about OKRs. There are OKR conferences (mostly for people who don’t get out much). They’ve been shown to be a useful technique for aligning teams with what the leaders of an organisation are trying to achieve, but doing it in a way that recognises things change, we learn as we go, and we need to be able to adapt.
Why use OKRs?
Align priorities
We use OKRs at OU to help teams align their work with organisational strategy. In large organisations in particular, the day-to-day work of the teams can get disconnected from the bigger priorities of the organisation. OKRs give us a way to leapfrog over the hierarchy of the organisation and directly connect what the team is trying to achieve to what matters most for the organisation.
Have two-way conversations
OKRs provide a means for two-way conversations between teams and leaders about the priorities for the organisation and how the work the teams do contributes them. OKRs don’t work without those conversations and the shared understanding that comes from them.
Give teams decision-making autonomy
We want teams to make the decisions about what work will achieve the Objectives, after all you all are the experts in what you do. OKR’s do this by separating the Objectives from the work to achieve them.
Track the things that matter
And they focus on tracking the outcomes that matter to the organisation, not the deliverables which may or may not contribute to the goal.
What is an objective?
An Objective is an easy-to-remember, qualitative descriptions of what you want to achieve.
It’s that simple. It doesn’t need to be complicated. It doesn’t have metrics or timeframes, it doesn’t say who is responsible. It just needs to express the most important thing the team is working on in a way that anyone can get.
Example objectives
Improve the quality of leads contacting us
This is a pretty good example. It’s easy to see why it would be the most important thing a team is working on, but it does require a bit of specialist knowledge to know what leads are, and maybe what a quality lead is.
Increase revenue by 20% in 3 months
This is a pretty poor Objective. It’s too specific and includes measures. And, although challenging Objectives are good, it’s probably unachievable.
Grow email subscriber list
This is a good Objective. It’s short and easy to remember, easy to talk about with people who aren’t specialists, and easy to see what it’s important.
When writing Objectives, it’s best not to over think it, don’t try to cover every caveat or be super specific. It’s much more important to have an easy-to-remember description of what you’re trying to achieve.
What is a key result?
A Key Result is a specific, measurable metric that shows movement from what it is now to what you want it to be.
They are always quantitative and need data to report on that movement.
Example key results
Increase form submissions from 5% to 10%.
Pretty good, tells you what the form submission rate is now and where you want to get to. Could be a bit more specific about which forms.
Motivate employees to enhance customer service.
Isn’t measurable, doesn’t show how motivated employees are now or what the change is.
Decrease user journey drop-off at step 4 from 25% to 20%.
This is a good Key Result. It’s specific about where the change will happen, and the direction the change will go.
Have a go
Write an Objective and a Key Result. It can be about anything. Work. Personal life. World peace, if you want.
Try to make your Objective easily memorable description of what you want to achieve.
And make your Key Result specific, measurable, and that shows movement from how things are now to towards achieving the objective.
Here’s mine.
Objective: Run five miles without stopping.
Key result: Reduce the time between stops from every ten minutes to every twenty minutes.
What did you notice?
Writing OKRs is easy right?
It’s often much easier to write the objective if you are clear on the bigger picture, and almost impossible if you aren’t. So, my objective of running five miles without stopping only makes sense if I know the bigger picture of wanting to take part in a marathon. Without that, it’s kind of a bit random and isolated. So, when you’re writing Objectives with your team, it’s important everyone has an understanding of the bigger picture of organisational priorities.
Key Results are often much harder. They need to be able to tell us that we’re making progress towards the Objective, not just tell us whether we’ve achieved it or not, and not just tell us that with completed steps along the way. So with my running objective, I wouldn’t want my Key Results to be ‘Go to the gym five times a week’, as that’s a done/not done task, and doesn’t tell me if I’ll ever be able to run five miles without stopping. My Key Result of reducing the time in between stops tells me if I’m getting closer to being able to run five miles without stopping because I know that distance is going to take a certain amount of time, and so if, each week I can run for longer without stopping then one day I’ll be able to run five miles without stopping.
We haven’t mentioned anything about the work we’ll actually do to achieve the objective.
OKRs is a goal-setting technique that doesn’t focus on, in fact doesn’t even mention, what work you’ll do to actually achieve the goal. And there are two good reason for this.
When we focus purely on what we’re delivering, and not on what we’re trying to achieve, the work can easily become disconnected from the goal. We could be doing the wrong work and never know it. Or we could carry on delivering more than we need to after we’ve already achieved the goal. OKR’s help us avoid that.
And, when we specify our goals as delivering pieces of work, it assumes we have a crystal ball and know that particular work is definitely going to achieve the goal. Instead, OKRs allow us to deliver a piece of work, use the Key Results to learn that it didn’t help achieve the Objective, and so change to delivering a different piece of work, all without changing the original Objectives.
What OKRs aren’t
Deliverables or initiatives
Getting a campaign or a web page live is a deliverable, it might be an important piece of work to do, but it isn’t an OKR Objective. OKR’s don’t specify the work.
Everything you’re working on
OKR’s should focus on only the most important things the team is working on, those things that achieve organisational priorities. We’re all busy working on lots of different things, but we wouldn’t put all of that work into OKRs.
KPI’s or other metrics and measures
OKRs don’t replace KPI’s and other metrics that your team tracks. Those other ways of showing performance and progress are equally valuable.
What makes a good OKR
You’ll know if you’ve got a good OKR if you can answer Yes to all of these questions.
Can everyone in the team see how our Objective contributes to an important org priority?
Organisational strategy is only achieved by the work teams do. Being able to connect the work you do directly to the big organisational priority tells you it’s important work.
Have leaders and teams talked about the Objectives?
A good OKR is one that has been well thought through, socialised, agreed and accepted. Remember our earlier definition of an Objective? It should be easily memorable. Anyone in the team should be able to say, “Our objective for this quarter is to improve the quality of leads contacting us” without even thinking about it, and definitely without having to look it up in a slide deck.
Is it within the team’s control to achieve this Objective?
If achieving the Objective relies on lots of other teams to do things that might not be a priority for them, or needs someone who’s going to be on leave, or depends on a system that isn’t set-up yet, then the team’s chances of achieving their Objective are affected by things outside their control. You don’t want Objectives like that.
OKRs are really simple, but…
OKRs are really simple, but some organisations like to make them complicated.
So, things to watch out for…
Demanding team’s set OKR’s every quarter, even if the team isn’t working on something that contributes to an organisational priority, or the work the team is doing doesn’t generate any measurable Key Results. OKR’s aren’t the only, or always the best, way to show what a team is achieving.
Objectives are cascaded down and team’s told what their Objective should be, or even worse what they should deliver. Talk to other teams and leaders about teams having the space to figure out for yourselves how best to contribute to organisational priorities.
Retrofitting work that has already been lined up into OKRs. Sometimes this can be ok, simply speaking work can be converted into an Objective by asking ‘why’ are we doing this work. But it’s a bad habit to get into as it means the team is getting locked into delivering a piece of work that may or may not achieve the Objective.
OKRs in practice
Some tips and tricks for getting the most out of OKRs:
Start small, learn as you go
Start small and learn as you go. Each time you think about OKRs, you’ll come up with more questions; how many OKRs should we have, how long should we have the same objective, what if the results only show in the future, etc., etc.? You’ll figure out the right answers for you by discussing those questions together.
Impact is better than perfection
There’s no single ‘right’ way to do OKRs. If the way you’re doing it means you’re talking to leaders to get aligned, focusing on your most important work, and measuring the results to know you’re making a difference, then that’s great.
Avoid lots of process
Avoid having lots of process around OKRs. You don’t want to create an industry around managing OKRs. They are meant to help your team focus on what matters most, not become lots of work to administer. So, if you find yourself spending more time updating slides about OKRs than learning from the Key Results, then you probably should change that.
Getting started with OKRs in six easy steps
Set the objectives
Teams and leaders talk about what’s important to the organisation right now, and what the team’s objective(s) should be. The team should write an Objective they think will contribute to that priority.
Set the Key Results
Teams figure out how they can measure the change towards the Objective.
Often the data is imperfect or not available, don’t let this stop you. Try to find some data. And use this to help you identify how to improve the data so that tracking gets easier in the future.
Do the work
Teams decide what work they’re going to do to affect the Key Result. Often you won’t know for sure, but that’s the point of OKRs, they help us deal with that uncertainty, but use your expertise to come up with a hypothesis about what work you think will achieve the Objective.
Share the Key Results
Sharing the Key Results with others helps everyone ask questions.
If they didn’t change, the team asks, did we pick the right Key Results? Did we pick the right work?
If they did change, the team asks, have we done enough to achieve the Objective or is there more we can do?
Review and learn
This is the important bit. Don’t miss it. This is the team’s chance to think about the work they did and whether it was the right work to affect the Key Results.
OKRs are a powerful tool for shifting teams from focusing on deliverables to focusing on having an impact on the things that really matter, but that only happens if you are regularly asking questions and learning what it takes to make that shift.
Repeat
Next quarter, start with the Objective again. Ask, is it still the right objective or should we have a new one. If you achieved it last quarter, you’ll definitely want a new one, but sometimes organisational priorities change so always start there.
Or in plan language: talk to each other, work together, be helpful, check things are going ok.
These are my four principles for team work.
Communicate
Communication doesn’t mean one-way information from those in the know, and communication doesn’t happen well when intermediaries (especially software tools) get in between people. Talking to each other is the best way to communicate.
Collaborate
Collaboration means working together to achieve the same goals, not working on different things separately or with different goals. Lots of work gets done in isolation. The best work gets done in collaboration.
Contribute
In some teams, everyone has specific roles and responsibilities. They all know what they do and they only do that. But in better teams, people use the breadth of their knowledge, skills and expertise to contribute, even if it isn’t in their job description. Being helpful makes a big difference in how teams work. Sharing knowledge, offering to chat, making introductions, taking on tasks when someone is busy, it all makes the difference between being a group of individuals and a team.
Coordinate
Coordinate used to mean centralised upfront planning and giving people instructions to follow, make sure they’re doing the right things and staying on track. Now it means looking for signals about what’s happening, what has changed and responding in real time. That’s why checking-in with each other is so important. If one person shifts their focus, maybe it’s a signal they know something the rest of the team don’t. But if everyone notices they can check that they all still have the same understanding of what the team should be focused on.
So, teams can use ticketing systems, have separate goals, stick to their roles, and plan ahead if you want, but they’ll probably do better if they talk to each other, work together, be helpful, and check things are going ok.
I used to think that you’d notice blame culture by seeing people punished for mistakes. And, that a culture of blame is wrong because no individual is ever solely responsible for a mistake because we all work within complex systems.
Now I realise that a culture of blame is much more subtle.
Blame culture exists when people feel like they have to explain their actions, and always their failings, as caused by something outside of themselves. This thing happened because that person didn’t do something, they say. Or some other thing didn’t happen because that’s just how it is around here. None of this was caused by my actions, they suggest. That is a culture of blame.
The opposite of a culture of blame isn’t a culture of accepting mistakes, it’s a culture of accepting responsibility. You can see the absence of a culture of blame in the sense of agency people have. When people show initiative and take risks, when they approach problems with ways they can contribute to solving them, when they take control of things within their influence, that’s when there is no culture of blame.
What do you believe about how the world works? Do you believe it works like a machine, that a cause always leads to an effect and that makes the world predictable? Or do believe it works in random ways, where sometimes a cause doesn’t have the expected effect and sometimes effects appear from unknown causes, that the way the world works is unpredictable and emergent.
These two opposite ways of seeing the world are often so deeply rooted that we don’t recognise them, but they matter. They matter when we run organisations the way we see the world. And they matter when we try to apply tools and techniques in our organisations. Our tools and techniques fit with one or the worldview, and they aren’t interchangeable.
Agile. Thinking in bets. OKR’s. Outcomes. Now, next, later roadmap.
Predictable worldview tools and techniques make sense if you believe in a predictable world. Emergent worldview tools and techniques make sense if you believe in an unpredictable world. Using the wrong tools for the worldview doesn’t make sense.
So, when people say things like, “agile failed”, maybe the problem is trying to apply emergent tools in an organisation with a predictable view of how the world works.
Strategies, plural. Not one big strategy, but lots of small simple strategies that make it easier to figure out what’s working.
Capabilities to solve the problem. Thanks to Ian for this addition. He’s right, a strategy without the ability to deliver on it is useless.
So, four parts to simple strategies.
A worthwhile problem to solve
A hypothesis about how to solve the problem
The capabilities to solve the problem
A way to know if the problem has been solved
A worthwhile problem to solve
This is where product managers spend most of their effort – finding and understanding problems and figuring out if they are worth solving. Those problems can be big or small, tame or wicked, organisational or customer problems. What makes the problem worth solving depends on the context but could include how many people it affects, how much they are willing to pay for a solution or how much it limits an organisation from doing what it wants to do. Without a worthwhile problem to solve, no strategy is going to create a successful product.
A hypothesis about how to solve the problem
With a deep understanding of the problem and confidence that it’s worth trying to solve, a product manager can create multiple hypotheses for solving the problem. Testing and validating these hypotheses enables the product manager to hone in on the solution most likely to succeed. Getting to a single well-defined hypothesis gives direction about what to build in order to solve the problem.
The capabilities to solve the problem
The product manager has to match what to build with whether the team can build it. Working with the team to figure out what they can build, they test feasibility. Not just feasibility for the technology, but compliance, security, accessibility, etc., to know the organisation and team has everything it needs to solve the problem.
A way to know if the problem is solved
Product managers have to figure out how to know if the product they built has solved the problem. Often this is by understanding user behaviour and measuring whether the product caused a change in that behaviour, also known as achieving an outcome. The product also has to be scalable, financially viable, marketable, etc., etc. in order to solve the problem for lots of people at the same time.
Product management and service design can complement each other and create better products/services because of it. But because both roles are pretty flexible, generalist roles, there’s lots of room for misunderstanding. To work well together, both people have to fill that room with understanding.
How not to work together
Sometimes, when two people from different disciplines start working together, they get stuck into the work without taking the time to figure out how they should work together.
In an attempt to tackle the confusion and misunderstanding this creates, we often try to define how product people and service design people should work together, which gets into trying to define terms like ‘product’ and ‘service’ as a way of drawing boundaries of responsibility and make sure people stay in their lanes.
I don’t think this is the right approach.
We aren’t trying to systematise or scale the relationship, we’re trying to nurture it. So, avoid to temptation to define things like ‘product’ and ‘service’. It becomes a purely theoretical exercise and won’t improve the relationship between product managers and service designers.
Instead of treating each other as job titles we can treat each other as people with a broad range of perspectives, experiences and expertise. And then we develop the relationship necessary to work well together.
Building a partnership
We have to talk about how one individual product manager works with one individual service designer. That’s the only way to talk about building a partnership. It’s about how two people talk to each other, create the space for each other’s perspective, not how two job titles might work together in theory. But, it might help us understand each other’s perspective. Maybe it looks something like this:
Service Designers merge a design methodology with a service orientation, Product Managers apply the scientific method and systems thinking in an organisational context.
Service Designer are user-centred, product managers balance multiple perspectives.
Service Designers deal with the relationships and interactions between tangible things, product managers deal with intangible and often unrelated things.
Service Designers go deep, product managers go wide.
Service Designers are usually involved with a service/product for a short period of time and are judged by their outputs, product managers are usually involved for a long time and are responsible for the quality and success.
Service Designers work is mostly upfront, a product manager’s work is never finished, it’s about iteration and incremental change.
All of these are good things. Good partnerships are about recognising different perspectives, skills and experiences individuals bring. The solution for how people work well together is creating the space for conversations to understand each other.
Creating the space
The space we want to create is one where different perspectives are welcome and treated equally. It’s a psychologically safety space. It has a shared expectation that no one will embarrass, reject, or punish the other for sharing ideas, taking risks, or soliciting feedback.
The relationship between product manager and service designer should be:
Mutually respectful of each other’s discipline, skills, expertise and expertise.
Equal in power, or at least reducing the power distance.
Supportive and encouraging.
Aligned to what the work is trying to achieve.
Understanding of the challenges the other faces.
These things are the basis for any good working relationship but it’s important to make them explicit as in many organisations there are implicit rules for things like how seniority is treated, and personalities can sometimes get in the way if one presents as more extroverted than another.
If it’s hard to say such things explicitly, user manuals for me, read me’s, etc., are a good place to start. But really, doing the hard work of creating a psychologically safe space for the partnership to live in will be worth it in the future. Spend time together, get to know each other.
Establishing who does what
Agreeing responsibilities should be straightforward as the roles are so different, but it rarely is. This can be because of organisational pressures, lack of clarity about roles, hidden agendas, etc., but also because we have all have different ideas about things.
The best answer to ‘who does what’ is to talk about it and agree responsibilities based on skills, experience, availability, etc.
If there are responsibilities that both think they should have, call it out. Discuss it.
Keeping the partnership going
Keeping working relationships positive and effective when everyone is under pressure and busy with getting the work done can be hard. It takes time and lots of effort.
A couple of tips for Product Managers to help Service Designers:
Provide context – You’ll have knowledge of the wider context of the market, organisational goals, technical constraints, budget limitations, team skills, supplier relationships, etc., etc. Help the Service Designer understand how these things affect their work.
Trust the expertise – Let the Service Designer do their thing. Give them the space to explore problems from their perspective and come up with solutions.
A couple of tips for Service Designers to help Product Managers:
Presenting information – Product Managers have to switch between strategy and implementation, now and future, new and existing, creating and operationalising. Understanding this means you can provide them with the right level of information at the right time.
Align thoughts – Product Managers think in experiments and work in iterations. This doesn’t always align with how a service might be designed. Think about how to bring those different ways together.
P.S. Talking to each other works for all roles. Even though some roles are better defined and have clearer responsibilities which make working together clearer, starting with a good relationship always makes working together easier.
I can tell you everything you need to know about agile in three words.
The first sentence of the Agile Manifesto says it all. It says, “We are uncovering better ways…”. Those are the three most important words in the whole manifesto, or anything written about agile since. They tell us the essence of what it means to be agile.
Just three words:
Uncovering – means finding out as we go, not thinking we can know it all upfront.
Better – let’s us know we are always looking for improvements.
Ways – tells us it’s a practice, it needs to be worked at repeatedly to make it successful.
Uncovering better ways… of doing anything… but especially…
Uncovering better ways to lead…
…is still emerging, and there’s lots to learn, but it probably means considering things like:
Embracing change and uncertainty, not portraying false certainty.
Involving people in creating vision and direction, not telling people what to do.
Cultivating emotional intelligence, self-awareness and vulnerability, not ignoring the soft skills.
Being a trusted thought-partner, not a teller of single truths.
I once worked with a team who each had individual performance objectives set with HR, and team objectives set by their manager, but their stakeholders judged them by what they delivered. They reported on long-standing KPI’s for their products but no one could remember who had set them and they weren’t used for decision-making. No one measured any outcomes.
Unsurprisingly, they didn’t know which measures mattered or how to be successful.
This isn’t an uncommon story. People often have multiple ways of being evaluated at work, and they often lack any kind of connectedness or coherence, and sometimes even conflict with each other. Once a year, managers take a guess at what an individual might be able to achieve over the next twelve months and set objectives accordingly.
There are better ways.
Let’s start by doing away with individual performance objectives.
Let individuals focus their efforts on achieving their team’s objectives. Individuals succeed when the team succeeds. However much an individual contributes to the team’s success, they can’t succeed unless the team does.
And… here’s the magic ingredient that helps the individual improve their performance faster than a manager with annual objectives: the team provides fast feedback that helps the individual course correct to meet the team’s expectations at that time and as they change.
If the individual gets and responds to fast feedback from the team, they have the maximum opportunity to improve. The feedback is humble, because the team understands the circumstances, helpful, because the team wants to the individual to succeed, and immediate, because everyone works together everyday. There is no need for measurement as a separate activity to inform and justify improvement. No need for quarterly or annual performance reviews that are distant from the work.
The role of the manager becomes one of coaching the individual to respond positively to the feedback, to use it to shape their behaviours towards what the team needs from them. Feedback from the team also helps individuals identify skills gaps in a way that individuals can’t for themselves, and which managers can help them to improve on. As they improve, so the team has a better chance of succeeding.
Team needs psychological safety to be able to give each other fast feedback in this way. But team’s need that anyway. And being able to give and receive feedback from each other helps to build psychological safety, so the two grow together.
