2. Business outcomes

Effective software organizations focus their investments on the right outcomes.

Achieving business outcomes isn’t solely about writing code or shipping new features; it requires delivering tangible results that align with business objectives, all while maintaining product quality, efficient feature delivery, operational stability, and user satisfaction.

In this chapter, we’ll explore how to structure a software development organization. Then, we’ll share a framework to guide engineering teams in balancing short-term gains with long-term sustainability. We’ll wrap up by discussing practices for successful prioritization.

Organizing for outcomes

The structure of an organization plays an integral role in how well the organization can deliver business outcomes. An organization’s job is to promote efficiency and productivity, communicate effectively with organization members and stakeholders, provide clarity in goals and alignment with business goals, and ultimately, deliver on those goals.

Teams exist to manage complexity

Teams, not individuals, are the atomic units that make up an engineering organization. In the beginning, an organization may have only one software development team, and there’s little complexity to manage. Team members have touched most of the codebase, and the codebase is small and tidy enough. Everyone knows everyone.

However, as a company accumulates new customers, features, and business needs, the full scope of the software grows difficult for any single person to grasp. More and more of the company’s software engineers have never touched critical parts of the software. Finding the right person to ask a technical question sometimes becomes a multi-day adventure.

This is why we have teams. By dividing into teams, an organization can take on more complex problems and tasks while effectively delivering business outcomes. The concept of a team allows a small group of people to feel connected with their objectives, codebase, and teammates.

At the same time, creating a team, by definition, creates a silo. When you put a group of people together, you’re implicitly saying that it’s more important for this group to be in sync with each other than with those outside the team. Silos are often considered in a negative light, but without some degree of siloing, everyone would have to pay attention to everything all the time, and things would undoubtedly fall between the cracks. With teams, we create focus and efficiency, even at the expense of more cross-team collaboration in some situations.

What is a team?

A team is more than a group of people assigned to work with each other. A viable team has common objectives and a clear understanding that success at those objectives requires team members to depend on and trust each other. Everyone on the team has clear roles and responsibilities without establishing rigid lines between how different team members contribute. Team members decide on the team’s goals in a process that values and considers the input of one another, stakeholders, and dependent teams; the success of a team is measured against its goals and objectives.

Teams have team members, typically from disciplines including software engineering, product design, and product management, among others. This cross-functional approach helps foster a sense of ownership and collaboration across the team rather than different roles that work by handing work off from one person to another.

Perhaps most importantly, a team should be substantively able to deliver value to the organization using only the resources of that team. If a group of people can only create value in partnership with another group, they’re not a team. Empowered teams are more resilient to organizational change and allow room for growth and development.

Tradeoffs in team design

There are four key areas to consider when you’re designing teams within a software organization.

1. Outcomes. You need to align teams with the company’s investment priorities and important business metrics, ensuring that the desired outcomes are being achieved efficiently.
2. Features. Every product area needs clear ownership in the form of a team responsible for its development, bug fixes, and improvements.
3. People. Healthy, effective teams include diverse viewpoints and skill sets, including those relating to software engineering, product management, and design.
4. Architecture. Conway’s law reminds us that the user-facing systems we create tend to mirror the organizational structure that created them.

When these areas are well-defined, they establish the boundaries of a team’s ownership and responsibilities. Creating effective teams involves evaluating tradeoffs in skill set requirements, dependencies on other teams, optimal team size, support and coaching needs, standardization, architectural support, and domain complexity. You’ll almost never get it right the first time, so experimentation will be necessary before you land on a good mix.

Compromises will be necessary. Having one larger, more diverse team might be more practical than having two smaller but deeply interdependent teams (for example, a frontend team and a backend team). Sometimes it’s not feasible to include every skill set within a single team, leading to alternative solutions like formal or informal organizations for certain skills. Sometimes the deployment target — for example, iOS — warrants a team all its own.

Effective teams tend to include engineers with experience across the stack. People whose experience with various aspects of software development — from data to systems design to frontend, if needed — can accelerate an engineering effort on multiple levels.

In cases where the codebase is complex and wasn’t designed to be worked on by independent teams, you might need to address technical debt or even rearchitect parts of the system before you can achieve better scalability and team autonomy.

Different kinds of teams for different purposes

Developing an engineering organization requires understanding the distinct needs that different types of teams fill and the order in which to introduce each type of team. Here’s a focused approach on how to strategically develop these teams, considering their unique purposes and contributions.

Start with product teams

The initial manifestation of an engineering organization is typically a single product team. Product teams are fundamental in owning and managing specific slices of your business domain, allowing them to operate with a high degree of autonomy and minimal dependencies.

