1. Introduction

There are plenty of origin stories for a company’s decision to invest in engineering effectiveness. Sometimes it’s a simple conversation among leaders: “Is it just me, or did we use to ship things faster?” Sometimes it’s driven by painful failure: “We missed most of our objectives last half, and product and engineering are pointing fingers at each other.” Sometimes it’s driven more by curiosity about an opportunity than an acute need: “I’ve heard of SPACE and DORA, and I think they could help us.”

There’s long been a hunger for better outcomes. Now, that comes with a suddenly urgent question: “How should we think about AI in the context of our engineering effectiveness?”

Each of these origin stories — and every other story that eventually leads a person like you to read a book like this — has a unique motivation. The way in which your leadership talks about the problem tells you a lot about the underlying issues you’ll find when you start digging. It’s relatively easy to try new things when you’re operating from curiosity, but it’s much harder when you’re under constraints and need answers fast.

Anyone who tells you there’s One True Way is lying. Each company takes its own path to arrive at the start of its effectiveness effort, and the path it follows after that will likewise be unique. There is plenty to learn from what others are doing, plenty we can standardize as an industry, and plenty you can discover from this book — but the way you improve your particular situation will be shaped by your organization’s size, age, culture, and capabilities.

How we approach effectiveness in this book

This book aims to collect the best practices of software product development, drawing on lean principles, modern product and project management, systems thinking, and much more. Much has been written on these individual topics across various books (see our recommended reading at the end of each of the following chapters), but here, we attempt to pull it all together into a coherent framework for running a software organization.

We like to think of effectiveness as the intersection of three concepts: business outcomes, developer productivity, and developer experience. Delivering business outcomes is the ultimate goal of any software organization. Once you know where you’re headed, developer productivity is about getting there quickly and at high quality. Developer experience is about creating an environment where engineers can do their best work — eliminating unnecessary friction, providing the right tools and platforms, reducing interruptions, and building a culture where people feel supported, satisfied, and engaged.

Many discussions of engineering effectiveness focus on just one of these concepts without recognizing that they are all intertwined. In this book, we look at each area individually and then discuss how to bring them together into a coherent and actionable plan for improvement.

Business outcomes

The core challenge of delivering a successful product is allocating finite resources to seemingly infinite problems and opportunities. The decisions involved here are difficult at any organization size, and they aren’t limited to software engineering — organizational design (among other factors) plays a huge role in how well a business can achieve its goals. There’s also a risk of trying to do too many things at once — even with the help of AI — with the inevitable result that few of them get done well, if at all. In larger organizations, these decisions often happen organically and implicitly, with fuzzy lines of accountability and no clear overarching picture of who’s spending time (and money) on what.

Developer productivity

Without intention and intervention, the pace of shipping value will naturally decline over time, and doing what has always worked won’t always keep working. Engineering leaders are increasingly held accountable for the value their organizations deliver — and they are increasingly at risk of people outside engineering deciding how to quantify this value. As your organization grows, your opportunities to drive improvement move from the team to the organization. The forces that hasten or hamper delivery become more varied and broadly distributed. Meanwhile, AI is radically rewriting the ways that work moves through an engineering organization, in ways we don’t yet fully understand.

Developer experience

Developer experience is arguably the other side of the developer productivity coin, and it can be hard to separate the two. Developer experience focuses on what it’s like to work within your organization and deliver its software: the tools you provide, the platforms engineers build on, the frequency and nature of interruptions, the quality of internal support, and the degree to which the codebase itself makes work harder than it needs to be. Developer experience efforts should encompass everything from eliminating unnecessary wait time to surveying engineers about their frustrations and — perhaps most critically — acting on what you hear.

Where you’re starting from

As you approach engineering effectiveness, bear in mind that every company is different, and it can be hard to predict exactly which approach will work for your organization. However, we’ve seen four distinct factors play a significant role in finding the right path.

Size shapes the nature of the work

In a small company, the work is mostly about getting team-level delivery right. Plenty of small companies do this well and ship fast — being small is an advantage here. But as you grow, the harder problems move up a level: now you have multiple teams solving the same problems in different ways, and a codebase that keeps expanding even when headcount doesn’t. Past a certain size (bigger than you are, probably, but smaller than you think), standardizing, automating, and speeding up development becomes a job in its own right — enough to warrant a dedicated team. The longer you wait to invest in that work, the more it piles up as debt that you’ll have to pay down later.

Age shapes your degrees of freedom

