The First 100 Days After Acquiring a Software Company: Control Before Transformation

Most discussions about post-acquisition integration focus on transformation: consolidating platforms, realizing synergies, accelerating the roadmap, and introducing new capabilities. The implicit assumption is that the main job is to change things.

I think that starts in the wrong place. Before you can change a software business, you have to understand how it actually works. During the first few weeks after an acquisition closes, that understanding is almost always incomplete, regardless of how thorough the diligence process was.

The first priority is not transformation.

It is control.

A platform can generate strong revenue while depending on two engineers who carry most of the critical system knowledge in their heads. A release process can look functional until the one person who knows how to navigate it goes on vacation. A product roadmap can appear strategically coherent while actually being driven by customer escalations, contractual commitments, and promises made years earlier.

Infrastructure can be stable until it is not.

The opposite is also true. A company can have an aging technology stack and a long list of deferred technical debt while still maintaining strong engineering discipline, predictable delivery, and no immediate need for a major intervention.

The first 100 days are about understanding the difference before making changes that could disrupt something that was working.

Days 1-30: Establish the Facts

The first month should not begin with a reorganization, a platform rewrite, or a new technology strategy. It should begin with evidence.

The goal is to understand how the company actually operates, not how architecture diagrams, management presentations, or diligence reports suggest it operates.

Those documents are useful. But they represent how the company was understood, documented, or explained at a particular point in time. They are not necessarily the same as operational reality.

The first questions should be straightforward:

Can the company release software predictably?
Do we know which systems are truly business-critical?
Where are the major operational dependencies?
Which individuals carry knowledge the organization cannot afford to lose?
How much of the engineering roadmap is driven by strategy, and how much is driven by customer escalations, production problems, and historical commitments?
Where does technology create business leverage, and where is it simply consuming capital?

Learn to Speak the Same Language

One of the first things I try to establish in a new organization is what I call speaking the same language. Every company develops its own vocabulary. Product names, acronyms, process terminology, and organizational shorthand accumulate over time and become part of how work gets done.

The problem goes deeper than jargon. Even ordinary English words can mean different things in different organizations.

Done. Approved. Committed. Production. Next sprint. Owner.

You can sit in a meeting, discuss a problem, agree on a solution, assign what appears to be clear responsibility, and leave believing the team is aligned and working on it. A week later, you discover that nothing happened.

The engineers assumed the work would begin in the next sprint. Someone else assumed the product owner would create a Jira ticket. The product owner assumed the engineering manager had already assigned the work. Everyone left the same meeting believing that something different had been decided.

This is why assumptions are particularly dangerous during the first few months. When you are new to an organization, familiar words can create a false sense of understanding. Before changing the operating model, you have to understand the one that already exists.

How are decisions actually made? What does a commitment mean in practice? Who has the authority to prioritize work? How does an issue move from discussion to execution? Where is the decision recorded? How does the team know when a decision has actually been made?

I have learned not to leave an important meeting without confirming four things: what was decided, who owns the next action, when it will be completed, and where it will be tracked.

These may sound like administrative details, but they are often the difference between a company that executes and one that spends most of its time discussing execution.

Establish a Baseline

The first month should also establish a baseline.

That baseline should include more than availability statistics and defect counts. It should explain how the technology organization actually performs:

Release frequency and lead time
Production incident frequency and severity
Engineering capacity allocation
Customer escalations
Infrastructure and vendor costs
Security and compliance exposure
Product delivery predictability
Key-person dependencies

The numbers will rarely be perfect. In some companies, reliable historical data will not exist.

Without a baseline, improvement becomes anecdotal. The organization may be working harder six months later without becoming more effective. It also becomes difficult to have an honest conversation about whether the investments made after the acquisition are generating a return.

Acknowledge the Human Reality

Acquisitions are unsettling for the people on the other side of them. Engineers, product managers, architects, and team leads who helped build the company are suddenly working for owners they may not know, in an organization they did not choose, with limited clarity about what will change.