Product teams make decisions and deliver features that directly drive business outcomes. This model aligns with rapid and effective product development, as each team becomes responsible for a distinct product segment, ensuring focused and specialized attention to their respective areas.

In practice, product teams start by focusing on key business areas or customer segments. As the organization grows, these teams expand, diversifying into more specialized units while maintaining their core focus on their segment of the product.

As an organization evolves, product teams will be the most common type of team.

Integrate platform teams

Once you have a few product teams, you’ll often discover that they act like independent companies. On the one hand, this is by design; on the other hand, you generally don’t want six product teams solving essentially the same hard problem in six different ways.

Some platform needs are common across almost all software companies. For example:

• CI/CD pipelines to get changes quickly and reliably to production.
• Design systems that make it easier for all frontend developers to build consistent interfaces.
• Scaffolding to deploy new microservices quickly in the company’s cloud environment, with security and compliance requirements met and with a good developer experience.

However, some platform needs will be very specific to your company. The idea with platform teams is that whatever your company is doing a lot of, it should get really good at doing. These could be things like:

• Tooling and libraries to visualize data in a data-heavy product.
• Ways to build integrations for an integration-heavy product, with tools like debugging webhooks and building authentication flows.
• Ways to tackle app performance issues so that teams can build features with less focus on scalability.
• Abstracting away unnecessary details of your business so that everyone can move faster.

No matter how important an objective is for your company, you can’t suddenly assign a thousand engineers to work on it using systems built for 10 engineers and still expect results. To that end, large tech companies often invest 30-50% of their engineers in platform teams with the objective of allowing the rest of the engineers to move faster.

The evolution and eventual roster of platform teams can vary quite a bit from one organization to another. A single platform team can own many things. Still, eventually, you tend to see a platform team break into several sub-teams, each focused on providing a specific type of value to product team engineers.

Introduce special teams

As the organization continues to scale, certain areas will emerge that don’t fit neatly into existing product or platform team structures. This is where you may have to get creative and design another type of team.

Product teams and platform teams have fairly simple patterns of ownership and communication needs. At some point, you’ll want to make a tradeoff that doesn’t perfectly fit these models, and that’s fine — as long as you recognize the tradeoff you’re making.

A team might specialize in one of these aspects:

• Enabling. They could be helping the rest of your organization with security, recruiting, onboarding, or any other crucial aspect.
• Complex subsystem. Sometimes a system is important enough to warrant continuous investment in a team that maintains it.
• Temporary or project-based. These teams are often formed to address specific challenges or objectives, and may be disbanded or reformed as goals are achieved or priorities change. This could be a big migration from yesterday’s testing framework to whatever we do today. Be aware that they might leave behind code whose ownership is questionable.
• Objective-driven. Some teams are defined by specific objectives they aim to achieve, not by a product or codebase boundary. This could be a team that’s focused on cross-cutting customer onboarding experience. A significant portion of the team’s work involves collaborating in areas owned by other teams. This requires them to have strong cross-functional communication and coordination skills.

Evolution of team structures

The evolution of team structures in an engineering organization typically follows a progression from product teams to platform teams and eventually to special teams, as needed. This progression aligns with the growing complexity and diversifying needs of the business.

1. Product teams. The most common kind of team in an organization. Your organization’s first team is almost certainly a product team. Product teams focus on specific business outcomes and product segments.
2. Platform teams. These are introduced to provide overarching support and standardization, enhancing the efficiency and cohesiveness of product teams. Typically, an organization has one platform team that may grow into its own platform organization.
3. Special teams. These emerge to address specific, cross-cutting objectives, filling any gaps in the organization and contributing to areas that require a broader, more integrated approach. An organization could have as few as zero special teams at any given time, depending on their business needs.

Each type of team addresses a distinct need within the organization, and their sequential introduction aligns with the natural growth and diversification of the organization’s responsibilities and objectives.

Tradeoffs in organization design

When you’re deciding how to structure and staff an organization, tradeoffs are inevitable. We talked above about how this works at the individual team level, but similar challenges exist when designing the organization as a whole.

Where you land on these decisions will depend on the stage of the company and the input of your stakeholders, among other factors. As you design and evolve your organization, you’ll do well to ensure that you make intentional decisions about where you want to land in each of these areas.

