Building Predictable Delivery After an Acquisition

A retrospective on integrating engineering practices after my company was acquired.

Reading Time: ~9 minutes

When the company I cofounded was acquired, I moved from leading its engineering function into a Director of Engineering role inside a larger organization. Almost overnight, my scope expanded from one product and one established engineering organization to three products, multiple engineering managers, and teams with distinct histories.

The larger company was growing rapidly through acquisition, bringing together products and teams faster than a single software-development lifecycle could fully emerge. My original team entered the organization with a delivery cadence and SDLC we had built and refined together. The other teams had evolved under different conditions, and each planned work, estimated complexity, communicated risk, and defined "ready" and "done" somewhat differently.

The challenge was not to transplant one team's process wholesale. I needed to understand how each team worked, preserve the practices that were already serving them, and establish enough shared operating discipline to make delivery predictable across all three products.

As I worked with the managers and examined delivery across the portfolio, several opportunities became visible. In parts of the organization, work sometimes entered development before key questions were resolved. The meaning of "done" varied between teams. Product and Engineering needed a more explicit agreement about when a request was actionable and when a commitment had actually been satisfied. When dependencies or decisions slowed a story, that delay was not always visible soon enough for the organization to respond.

The visible symptom was inconsistent delivery against our forecasts. It would have been easy to treat that as a motivation or estimation problem. Looking closer, the larger opportunity was to improve the system around the teams.

The answer was not more pressure. It was clearer agreements and a delivery system that made stalled work easier to see and address.

Predictability Before Velocity

Story points are useful for forecasting. They are terrible measures of individual performance, and they become dangerous when leadership treats the number itself as the outcome.

I was not trying to make the teams produce more points. I wanted them to become dependable. When a team made a commitment, the business needed to trust it. When the forecast was wrong, we needed to learn why early enough to do something about it.

That meant paying attention to more than velocity:

How much planned work was actually completed?
How much work carried into the next planning period?
How long did work remain in progress?
Where did it wait?
How quickly did the team respond when something became blocked?
Was completed work genuinely releasable?

Predictability had to come before speed. Otherwise we would simply move uncertainty through the system faster.

The Dashboard Wasn't Enough

To understand why our forecasts and delivery were diverging, I went into the work itself. I read the pull requests, followed the code paths, and compared what had actually been required to the story the team had estimated.

I was not looking for a ratio between story points and lines of code. Lines of code are no more useful as a performance measure than story points, and points are meaningful only within the team that estimates them. I was looking for the work that our planning process had failed to make visible.

A story that appeared small in the backlog might require changes across several services, new authorization rules, a data migration, integration testing, deployment configuration, or careful handling of failure cases. Sometimes the implementation exposed architectural coupling that nobody could have seen from the ticket. In other cases, one story was carrying several distinct behaviors that should have been separated before the team committed to it.

Reading the pull requests gave me enough technical context to ask better questions:

Did the story describe the work the engineer actually encountered?
Was the complexity inherent, or did our architecture make the change harder than it should have been?
Were testing, integration, migration, and operational work represented in the estimate?
Could we split the behavior into smaller increments that delivered value independently?
Were similar stories receiving reasonably consistent estimates within the team?

Done poorly, this kind of involvement can become inspection theater. My goal was not to grade engineers through their pull requests or second-guess every implementation decision. It was to calibrate our planning system against reality and to understand where leadership could remove friction.

That hands-on technical review also made conversations with managers and engineers more useful. Instead of asking why a number had been missed, we could discuss the hidden work, architectural constraints, or unclear behavior that made the original forecast incomplete. Those lessons then flowed back into how we prepared, decomposed, and estimated future work.

Definition of Ready: Protecting the Team From Ambiguity

Our first major change was agreeing on a Definition of Ready.

Before work could become a team commitment, we expected to understand:

The outcome — Why are we doing this, and what should change for the user or the business?
The behavior — What observable conditions will tell us the work is correct?
The boundaries — What is included, and just as importantly, what is not?
The dependencies — Are we waiting on another team, a vendor, a decision, or access to a system?
The open questions — Have the important product and technical decisions been made?
The size — Is the work small enough to move through the system without disappearing into a multi-week black box?

Definition of Ready was not a bureaucratic gate or a document-completion exercise. It was a shared agreement between Product and Engineering. Product remained accountable for clearly expressing the problem and desired behavior. Engineering remained accountable for identifying technical uncertainty, dependencies, and delivery risk.

The definition protected engineers from being asked to commit to work whose most important decisions had not been made. It also gave Product earlier feedback. Instead of discovering ambiguity after implementation started, we found it while the cost of changing direction was still low.

Definition of Done: Making Completion Mean Something

We also needed one consistent meaning for "done."

Code being written was not done. A pull request being opened was not done. Work moving into a testing column was not done. Even a merged change was not necessarily done.

For us, done meant the agreed behavior was complete, reviewed, tested, accepted, and releasable. Depending on the work, that included:

Acceptance criteria verified
Automated tests passing
Code review completed
Security and architectural expectations satisfied
Operational visibility in place
Documentation or configuration updated
The change deployed or ready to deploy through the normal release process

The exact checklist mattered less than the agreement. Everyone needed to know where the finish line was before the team started running.