That uncertainty is not separate from the technology assessment. It directly affects the quality of the information you receive. People do not always tell you what you need to know when they believe every conversation is an evaluation of whether their job will continue to exist.

Key employees may already be evaluating their options. Informal networks will quickly form opinions about the new owners and leadership team. Decisions about platforms, tooling, team structure, automation, and operating models will be interpreted through the lens of job security and organizational trust.

The first month therefore requires visibility and honesty. Leaders should be clear about what is known, what remains uncertain, and how decisions will be made. False confidence does not reduce uncertainty. It reduces trust.

The companies that retain the technical talent they acquired are usually the ones that treated that talent as an asset worth protecting from the beginning.

Days 31-60: Separate Risk From Noise

By the second month, patterns should begin to emerge. This is where judgment matters.

Every software company has technical debt. Every engineering team has architectural decisions it would make differently today. Every platform has systems that are older, more complicated, or less elegant than someone would prefer. Not all of those things are investment risks.

The important question is not whether the technology is modern. The important questions are whether it constrains growth, creates material operational risk, makes the company more expensive to operate than it should be, or prevents the business from executing its strategy.

A ten-year-old application that is stable, profitable, and inexpensive to operate may be far less important than a modern cloud platform that requires constant production intervention. A monolith is not automatically a problem, and microservices are not automatically an advantage. Cloud migration is not automatically value creation. AI is not automatically a strategy.

The second phase of the first 100 days is about separating what is inconvenient from what is material.

Understand the History Behind Every Recommendation

Every recommendation comes with history. When new ownership or leadership arrives, people naturally see an opportunity to revisit decisions they disagreed with in the past.

An engineering leader may have been asking for a platform rewrite for three years. A product manager may have been pushing for a feature that never received funding. A security team may believe a particular infrastructure initiative should have been the company’s highest priority all along.

The new management team arrives without that historical context, and an old argument is suddenly presented as an immediate crisis. Sometimes the concern is legitimate. Sometimes you are simply walking into chapter seven of a disagreement that started years before you arrived.

That is why I believe it is important to review the history behind major technical and product decisions:

Why was this architecture selected?
What alternatives were considered?
Why was this project deferred?
Was it rejected once, or repeatedly?
What business constraints existed at the time?
Was the issue technical, financial, commercial, or organizational?
What has changed since the original decision?

A decision that looks irrational today may have been completely rational when it was made. A decision that made sense five years ago may no longer make sense now.

The goal is not to defend the past. It is to understand how the company arrived at its current state before deciding where it should go next.

Bias does not automatically make a recommendation wrong. It means the recommendation has to be evaluated against evidence, business impact, and the current investment thesis. Without that context, new leadership can easily mistake persistence for urgency.

Categorize Findings by Business Impact

Not all findings deserve equal attention. Treating them as though they do creates paralysis and consumes management attention without improving the business.

I find it useful to group findings into four categories.

Immediate risk: These are issues that could affect revenue, customers, security, compliance, or business continuity. They require action regardless of whether addressing them is convenient.

Execution constraints: These are problems that slow product delivery, increase operating costs, create recurring support work, or prevent the organization from scaling. They should be addressed through a defined and measurable improvement plan.

Strategic capabilities: These are investments required to execute the investment thesis. They may include enterprise readiness, new market entry, AI-enabled workflows, acquisition integration, improved data capabilities, or a more scalable product architecture.

Technical debt that can wait: These are issues engineers may reasonably want to improve but that do not currently justify the cost, risk, or disruption required to address them.

This prioritization is where many technology transformations go wrong. The objective is not to fix everything. It is to decide what matters and to be explicit about what the company is choosing not to do.

Days 61-100: Turn the Findings Into an Operating Plan

By the third month, the company should be moving from diagnosis to execution. Technology priorities should now connect directly to the investment thesis.