• Autonomy vs. coordination. Autonomy can foster a culture of innovation and quick adaptation, allowing teams to respond rapidly to challenges and opportunities. Excessive autonomy can lead to inconsistent organizational practices and difficulties integrating work from different teams. Emphasizing cross-team coordination ensures that all parts of the organization are aligned and moving in the same direction. Still, it has the potential to slow down some decision-making processes and stifle innovation and ownership at the team level.
• Specialists vs. generalists. Specialists are essential for tackling complex, niche problems. A team composed solely of specialists might struggle with flexibility and cross-functional tasks. In contrast, generalists can work across various domains, providing the team with greater versatility, but they may lack the in-depth knowledge needed for certain tasks.
• Centralized vs. distributed decision-making. Centralized decision-making ensures a unified strategic direction and consistency in processes. However, it can lead to decision-making bottlenecks and a disconnection from the on-the-ground realities faced by teams. Distributed decision-making empowers teams, allowing for faster responses and a greater sense of ownership over outcomes. Yet, without sufficient coordination, this can lead to a lack of strategic alignment and varying approaches to similar problems across the organization.
• Short-term delivery vs. long-term sustainability. Prioritizing short-term delivery can achieve quick market gains and customer satisfaction, but it may come at the cost of accumulating technical debt. Conversely, focusing on the long-term sustainability of the architecture ensures a robust and scalable platform but could delay immediate product deliverables.
• New features vs. maintenance. New features keep the product competitive, but focusing solely on new development can neglect the necessary improvement and maintenance of existing features, potentially impacting reliability and customer satisfaction.
• Large vs. small teams. Larger teams can manage a wider range of tasks and bigger projects but may face challenges with agility and internal communication. Small teams, known for their agility and effective communication, can quickly adapt and innovate but may be limited in the scale of projects they can effectively manage.
• New tech vs. existing solutions. New technologies can offer strategic advantages and long-term benefits, positioning the company at the forefront of innovation. However, they come with risks and uncertainties. On the other hand, existing, proven technologies provide stability and predictability but may lack the advantages of newer solutions. (When in doubt, choose boring technology.)

The decisions you make here don’t have to be permanent ones; you’re going to get some things wrong, and decisions that were correct before will turn wrong over time. Don’t stick a firm stake in the ground when deciding on these tradeoffs. Instead, identify where on the spectrum you want to be for each category and determine how well you’re adhering to that — and how well it’s serving you — over time.

Antipatterns for organization design

As you think about the different tradeoffs, there are plenty of antipatterns to avoid. Each of these antipatterns is a choice that very smart people have made in the past, but we recognize now that each of these choices sets you up for different kinds of struggles and failures.

• Frontend and backend teams. Most customer-facing features require both frontend and backend work. Dividing teams along these lines leads to a lack of collaboration, understanding, and ownership among different parts of the product development process. This separation often results in challenges with integrating the frontend and backend aspects of a project, typically leading to competing prioritization decisions by the different teams.
• Multiple teams sharing a backlog. Many engineers working from a single shared backlog can lead to prioritization issues, reduced ownership, and decreased clarity on individual contributions. When too many people are involved, it becomes challenging to manage dependencies and coordinate effectively, leading to bottlenecks and slowdowns. Additionally, this setup can dilute responsibility and accountability, as team members may not feel directly connected to the outcomes of their work.
• Too many small teams. While small teams are often more agile and efficient, over-fragmenting the engineering organization into too many tiny teams can lead to problems with coordination, culture, alignment, and consistency. A new team may need to be tiny at first, but teams of five to seven software engineers will be healthier and more sustainable over the long term.
• Delivery teams. These are teams that are solely responsible for delivering work specified by people outside the team. Without integrating cross-functional perspectives, they will tend to ship products that are technically sound but fail to meet user needs or business objectives.
• Lack of clear areas of ownership. When there is ambiguity about who owns specific parts of the product or codebase, it can lead to neglect of certain areas, especially maintenance and quality assurance, creating confusion during decision-making processes.

Roles and reporting lines

Typically, software engineers report to a line engineering manager. These leaders are familiar with the engineers’ day-to-day work, providing guidance, oversight, and support. In a small or shallow organization, there could be very few additional layers between that line manager and the CEO or CTO. In a more mature or structured environment, more roles start to emerge. Not every organization will need every role, but these broad distinctions become fairly typical over time, and each has a part to play in an organization’s effectiveness effort.

