Engineering Priorities for 2025: What to Build, What to Fix, What to Stop

TL;DR. Every planning cycle has a gravity problem: last year's investments pull disproportionate budget into this year regardless of return. The four DORA metrics — deployment frequency, lead time, change failure rate, mean time to restore — tell you which single constraint to address. The plan that focuses all investment on the most constrained metric produces more improvement than the plan that spreads investment across twelve initiatives.

Every planning cycle has a gravity problem. The things that worked last year pull disproportionate investment into the next year, regardless of whether they are still the highest-return activities. The new initiatives that should get investment get squeezed by the continuation of what already exists. And the honest conversation about what to stop doing gets deferred because stopping something requires acknowledging that past investment did not produce the expected return.

This is a planning failure, not an engineering failure. And the way to address it is to start the year with a harder question than "what should we do next?" The more useful question is "what should we stop doing so we can do the right things?"

What high-performing teams prioritize — and it is not exciting

The DORA research, the Google DevX studies, and the patterns I see in the engineering organizations I work with point to a consistent set of priorities for teams trying to move from average to high-performing delivery. They are not exciting. They are effective.

Deployment automation and reliability is the highest-leverage investment for organizations below the DORA high performer threshold. Teams that deploy manually or with significant human coordination overhead are spending engineering capacity on process that should be infrastructure. Every hour an engineer spends managing a deployment, coordinating with other teams, running manual smoke tests, or executing a rollback procedure by hand is an hour not spent building. The investment to fully automate deployment processes pays back within a few months and continues paying back indefinitely, because the benefit compounds across every deployment for the life of the service.

The 2025 DORA data shows that elite performers deploy on demand, multiple times per day per service. Medium performers deploy between once per week and once per month. The difference in lead time between these groups is dramatic: elite performers have lead times measured in hours. Medium performers have lead times measured in weeks. That difference in speed translates directly to competitive advantage: the ability to respond to market changes, customer feedback, and emerging issues with dramatically greater velocity.

Test infrastructure quality matters more than test coverage metrics. A test suite that has 80 percent coverage but is slow and flaky is worse than a test suite with 60 percent coverage that runs in 8 minutes and is reliable. Flaky tests destroy developer trust in the testing infrastructure, which leads engineers to ignore test failures, which makes the tests worthless as a safety net. Fixing flaky tests is unglamorous work with high returns that compounds over time: every flaky test fixed reduces the noise in the CI environment and increases the signal value of the tests that remain.

The investment in test infrastructure quality should focus on three things: identifying and fixing the tests responsible for most of the flakiness, improving the parallel execution architecture so that the overall suite runs faster, and establishing standards for new tests that prevent the re-accumulation of the problems being fixed. Without the third element, the other two investments decay.

Observability investment is often deferred until after a significant incident, which is approximately the worst time to make it. A service that does not have structured logging, meaningful health checks, and basic performance metrics is a service that will eventually produce an incident that takes far too long to resolve because the diagnostic information does not exist. The investment in observability is most valuable before you need it, because the data it produces also serves purposes beyond incident response: understanding system behavior, capacity planning, and demonstrating the impact of performance improvements.

Stopping things is the planning conversation nobody wants to have

Most engineering organizations have initiatives that have been running for more than a year without clear evidence of value. These typically survive not because they are high-priority but because stopping them requires a deliberate decision that nobody has made. The default is continuation, even when continuation means spending engineering capacity on work that is not producing return.

The common categories that deserve evaluation: integrations that seemed strategically important but that nobody is actively using. Refactor projects that are partially complete and have been "in progress" for multiple quarters without a clear completion path. Internal tools built for a use case that has evolved and no longer matches what was built. Process improvements that were implemented but that did not change behavior in practice because the underlying workflow incentives were not addressed. Monitoring for metrics that nobody reviews.

Getting specific about what to stop is one of the hardest conversations in engineering leadership because it requires acknowledging that past investments did not produce the expected returns. The engineering leaders who handle this well frame it as a learning exercise rather than a failure acknowledgment. "We learned that this integration approach does not fit our workflow. We are stopping it and investing the capacity elsewhere" is a statement that builds trust by demonstrating honest evaluation.

Carrying failed investments forward is an ongoing cost, both in maintenance and in the organizational ambiguity they create. "We are still working on the X refactor" loses credibility over time and creates uncertainty about what the team is actually prioritizing. "We stopped the X refactor because Y, and here is what we are doing instead" is a statement that demonstrates strategic clarity.

Measurement before investment — the principle most engineering plans violate

The biggest mistake in engineering planning is making investment decisions without a baseline measurement of the current state. The teams that improve the fastest are not the ones with the most interesting plan. They are the ones that started with the clearest picture of where they were.