If the thesis depends on accelerated growth, can the product organization deliver the required roadmap? If it depends on margin expansion, where can infrastructure costs, vendor spending, support burden, or engineering inefficiency be reduced?

If the company plans to move upmarket, are its security, reliability, implementation capabilities, and product maturity ready for larger customers? If M&A is part of the strategy, can the platform and operating model absorb additional products, customers, and engineering teams?

If AI is expected to create value, where will that value actually appear? Will it increase revenue, improve retention, reduce operating costs, accelerate product delivery, or improve customer outcomes?

The output of the first 100 days should not be a comprehensive technology strategy document. It should be a focused operating plan with clear ownership, measurable outcomes, funding requirements, and explicit tradeoffs.

That plan should identify:

What must be stabilized immediately.
What must be improved over the next 12 months.
What investments are required to support the value-creation plan.
What management has deliberately decided not to do.

The fourth category is important. Good technology leadership is not only about deciding where to invest. It is equally about deciding where not to spend money, time, and organizational attention.

Decide What the Core Team Should Own

One pattern I frequently see in software companies is a strong bias toward doing everything internally. The logic is understandable. The engineering team knows the product. They understand the architecture. They know the company’s standards. Assigning more work to the same people can appear easier and safer than bringing in outside help.

But that logic can produce exactly the wrong outcome. The most valuable engineers become bottlenecks. Product knowledge becomes concentrated in even fewer people. Strategic roadmap work competes with internal tooling, infrastructure automation, cloud migrations, compliance work, security remediation, and other necessary activities that may not be core to the product.

The question should be: What work truly requires deep knowledge of our product, customers, and competitive differentiation?

That is where the core team should spend its time.

Automating a DevOps process may be essential. But that does not mean the engineers with the deepest product knowledge should spend the next six months building that automation themselves. The same logic may apply to cloud infrastructure, test automation, data migration, security remediation, observability, and other specialized work.

Important work is not always differentiating work.

Leadership should determine what must remain with the core team and what can be bought, automated, standardized, or delivered with specialized outside support.

This also requires an honest conversation about incentives. Automation changes jobs. Standardization eliminates work that people previously performed manually. Outside assistance can be interpreted as a threat to an internal team’s role or influence.

Teams may resist these changes for reasons that have little to do with the technical merits of the proposed solution. Organizational resistance can sometimes present itself as a technical objection. That does not mean the team is acting in bad faith. Their concerns may be reasonable and should be understood.

Leadership still has to distinguish between protecting the product and protecting an existing way of working. The goal is not to outsource everything. It is to protect the scarce capabilities that create enterprise value and direct them toward the work that matters most.

The Temptation to Move Too Fast

Acquisitions create pressure for visible momentum. New owners want progress. Boards want evidence that the investment thesis is being executed. Management teams want to demonstrate that they are in control.

That pressure can make it tempting to launch transformation programs immediately: replatform the product, move everything to the cloud, replace engineering leadership, reorganize the development teams, or introduce AI across the roadmap.

Some of those decisions may ultimately be correct. But making them before understanding the operational reality of the company can destroy value just as easily as create it.

A reorganization executed before understanding how decisions are actually made creates confusion without improving accountability. A replatforming program launched before understanding system interdependencies creates risk without improving reliability. Leadership changes made before understanding how critical decisions were made can eliminate institutional knowledge that took years to accumulate.

The first 100 days should produce confidence before complexity:

Confidence that the business can operate reliably.
Confidence that the major risks are understood, not merely documented.
Confidence that the new leadership and the existing team are communicating clearly, rather than exchanging familiar words with different meanings.
Confidence that recommendations have been separated from historical agendas and organizational bias.
Confidence that the most valuable technical talent is focused on work that actually requires its expertise.
Confidence that technology investment is aligned with the investment thesis, rather than with the loudest voice in the room.

The best first 100-day plans do not try to transform everything.

They establish clarity about what matters, create control over the areas that do, and build the operating discipline required to execute the value-creation plan without damaging what was already working.