• Senior software engineers. They’re usually expected to take projects from start to finish, alleviating the team leads or managers from micromanaging individual projects. This approach allows leaders to focus more on team dynamics and strategic planning. Importantly, they rarely work alone; their leadership comes from being a force multiplier for the team by guiding and mentoring others. They advise junior team members, enhance team skills and cohesion, and play a critical role in maintaining high quality standards.
• Staff+. Staff+ engineers function as leaders within the larger engineering organization but without direct people management responsibilities. Their scope typically extends beyond a single team, setting operational standards and guiding architecture across a portion of the group or organization. Staff+ engineers set operational standards and guide architectural decisions that ensure scalability and efficiency. They influence technical strategy, align it with business goals, and mentor other engineers, elevating the overall technical skills of the organization. Often, they report to a manager at a higher level than the manager of the team they work most closely with.
• Line engineering managers. Successful people in this role have a strong understanding of software development, usually through several years of hands-on experience. They ensure that the team has what it needs to be successful and coordinate with other teams in the organization. Through one-on-ones and other techniques, they use coaching and performance conversations to support career progression while often still providing technical guidance. They may partner with a Staff+ engineer for technical guidance as well. This role is pivotal in organizations where individual teams require focused managerial and technical support, ensuring that the technical execution and team well-being are prioritized.
• Senior managers and directors. Typically, they’re responsible for several teams, with line engineering managers reporting to them. As part of managing their organization, they’re likely responsible for headcount, budget planning, performance management, organization design, cross-team alignment, higher-level goal setting, inter- and intra-organization optimizations, and so much more — the role can vary greatly by company stage and size, and even within internal organizations. People in this role typically aren’t hands-on in day-to-day software engineering work; indeed, a major challenge is to stay connected to the realities of that work while doing the rest of the job. They tend to report to senior directors, a vice president, a head of engineering, or sometimes the CEO or CTO.
• VPs and CTOs. VPs tend to be execution-oriented, while CTOs focus on providing a strategic and technical vision. Depending on the organization, the overall engineering vision and strategy usually come from someone in one of these roles, and the vision they provide aligns with the company’s long-term goals. Either of these roles can lead an engineering organization, make high-level decisions on technology and product development, and ensure that the engineering team scales in line with the company's growth. Each role is crucial in fostering innovation, driving technical excellence, and ensuring that engineering practices contribute effectively to the company's objectives.

Product roles also have a tremendous influence on an effectiveness effort. These roles often report separately from engineering roles, but individual product managers and product designers are assigned to individual teams.

Teams as a strategic investment

High-performing teams are an exception, not the rule. They don’t just happen — they require time to form, good leadership to maintain motivation, and clear areas of ownership and autonomy.

Not long ago — and certainly some companies still do this! — teams were organized around a set of features that needed to be built. Team members had input on the technical implementation but little involvement in defining how the feature would work, and often sought (and received) little feedback on whether their work had the desired outcome. The work was the outcome.

In contemporary thinking, teams are conceived not just as functional units executing predetermined tasks but instead as strategic investments. This shift recognizes teams not as stops on an assembly line but rather as fundamental drivers of business success, where their focus is on understanding users, not just on the features or products they develop.

Once again, empowered teams — a table stake we mentioned in Chapter 1 — are essential to making this work, and those teams need to be held accountable for the outcomes they achieve. Teams that can adapt and respond to new information and changing conditions will perform best in this scenario.

Investing in teams means more than just providing tasks; it involves nurturing their growth, capabilities, and cohesion. This includes:

• Skill development. Continuous learning and development opportunities help teams stay ahead of the curve, both technically and in terms of industry knowledge.
• Cultivating culture. A strong team culture that fosters collaboration, innovation, and a sense of ownership is crucial. The team’s values and norms should align with those of the larger organization.
• Resource allocation. Ensuring teams have the necessary resources — from tools and technology to sufficient staffing — is a key aspect of treating the team as an investment.

Again, the team, not the individual, is the fundamental unit of an engineering organization and a powerful lever for improving an organization’s effectiveness. Designing an outcome-oriented organization demands that you consider team and organization shape, as both influence how effectively work gets done.

Balancing engineering investments

In 2020, Matt Eccleston, a former Dropbox VP of Engineering, spelled out a framework for balancing and budgeting engineering resourcing. Our adaptation of this is what we call the Balance Framework. The Balance Framework is a model for understanding the distribution of an engineering organization’s efforts. It categorizes the organization’s work into four main areas: new things (creating new features or services), improving things (enhancing current features, services, and business processes), keeping the lights on (KTLO) (maintaining existing systems and services), and productivity work (making it easier to get work done).

One of the most potent aspects of the Balance Framework is its ability to create a shared language for people to use across various organizational roles, such as engineering, product, and senior leadership. This shared language allows for improved communication, aligning objectives, prioritizing work, and tracking progress more efficiently.

Let’s look at each category more closely:

• New things. Developing new features, products, or services. This represents innovation, exploring new market opportunities, and expanding product offerings.
• Improving things. Enhancing current features, services, tools, and business processes. This could be optimizing a feature for better user experience or revamping a service for improved performance.
• Keeping the lights on (KTLO). Keeping existing systems running effectively and efficiently. This includes bug fixes, system maintenance, and dealing with technical debt.
• Productivity work. Improving skills, optimizing workflows, upgrading tools, and creating an environment that allows the team to work at its best.