DORA metrics provide the most useful baseline because they measure the outcomes that matter rather than the activities that produce them. Deployment frequency tells you how fast the team can deliver changes. Lead time tells you how much latency exists in the delivery process. Change failure rate tells you how much quality control exists before changes reach production. Mean time to restore tells you how quickly the team can recover when something goes wrong.

These four metrics, measured honestly and tracked over time, reveal the highest-leverage areas for investment more clearly than any planning exercise. If deployment frequency is low, the bottleneck is in the deployment process. If lead time is high but deployment frequency is adequate, the bottleneck is earlier in the process, likely in code review or testing. If change failure rate is high, the bottleneck is in test coverage or deployment automation quality. If mean time to restore is high, the bottleneck is in observability or runbook quality.

The specific investment prescribed by each constraint is different, which is why investing without the measurement tends to produce investments that address the wrong constraint. Teams that invest in monitoring when the actual bottleneck is deployment automation, or invest in deployment automation when the actual bottleneck is flaky tests, produce less improvement per investment dollar than teams that identify the correct constraint first.

The highest-leverage investment is infrastructure, not features

The biggest leverage point for most engineering organizations is not a specific technology or tool. It is the investment in engineering infrastructure: the CI/CD pipelines, the observability stack, the developer environment consistency, and the platform abstractions that reduce cognitive overhead.

These investments are consistently underfunded because they do not appear on the product roadmap and their benefits are diffuse rather than attributable to any specific feature or quarter. The product manager cannot point to improved deployment automation as a feature that customers requested. The executive sponsor cannot easily communicate the value of better test infrastructure in a board presentation.

But the data on engineering performance is clear. The organizations with the best delivery metrics have made consistent infrastructure investments over time. The high-performing organizations in the DORA data are not lucky. They are the result of deliberate investment in the conditions that make high performance possible.

The plan that actually works focuses on one constraint at a time

The engineering planning process that produces the best outcomes follows a consistent structure. It starts with a measurement of the current state across the four DORA metrics. It identifies the single most constrained metric and designs a set of investments specifically targeted at that constraint. It explicitly sets aside capacity for infrastructure investment that is protected from feature delivery pressure. And it establishes a measurement cadence that will reveal whether the investments are producing the expected improvement.

The plan that fails is the one that lists every initiative that seemed valuable in last year's retrospective and assigns each one a quarter. This plan looks thorough and produces a spreadsheet that leadership can review. It does not produce a consistent focus on the highest-leverage constraint, which means the investments are distributed across many areas rather than concentrated on the one that matters most.

The teams that will be in a materially stronger position in December than they are in January are the teams that started the year with a clear diagnosis rather than a list of initiatives. The diagnosis is not complicated. It is four numbers: deployment frequency, lead time, change failure rate, and mean time to restore. The number that is most constrained tells you where to invest.

Engineering leaders need to build the investment case in business terms, not engineering terms

Engineering leaders who want to make infrastructure investments need to build the case for them in business terms, not engineering terms. The board and executive team do not need to understand deployment automation. They need to understand the business impact of the current deployment frequency and what the improvement would mean for product velocity.

The framing that works: "Our current deployment frequency means that a feature takes an average of three weeks from development complete to reaching customers. Our competitors are shipping in two to three days. Reducing our lead time to this level requires X investment and would produce Y improvement in our ability to respond to customer feedback and competitive pressure."

This framing connects the technical investment to the business outcome that matters to leadership. It requires the engineering leader to do the work of measuring the current state accurately and modeling the expected improvement credibly. But the investment in building this case is an investment in the organization's ability to prioritize engineering infrastructure over time, which pays back many times over.

Talent strategy belongs in planning season, not mid-year when the gap is already visible

Engineering planning cycles that focus exclusively on technical investments miss an important dimension: the talent strategy. Who the team is at the end of the year determines what is possible to build, and that strategy needs to be as deliberately planned as the technical roadmap.

The talent strategy questions worth answering explicitly at the beginning of a planning cycle: What skills does the team currently lack that will be critical for the year's objectives? What roles, if unfilled, represent the most risk to the plan? What engineers are most at risk of attrition, and what would retain them? What growth opportunities can the organization provide that would make it the most attractive employer for the engineers it most wants to hire?

These questions are rarely addressed in the same planning context as technical roadmaps, which is why organizations frequently find themselves six months into a technical plan with a skills gap that makes the plan slower than expected to execute.

The most effective approach is to treat the talent strategy as a constraint on the technical plan. If the plan requires capabilities the team does not have and cannot hire in the first quarter, the plan needs to account for that constraint either through adjusted scope, deferred milestones, or an accelerated hiring plan with realistic timeline expectations.

