2. Business outcomes

Effective software organizations focus their investments on the right outcomes.

Software organizations exist to deliver results, not just features. That means keeping quality high, systems stable, and users happy — all while making sure the work connects to what the business actually needs.

In this chapter, we’ll look at how to structure an engineering organization around business outcomes and how to set and communicate priorities clearly. Then we’ll tackle the question every engineering leader eventually faces — are we working on the right things? — and wrap up with some guidance on managing cross-team initiatives.

Organizing for outcomes

How you structure your organization shapes everything — what gets built, how fast, and whether the thing being built matches up with what customers need. Structure is rarely the first thing leaders reach for when something isn’t working, but it’s often the underlying reason why.

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. Dividing into teams lets an organization take on more complex problems while still delivering. And for the people on them, teams create something less tangible but just as important: a sense of belonging, shared purpose, and connection to the work.

At the same time, creating a team, by definition, creates a silo.

Silos get a bad reputation, but without some degree of siloing, everyone would have to pay attention to everything all the time, and things would undoubtedly fall through the cracks. With teams, we create focus and efficiency, even at the expense of more cross-team collaboration in some situations.

What makes a team viable

We agreed that empowered teams are a table stake for effectiveness in Chapter 1. But what does that look like, structurally?

A team is more than a group of people assigned to work together.

Roles and responsibilities are clear, but the lines between them aren’t rigid. Team members set the team’s goals together, weighing one another’s input along with that of stakeholders and dependent teams. Measuring success against those shared goals encourages genuine ownership and collaboration, rather than a workflow where roles hand work off to each other in sequence.

Perhaps most importantly, a team should be able to deliver value on its own. If a group can only create value in partnership with another group, they’re not a team — they’re half of one. Teams that can stand on their own tend to be more resilient and give their members more room to grow.

Tradeoffs in team design

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

• Outcomes. You need to align teams with the company’s investment priorities and important business metrics to make sure that you’re shipping the right work effectively.
• Features. Every product area needs clear ownership in the form of a team responsible for its development, bug fixes, and improvements.
• People. Healthy, productive teams include diverse viewpoints and skill sets, including those relating to software engineering, product management, and design.
• Architecture. The systems we create tend to mirror the organizational structure that created them, a pattern known as Conway’s Law. In other words, org design is software design.

When these areas are well-defined, they establish the boundaries of a team’s ownership and responsibilities. Creating strong 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 — iOS, say — warrants a team all its own.

Successful teams tend to include engineers with experience across the stack — people whose familiarity with various aspects of software development, from data to systems design to frontend to AI, 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 — let alone AI agents — 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

Building an engineering organization means understanding the different types of teams you’ll need — and the order in which to introduce them.

Start with product teams

Most engineering organizations start as a single product team. Product teams own and manage specific slices of your business domain, allowing them to operate with a high degree of autonomy and minimal dependencies. They make decisions and deliver features that directly impact 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, they expand and specialize — but product teams remain the most common type of team, no matter how big your organization gets.

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 probably don’t want six product teams solving the same hard problem in six different ways.

Some platform needs are common across almost all software companies: 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.

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, or 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 a double-digit percentage 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 (helping the rest of your organization with security, recruiting, onboarding, or any other necessary aspect); complex subsystem ownership (when a system is important enough to warrant continuous investment in a team that maintains it); temporary or project-based work (often formed to address specific challenges or objectives, and may be disbanded or reformed as goals are achieved or priorities change — be aware that they might leave behind code whose ownership is questionable); or objective-driven work (defined by specific objectives rather than a product or codebase boundary, such as a team focused on cross-cutting customer onboarding experience, where a significant portion of the work involves collaborating in areas owned by other teams).

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 will depend on the stage of the company, your stakeholders, and a dozen other factors. The important thing is to make these decisions deliberately rather than let them happen by default.