Investing too heavily in any one category can lead to problems. For example, focusing too much on new things at the expense of KTLO could result in system instability and a decreased ability to deliver work due to technical debt. Conversely, excessive focus on KTLO might result in fewer new things and improvements, leading to a stagnating product and missed opportunities for innovation and improvement. A healthy blend tends to include at least 10% for productivity work and between 10% and 30% for KTLO work. The remaining time investment will depend on the nature of your business and your product strategy.

Balancing at the team level

Never forget that a quarter, a half, and a year all have a finite number of days in them. In a quarter, there are 13 weeks, or 65 working days. When thinking about what a team can get done, remember that some percentage of that time needs to be held back for slack time (to address KTLO and reactive work), vacation time, and holidays. A team of five that starts with a theoretical 325 available engineering days in a quarter may end up having as less than half of that time available to invest in the new things and improving things category.

With that in mind, teams should also be thoughtful and intentional about how they invest their time in different areas, even if the exact breakdown doesn’t match the organization-level investment levels. Setting an investment balance intention at the team level can help make future decisions more straightforward.

Fostering collaboration with the Balance Framework

The Balance Framework emphasizes that improving productivity is a collaborative effort among engineering, product management, and product design. It creates a shared language between the diverse roles involved in product development, from software engineers to the CFO.

It also empowers engineers to advocate for the kind of productivity work that often goes overlooked and understand the value of the new things they’re building. A specific allocation for improvements allows product managers and designers to make strategic near-term investments that will pay off in the long run instead of always prioritizing shiny new features. All this ensures that customer-reported issues are addressed while fostering a sense of ownership over the product among engineers, promoting a more engaged team.

Other stakeholders benefit too. Finance can use the information for forecasting and reporting. Given competing priorities, sales and marketing can use this information to understand how much feature development they can expect.

In a smaller organization, conversations around impact and priorities can happen organically; in a larger one, whole departments might exist for each role, making communication more challenging. Having a standard language through the Balance Framework saves you the pain of unintended miscommunication and helps you align priorities between stakeholders.

Using the Balance Framework to improve effectiveness

You can use the Balance Framework to set organizational, team, or even individual intentions around how time gets spent, as well as to give business leaders the visibility they need to determine where engineering effort is going.

With the Balance Framework, you might set a goal for an organization to reduce its KTLO investment from 40% to 20% by the end of the year while maintaining or improving quality metrics. Specific teams can put an additional 20% of their efforts into productivity by addressing technical debt and implementing automation. Product (improving things and new things) will only get 40% investment until the KTLO burden diminishes; the product team buys faster feature delivery in the future by accepting slower feature delivery today.

This example highlights essential tensions in software engineering, mainly because you always have only 100% to spend. If the team previously spent 0% of their time on the productivity improvements category, then that 20% has to come from the other three categories. In this example, product work initially got 60% of the organization’s attention; dropping that to 40% will hurt a bit.

The main challenge of the Balance Framework is that it requires you to adopt a taxonomy when labeling work across your engineering processes so that you can associate each unit of work with a Balance Framework category. The easier you make it for engineers to label their work, the more likely you will get trustworthy data. You may want to adjust the exact classifications — for example, it may be helpful to differentiate productivity improvement work from feature improvement work — but try to keep it to just a handful of adjustments.

Once the data starts to flow, you can also begin to use it to set team and individual intentions. For example, you can identify whether one person on your team is doing all the KTLO. If so, it may become a team or individual priority to spread that burden more evenly.

What to do when you’re drowning in KTLO

If you’re dealing with a substantial amount of KTLO work, it’s a clear sign that something needs to change. KTLO tasks are those necessary to maintain the existing systems and processes, and while they are essential, excessive KTLO can limit a team’s ability to innovate and deliver new value.

You can employ a few approaches if a team is swamped with KTLO work.

