The CTO Without a Product – Managing Engineering at Scale in the Outsourcing Model
- Mar 18, 2024
- 8 min read
Written by Oleksandr Orlov, Co-Founder and CTO, Andersen
What does a CTO do when the company has no product? I have spent fifteen years finding out. Since co-founding Andersen in 2011, I have grown the company from a two-person operation into an organization of more than 3,700 engineers across 16 global locations. Andersen has delivered software for Siemens, S&P Global, Mercedes-Benz, Capital Farm Credit, and TUI, among many others. No proprietary platform. No shared codebase that persisted beyond the engagement. Before Andersen, I ran engineering at MyBit BV in the Netherlands, managed project delivery at Possoftware in Ukraine, and ran my own development business. Every role shared the same facts: no proprietary product, no accumulating architecture, no roadmap. Just the organization’s capacity to deliver and the question of how to build and protect that capacity.
The management literature on software engineering leadership was written for product companies. Its frameworks assume a stable technical object at the center:
A system being improved over time.
A team organized around its components.
An architecture that grows with the business.
None of that applies in outsourcing. Engagements begin and end. Stacks change with every client. Teams form, deliver, and dissolve. What remains is the organization. In outsourcing, the organization is the product.
That realization took me longer to reach than it should have. What follows is what I learned on the way there.
Observation 1: The management wall is not a technical problem
My first serious crisis as a technical leader had nothing to do with code. I had built Andersen’s engineering function from scratch – hiring, structuring teams, setting technical direction – while managing twenty engineers directly. Twenty people reporting to one person, across simultaneous projects with different clients, different stacks, and different delivery pressures, is a structural failure waiting to surface.
The instinct is to work harder. That instinct is wrong. The problem was not the workload. It was architecture. No individual effort resolves a span-of-control failure.
What I built in response became the management foundation Andersen still operates on, layered in two directions:
Vertical: project managers, delivery managers, and their supervisors. Defined spans of authority, escalation paths, and accountability at each level.
Horizontal: the connective tissue most outsourcing organizations skip. Goal frameworks tied to measurable results. Performance matrices that gave engineers across different geographies a shared standard. Development tracks for every engineering discipline. Resource management systems designed to absorb dozens of simultaneous projects without concentrating pressure at the top.
Figure 1: Andersen’s Two-Layer Management Architecture
The horizontal layer doesn’t appear in an org chart, which is why it is consistently underbuilt. In a distributed organization, it determines whether the company functions as a single entity or as separate teams that share a brand name. Without it, quality standards diverge across geographies. A client escalation is usually how the divergence gets discovered.
Andersen scaled from tens of engineers to hundreds to thousands in the years that followed. The architecture built during that early crisis is what made the scaling possible.
Recommendation:
Build the horizontal alignment layer while the organization is small enough to design it cleanly: shared goal frameworks, common performance criteria, cross-geography development tracks. The vertical hierarchy is instinctive. The horizontal layer requires intention. Do it before growth makes it urgent.
Observation 2: Quality variance is an organizational failure
For a period in Andersen’s growth, I explained inconsistent delivery results the way most technology leaders do: in terms of the people involved. Good projects had strong teams. Difficult projects had weaker ones. The explanation gave me nothing to act on.
The change came when I noticed that the same engineers produced different results in different project contexts. Quality was not a fixed property of the individual. It was produced by the interaction between the individual and the organizational system around them. When the system was clear – defined processes, documented standards, a technical reference community – results improved. When the system was absent, outcomes depended on individual judgment. Individual judgment varies.
This observation produced the most consequential structural decision I made at Andersen: The PDS Competency Center. It is an internal unit that owns the standards for a specific delivery or technical domain: how projects are estimated, how technical decisions are documented, how code is reviewed, how engineers are assessed.
The first center I built addressed fixed-price project delivery, the commercial structure with the highest consequence for quality variance. Building it required formalizing what had existed only as institutional knowledge: how a fixed-price engagement is scoped so scope is unambiguous, estimated so the estimate is defensible, and delivered so milestones mean the same thing to both the client and the team. The result was reproducibility. An engineer joining a fixed-price project anywhere in Andersen’s network worked within the same framework as one who had run twenty such projects.
From there: an AI-augmented delivery center embedded AI tooling into the fixed-price framework as a native capability – a defined practice with its standards and assessment criteria. An AWS Competency Center followed. In each case, the logic was identical: commit to a domain, build the standards infrastructure that makes depth reproducible, and staff the center with engineers who develop sustained expertise.
Andersen has delivered over 1,000 projects across these frameworks. The quality floor the Competency Centers set is determined by the organization, not by whoever happens to be on the project.
Figure 2: The Competency Center Model
Recommendation:
Stop managing quality at the project level. Build the standards infrastructure and let it set the floor. Chasing quality engagement by engagement is a permanent, unwinnable race.
Observation 3: Fixed-price contracts fail for organizational reasons
Fixed-price engagements are the dominant commercial structure in outsourcing and the dominant source of margin erosion and strained client relationships. The conventional explanations (clients underspecify, requirements change, estimation is imprecise) describe symptoms, not causes.
The cause is almost always the same: no defined process for handling scope questions that arise mid-project. Those questions are routine. A feature can be read as in scope or as a change. A technical decision conflicts with an assumption that was never written down. A new stakeholder arrives with different requirements. Whether they become manageable process events or damaging disputes depends entirely on whether a handling framework exists.
Without one, each scope question triggers a standoff – an unstructured negotiation at the moment when both sides have the least goodwill available, working from documentation written months earlier. Time is lost. Relationships degrade. The project carries the residue forward.
Over many engagements, I developed a delivery framework for fixed-price projects built on four elements:
Scope definition written at the implementation level, so disagreements are resolved by reference to the document.
An estimation methodology that requires assumptions to be documented explicitly.
A specific resolution process for mid-project scope questions that replaces negotiation with procedure.
Milestone certification that gives the client and the team a shared definition of progress at every stage.
Figure 3: The Fixed-Price Delivery Framework
The ProScan Imaging engagement tested this framework at full scale. ProScan is an Andersen client: a Cincinnati-based medical imaging corporation whose platform supports radiologists, clinical staff, and patients across a network of more than 400 clinical locations throughout the United States. Processing over 3,000 imaging orders daily, ProScan came to Andersen with a platform that could no longer support its growth – the legacy system was constraining both scale and compliance posture. The engagement involved migrating years of medical records to a modern relational architecture, rebuilding the platform for 10,000 active users with capacity to scale beyond 21,000, and achieving HIPAA compliance across every component. Scope questions arose throughout. None accumulated into disputes. Andersen delivered in roughly half the time of comparable enterprise healthcare engagements – less a result of any individual technical decision than of the framework that kept the engagement moving.
Recommendation:
Treat scope management as an engineering discipline. Design the process for mid-project scope questions before the project starts, agree on it with the client at kickoff, and make it the default path. Improvised negotiation under deadline pressure is the expensive alternative.
Observation 4: Vendor lock-in is a management failure before it becomes a client crisis
One of the clearest illustrations of poor delivery infrastructure came from an engagement we were brought in to resolve. A client's existing vendor had engineered proprietary dependencies throughout the platform – data formats, runtime dependencies, interface protocols – that made the client dependent on that vendor for every significant change. When contract renegotiation arrived, the vendor used those dependencies as leverage. The client had no practical exit.
My team removed them: ported data to open formats, replaced proprietary interfaces with documented standards, and rebuilt the components tied to the vendor's specific runtime. Technically straightforward. Organizationally difficult – executed in a live production environment, on a system the client depended on daily, while a commercial dispute with the incumbent vendor ran in parallel.
The experience made explicit something I had understood only in principle: vendor independence is a non-functional requirement. And in outsourcing, the outsourcing company itself is a potential source of lock-in. Clients whose systems are built on frameworks that only the original delivery team understands are dependent on their vendor at the moment they most need options.
I made vendor independence a design standard across all Andersen projects: open standards, documented interfaces, portable data formats, no proprietary runtime dependencies in client-facing systems. A client who can leave but chooses to stay is a more stable relationship than one who cannot leave. The ProScan platform reflects this principle: Java, Spring Boot, React, TypeScript, PostgreSQL, AWS – every technology choice was made against one criterion: can ProScan's own team maintain and extend this system without Andersen?
Recommendation:
At every architecture review, ask: could a competent engineering team that has never worked with your organization maintain this system in five years? If the honest answer is no, the architecture needs to change before delivery.
Observation 5: The services you don’t offer define you as much as the ones you do
An outsourcing company that grows without portfolio discipline accumulates services in the shape of whatever clients happen to request. The result: real depth in some domains, thin coverage in others, with no reliable way to distinguish them until a delivery problem reveals it.
The criterion I used to correct this at Andersen was service liquidity: can this service be deployed across different client contexts without rebuilding the delivery approach each time? A liquid service has a stable operational model. A service requiring near-complete reconstruction for each new client is not mastered. It is still being built, at the client's expense.
The managed services department I built at Andersen is liquid: stable model, varying technical specifics. Penetration testing, formalized over the last two years, operates on a defined methodology deployed systematically. AI consulting is a third example. I pushed it into the portfolio ahead of market demand, building an internal unit to adapt AI tooling to specific project contexts and develop proprietary solutions where commercial products fell short. When demand arrived, the organization was already structured to meet it.
Services that are not liquid dilute depth without building it. Portfolio discipline means shrinking that category – deciding whether to invest in building depth or stop accepting those engagements.
Recommendation:
Audit your service portfolio against one criterion: where does the organization have genuine, reproducible depth? Build competency infrastructure around those services. For everything else, decide – invest or exit. Drifting is a decision by default, and its cost compounds.
What fifteen years of outsourcing can teach
The five observations converge on a conclusion I did not reach quickly: in outsourcing, the CTO's primary engineering problem is the organization. Not the architecture of any individual client system. Not technology selection. The problem is building an organization whose delivery quality is determined by structure, not by which individuals are assigned to which project.
I started understanding this when I was managing twenty engineers and struggling with it. I built toward it through every decision that followed: the management architecture, the PDS Competency Center, the fixed-price delivery framework, the vendor lock-in removal, the AI portfolio push two years before the market made it standard. Each was a decision about what the organization was capable of and what floor it would not fall below.
Product CTOs have a product to organize around. Outsourcing CTOs must build the infrastructure that serves the same function: management architecture, delivery standards, portfolio discipline, client protection principles. That infrastructure is what separates an outsourcing company that is genuinely good from one that is occasionally lucky.
Building it is the work. I don’t consider it finished.