• Autonomy vs. coordination. Autonomy encourages innovation and lets teams move fast. But too much of it leads to inconsistent practices and makes it hard to integrate work across teams. Coordination keeps everyone pointed in the same direction, but too much of it can slow decision-making and chip away at team ownership.

• Specialists vs. generalists. Specialists are invaluable for complex, niche problems, but a team made up entirely of specialists tends to struggle with flexibility and cross-functional work. Generalists can work across domains and fill gaps — most healthy teams need both.

• Short-term delivery vs. long-term sustainability. There are legitimate business reasons to prioritize short-term delivery: quick market gains, customer satisfaction, hitting a window. But it usually comes at the cost of technical debt.

  Investing in sustainability keeps the platform healthy but slows down what’s shipping now.

  Most organizations end up somewhere in the middle, whether they planned to or not.

• New features vs. maintenance. New features keep the product competitive, but neglecting existing ones — letting reliability slip, leaving rough edges unaddressed — erodes the customer satisfaction that made those features worth building in the first place.

• Large vs. small teams. Small teams move fast and tend to communicate well. Large teams can take on bigger, more complex work, but often struggle with agility and internal communication. The right answer usually depends on what the team owns and how much coordination the work requires.

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 drive 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 in 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 sets you up for different kinds of struggles and failures. They tend to fall into two broad categories: structural choices that create coordination overhead, and incentive or accountability failures that diffuse ownership.

Structural antipatterns

• Frontend and backend teams. Most customer-facing features require both frontend and backend work. Dividing teams along these lines creates gaps in collaboration, understanding, and ownership — and typically ends in competing prioritization decisions that nobody wins.
• 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. Does AI change these rules? Realistically, you still need a certain number of people on a team to own its runtime responsibilities through vacations, illness, and other absences. AI will hopefully put an end to teams of 20, but teams of five to seven are still viable — though the seniority mix is likely changing.
• Lack of clear areas of ownership. When there’s ambiguity about who owns specific parts of the product or codebase, those areas tend to get neglected. Maintenance slips, quality assurance falls through the cracks, and when something breaks, nobody’s quite sure whose problem it is.
• Victims of Conway’s Law. Teams structured around an existing (often legacy) system architecture rather than around customer value streams or product capabilities. The org chart calcifies a technical structure that may no longer make sense, and reorganizing becomes impossible without a rewrite.
• Engineering teams embedded in business units. Engineers reporting into non-engineering functions who build critical systems outside the main engineering organization’s visibility, standards, or operational support. This works fine until the code becomes load-bearing infrastructure and the original builder leaves. AI has made this pattern more enticing, since it’s now easy for almost anyone in a business unit to produce something that looks like working software. But what gets built this way often lacks the engineering rigor to survive production, and the medium- and long-term costs of maintaining, scaling, or replacing it aren’t always considered thoroughly enough.

Incentive and accountability antipatterns

• Delivery teams. These are teams solely responsible for delivering work specified by people outside the team. They are usually staffed long term, but there’s minimal opportunity for the team to coalesce around a shared purpose. Without that context, they tend to ship things that are technically sound but miss what users actually need or the business requires.
• Project teams. These are “teams” that form solely to deliver a project before they disband, only for the team members to be thrown back into a pool of resources that will be reallocated later. They are ticket-takers, doing work they don’t understand; there is no opportunity for customer connection, long-term cohesion, or process maturation.
• Platform teams without customers. Internal platform teams that build tooling or infrastructure without treating other engineering teams as genuine customers. They ship what they think is needed rather than what would truly reduce friction, often resulting in beautiful systems that nobody uses while teams route around them with workarounds.
• Tollbooth teams. A single team responsible for cross-cutting concerns like authentication, payments, or data infrastructure that becomes a blocking dependency for every other team. Every feature requires a ticket in their queue, and their prioritization decisions effectively control the entire organization’s roadmap.
• The fixers. A team whose purpose is to clean up after other teams — handling production incidents, fixing bugs, managing technical debt. This creates a moral hazard, where delivery teams have no incentive to build maintainable systems and the fixers never escape their Sisyphean backlog.