• Prioritize and delegate. Not all KTLO work is equally important. The team should take time to evaluate their KTLO tasks and prioritize them based on their business impact. The low-priority, non-strategic tasks could be automated, outsourced, or temporarily ignored, allowing the team to focus on higher-impact tasks.
• Invest in automation. If a significant proportion of KTLO tasks are routine and repetitive, the team could invest in automation. This may involve using existing tools or developing custom solutions. Automating repetitive tasks can free up significant time, allowing the team to focus on more strategic work.
• Reduce technical debt. Too much KTLO work could be the result of substantial technical debt. For example, a codebase that’s full of one-off exceptions for individual customers can make any change risky; this variance should be managed via configuration, not code. Regularly allocating time to reduce technical debt — through refactoring, improving test coverage, updating documentation, etc. — can reduce the amount of KTLO work over time.
• Reconsider the product roadmap. If KTLO tasks are hindering progress, it might be time to revisit the product roadmap. Balancing new features and improvements against maintenance tasks is crucial to ensure the team can deliver on strategic objectives over the long term.
• Ask for more resources. If KTLO tasks are overwhelming and the strategies above aren’t enough, the team might need more help. This could mean hiring more team members, reallocating resources from other parts of the organization, or using third-party service providers.

When you’re inundated with KTLO, it can be tempting to take shortcuts or make hasty decisions to lighten the load. Victory will be fleeting if you choose tactics like working longer hours or taking solely a firefighting approach. Quick “fixes” often exacerbate the very issues they aim to solve, adding to technical debt and leading to burnout among software engineers.

Similarly, prioritizing new features at the expense of KTLO tasks, or hastily outsourcing these tasks without proper oversight, can create more problems down the line. The key to effectively managing KTLO work isn’t simply to eliminate KTLO tasks but to approach them strategically, keeping in mind their impact on long-term product goals and the well-being of the team.

Setting priorities

Every engineering organization, no matter its size, struggles with managing competing requests from stakeholders. It’s common to see an organization trying to decide among very different types of work. For example, finance wants engineering to cut cloud spend, product wants engineering to build things that drive customer value, and engineering wants engineering to pay down its technical debt.

With a poor prioritization strategy — or none at all — you end up with multiple competing high-priority goals. In the above scenario, if you choose to say yes to all three things, it’s entirely possible that none of them actually gets done because engineering’s finite time is split across three major projects when there is only room for one. Not only is this bad for the business, but it’s also painful for the engineers who are trying to do all the work. Quickly, you’ll see signs of:

• Priority fatigue/burnout. Engineers will no longer rally around top priorities even when needed since everything is a top priority. Instead, they just “do some work and go home.”
• Hiding work. Engineers will start hiding work from product management or including unnecessary work in product increments, e.g. “We can't do this one-week thing unless we spend two weeks refactoring the whole thing.”
• Withholding feedback on priorities. When engineers feel like prioritization is poor and nothing is changing, they often stop giving feedback. Leadership will only see the effects of poor prioritization on teams and struggle to understand the underlying issues that led to those effects.

Any one of these things can be poison to an effectiveness effort — they will make meeting the table stakes mentioned in Chapter 1 almost impossible.

Setting priorities is more than just ranking a list of tasks in order of importance. True priorities should highlight the areas where effort will have the most impact on the organization’s goals.

When something is a priority, that doesn’t necessarily mean that every engineer is continually engaged in working toward that priority. Rather, saying something is a priority implies a strategic alignment of choices, where team members, when presented with options, prioritize work that contributes to these key areas. When priorities are clear, the organization focuses on strategic outcomes while day-to-day operations continue without major disruption.

At every level of the business, priorities must be informed by product and business strategy. While empowered teams should be setting their own local priorities, these priorities must be informed by the product and business strategy — and vice versa. Effective prioritization requires knowledge and insights to flow in both directions, so team input should also inform priorities at the group, organization, and even business levels.

OKRs: A framework to communicate priorities

Priorities don’t matter much if they’re not communicated clearly. The Objectives and Key Results (OKR) framework, described by former Intel leader John Doerr in his book Measure What Matters, has emerged as a common tool for communicating priorities across an organization and tracking progress on those priorities. However, the effectiveness of this approach varies across different levels of the business and depends a lot on making sure that the overhead doesn’t outweigh the benefits.

We like to think of OKRs as a “high-five” standard; if we accomplish this, will the organization, group, or team have a moment when they all high-five each other (at least metaphorically)? OKRs should be achievable but ambitious. They should be based on outcomes, not a list of tasks to be completed or outputs to be created.

For example, consider a business objective to “hold the line on churn,” with key results of 95% net revenue retention across the customer base and 99% retention among the top 100 customers. Just like any good objective, it doesn’t tell you how to achieve these things — that falls to the teams and groups across the entire organization. It also doesn’t tell you who will do the work; efforts toward business-level objectives will often involve marketing, sales, product, and engineering (at least).

With this in mind, OKRs immediately present the challenge of managing cross-team and cross-organization work. We’ll discuss this challenge in more detail below, but at a high level, what we’ve seen work well is a system where the engineering organization also has OKRs, and those OKRs closely reflect company OKRs. Within an engineering organization, each objective and key result may be owned by a group or team.

