Five Engineering Investments Worth Making in the First Quarter

TL;DR. Q1 is when engineering capacity is most discretionary — roadmaps are set but not yet consumed, the previous year's urgency has faded, and organizational attention is at its seasonal low. Five investments made during this window compound throughout the rest of the year: CI performance (a build that degraded by 13 minutes over 12 months is costing roughly five weeks of senior engineer capacity per month), targeted documentation of the three riskiest systems, an honest on-call rotation review, a one-question developer experience survey with visible follow-through, and a committed decision on the piece of technical debt that has been on the roadmap for 18 months without a plan. None of these are glamorous. All of them compound.

There is a particular kind of engineering debt that does not show up in any technical debt backlog. It accumulates in the friction of daily work, the things everyone works around without ever quite fixing, because there is always something more urgent. Q1 is when you have the chance to address it before the year's roadmap consumes all available capacity.

These five investments are unglamorous by design. They do not become product announcements. They do not generate blog posts or conference talks. But the teams that make them in Q1 consistently outperform the teams that do not for the rest of the year, and the advantages compound over multiple years if the investments are made consistently.

The reason Q1 is the right time for this work is that the beginning of the year is the moment when engineering capacity is most discretionary. Annual roadmaps have been set but not yet consumed. The urgency of the previous year's backlog has faded. New engineers who joined in Q4 are now productive enough to contribute to infrastructure work. And the organizational attention that would otherwise be pulled toward product delivery is at its seasonal low.

Audit your CI pipeline before the year's roadmap consumes the capacity to fix it

Pull the data on your current CI run times and pass rates. Most teams, when they look at this for the first time in a year, find two things: the build has gotten slower than it was twelve months ago, and a meaningful percentage of test failures are flaky rather than real.

CI pipeline degradation is nearly universal and nearly invisible. Build times that grow by one minute per month over the course of a year have grown by twelve minutes without anyone noticing the accumulation. The engineers running the builds adapt their workflow to the slower feedback loop without registering it as a problem. The degradation is only visible when you look at the historical data.

A CI pipeline that has degraded from 12 minutes to 25 minutes over the course of a year is imposing a compounding cost on every engineer every day. At a 20-person engineering team running 50 builds per day, the difference between 12 and 25 minutes is 217 engineer-hours per month. That is roughly five weeks of a senior engineer's capacity, wasted in waiting.

The audit should cover three things. First, where the time is going: which steps are slowest, whether there are sequential steps that could be parallelized, and whether the cache configuration is working as intended. Second, flakiness rates: what percentage of failures require a rerun to pass, and which specific tests are responsible for the majority of the flakiness. Third, failure mode distribution: when builds fail, what are the most common reasons, and which of those reasons represent real problems versus infrastructure noise.

Spending two sprints on CI performance and flakiness remediation in January will typically pay back within six weeks and continue paying back for the rest of the year. The investment compounds because every subsequent build, every hour of every engineer's day, benefits from the improvement.

Document your three riskiest systems before the engineer who understands them leaves

Every engineering organization has systems that are one engineer departure away from becoming unmanageable. The service that processes the majority of revenue but that only one engineer truly understands. The data pipeline that runs on a schedule set three years ago by someone who has since left. The authentication system that works but that nobody feels confident touching. The integration with a third-party system that is held together by institutional knowledge that exists only in one person's head.

The documentation investment here is not comprehensive. Comprehensive documentation is a project that takes months and rarely gets completed. The targeted documentation that actually prevents incidents and reduces bus factor requires a much smaller investment.

For each risky system, the documentation goal is: what does the system do in one paragraph, who should be contacted when it breaks and in what order, what are the three most likely failure modes and how do you diagnose each one, and where are the critical configuration values and how do you access them. That is roughly two to four hours of documentation work per system. Six systems at three hours each is eighteen hours. Two and a half days of focused work that could prevent a two-week incident.

The process of creating this documentation also surfaces risks that were not visible before. Engineers who are asked to document systems they own frequently discover that they are not as confident in their understanding as they thought. That discovery is more valuable when it happens in January during a planned documentation effort than in July when the system fails at 2am.

The teams that do this work well establish a rotation: each quarter, three to five systems get the targeted documentation treatment. Over two years, the entire critical system landscape has been covered and refreshed.

Review your on-call rotation when there is time to fix it, not during the next incident

If you have engineers on call, ask them honestly: what percentage of their pages require waking someone up at 2am because the context is too specific or the tooling is too limited? Any page that consistently requires escalation is either a runbook gap, an alerting threshold problem, or both. Both are fixable. Neither should be left unfixed through the year.

The burn rate on on-call rotations is real and underestimated by engineering leadership at almost every organization I have worked with. Engineers who are woken up twice a week for alerts they cannot resolve independently are burning out at a pace that salary increases do not offset. The on-call experience is one of the most frequently cited reasons senior engineers leave engineering organizations, and it is one of the most fixable.