A strong Definition of Done also removed hidden work. We stopped declaring victory and quietly creating follow-up tasks for testing, cleanup, instrumentation, or deployment. If those things were necessary to deliver the outcome, they were part of the work.

Urgency Without Panic

Definitions helped work enter and exit the system cleanly, but they did not solve what happened in between. We needed a stronger sense of urgency around flow.

Urgency is often confused with pressure. They are not the same.

Pressure says, "Work faster."

Urgency asks:

What stopped moving?
How long has it been waiting?
What decision is missing?
Who owns the next action?
Who needs to know that the forecast changed?

Urgency is shortening the time between discovering a problem and doing something about it.

We started paying attention to work every day, not just at sprint planning and review. When a story stopped moving, the expectation was not that the assigned engineer should struggle with it alone. The expectation was that the blockage would become visible, an owner would be identified, and the right people would communicate.

Nothing should sit silently.

If a requirement was unclear, Engineering raised it with Product immediately. If a dependency threatened a commitment, the responsible manager escalated it. If a review was waiting, the team knew. If one person held context that could unblock another, we created the conversation instead of letting the ticket age.

This was not about adding more meetings or asking for constant status reports. It was about reducing the latency between handoffs, decisions, reviews, and responses.

Finish Work Before Starting More Work

When delivery became uncomfortable, the natural reaction was often to start something else. A blocked story remained open while another entered development. Soon everyone was busy, but very little was finishing.

We changed the emphasis from keeping people busy to keeping work moving.

That meant limiting work in progress, swarming items that were close to completion, and treating aging work as a signal. Starting another story could make an individual look productive while making the overall system slower.

Utilization is not throughput. A busy team can still be an unpredictable team.

The daily question became less about what each person had started and more about what the team could finish.

Communication Is Part of Delivery

One of the most important changes was treating communication as part of the work rather than something adjacent to it.

Teams do not usually miss commitments at the instant a sprint ends. The commitment becomes endangered earlier: when an assumption proves false, a dependency slips, a review waits, or a decision remains unresolved. The missed commitment is merely when everyone finally acknowledges what the system already knew.

We established a shared expectation that managers and engineers would communicate those changes while options still existed. Early communication allowed us to clarify scope, move expertise, resolve a dependency, or reset an expectation honestly. Late communication could convert a solvable delivery problem into a trust problem.

The goal was not perfect forecasts. Complex software work will always contain uncertainty. The goal was to eliminate surprises we had already had time to see coming.

Sprints Are Planning Intervals, Not a Pace

The word "sprint" can encourage unhealthy behavior. It implies a burst of effort followed by recovery. But software teams do not run one sprint. They run another, and another, and another.

A sprint is a planning interval, not permission to operate at sprint intensity. Software delivery is a marathon run through a series of short feedback loops.

Sustainable pace was therefore part of the improvement, not a competing priority. A process that only works when people stay late, skip quality controls, or depend on heroics is not predictable. It is borrowing from the next sprint.

We wanted urgency in the system, not anxiety in the people. Clear priorities, smaller work, fast decisions, visible blockers, and disciplined completion made the teams faster without requiring them to remain in a constant state of emergency.

Managing Through Managers

Because I was leading through multiple engineering managers, I could not make the transformation durable by personally running every team.

My job was to establish the operating expectations, coach managers on how to use them, and hold leaders accountable for outcomes. Their job was to adapt those expectations to their teams, surface problems, and develop the engineers doing the work.

That distinction mattered. If I bypassed managers whenever delivery became difficult, I might solve an individual problem while weakening the organization. Instead, we used the integration to build management capability: how to identify risk, how to challenge ambiguous work, how to create accountability without blame, and how to communicate clearly across functions.

The process became repeatable because ownership existed at every level.

What Changed

Over time, the teams became increasingly consistent about completing the work they forecast each week. Story points became more useful—not because the number increased, but because the forecast became more credible.

Stakeholders gained clearer visibility into delivery and greater confidence in our forecasts. Product and Engineering had a stronger shared contract for preparing and accepting work. Managers could identify delivery problems earlier. Engineers spent less time navigating ambiguity and waiting for decisions. The conversations shifted from reacting to surprises toward improving what the organization could accomplish next.

We did not get there through a new project-management tool, a reorganization, or a mandate to work harder. We got there through explicit agreements and daily attention to flow.

What I Took With Me

The experience changed how I think about engineering leadership:

Clarity is a form of speed. Time spent resolving ambiguity before commitment is usually cheaper than resolving it during implementation.
Urgency is response time, not working time. The fastest teams expose and act on problems quickly.
Predictability is more valuable than impressive velocity. A credible forecast lets the business make better decisions.
Sustainable pace is an operational requirement. A system dependent on heroics is already failing.
Managers build the system. Leaders create the agreements, feedback loops, and accountability that allow talented people to deliver consistently.

These lessons have become even more important as AI changes software development. AI can generate implementation quickly, but it also amplifies ambiguity. If "ready," "done," architecture, and quality remain subjective, AI produces uncertainty faster.

Definitions of Ready and Done are early forms of deterministic control. Today I extend the same thinking through behavioral specifications, automated testing, architectural fitness functions, and quality gates. The mechanism has evolved, but the leadership principle is the same:

Make expectations explicit, make problems visible, and build a system in which high-quality work can keep moving without depending on heroics.