Teams are a strategic investment

The shift from thinking of teams as task executors to thinking of them as strategic investments follows directly from the outcomes-over-output principle in Chapter 1.

High-performing teams are an exception, not the rule. They don’t just happen.

Investing in teams means more than giving them work to do. It means creating space for learning, building a culture where collaboration and ownership are honest rather than performative, and making sure teams have what they need — the right tools, the right people, and enough of both.

The team, not the individual, is the fundamental unit of an engineering organization — and the most powerful place to focus your improvement efforts. How you shape teams and the broader organization has an enormous influence on how effectively work gets done.

Recognizing when your org design isn’t working

Organizational design problems don’t always announce themselves clearly. They tend to surface as symptoms that are easy to misattribute — blaming individuals, tools, or “the process” when the underlying issue is structural. Watch for these signals:

• Teams that can’t ship without another team’s involvement are a sign that ownership boundaries don’t align with the work that needs to get done. If the same cross-team dependency keeps appearing sprint after sprint, the team boundary is probably in the wrong place.
• Persistent ownership gaps — the same areas of the codebase or product that keep surfacing in incident reviews, or areas where nobody feels responsible for quality — suggest that your team structure has left meaningful seams unowned.
• Teams in which most work is reactive rather than planned often indicate that the team’s scope is too broad, or that the systems they own weren’t built to be maintained by a team of their size.
• High rates of context switching, where engineers are frequently pulled into work outside their team’s stated focus, can signal that the team’s boundaries don’t match the actual dependencies in the codebase or the product.

None of these signals mean you should reorganize immediately — reorganizations are expensive and disruptive. But they should prompt honest conversations about whether the current structure is helping or hindering the work.

Roles and reporting lines

As organizations grow, 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 are usually expected to take projects from start to finish so that leaders can focus more on team dynamics and strategic planning. Their leadership comes from being a force multiplier for the team — guiding and mentoring others, raising the quality bar, and helping the team gel.
• 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. They influence technical strategy, align it with business goals, and mentor other engineers.
• Line engineering managers make sure the team has what it needs and coordinate with other teams. Through one-on-ones and regular coaching conversations, they support career progression while often still providing technical guidance.
• Senior managers, directors, VPs, and CTOs fill roles that vary greatly by company stage and size, but they share responsibility for headcount, budget planning, organization design, cross-team alignment, and strategic direction. A major challenge for people in these roles is to stay connected to the realities of day-to-day software engineering work.
• Product roles — product managers and product designers assigned to individual teams — also have a tremendous influence on an effectiveness effort, even though they often report separately from engineering roles.

Setting priorities for your organization

Finance wants engineering to cut spend, product wants engineering to build things that drive customer value, and engineering wants to pay down its technical debt. If you choose to say yes to all three things, it’s entirely possible that none of them get 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.

With a poor prioritization strategy — or none at all — you end up with multiple competing high-priority goals. Quickly, you’ll see signs of trouble:

• Priority fatigue and 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 — for example, “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 ranking a list of tasks. When something is a priority, that doesn’t mean every engineer drops everything to work on it. It means that when team members face choices, they default to work that contributes to those key areas. Day-to-day operations keep running — priorities just shape where discretionary effort goes.

Priorities at every level should be informed by product and business strategy, but the flow goes both ways. Empowered teams set their own local priorities within that context, and their input should also shape priorities at the group, organization, and business levels.

OKRs: A framework for communicating 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 become one of the most common ways to do that. How well it works, though, varies a lot depending on where in the organization you’re applying it and whether the overhead is worth it.

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).

We’ll discuss this challenge in more detail below, but at a high level, what we’ve seen work well is a system in which the engineering organization also has OKRs, and those OKRs closely reflect the company’s 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 maintenance work, 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.

