Can the outsourcing company you bought transition to the AI Consulting Org Design?

Context from the first article

In the previous article on the two diligence landmines in software outsourcing, we’ve talked about how traditional software outsourcing are increasingly getting squeezed between a loss of revenue and the difficulty to become an AI consulting / delivery firm.

This presents a challenge for software outsourcing owners, an opportunity for the prepared seller and an opportunity for the right buyer.

Here, we’ll focus on Org Design (OD): what has to change in the way the company is structured to deliver AI solutions, and how this translates into buyer Due Diligence (DD) and value creation playbook preparation.

First, for the non-tech buyer, let’s have a high-level view of how most software outsourcing companies are organized.

Traditional SDLC OD

Outsourcing companies are essentially a cost-plus business (pay engineers x, sell engineers x + margin), so the basic commercial engine is simple:

• Find clients who need some engineering capacity.
• Bill for such engineering capacity.
• Keep utilization as high as possible (eg engineers may not be full time on a single client).
• Renew or expand the account.
• Repeat.

Given that business model, the following OD naturally follows:

• Sales find clients.
• An Account Manager takes over and tries to keep the client happy, expand the account, and prevent churn.
• Delivery Managers are responsible for making sure the company can actually deliver what was sold. They sit between the client, the commercial team and the delivery team.
• A Resource Manager acts like an air traffic controller for engineering capacity. S/he optimizes every engineer working hour into a billable hour, by knowing who is available, who is rolling off a project, who can be moved to another client, etc.
• Then you have all the delivery units. The people who deliver the work. Developers, QA/testers, business analysts, etc.

I am over simplifying but this OD allows for 4 commercial variations:

• The billable-hour model: client buys people by profile. One senior backend engineer, two frontend engineers, one QA, maybe one part-time DevOps engineer. The outsourcing company makes money on the spread between what it pays the engineer and what it charges the client.
• The dedicated team model: client gets a more stable team over time. The team may include Software Engineers, QA testers, a Business Analyst, a Project Manager, maybe a Tech Lead. It feels more embedded. But commercially, it is still sold as a team.
• The managed team model: client does not just buy individual engineers. It buys a team with some management layer around it. That usually means a Project Manager, Delivery Manager, Tech Lead, QA lead and sometimes a Solution Architect.
• The fixed-scope project: clients wants to pay for a defined output at a defined price. This looks more outcome-oriented, but internally it is still depends about shuffling people around.

So this is it. That is the machine you buy if you buy a software outsourcing company.

It worked well and often generated EBITDA margins in the mid teens, when well managed.

However, this OD is not suited for AI consulting and AI delivery. Why?

The old SDLC OD is anchored around what used to be a scarce capability: software engineering.

That has become a commodity, courtesy of Claude Code and Codex (CCC).

True, AI is not replacing good judgment. But that’s not what you’re buying. You’re buying a company relies entirely on its staff to generate revenue (of which roughly 70% of them should be billable and actually generate money), of which a big chunk are becoming replaceable by the almighty tokens.

As a buyer, you already know this. So this begs the next question: since tokens are a variable cost and produce extremely high quality code, how will you re-organize the company if the play is to make it an AI consulting + delivery company?

Enter: AI SDLC and the new OD.

AI SDLC and the new OD

First, let’s avoid the common mistake of thinking “Take our current team and give CCC to get our engineers to code faster”.

The reason: as we mentioned in the previous article, SDLC is process-bound, not engineering bound.

Faster code at the engineer level doesn’t (and cannot) equal to faster delivery, if the entire SDLC is the same (eg a Business Analyst writes requirements, creates stories and tickets in Jira, which the Dev implements, after which a QA tests, etc.).

Instead, you must do the difficult thing of throwing the old OD diagram above to the trash, and make a new one.

Let’s take a detour and take a look at a SaaS OD. SaaS OD and AI OD are similar in spirit so this should make the mental transition easier.

In a product company, you don’t sell billable hours. You sell value, in the form of implementing stuff that solves the client’s operational problems.

Therefore, you don’t need all the overhead and complexity of an outsourcing company. No more RM and obsession over squeezing every working hour into a billable hour. The obsession is over the customer, which, in an AI consulting + delivery company, is actually what you want.

