Running long-term planning for your team
Running long-term planning for your team
Planning objectives creates alignment in the organization. There are many ways to fail in planning, there is no easy way to get it right.
When you're managing the team, it's unlikely that your area has no plans for the future. More often there is a bundle of ambitions, multiple ideas about the next steps, and many points of view on priorities. In such a diversity of opinions, aligning on specific steps forward might be a challenge. Defining objectives** is a great tool to focus the whole organization and work towards the same direction.
**By the word "objectives" I do not refer to any specific framework like OKRs, KPI, SMART. In this text, "objectives" just means important stuff that we want to get done.
A well aligned organization avoids wasting time and effort on projects that will be put on a shelf. There are multiple reasons why a project might never reach the customers. The engineering team delivered their work, but marketing folks are fully booked for the next quarter, so the launch put on hold. Alternatively, the engineering team might wait for another team to build an API, but that team works on other priorities.
To achieve a high level of cohesion in the organization, the right work must be done at the right time. It does not make sense to invest effort in planning a big project if there is no agreement in place to include this work into the roadmap. Before biting a big chunk, make sure you can process it downstream1.
Investing into the objectives planning for your organization, will help to align teams and minimize waste of effort. The planning process is time-consuming and requires a lot of discussion. There are many ways where it can go sideways. Yet, it's a key part of being a manager. Other aspects of your job, like keeping your team happy, helping them grow, will not be possible if your org does not execute for the company. Before jumping straight to the objectives planning, it's absolutely necessary to define the ground rules.
Building a shared definition of success
Without a shared definition of success across the group of decision-makers, the whole planning process might become an annoying formality rather than a helpful exercise. Without such understanding, each part of the organization will focus on their, locally defined, success criteria and is likely to compromise overall cohesion. The marketing team chases the number of users signed. Product folks focus on the conversion rate or whatever. Engineers care about the availability of systems. However, the number of users of the service doesn't matter if users pay less and drop out. Shiny features do nothing if the services are down. A well-written software that does nothing for the business is a waste. The interaction between these things is complex, and only balancing all aspects in a healthy range drives business.
To keep that balance, it's important to combine all of these perspectives into a set of metrics that show how successful the organization is. These metrics will drive the decision-making, and therefore they should be tied to the business results.
There is an immense amount of effort spent on building features that add little value to the product. Alexa will whisper back to you if you whisper a command. Slackbot will encourage you to use the word "folks" if you send a message with the word "guys" to a big channel. And you absolutely need a feature in a bank app to add emojis to money transfers.
Wrong metrics lead to redundant work. Praising people for doing stuff decays the culture and creates chaos. People might actually do harm to the company by chasing the wrong metrics. This is knows as the "cobra effect" or "perverse incentive"2.
Therefore, objectives should be connected to the key business metrics. Achieving an objective must result in something meaningful for the company and its customers. Objectives bring focus, good metrics ensure the organization is focused on what matters.
Identifying potential projects
It's the manager's job to identify high potential projects for the team. No matter how often the company plans (quarterly, half-yearly, or every year), you should have a list of projects that your team can work on.
Not just the list of ideas, but the list of projects—There is a good reason for each why it's worth doing, how much work it will take, what the dependencies are, risks, and critical assumptions.
For technical initiatives, it's straightforward. You know your technologies, you know where the team struggles, and you can get engineers in the room to decide what to do about it.
However, if your team is doing only technical work, the value of this team is questionable. Unless it's a sort of platform team. This is why you need to talk to your peers—product managers, UX, marketing. What are they working on? Are there topics where your team can help?
Note: Keep your expectation reasonable, not all these folks work with engineers day to day. They might not have clear requirements, or even well described problems. You will help the company a lot if you can get ideas from other people and turn them into projects.
Aligning on priorities
A tricky aspect of alignment is to agree on priorities. You might need to convince a group of people, why your initiative is worth doing and why it should come on top of other features.
The reasoning behind the prioritization may be unclear. Often, the person with decision-making power is not known. There are many implicit rules, and engineers may be reluctant to participate in this process. Some may even call it “politics”. There are ways to navigate this space.
A big source of frustration is trying to agree on priorities without using the same units to compare projects. A vivid example is the prioritization of technical debt. Engineers and product folks regularly have a fight about it. Engineers appeal to bulky code base, complexity, difficulty of making changes. Product managers push back and ask for business value. The fight continues, as long as each side uses their own language to evaluate the importance of technical debt.
The tone of the discussion changes drastically once engineers pickup business language. It's more productive, though requires more effort, to express the cost of technical debt in financial terms. During this year, we had in total 20 hours of our service being down because we overloaded our database with sudden traffic spikes. We've already lost your-cost-of-product-not-working-for-one-hour x 20. Moreover, as our traffic grows, we will get more and more similar outages. Any objections to prioritize reliability improvements?
Note: Often enough, engineers use the term "technical debt" loosely, and push for things that gave little value.
In a sense, it's easier to calculate the cost of the technical debt because it's always in the past. You can get accurate numbers of revenue lost due to outages. In contrast, product features are always forward-looking, their expected value based on assumptions about the future.
If your area has a clear set of metrics to describe success, it's only reasonable to prioritize projects based on the impact. If you don't have clear metrics to guide decision-making, prioritization may be a mess. In this case, the only way to get your things prioritized is to invest in relationships with stakeholders. Hey, come on! You should have metrics. Otherwise, how do you know if you're doing good for the company?
Aligning on dependencies
Just your team doing the work is not enough for success. Probably, you need other teams to be involved. However, these teams are working on their priorities.
A clear signal of misalignment in an organization is when it has multiple backlogs. Product managers have a product backlog, the engineering team has an engineering backlog, the UX team has their UX backlog. It makes sense to plan ahead for each job family, but the danger is that each team might be busy and not produce any value.
Imagine an engineering team investing hundreds of hours in producing next-generation architecture for their area. They wrote extensive design documents, evaluated alternatives, and built proof of concepts. The only issue, there is no chance they will be able to implement any of it in production next year due to a company-priority project. It is not only a waste of time, it also is a source of frustration for engineers.
Understanding the role of your team and how it's connected with the rest of the organization is crucial. How does the work reach your team? What teams need to work before your team is involved? Similarly, what are the teams down the line? Who will pick your team's work and carry it to the customers? Will there be go/no-go decisions down the road? Approvals? Reviews?
Once you know who is involved, working backwards from the goals helps to sequence work items and agree with relevant teams on deliverables and dates.
Measuring progress
Agreeing on the most significant topics is half of the journey. Having meaningful measurements of progress is what gets the job done. What you measure will drive the behavior of the team. When connected to performance evaluation, objectives can become a powerful incentive. "This is what we agreed to deliver, my career depends on it. It's time to roll the sleeves and work on it"—A manger might think. The value of this work or its side effects may become an afterthought.
Ideally, progress should be measured by the business outcomes (revenue, costs, operational efficiency). It might not be possible when developing an entirely new product. It's always worth splitting the work into incremental steps rather than doing the entire thing before seeing the results. Big-bang launches have a higher risk of failure due to delayed feedback.
Without clear measures of outcomes, it's easy to slip into measuring effort. That often happens with technical migration—The new, yet to be built system, promises to solve all problems and succeed the existing one. Such initiatives typically miss on an analysis of the current state and give vague promises of a better future. Joel Spolsky wrote in 2000, "The single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."3 Decades later, the point still stands.
Without being able to trace the result of work to the outcomes, the organization would spend thousands of hours on migrations with little to no improvements. Will the new system have better service-level objectives (SLO) than the old one? Does the old one have any SLOs at all? What specific capabilities are missed? Why does it require building a new system to provide these capabilities? Will the new system cost significantly less than the existing one? How long does it take to get a return on investments?
Answering these questions is way harder than measuring the number of milestones delivered, or the number of services migrated, or the number of tickets completed4. Customers do not care about that, and the company's balance sheet does not reflect any of those.
What matters are:
Revenue—how much customers pay while using a company's services.
Cost—how much does it cost to run the business, hardware cost, user acquisition cost, etc.
Reliability—how often services brake, and how long does it take to repair them.
Operational efficiency—number of people participating in critical business processes and the lead time of these processes. For example: how long does it take to resolve a customer support ticket, publish a new page, start selling a new product, etc.
If it were that simple, we probably shouldn't have meaningless objectives, right? Not quite. Reality is complex, measuring the true value of something might be tricky. For example, how to measure the value of the loyalty program? There are many assumptions in place. Such as recurring users will spend more over their lifetime, that they will be more loyal to the brand, and they will spread the word, etc. But who knows if these assumptions are correct.
Danger of proxy metrics
That's how proxy metrics creep in and might become a primary driver. A proxy metric is a simplification of reality, that abstracts away the complexity. For example, software quality. It is a complex concept. There are many dimensions of quality: user experience, reliability, performance, adherence with the requirements, etc. In contrast, test coverage, a proxy metric of quality, is a simple thing.
The danger of relying on proxy metrics — they represent only some parts of the reality, leaving you blind to the rest.
It happens that each team optimizes their own metric and ignores the bigger picture. For example, attracting more users to the service is a good thing. More users will lead to more money. Won’t it?
The marketing team might be chasing this metric. On the other side, the product team might see spend per user and retention rate are going down. In addition to that, the engineering team deals with outages caused by sudden traffic bursts, and those outages probably make existing users unhappy. Optimizing one part of the system, might harm the whole.
An even greater danger is when people in the company begin to treat proxy metrics as something real. These abstract numbers might become "vanity metrics". They supposed to impress people who might not be familiar with the domain. The number of registered users for the mobile app is an example of a vanity metric. There might be a million of registered users. Let's not mention that 99% of them are not active. Moreover, only a hundred of them use paid features. But still, a million users sounds impressive, and not everyone will dig deeper.
There are many easy ways that give an illusion of progress. This is, probably, the number one reason why so many big companies are inefficient.
There is only one way to ensure your organization delivers projects that the company and its customers care about—It is to think critically and connect objectives to the business results.
Takeaways
Know the primary business metrics of the company—How the company measures success, and evaluate your projects based on these metrics.
Work with peers to build a holistic overview and metrics specific to your area. Run regular reviews for these metrics.
Don't fool yourself with proxy metrics. Remember—map is not the territory.
Cobra effect: https://en.wikipedia.org/wiki/Perverse_incentive
Why the FBI Can't Build a Case Management System: https://ieeexplore.ieee.org/document/6127846