A company’s trajectory is shaped by what the tech world looked like when it was making pivotal tech decisions. The earlier those decisions took place, the less technology had been commodified — this is true for companies that started building in 2005, 2015, and 2025. The more time that has passed since those decisions, the more likely it is that they’ve been layered with alterations and customizations. A build-vs-buy debate doesn’t have an obvious winner when you’re dealing with bespoke systems; on the other hand, the earlier you add observability to your engineering workflows, the more likely you are to have that information when you need it, even as your company evolves.

Culture shapes the pace and permanence of change

Companies that highly value team autonomy will face different challenges than companies that have standardized on tooling and centralized processes. The depth of trust between leadership and individual contributors will influence how readily those individual contributors embrace productivity efforts, and the company’s engineering ladder will play a big part in who raises their hand to do the work.

Capabilities shape your ceiling

Even with the right size, a young-enough organization, and a healthy culture, missing foundational engineering capabilities will limit how far you can go. Does the organization have stable teams with clear ownership, or are individuals constantly shuffled across projects? Do services have clear boundaries that allow independent work, or is everything entangled? Is your CI/CD mature enough that teams can deploy independently? Can you measure the basics today — cycle time, deployment frequency, change failure rate? Is the codebase in a state where improvements are even trackable?

This matters more now than it used to. AI functions as an amplifier: organizations with strong foundations get faster and better, while organizations without them ship dysfunction at a higher velocity.

If your company has strong foundations in these areas, you’ll be able to adopt new practices, tooling, and technologies — and you’ll see results relatively quickly. If it’s missing these foundations, you must build them first, or risk gaining visibility into the dysfunction without the structural ability to fix it.

Measurement and goal-setting

Good measurement is one of the most valuable things you can build into an effectiveness effort, yet one of the easiest to get wrong. The desire for metrics can paralyze progress on well-known problems, and the wrong metrics can actively mislead. Done well, though, measurement gives you the ability to see where you are, track whether things are improving, and have honest conversations about what’s working and what’s not.

The Goals, Signals, and Metrics Method is a useful guide for measurement and goal-setting:

• Goals focus on outcomes, not the anticipated implementation.
• Signals are things that humans can watch for to know if you’re on track.
• Metrics are the actual things you measure and report on to track progress toward the goal.

In practice, you first agree that there’s a problem worth solving. Then you set a goal that, if achieved, would be clearly understood as progress. Next comes the “I know it when I see it” conversation — what statements, if true, would have everyone nodding that you’re moving in the right direction? These are your signals. Metrics come last (this is by design), and not all aspects of productivity can be measured conveniently, if at all. It’s okay if some of your ambitions are intangible: “Deploy issues shouldn’t dominate our next developer survey” is a perfectly reasonable goal.

Keep a few principles in mind as you use this framework:

First, don’t let the perfect metric block progress. Sometimes all you need to do is make sure no one thinks The Thing is a terrible idea, do The Thing, and check in with your users or stakeholders to see whether they noticed you did The Thing. Be prepared to advocate for and celebrate clear-if-unmeasurable wins.

Second, metrics can be difficult to interpret correctly and consistently. The space is full of lagging indicators and metrics biased by moments in time. Self-reported satisfaction scores, for example, can drop quickly and tend to recover slowly. How you slice your data matters too: an average metric might overemphasize outliers, while p50 can hide pathological cases at p99.

Third, there’s a fine balance between metrics that guide improvements and those that make people feel watched. This shouldn’t stop you from measuring, but it does mean being transparent with individual contributors about what you’re tracking and how it will be used. Make it easy for them to see the data they’re contributing.

Finally, these metrics work best as conversation starters and poorly as comparison tools — especially when context has changed, like a change in staffing or priorities. Meaningful differences in team skill sets, tenure, seniority, codebases, and complexity have to be considered in any head-to-head comparisons between teams.

When you start working toward a goal, establish a baseline first.

Over time, you’ll have enough information to set thresholds that actually mean something. Keep in mind, though, that quantitative data will sometimes disagree with the stories you’ve been told. It’s not a reason to distrust the data, or the stories, but it is usually the start of a useful conversation.

Table stakes

Any effectiveness effort becomes significantly easier if you adopt and embrace a few proven principles. These principles are so essential that we’ll revisit them throughout the rest of this book, whose guidance will be of limited use if you don’t also embrace or move toward embracing these principles in your organization. Indeed, if your engineering organization struggles to be effective, at least one of these principles is probably missing.

1. Empowered teams. When teams can make autonomous decisions about their work, organizations can respond more quickly to changes, improve motivation, and ship solutions more likely to meet customer needs. When they must rely on others to make progress, the effectiveness of their teams suffers.
2. Rapid feedback. Quick and frequent feedback allows for rapid learning and adjustments. This agility helps better align your product with market needs and customer expectations. When you have weeks-long feedback cycles, a lot can go wrong between check-ins.
3. Outcomes over output. Focus on the value and impact (outcomes) of engineering work rather than just the volume or efficiency of deliverables produced (output). This helps ensure that development efforts actually contribute to business goals and customer value.