As the company scales, the OD adjusts. You may end up with distinct product lines, implementation teams etc. But it never becomes an outsourcing-like OD.

Should the “AI OD” look like the “SaaS OD”? Only in spirit.

The useful concept to borrow from is the one of “delivery pod” - eg small but highly capable teams, as close to the customer as possible and with decision authority on what to build.

Here is the stylized version of the AI-native OD.

How AI-native OD works in a nutshell:

• The sales / AI Consulting still closes the commercial deals. They must identify the person in charge (PIC) for the workflow at hand. AI transformation is all about workflow transformation.
• Ideally, you’d want to have 1 PIC representing 1 key workflow as to not dilute ownership and authority. This is the person your Deployment Strategist will mainly talk to
• The Deployment Strategist’s job is to understand the business case, specific workflow (say, KYC workflow or credit pre-scoring workflow or whatever the workflow of the client is), and sketch out the AI solutions, within the constraints of the client (regulation, tech environment requirements, etc.). This means she’s a mix of AI architect / senior engineer + your old PM in the SaaS world + a dash of your Tech pre-sales in the outsourcing world
• That person works closely with an AI engineering pod (or workflow pod) made mostly of AI engineers (recommended profile below)
• AI engineers understand AI architectures, manage AI coding agents, build and deploy the solution, implement AI evaluations, use AI to test the outputs, handle technical tradeoffs - in other words, anything that has to do with building and deploying the AI solution
• Pods have another layer of supporting functions, and greatly augmented by coding agents

You will notice that a few roles are gone relative to the SaaS OD: PM, BA, designers and QA.

This is because AI coding agents (when used properly) compress the work of these teams, while the Deployment Strategist is a much more complex role than the PM one (although it still interfaces between the client and the delivery teams). This is what enables much shorter feedback loop with the client.

Now, one caveat. The above AI OD is the ideal direction to shoot for and is actually still pretty rare. Palantir showed the world how to do it with the “FDE” model (Forward Deployed Engineer - which is essentially a more complex version of the above OD). But there’s only one Palantir :)

In most cases, you’ll end up with a hybrid version first, tending to the ideal. But there is one big challenge with the AI-native OD.

In the AI-native OD, a lot hinges on the AI engineers, so one need to discern what makes an effective one.

So here’s our recommended shortlist.

What makes AI engineers effective ones?

Here’s a shortlist of what we think as the key traits of effective AI engineers:

• Strong software architecture judgment in general (not just AI)
• Understanding of how to build strong AI harnesses and the governance layers required in real-world applications.
• Deep fluency with managing and working with AI coding agents.
• Enough domain understanding to implement the client’s AI workflow.
• Enough delivery ownership to move from problem discovery to prototype to deployment without waiting for five separate roles to give approval.

Some of this may sound abstract to the non initiated (AI harness? governance layer? managing AI agents?). You also notice we don’t say things like “must know how to train a model” or “have 10 years of experience in machine learning”. These are actually not needed. But bear with me, it will become clearer in the next post about what AI engineering is really about.

For now, what should be clear is that the profile above doesn’t look like most traditional SWE, which is your challenge. Point #2, #3 and #5 are where it is still hard to find the right fit.

So you should bet on an org transformation that relies on building internal talents more than buying them from outside. Realistically, there just won’t be that many around.

Therefore, as part of your pre-IC DD, you need a practical way to estimate which existing engineers are the most likely to form your new AI pods. You cannot escape it.

Which is the topic of the next section.

A good way to assess AI-transition-readiness among SWE

The seller will probably give you a list of engineers by seniority, tech stack (.NET, JS, Java etc) etc. In the context of an AI transformation, that is not very useful.

When it comes to talents, your goals should be to have a clear-eyed view on:

• How motivated and capable are the people who run the legacy business? Can we count on them to keep running the show?
• Who are the next people to build out our AI delivery muscles? How do we close the gaps?

#1 is probably already a standard part of your DD. #2 is newer, so here are some suggestions.

Ask the seller to give you the following:

• A stack-ranked list of all the people who fit the criteria for an AI engineer (use the trait list above). Do not expect that there will be many, however you want to make sure you know who they are if they actually are already in the org. Let’s call them the “FDE HIPO” (Hi-Potential)
• Give me a separate list of the following SWE: 8+ years of working experience with 3+ large projects under their belt. Let’s call them “Principal SWE” as a shortcut (not a formal job title). Depending on the list you get, be flexible (you could include 6 years but more projects for example)
• For the specific industry vertical that you want to serve, give me a list of the people you think have the deepest understanding of the industry workflows. Let’s call them “Functional SME” (Subject Matter Experts)

We think of that as the bare minimum. Of course, you’ll also want the list of the top sales people, but that’s business as usual so I didn’t list it here.

Next, what you want is to interview each person in each group. Again, it is quite unlikely that you will end up with hundreds, so it is feasible. Your goals is to figure out the following:

• FDE HIPO: use the WHO method of interviewing by Geoff Smart and Randy Street but adapt it to the criteria for ideal FDE we talked about earlier. These are your A-people in AI pods, and the first to get on a new AI client
• Principal SWE: assess overall architecture experience (that’s why you need at least 3 big projects) and ask situational questions on AI SDLC practices. You also want a feel for degree of ownership and how they think about working with AI agents. Lack of familiarity in a specific customer workflow shouldn’t be a killer at this point. The right ones can pick up speed quickly and can build your next AI pods
• Functional SME: assess actual understanding of complex, real-world industry workflow. Use an external functional consultant for the functional questions, and your judgment for their ability to work directly with clients and AI engineers. Although they are technically part of the “support team” in the AI OD diagram above, they are a key complement to a good delivery

These interviews get fairly technical and requires real AI deployment experience in real AI SDLC settings to ask the right questions, in the right context. We highly recommend you to bring in external help for such high-value interviews. After all, they will be key inputs for your value creation plan.

The output of this exercise is a map of your future AI talent pool. People who can potentially drive and deliver AI delivery forward, provided the right compensation and authority is offered.

What about the rest (eg the majority of the teams you buy)? Current projects must keep bringing in revenue, and depending on market conditions you may have to budget for an incentive to get these legacy contracts over the finish line.

We also recommend having a clear path to joining the new AI revenue units, which is part of why you need an AI upskilling program in your value creation plan.

Now let’s talk about what to include in that plan.

What to include in your value creation playbook

I will assume here that you are the kind of activist buyer who believes in operational and revenue improvement.

Meaning: you either have or can find operating partners who can roll their sleeves up and execute on value creation for you.

Here’s what the value creation playbook should include, specifically for an AI transformation:

• Bring in the first few AI contracts and treat them as lighthouse AI customers. The sooner, the better. Of course, refrain from this if you have zero confidence that the team will be able to deliver
• Along with the above, bring in an AI operating partner. Someone who can run the technical pre-sales, provide technical oversight and guidance to your FDE HIPO and help upskill the team as the delivery goes. Needless to say, you need someone who’s been there, done that. S/he will bear the brunt of the initial transformation, both from a people and technical side.
• Have a time-bound, name-specific pod that will be assigned for the lighthouse projects. Install a top down and “let’s go get this done” mentality. Do not leave room for internal and eternal debates, which can run deep in outsourcing cultures. The AI operating partner must know how to drive this.
• Pick an industry vertical to the extent possible. Don’t do a lighthouse customer for healthcare, another one for automotive and yet another want for insurance claims. The goal is to concentrate the bets at first as to shorten the transition curve to an AI SDLC, and start identifying patterns that can lead to revenue upsell or even productization later
• Start pricing these AI lighthouse projects differently. It doesn’t matter if it’s not perfect at first. What matters is to start charging for value and outcome delivered, not billable hours or body count. Your CFO must get involved.
• Consider bringing in an AI CTO who has already built and deployed an AI solution for paying clients (eg not the typical “we built a chatbot”). While the company you’re buying probably has a CTO, it’s probably not an AI CTO. We think of it as an insurance to make sure the right architecture is delivered.
• After 2-3 successful AI deliveries, start building an AI upskilling program. You will need to hire an external instructional designer for this. Think of the AI operating partner as being the leading subject matter expert on what / who to train, and the instructional designer as the one deciding the sequence, structure, methods to maximize skill transfer versus theory, etc. Don’t dream of having this done in-house or by HR. That’s just not in their lanes.
• Re-design the incentive scheme. With a much higher degree of ownership required from the client-facing pods, one would expect compensation to be aligned. As far as we know, some traditional outsourcing firms pay bonuses at the end of the year based on the company revenue goals. To super charge delivery at the speed of AI, incentive must drive behaviors, not just people management. This deserves an entire post on incentive schemes.