So, in the above example, an engineering organization might set OKRs such as the following.

• Objective: Hold the line on churn
  • Reach five 9s of API uptime in a running 30-day window to address frequent user complaints.
  • Measure and improve ongoing engagement with users via messaging apps and emails.
  • Support a +20% YoY improvement in net revenue retention among the top 100 customers.

For some teams in the organization, these OKRs could directly intersect with their area of ownership, and they should prioritize their work accordingly. Still, OKRs should never create an all-hands-on-deck situation; part of using OKRs responsibly is accepting and explicitly acknowledging that they will never cover the full scope of work that should be happening.

A clever senior leader may share a list of OKRs but then declare, “Security is always our top priority” (or cost cutting, or KTLO, or something else that didn’t end up on the OKR list). Sometimes product and engineering will each come up with separate OKRs. If you have two lists of five top objectives, you have 10 top objectives. There must be one short list at the highest level, and everything on it should be material to the success of the business. Otherwise, every level below has to choose who to please and who to offend.

An efficient OKR process is marked by minimal overhead, with individual teams spending less than a week per quarter on OKR-related tasks. While the OKR approach does require aligning with other teams, the alignment process should not be about crafting a perfectly cascading plan across the organization but rather about ensuring that there is harmony in direction and purpose.

As you evaluate OKR progress, watch out for “watermelon status,” where the outward reporting of progress does not match the actual data, indicating a disconnect between perception and reality. Keep watch also for objectives that focus on an output or checklist vs. a specific business outcome.

OKRs must be part of a larger discussion involving investment balance and organizational design. Imposing an OKR process on a team that is under-resourced or misaligned with the company’s broader goals can lead to frustration and inefficiency. Your goal should be integrating OKRs into the organizational fabric, ensuring they complement and enhance the overall strategic direction and resource allocation without becoming a source of debilitating overhead.

At the business and organization level, OKRs excel in setting clear directions and establishing priorities. They are designed to focus on a few crucial objectives, ensuring a focused effort where it matters most. As discussed above, the key results associated with these objectives steer clear of dictating the how, focusing instead on what the achievements will look like upon completion.

Applying OKRs at the group level brings challenges, particularly in organizations where trust is low. There’s often a tendency to develop group-level OKRs that cover every team, lest some teams feel overlooked or undervalued. Furthermore, the very structure of some organizations can make it challenging to establish shared objectives that resonate across all teams.

Team-level OKRs

At the team level, OKRs are useful for communicating and aligning with leadership and other teams, leaving the details to the team to work out while creating visibility for leaders. Be careful, though: the practicality of OKRs at the team level can be outweighed if you’re spending too much time developing them.

Measurement paralysis is a frequent challenge, as a team spends time figuring out how to measure the impact of an issue rather than simply resolving it. Another challenge of OKRs at the team level is that they need to serve audiences up, out, and down. Coming up with language that accurately represents work to the team, its stakeholders, and its management chain can be (and can create) far more trouble than it’s worth.

Another shortcoming of OKRs is that the “ambitious but achievable” standard doesn’t work as well for KTLO work. The OKR framework described by Doerr excludes this kind of work, focusing only on new business objectives. When OKRs focus only on new work, a team or individual can end up in a situation where their extremely necessary KTLO work is undervalued.

OKRs also don’t include reactive work — the stuff that comes up that’s difficult to predict ahead of time. This could be anything from a security issue in a software library or a production incident to a last-minute request from a VP to gather some data.

Finally, don’t ask teams to create new OKRs every quarter or on any particular cadence. At the team level, a light and occasional refresh should be sufficient. Otherwise, team OKRs often become more like to-do lists than strategic objectives, providing little value as a communication tool. The time invested in developing and tracking these OKRs can be extensive, and the benefits might not always be proportional.

A note on OKRs for platform teams

Platform groups face a unique scenario when it comes to OKRs. These groups find OKRs most beneficial when the group thinks of itself as owning a product rather than just maintaining a set of services or capabilities.

For more service-oriented teams, OKRs can feel irrelevant because much of their work tends to be KTLO-shaped. Depending on their nature, platform teams may be a case where standard OKR practices don’t make much sense. Here and elsewhere, in the interest of empowered teams, listen closely to the team if it struggles to communicate its planned work this way.

Managing cross-team initiatives

One of the hardest prioritization challenges for a software company is cross-team projects. It’s rarely convenient for people across teams to suddenly work on the same thing at the same time, especially if the value of that work to the team’s users isn’t very clear. It’s imperative to keep people on the same page about the importance of the project and to understand project progress across teams.