Empowered teams

Empowering teams means delegating decision-making authority to those closest to the work. Providing your teams with the necessary context and trusting them to make informed decisions can improve both efficiency and motivation in a meaningful way.

Consider a scenario where a software development team regularly encounters delays due to a cumbersome and outdated deployment process. Instead of management dictating a specific solution, empowering the team would involve giving them the authority to research, propose, and implement a new deployment strategy. This could include choosing new deployment tools, redesigning the deployment pipeline, or adopting new practices like continuous deployment.

This approach recognizes that the team closest to the deployment process is best positioned to improve it. It also makes the team more invested in the outcome than a top-down mandate would. Allowing the team to experiment and take risks can lead to more innovative solutions, and it speeds up decision-making by eliminating multiple rounds of external approval.

This matters even more now that AI can handle a lot of task-level work. If a problem can be broken into smaller tasks and handed off, an AI agent might do that faster than a person could. What it can’t do is own an outcome: figure out what the right problem is, make tradeoffs, and care about the result — which is where empowered teams come in.

Note that this doesn’t mean all decisions should or will fall to individual teams; some decisions properly belong at the organization or even business level. An empowered team will feel confident in providing input and feedback on those decisions when they have it.

Rapid feedback

Rapid feedback means getting information early and often — through automated testing, continuous integration, code reviews, stakeholder check-ins, user feedback, and many other moments in the software development lifecycle where you need to decide whether to proceed or change course.

Delayed feedback leads to rework, wasted time, and missed opportunities. The goal is to solicit feedback regularly and frequently, rather than bundling up large chunks of work for one cumbersome mega-review at the end. Indeed, having these feedback processes already in place is a prerequisite for any real AI adoption in engineering, and AI can also be used to limit the need for certain human processes.

When a review or approval process is unavoidable, the best way to keep feedback rapid is to establish a regular cadence. Reviewing smaller batches means future work can be shaped by earlier feedback — and you’re far less likely to find out late that you’ve been heading in the wrong direction.

Outcomes over output

Goals and success measurements should be based on outcomes, like customer satisfaction or market share, rather than output, like the number of features released, bugs closed, or story points completed. Incentivizing teams based on output volume can steer them to invest in quantity over business impact.

When teams are aligned around business outcomes and measured on the results that matter, they’re more likely to find creative ways to solve problems while still driving the company forward.

The table below highlights key differences between the two approaches.

Aspect	Output-based approach	Outcome-based approach
Definition of success	The quantity of what is produced, such as features, documentation, or lines of code.	The impact on customer behavior and business results, such as improved customer satisfaction or increased sales.
Key metrics	Measures include the number of features deployed, code commit frequency, and deadlines met.	Measures include customer engagement metrics, conversion rates, market share, and revenue growth.
Development focus	Focus is on executing a predefined set of tasks and deliverables.	Focus is on validating hypotheses about customer needs and business value by delivering the smallest viable increment.
Feedback loop	Feedback is often related to whether the product is delivered on time and within budget.	Feedback is based on how well the product changes user behavior or improves key business metrics.
Decision-making	The progress of deliverables drives decisions according to the project timeline.	Decisions are driven by data and insights about what will move the needle on desired outcomes.
Approach to change	Changes are often viewed as a setback or a sign of planning failure.	Changes are viewed as opportunities to learn and pivot toward more impactful results.
Team alignment	Teams may work in silos, with each department focusing on their own set of deliverables.	Cross-functional teams work collaboratively, with a shared understanding that the goal is to achieve the desired outcomes.
Response to failure	When a feature or project does not meet the specifications or deadlines, it is considered a failure.	Failure is viewed as a learning opportunity that informs the next iteration and brings the team closer to achieving the outcomes.

What to expect from the rest of this book

So far, we’ve established why your effectiveness journey will be shaped by the size, age, culture, and capabilities of your organization. We’ve introduced the three pillars of effectiveness — business outcomes, developer productivity, and developer experience — and the table stakes that underpin them: empowered teams, rapid feedback, and outcomes over output. We’ve also walked through how to approach measurement, starting from goals and signals before arriving at metrics.

The next chapters take each of the three pillars in turn, sharing guidance that’s broadly applicable despite company differences. We’ll close with a chapter that offers a loose roadmap across all three areas for organization-wide improvements in effectiveness.

Let’s get to work.