One big caveat: I would not even start the transformation / new client AI project without an AI Operating Partner, thinking that “someone in the existing team can do this. They have institutional authority and they already get along well with everyone”.

It is exactly because of that historical baggage that they won’t make the hard decisions when needed, not to mention that they naturally will bring years of outsourcing mindset into a consulting business, supercharged by faster delivery cycles and high ownership, to deliver something they probably have never delivered before. In other words, very high risk.

So take your time finding the right AI operating partner. It will pay off hugely. Not doing so may end up costing you the company.

Key take aways

This is it! Here is a TLDR on how to assess the AI-transformation readiness of a traditional software outsourcing company:

• Traditional outsourcing companies are organized to sell and manage billable capacity. That machine was built for the old SDLC, not AI-native delivery, and need a complete overhaul, not tweaking
• AI does not just make engineers faster. It compresses parts of BA, SWE, QA, DevOps and solution architecture work into smaller, more autonomous delivery teams. The new OD must reflect that.
• The scarce activity is no longer writing code. It is the AI SDLC process itself, staffed with people who can understand the client workflow, architect the system, manage AI agents, handle deployment risk and ship to stakeholders.
• In pre-IC diligence, map the future AI talent pool. Identify FDE HIPOs, Principal SWE candidates and Functional SMEs. Do not rely only on seniority, tech stack or management’s view of who is “strong”. Use the “AI engineer trait checklist” as a starter
• In value creation, the top #3 recommendations are: bring the first lighthouse AI customers, a strong AI operating partner, and focus on a specific industry vertical
• Other secondary recommendations in value creation once you nailed the top #3: rework pricing and incentive schemes to align the org on the outcomes / impact delivered to clients

Next up, we’ll talk about the nebulous topic of “AI engineering”. It means different things to different people, and to the non-tech person, it is often just a jungle of jargon. Yet, we think everyone should have a sound understanding of this, as to not be sold AI fluff or make the wrong business decisions.

Stay tuned!

Note on the grief curve among SWE

A friend of mine who’s been running an outsourcing firm for 20+ years shared this insight:

When it comes to AI adoption, SWE go through the typical “5 stages of grief”.

I’ve added some of my own observations and practical recommendations.

The 5 stages of grief of SWEs:

• denial (AI is not good enough, it makes mistakes, etc.),
• anger (SWE realize CCC are excellent coders and therefore feel threatened),
• bargaining (they stick to using CCC as a debugger companion, while wondering if they should really pick up AI),
• depression (there is no “curriculum” of “this is how to go from SWE to AI SWE”, so they try to figure things out by themselves, and a quickly swallowed by the topic)
• and acceptance (give up, or emerge as a confident AI engineer)

The grief curve is useful because it gives you stylized categories to put SWE in, based on behaviors and not based on what the seller tells you.

Of course, don’t go and ask the seller to categorize their SWE in those 5 buckets. But the idea is that by talking to SWE you can pretty much know what to expect of them, hence the value of targeted interviews and the short lists.

While seniority matters, I have personally seen senior SWE be in stage 1-2 as much as mid-level SWE. In fact, resistance is perhaps to be anticipated, since they are probably the most threatened. So it is a matter of mindset and open mindedness, not engineering expertise.

Funnily enough, I do see lots of junior engineers jump straight to stage 4. They have no-to-low historical baggage to start with, so they’re willing to try every AI tool and framework out there to get a job (and maybe displace the mid-level SWE who drags its feet). Quality is often horrendous. But that’s something that can be fixed. Mindset is harder to fix.

In general, our recommendation is to focus on bucket #4 and #5.