Successfully and predictably leading complex, cross-cutting initiatives in a software engineering organization requires timely, accurate, trustworthy data about the work that’s being done toward completing the initiative. With that knowledge in hand, you can ensure that progress is made with a reasonable scope and a reasonable amount of engineering resources.

If things aren’t moving along as quickly as you’d hope, there are a few common culprits you can look for and address.

• Doing too many things at once. When teams try to handle too many tasks simultaneously, it leads to interruptions and context switching, drastically reducing productivity and focus. Team members become overwhelmed, leading to a decrease in work quality and delays in project timelines. Teams need to prioritize tasks, define specific focus areas, and implement work-in-progress limits. Advocate for realistic planning based on the team’s scope and obligations; leaders should limit the number of initiatives a team is expected to work on at any given time.
• Working on increments that are too large. Large increments can extend development cycles, reducing the team’s ability to adapt to changes and delaying feedback. This approach can also overwhelm the team and make it challenging to track progress. Teams should break down work into small increments — tasks that can be completed in one or two days. Smaller increments allow for quicker feedback, easier adjustments, and clearer demonstration of progress. Small increments are also proven to increase overall throughput.
• Relying on individuals vs. the team. When an initiative depends excessively on a single person, bottlenecks and delays arise when those individuals are overloaded or unavailable. This pattern also undermines team collaboration and knowledge sharing. Leaders at every level must encourage a team-oriented approach where knowledge and responsibilities are shared. Incorporate cross-training and collaborative work practices to ensure the team can make progress even when key individuals are absent.
• Failing to incorporate new information. When a team sticks too rigidly to a plan without adapting to new information or changing circumstances, you end up with outdated solutions and missed opportunities. Promote and cultivate a growth mindset, encouraging teams to revisit and revise plans as new information becomes available.
• Focusing on outputs over outcomes. When initiatives are evaluated solely on outputs (like the number of story points or features completed), it’s easy to lose sight of the actual goals of the initiative, such as improving user satisfaction or increasing sales. This misalignment can lead to inefficiencies and time spent on work that doesn’t contribute to the objective. Focus instead on the outcomes the project is trying to achieve. Set clear (preferably user/customer-centric) goals, and measure progress toward them to ensure that work aligns with the project’s desired outcome(s).
• Ignoring hidden work and KTLO work. Often, there’s significant work involved in maintaining existing systems that goes unnoticed or underestimated. Ignoring this aspect can strain resources and impact the delivery of new projects. Account for maintenance and operational work when planning initiatives and adjust your expectations as needed as the initiative proceeds.

What’s next?

In this chapter, we emphasized the strategic connection between software development and business objectives and highlighted the Balance Framework as a key tool for managing resource allocation across near-term and long-term goals. We also explored the evolution and role of different team types — product, platform, and special teams — in effectively handling organizational complexity and driving business outcomes. We looked at examples of tradeoffs in team design and organizational structure as well as tactics for prioritizing and managing cross-team efforts.

In the next two chapters, we’ll talk about developer productivity and developer experience — two sides of the same coin that are both essential to a successful, sustainable software development organization. Business outcomes will suffer in the long run without investment in both areas.

Further reading

• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. A foundational read for understanding the practices and capabilities that lead to high performance in software organizations.
• Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais. A practical guide for designing team structures in software organizations, aligning with the principles of effective teamwork and outcome orientation.
• Good Strategy Bad Strategy: The Difference and Why It Matters, by Richard Rumelt. An essential book for understanding the fundamentals of strategic planning and execution.
• Mindset: The New Psychology of Success, by Carol S. Dweck. Explores the concept of mindset, distinguishing between a fixed mindset (believing that abilities are static) and a growth mindset (believing that abilities can be developed through hard work and dedication). Dweck argues that adopting a growth mindset leads to greater success and fulfillment.
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford. A highly readable novel that provides insights into DevOps practices and the importance of collaboration between development and business.
• Measure What Matters, by John Doerr. Dig into the OKR framework with its creator.
• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, by Camille Fournier. A practical guide for engineering leaders, focusing on the challenges of managing technical teams and projects.
• Writing an Engineering Strategy, by Will Larson. Larson writes extensively on engineering leadership, team organization, and technology management, providing valuable insights for software development leaders.
• Choose Boring Technology, by Dan McKinley. This post advocates for the careful selection of technology in business and introduces the concept of innovation tokens, recommending that companies spend these sparingly and only on technologies that provide a significant advantage.
• A Framework for Balancing and Budgeting Engineering Resourcing, by Matt Eccleston. Discusses the importance of balancing different types of engineering investments to ensure long-term success and sustainability.