A well-run OKR process is marked by minimal overhead — individual teams should spend less than a week per quarter on OKR-related work. Aligning with other teams is necessary, but the goal isn’t a perfectly cascading plan. It’s making sure everyone is broadly pointed in the same direction.

Recognizing healthy and unhealthy OKR usage

As you evaluate OKR progress, watch out for “watermelon status” — green on the outside, red on the inside, where reported progress doesn’t match what the data shows. Keep watch also for objectives that focus on an output or checklist vs. a specific business outcome.

Beyond watermelon status, a few reliable signals can tell you whether your OKR process is creating value or just creating overhead.

Key results change behavior — teams make different tradeoff decisions than they would have without the OKR. Progress reviews surface genuine surprises rather than just confirming what everyone already knew. And when a key result isn’t moving, the conversation naturally turns to “what should we do differently?” rather than “how do we explain this?”

Unhealthy OKR usage looks different: OKRs are written at the start of the quarter and never referenced again. Key results are actually task lists disguised as outcomes — “ship feature X” rather than “improve metric Y.” Teams report green on OKRs while stakeholders report dissatisfaction with progress. And the quarterly OKR process takes more than a week for any team, with more energy spent on writing the OKRs than on achieving them.

OKRs need to be part of a larger conversation about how engineering effort is distributed — something we’ll cover in the next section. Imposing an OKR process on a team that’s under-resourced or pointed in the wrong direction just creates frustration. The goal is for OKRs to fit naturally into how your organization already works, not to become a source of overhead that outweighs any benefit.

OKRs at the business and organization level