The baseline measurement is the most impactful prep action before planning season

The single most impactful preparation action an engineering team can take before planning season is to establish an honest measurement baseline across the DORA metrics. Not because the numbers will be impressive to share, though for high-performing organizations they sometimes are, but because without the baseline the plan is built on intuition rather than evidence.

The planning conversation changes when it is anchored to specific numbers. "We want to improve our deployment frequency" is a direction. "Our deployment frequency is 4 times per month, which places us in the low performer band on DORA benchmarks, and we want to reach 40 times per month by Q4" is a plan. The first version of that conversation cannot be held to account. The second one can.

Measurement creates commitment and commitment enables accountability. The engineering organizations that consistently improve year over year are not those with the most talented engineers. They are those with the most honest relationship with where they are and the most specific plans for where they are going. That honesty starts with measuring the right things and reporting them accurately before the planning conversation begins.

Annual planning is the right time to ask whether the team structure still fits

Annual planning is the appropriate time to ask whether the team structure that worked at the beginning of the previous year is still the right structure for the next year's objectives. Team topologies that were appropriate at 30 engineers may produce coordination overhead at 50. Stream-aligned teams that were effective when the product was simpler may need platform team support as the infrastructure complexity has grown.

The specific structural questions worth addressing in planning: are there coordination bottlenecks between teams that a team topology change would reduce? Does the platform team have the capacity to effectively serve all the stream-aligned teams that depend on it? Are there enabling team functions, coaching, technical standards, tooling improvements, that are currently being performed by no one because no team is explicitly responsible for them?

These structural questions are easier to address at the beginning of a year than in the middle of one. Mid-year structural changes, even when clearly necessary, create disruption and uncertainty that affects delivery for longer than the same changes made during a planned transition.

The Q1 investment with the highest full-year return is documentation infrastructure

The specific engineering investment with the highest return when made in Q1 and the lowest return when made in Q4 is documentation infrastructure: the combination of ADR practices, runbook quality standards, and on-call ownership documentation that prevents institutional knowledge from being locked in individual engineers' heads.

The reason timing matters is that documentation quality compounds over the year. A team that establishes clear ADR practices in January has eight months of architectural decisions documented before the year-end planning cycle. A team that starts in September has two months. The difference in knowledge capital at year-end is substantial, and it pays forward into the next year's onboarding, architectural decision quality, and incident response effectiveness.

The investment is modest: two to four hours of engineering time per significant architectural decision, and one to two hours per major runbook addition. The discipline to make this investment consistently is harder than the time suggests, because it requires treating documentation as a first-class engineering deliverable rather than as an optional afterthought. Teams that have established this discipline in Q1 tend to maintain it through the year. Teams that try to establish it in Q4 tend to find that the year-end pressure prevents the habit from taking root.

Frequently asked questions

What is the most common engineering planning mistake?

Making investment decisions without a baseline measurement of the current state. The teams that improve fastest start with the clearest picture of where they are — four DORA numbers — then design investments targeting the single most constrained metric. Teams that produce a list of initiatives without this diagnosis distribute investments across many areas rather than concentrating on the one that matters most.

How do I get executive support for infrastructure investment instead of features?

Connect the investment to business outcomes in revenue terms. "Our deployment frequency means features take three weeks from development complete to customer delivery. Reducing lead time to three days requires X investment and would produce Y improvement in our ability to respond to customer feedback." That framing is defensible in a board conversation in a way that "technical debt reduction" is not.

When is it worth stopping an existing engineering initiative?

When it has run for more than one year without clear evidence of changing how the software actually gets built. Integrations nobody uses, partially-complete refactor projects stuck for multiple quarters, internal tools built for a use case that has evolved — these all carry maintenance cost and organizational ambiguity. "We learned that this approach does not fit our workflow, we are stopping it and investing the capacity elsewhere" is a stronger statement than quietly letting it continue.

Should the talent strategy be part of the technical roadmap planning?

Yes. Treat it as a constraint on the technical plan. If the plan requires capabilities the team does not have and cannot hire in Q1, the plan needs adjusted scope, deferred milestones, or an accelerated hiring plan with realistic timeline expectations. Organizations that plan the technical roadmap without accounting for skills gaps find themselves six months in with a slower execution rate than predicted.

---

If you want specific data on where your team's constraints are rather than a list of industry best practices, a Foundations Assessment is the starting point.

For a deeper read on what to measure before committing to a platform investment, read Platform engineering ROI — what to measure and how to defend it.

For the DORA baseline work that makes Q1 goal-setting measurable, read the DORA metrics implementation guide.

For what 2025 AI adoption requires from a platform readiness standpoint, read the AI amplifier — what DORA 2025 is actually telling you about your platform.