The Q1 review should produce three specific outputs. First, a categorized list of the 10 most frequent alert types in the previous quarter, with a clear designation for each: this alert requires human judgment to resolve, this alert should be automated away, this alert threshold is wrong and should be adjusted. Second, a runbook quality assessment: for each service on the rotation, do the runbooks exist, are they current, and have they been used and validated in the last six months? Third, a rotation structure review: is the rotation sized appropriately for the incident volume, and are the engineers on the rotation equipped to handle the incidents they receive?

The investment required to address the issues found in this review is almost always smaller than the ongoing cost of leaving them unaddressed. Alert threshold adjustments take hours. Runbook gaps can often be closed by the engineers who resolved the most recent incidents for each system. Rotation structure changes take a conversation. The bottleneck is usually the attention and priority required to do the review, not the work required to fix what it finds.

One question — not forty — is the developer experience survey format that produces action

Ask your engineers one question: "What is the most frustrating part of your daily workflow?" Not a 40-question survey. One question, open text, anonymous if possible.

You will hear about the build times. You will hear about a specific service that is always broken. You will hear about a recurring meeting that does not produce decisions. You will hear about documentation that is perpetually out of date. You will hear about a tool that everyone uses but that was never configured properly after it was adopted two years ago. You will hear about deployment processes that require manual steps that could easily be automated.

Pick the three things that appear most frequently. Fix one of them before the end of Q1. Tell the team you fixed it and that you got the idea from their feedback. This creates a feedback loop that most engineering organizations do not have, where leadership demonstrates that engineer input influences the work environment, which produces higher quality input in subsequent surveys.

The returns from this loop compound over time. The first survey produces the most obvious fixes. Subsequent surveys, run quarterly or semi-annually, produce increasingly specific and nuanced feedback as engineers learn that the feedback will be acted on. After two years of consistent surveys and visible follow-through, the quality of the feedback is dramatically higher than the initial survey, and the organization has a continuously improving picture of where engineering friction is concentrated.

The single-question format is important. Longer surveys produce lower completion rates and more performative answers. A single question asked and acted on is worth more than a comprehensive survey that produces a report that gets filed.

Make a committed decision on the technical debt that has been deferred for 18 months

Most engineering organizations have at least one piece of technical debt that has been on the roadmap for 18 months or more. It gets reprioritized every quarter. Everyone knows it should be addressed. Nobody has committed to doing it. The legacy authentication service that was supposed to be replaced two years ago. The monolith that was supposed to be decomposed before it got too large. The database schema that was designed for a product that no longer exists.

In Q1, either commit to a specific plan and timeline for addressing it, or officially decide not to address it this year and remove it from the roadmap. Living with the item on the backlog without a committed plan has a cost that is easy to underestimate. It creates ongoing cognitive overhead for every engineer who knows about it. It signals that the organization does not follow through on its technical commitments. And it prevents honest capacity planning, because the debt item is simultaneously consuming backlog space and not receiving any actual investment.

A clear "not this year, and here is why" is more respectful of your engineers' time and intelligence than "we will get to it eventually." It also forces the honest conversation about whether the debt is actually as important as it seems when it is being discussed and as unimportant as it seems when it is being prioritized.

The conversation required to make this decision is difficult but valuable. It surfaces the actual organizational priorities rather than the stated ones. The teams that have this conversation honestly in Q1 tend to make more progress on the items that remain on the roadmap, because those items are the ones that actually have organizational commitment behind them.

Why these investments compound while feature work does not

The five investments described here share a common characteristic: the return is not visible in any single sprint or quarter. CI performance improvements show up as small gains in every build, every hour, every day for the rest of the year. Documentation quality shows up as avoided incidents that never happen. On-call improvements show up as engineers who stay rather than engineers who leave. Developer experience surveys show up as feedback that improves the organization year over year.

This is precisely why these investments are the ones that get deferred. The returns are distributed across the year rather than concentrated in the current sprint. The costs are concentrated in the current sprint, which makes the trade-off look unfavorable when viewed through a short-term lens.

The engineering leaders who consistently make these investments are the ones who have learned to evaluate infrastructure work on its annual return rather than its sprint return. The organization that makes these five investments every January for five years looks dramatically different from the organization that deferred them each year in favor of feature delivery. The compounding advantage of consistently maintained tooling, documentation, and measurement is one of the most durable structural advantages available to an engineering organization.

The governance gaps that growth phase left behind — and why Q1 is when to close them

Engineering organizations that have grown through a year of rapid feature delivery often arrive in Q1 with governance gaps that became invisible during the growth phase. Services that were provisioned quickly without proper security review. Dependencies that were added because they were convenient without a formal decision about whether they were appropriate. Access controls that were configured for speed and never tightened after the launch.

These gaps do not cause incidents immediately. They cause incidents eventually, often at the worst possible moment. The Q1 window before delivery pressure is highest is when these governance reviews are most likely to actually happen.

A governance review does not need to be comprehensive to be valuable. A focused review of the services created in the past 12 months, checking for external access control configuration, dependency audit status, and secret management practices, typically takes one to two weeks for a mid-sized engineering team and surfaces the most critical gaps without requiring a full security audit.