At the business and organization level, OKRs excel in setting clear directions and establishing priorities. They are designed to focus on a few objectives, ensuring a focused effort where it matters most. 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 gets trickier, particularly where trust is low. There’s a tendency to develop group-level OKRs that cover every team — partly to avoid anyone feeling left out — which quickly leads to a list that’s too long to be useful. Some org structures also make it hard to find objectives that feel relevant to all the teams underneath them.

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 — when a team spends time figuring out how to measure the impact of an issue rather than simply resolving it — is a common challenge. 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 Keeping The Lights On (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.

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.

Are we working on the right things?

Even with clear priorities, you still face the question of whether your organization’s actual effort reflects them. Every engineering organization has a finite budget of time, and every choice about where to spend it is implicitly a choice about where not to.

This question — are we working on the right things? — is deceptively hard to answer, partly because it requires you to first answer a more basic one: what are we actually working on? In many organizations, the answer is surprisingly murky. Engineering thinks it’s spending most of its time on new features; product thinks engineering is always tied up in maintenance; leadership assumes there’s slack that could be reallocated. Without a shared picture of where effort is going, these perceptions harden into competing narratives, and resourcing conversations become political rather than strategic.

You need a way to categorize the work your organization does so that everyone — engineering, product, and senior leadership — can look at the same picture and have a productive conversation about whether the current allocation is the right one.

In 2020, Matt Eccleston, a former Dropbox VP of Engineering, spelled out a framework for doing exactly this. Our adaptation is what we call the Balance Framework. It categorizes an engineering organization’s work into four areas:

New things. Developing new features, products, or services — innovation, new market opportunities, and expanded product offerings.

Improving things. Enhancing current features, services, tools, and business processes — optimizing for better user experience, revamping a service for improved performance.

Keeping the lights on (KTLO). Keeping existing systems running effectively and efficiently — 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.

The power of this categorization isn’t in the categories themselves — you could adjust or rename them for your context. The power is in having a shared vocabulary that makes investment conversations concrete rather than abstract. When someone says “we need to spend more time on new features,” the natural follow-up becomes “where does that time come from?” rather than a vague agreement that evaporates by the next sprint.

Investing too heavily in any one category leads to predictable problems. Too much focus on new things at the expense of KTLO results in system instability and a growing pile of technical debt that starts slowing everything down. Excessive focus on KTLO means fewer new things and improvements, leading to a stagnating product and missed opportunities. A healthy blend tends to include at least 10% for productivity work and between 10% and 30% for KTLO work — the rest depends on your business and where the product is headed.

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 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.

Getting everyone looking at the same picture

The categories give engineers a clearer picture of where their work fits and make it easier to make the case for productivity work that often gets overlooked. 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 and the teams keep a sense of ownership over the product.

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

In a smaller organization, conversations about impact and priorities happen organically. In a larger one, whole departments might exist for each role, and miscommunication becomes the default. A shared vocabulary for how engineering effort is distributed helps everyone stay on the same page.

From visibility to intentional investment

Once you can see where effort is going, you can start making deliberate decisions about where it should go — at the organizational level, the team level, or both.

For example, 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 a core constraint 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 new 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 is that it requires consistent labeling — every work item needs a category. The easier you make that for engineers, the more trustworthy the data will be. You can adjust the classifications to fit your context, but try to keep changes minimal. The more categories you add, the harder it becomes to maintain.

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.

How to know your investment balance is shifting

A few practices will help you get value from the effort.

Review investment balance at a regular cadence — quarterly is typical at the organization level, monthly or per-sprint at the team level. The goal of the review should be to spot trends. If you set an intention to shift 20% of effort from KTLO to productivity work, you should be able to see that shift materialize over a quarter or two. If you can’t, it’s worth asking whether the taxonomy is being applied consistently, whether the underlying work is genuinely resistant to rebalancing, or whether teams are labeling work in one category while the actual effort belongs in another.

Watch for second-order effects. If you reduce KTLO investment, are quality metrics holding steady or declining? Are incident counts rising? A healthy rebalancing means the KTLO work that remains is more targeted and strategic, not that you’re deferring problems. Conversely, if you increase productivity investment, you should eventually see its effects in the other categories — faster feature delivery, less time spent on KTLO, or both.

Be honest about what the data is telling you. If a team’s actual investment balance has barely moved despite a stated intention to change it, the most likely explanation is that the work itself is demanding the current allocation. That’s valuable information. It may mean the team’s systems need deeper investment before the balance can shift, or it may reveal a dependency on another team that’s forcing reactive work.

What to do when you’re drowning in KTLO

A persistent KTLO allocation above 30% is usually a sign that something structural needs to change. A few approaches can help — and this is one area where AI tooling, used carefully, can make a good dent.

Reduce technical debt. Too much KTLO often traces back to debt. A codebase full of one-off exceptions for individual customers makes every change risky — and that variance belongs in configuration, not code. Allocating regular time to refactor, improve test coverage, and update documentation reduces the KTLO load over time. This is also where agents are genuinely useful: overdue dependency upgrades, framework migrations, backfilling tests for untested code, and generating the documentation nobody got around to writing are all well-bound, low-ambiguity tasks that an agent can take a first pass at. The work still needs review, but the cost of starting drops to near zero.

Automate the routine. When KTLO tasks are repetitive, automating them frees up time for work that needs human judgment. Some of this is classic scripting; increasingly, some of it is work you can hand to an agent. If a chore is predictable enough to document, it’s often predictable enough to delegate.

Reconsider the roadmap. If maintenance keeps losing to new features, the roadmap itself may be the problem. Protecting time for maintenance keeps the product deliverable.

A word of caution, the same caution that runs through this book: AI isn’t a holy grail, and it’s not your easy ticket out.

You need tests you trust, small changes, and a review process that catches problems — so you can tell whether an agent’s work is safe to ship. If those are missing, paying down enough debt to put them in place is the higher priority.

The other tempting responses — having engineers work longer hours, chaotic firefighting, outsourcing in a hurry, or shipping features while the debt piles up — defer the reckoning rather than resolve it, and most of them add to the debt.

You can’t eliminate KTLO, but you can keep it at a manageable level without it crowding out everything else.

Managing cross-team initiatives

Well-designed organizations minimize cross-team initiatives, but they can’t eliminate them entirely.

Cross-team initiatives fail in ways that single-team projects don’t. The work itself might be straightforward, but the coordination overhead, misaligned incentives, and diffuse ownership create failure modes that no amount of individual team excellence can solve.

Establish clear ownership at the initiative level. When everyone is responsible, no one is responsible. Cross-team initiatives need a single accountable owner — a product manager, a tech lead, or a program manager — who has the authority to make tradeoffs, escalate blockers, and keep the work moving. This person may not be doing the work themselves, but they’re the one who loses sleep when it stalls.

Align incentives before you align calendars. Teams prioritize what they’re measured on. If Team A is measured on shipping their roadmap and Team B is measured on platform stability, your cross-team initiative that requires both teams to drop everything will fail — not because people are uncooperative, but because you’re asking them to work against their own goals. Before kicking off the work, make sure each team’s leadership has explicitly committed to the initiative and adjusted expectations accordingly.

Make dependencies explicit and visible. Most cross-team delays happen at handoff points: Team A is waiting on Team B, but Team B didn’t realize they were blocking anyone. Map out dependencies early. Make them visible to everyone involved, and check on them regularly. Dependencies may be unavoidable, but they should never be a surprise.

Create shared context, not just shared deadlines. Teams that understand why an initiative matters and how their piece fits into the whole make better local decisions than teams that are just executing tickets. Invest in the upfront alignment work: a shared kickoff, a clear problem statement, a picture of what success looks like. This pays off every time someone has to make a judgment call without checking with the other teams first.

Shorten feedback loops across team boundaries. Within a team, you find out quickly when something isn’t working or when someone is working on the wrong things. Across teams, problems can fester for weeks before anyone notices without regular integration points. Demo early and often, and make it easy for teams to raise concerns before small misalignments become expensive rework.

Watch for the slow drift of competing priorities. Cross-team initiatives often start strong and then gradually lose momentum as each team’s local priorities reassert themselves. The initiative never officially gets deprioritized; it just stops moving. Combat this with regular check-ins at the leadership level, not just the IC level, and be willing to explicitly re-up commitments when energy starts to flag.

Account for operational and maintenance overhead. Cross-team initiatives often focus so heavily on the deliverable that they ignore the operational burden it creates. If a new cross-cutting feature requires ongoing monitoring, incident response, or maintenance, decide early which team owns that work — otherwise, nobody will.

Knowing whether cross-team initiatives are succeeding

The chapter’s central argument is that outcomes matter more than activity — a principle that applies to cross-team work as much as it does to product development. It’s easy to mistake motion for progress on cross-team initiatives — tickets are moving, meetings are happening, status reports are green — while the actual outcome remains distant or unclear.

Evaluate these cross-team initiatives the same way you’d evaluate any other investment: against the outcome they were meant to achieve, not the tasks they were meant to complete. If a cross-team migration was supposed to reduce deployment times, measure deployment times. If a cross-team effort was supposed to improve onboarding conversion, measure conversion.

It’s also a good idea to periodically ask whether the initiative is still the right investment. Cross-team work is expensive — not just in engineering time, but in coordination overhead and the opportunity cost of what those teams aren’t doing. An initiative that made sense three months ago may no longer be the best use of multiple teams’ time if priorities have shifted. The willingness to wind down a cross-team effort that’s no longer serving the business is a sign of organizational maturity, not failure.

What’s next?

This chapter covered a lot of ground. We looked at how to structure an engineering organization around business outcomes — starting with how teams manage complexity and the tradeoffs in designing them. We got into priority-setting and what OKRs can and can’t do at different organizational levels. The Balance Framework gave us a way to make investment conversations concrete, including how to spot and address a KTLO problem. And we finished with cross-team initiatives: how to run them well and how to tell whether they’re delivering what you hoped.

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.

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.
• Balancing Engineering Investments, by Matt Eccleston. Discusses the importance of balancing different types of engineering investments to ensure long-term success and sustainability.