Products You May Like
There is a particular failure mode common to technically excellent CTOs. They optimize for engineering elegance. They debate architecture patterns at length, push for the cleanest possible codebase, and build infrastructure their peers would admire — while the business around them makes decisions they don’t understand and couldn’t influence. The technical output is impeccable. The commercial outcome is somebody else’s problem.
Oleksandr Orlov, co-founder and CTO of Andersen, built a 3,500-person global software company by refusing to accept that division of labor.
“Education doesn’t save projects,”he says.“Methodology does. But methodology without diverse knowledge is just a template.”
Oleksandr holds two degrees — systems engineering and enterprise economics — from Cherkasy State Technological University. In the mid-2000s Eastern European tech scene, the second qualification was treated as an oddity. Engineers coded. Economists ran spreadsheets. Orlov spent the next two decades proving the distinction was always artificial.
The Management Problem Nobody Talks About
The majority of engineering organizations treat team structure as an org-chart exercise. Boxes, lines, reporting relationships. Oleksandr treats it as an engineering problem with the same rigor he’d apply to a distributed system: failure modes, redundancy, latency, throughput.
When Andersen was growing fast and Orlov found himself with 20 engineers reporting directly to him, the system broke. Not because the people were wrong, but because the architecture was wrong. He still recalls the number — twenty — with the precision of someone who remembers exactly when the informal approach hit its limit.
His solution was structural. Oleksandr designed a management architecture with layered accountability: project managers, delivery managers, their supervisors, each tier with defined decision authority and handoff protocols. He built the incentive layer in parallel — goal frameworks tied to measurable outcomes, individual development matrices for every engineering track, resource management systems calibrated to absorb the pressure of dozens of simultaneous client engagements.
The difference between that system and a conventional org chart is the same as the difference between a monolith and a microservice: when something breaks in one place, it doesn’t bring down everything else. When a delivery manager burns out or changes roles, the project doesn’t lose institutional knowledge with them — the system holds.
“Any organization is people,”Oleksandr says.“Where there are people, there will be human factors. What you can do is build systems that reduce the damage and raise the floor.”
Fixed-Price as a Technical Discipline
One of the most consequential decisions in software services is also the least discussed in engineering circles: how you price the work. Time-and-materials contracts put schedule and scope risk on the client. Fixed-price contracts transfer that risk to the vendor. Most development companies consider this a sales and legal question. Andersen’s CTO views it as an engineering one.
The PDS Competency Center — the internal framework Oleksandr founded at Andersen to govern fixed-price engagements — is, at its core, a risk pricing system. It arrived as a conclusion drawn from failure analysis.
Orlov built the PDS framework by examining every fixed-price engagement that ran over budget, every scope dispute that became a commercial standoff, every estimate that collapsed under undocumented conditions. He wasn’t looking for why a particular project went wrong. He was looking for the organizational condition that made that class of failure repeatable.
He kept finding the same gap. The organization had no formal mechanism for translating client expectations into engineering commitments at a level both parties could hold each other to. Estimates rested on assumptions nobody had written down. Scope was defined at the level it could be sold, rather than what the team could deliver. When conditions changed mid-project, there was no framework for evaluating what had altered or what it meant for the original commitment.
His dual academic background — systems engineering and enterprise economics, both completed at Cherkasy State Technological University — gave him an unusual lens here. Where most engineering leaders treated the problem as a delivery failure, Orlov treated it as a pricing failure. Every estimate is a bet. The question is whether the organization knows what it’s betting on and has priced the uncertainty correctly.
The PDS Competency Center was built to answer that question through four mechanisms:
- Formalized scope definition at implementation level;
- Documented estimation assumptions;
- Structured dispute resolution for mid-project scope questions;
- Milestone certification that gave client and team a shared view of progress at each stage.
The framework took years to stabilize. It was revised after every major engagement that stress-tested it.
Before PDS, “fixed-price” at Andersen meant talented engineers working against a deadline with individually negotiated assumptions. After PDS, it meant a repeatable process: common estimation models, shared scope protocols, and defined escalation paths. Thus, the system itself was standardized and accessible to everyone. Geographic distribution stopped being a quality variable.
The consequences were commercial as much as operational. When a team bases estimates on documented assumptions and defines scope at the implementation level, pricing reflects what the organization knows in reality. That transformation produced two outcomes Oleksandr considers equally important:
- Andersen stopped pricing engagements it would win and then lose money on;
- Clients received commitments the delivery team could stand behind.
These results change the character of the relationship from the first milestone.
The ProScan Imaging engagement makes the case concretely. A HIPAA-compliant national teleradiology platform supporting hundreds of U.S. clinics, delivered in roughly half the time of comparable enterprise healthcare projects. Not because the team was exceptional. Because the scope was clear enough that questions got resolved rather than disputed. Because the estimates were grounded enough that the project did not drift. Because the milestones were specific enough that both sides could see progress at every stage. The framework, developed by Oleksandr, is what made it reliable.
Profitable Technology Is Specific Technology
Oleksandr Orlov’s economics background shows most clearly in how he decides which services Andersen offers. The question he asks is not “Can we build this?” In a company of 3,500 engineers, that answer is almost always yes. The question is whether the market will pay for it at a margin that justifies the investment in people, infrastructure, and institutional knowledge.
He calls these “liquid services” — a term borrowed from financial markets. Liquid services have consistent demand, defensible pricing, and delivery that can be standardized across teams and geographies. In Andersen’s portfolio, they are the difference between sustainable growth and expensive capability that wins a few impressive contracts and never quite scales.
That framework drove Andersen’s technical expansion over the past four years. AI consulting passed Orlov’s test because enterprise demand for implementation expertise had outrun the supply of companies that could deliver it with process discipline. Managed services augmented by AI passed the same test. So did formal penetration testing — a security segment where American enterprises were committing serious budgets and where Andersen had the technical depth and the compliance credentials to compete.
“I want the customer to make money using our services,”Oleksandr says.“Even when you’re in a difficult stretch on a project — and there are those stretches — that goal doesn’t change.”
It is, in practice, the filter behind every service Andersen has launched under his watch: not what the company can build, but what the market demands right now. And what Andersen can deliver reliably enough to stake its reputation on.
Who Gets Hired, and Who Doesn’t
Ask Orlov about hiring philosophy, and he avoids the usual language about culture fit. He has a simpler test.
“I don’t like fake people,”he says.“Someone can exaggerate their abilities, but not more than ten percent.”
At peak hiring periods, he was running one or two technical conversations a day. His current cadence is roughly one per week. He doesn’t track the cumulative count and makes no apology for it.“I care about the person and the specialization,”he says.“The funnel is recruitment’s job.”
In technical conversations, he values people who can recognize what they don’t know.“The main issue with continuous education is understanding that you know nothing,”he says — a standard he applies to himself with the same consistency he applies to anyone across the table.
Oleksandr describes learning the way he’d describe scaling a system:“At the first step you reach with your hands. At the second you need a ladder. At the third, you need complex solutions and equipment.”He still uses the ladder and says so without embarrassment.
The people he won’t hire are those who paper over the gaps rather than name them. In an organization running dozens of concurrent engagements across multiple continents, that habit carries a cost that is anything but abstract.
Distributed Teams and the Difference a System Makes
Executing engineering operations across twenty locations creates a specific problem: the gap between what people are told to do and what theycando when the manager is seven time zones away. Orlov’s answer is building better systems:
“Horizontal and vertical management structures. Project managers, delivery managers, their supervisors. Goals, bonuses, development matrices, resource management,”he explains.
Oleksandr lists them the way a senior engineer lists components in a reliable architecture. Each element is load-bearing. None is decorative.
The same logic governs how Andersen handles AI adoption internally. Rather than mandating a single toolset across the company, Orlov built a dedicated internal unit whose job is to assess which AI instruments are useful for a given project context and to develop proprietary solutions where commercial products fall short.“We adapt the right instruments for each project,”he says.“AI agents have already become the standard. The question is how fast you can make them useful.”
His answer to that question was to build a system rather than issue a directive. At Andersen, that’s the default mode.
What P&L Means to an Engineer
Ask Oleksandr Orlov what separates him from other technical directors, and he doesn’t name a technology or a certification. He describes a habit of perception.
“Most people look from one side,”he says. “I try to look from the customer’s side, the user’s side, the implementer’s side. At the same time.”
It is, in practice, the same cognitive skill required to hold multiple system states in mind while debugging, applied across an entire organization. The implementer’s perspective reveals what’s hard to build. The user’s perspective reveals what gets ignored once it’s built. The customer’s perspective reveals whether any of it produces the outcome they paid for. Many technical leaders develop one of these fluently. Oleksandr treats all three as a single, inseparable lens.
That integration defines his career: technical depth combined with business judgment, as one compound discipline. The code tells you what’s possible. The P&L tells you what matters. The leaders who can read both at the same time are the ones who build organizations that scale alongside software they develop.
Andersen, 16 years after a handshake between two engineers in Cherkasy, now operates 20 international offices with a team of 3,500. The architecture of that growth was technical, organizational, and commercial at once — constructed by someone for whom those were never separate problems to begin with.