The engineers who do this work in Q1 are typically the ones least likely to be doing it, because governance reviews are not exciting and the code is already running. The organizations that do it anyway are building the habits that prevent the governance-related incidents that cause the most reputational damage and the most regulatory exposure.

The monthly delivery health summary that changes the engineering–business conversation

One investment that pays specific dividends throughout the year but that must be established in Q1 to take effect is a regular, visible communication practice from engineering leadership to business leadership about delivery health.

The format that works best is simple: a monthly one-page summary of the four DORA metrics, a brief narrative about what changed and why, and a clear statement of what the engineering team is investing in this month and what it expects to improve. This communication does not require sophisticated tooling or elaborate reporting. It requires the discipline to measure consistently and communicate clearly.

The value of this practice accumulates over time. After six months of consistent communication, business leadership has developed a genuine understanding of what deployment frequency means and why it matters. The engineering investment conversation changes from "trust us, this infrastructure work will help" to "here is our last six months of data showing the investment producing the expected improvement." The trust this builds between engineering and business leadership is one of the most valuable organizational assets an engineering team can develop, and it starts with consistent measurement and clear communication in Q1.

Making each investment specific enough to survive Q1 delivery pressure

To make these resolutions actionable rather than aspirational, each one requires a specific owner, a first concrete deliverable, and a measurement of whether it was completed.

For CI performance: the owner is the senior engineer most familiar with the current pipeline. The first deliverable is a report within two weeks identifying the top three causes of build time over 10 minutes. The measurement is the average build time at the end of Q1.

For documentation: the owner is the team lead for each squad. The first deliverable is a list of the five most commonly asked questions by new team members, completed within the first sprint. The measurement is whether each question has a documented, findable answer by end of Q1.

For on-call sustainability: the owner is the engineering manager. The first deliverable is an audit of alert volume by service from the previous 60 days, completed before the end of January. The measurement is the percentage of alerts that are categorized as actionable versus noise by end of Q1.

For developer experience measurement: the owner is the engineering manager. The first deliverable is a lightweight feedback mechanism established within the first two weeks: a channel, a form, or a standing agenda item in the team retrospective. The measurement is whether it produces at least five actionable pieces of feedback per month.

For technical debt: the owner is whoever has been carrying the anxiety about the specific debt item longest. The first deliverable is a documented decision, either a plan with a committed timeline or an explicit "not this year" with documented reasoning, within the first month. The measurement is binary: decision made or not.

These specifics are examples. The actual owners, deliverables, and measurements should reflect the team's actual context. But the specificity itself is the point. Resolutions without owners and first deliverables are intentions. Intentions do not survive Q1 delivery pressure.

Frequently asked questions

Why is Q1 specifically the right time for these investments?

Because it is when engineering capacity is most discretionary. Annual roadmaps have been set but not yet consumed. The urgency of the previous year's backlog has faded. New engineers who joined in Q4 are now productive enough to contribute to infrastructure work. And organizational attention that would otherwise pull toward product delivery is at its seasonal low. The same investments attempted in Q3, when delivery pressure is highest, are routinely deferred. Made in January with a committed owner and a first deliverable, they survive.

What does a useful targeted documentation approach for risky systems look like?

Four pieces of information per system: what the system does in one paragraph, who to contact when it breaks and in what order, the three most likely failure modes and how to diagnose each one, and where the critical configuration values live and how to access them. That is two to four hours of documentation work per system — not a comprehensive technical document. The process of writing it is also a diagnostic: engineers asked to document systems they own frequently discover they are less confident in their understanding than they thought. That discovery in January during a planned effort is more valuable than the same discovery in July at 2am.

What makes a developer experience survey actually produce actionable results?

One question, not forty: "What is the most frustrating part of your daily workflow?" Longer surveys produce lower completion rates and more performative answers. The single question asked and acted on produces more value than a comprehensive survey filed as a report. The specific follow-through that creates a functioning feedback loop: fix one of the three most common responses before the end of Q1, then tell the team you fixed it and where the idea came from. Engineers who see feedback turned into visible action give increasingly specific and useful feedback in subsequent surveys. The loop compounds over multiple years.

Why is "not this year" a valid and useful technical debt decision?

Because the item living on the backlog without a committed plan has ongoing costs beyond the debt itself. It creates cognitive overhead for every engineer who knows about it, signals that the organization does not follow through on technical commitments, and prevents honest capacity planning. A clear "not this year, here is why" is more respectful of engineering time and intelligence than perpetual deferral. It also forces the honest conversation about whether the debt is actually as important as it seems when discussed and as unimportant as it seems when prioritized. Teams that make this decision explicitly in Q1 make more progress on the items that stay on the roadmap.

---

If you want help identifying where the highest-leverage investments are for your specific team, a Foundations Assessment gives you data rather than guesses.

For the DORA baseline work that makes Q1 resolutions measurable, read the DORA metrics implementation guide.

For the team maturity diagnosis that tells you which of the five ad-hoc patterns applies to your platform, read 5 signs your platform team is stuck in ad-hoc mode.

For the ROI argument that turns platform resolutions into a budget conversation, read platform engineering ROI — what to measure and how to defend it.