Suppose your implementation team finally gets an AI workflow working. It produces useful first drafts of integrations, catches routine mistakes, and cuts down the time spent writing documentation. Engineers still review the output, but the improvement holds up after review.
At the next budget meeting, someone asks whether you still need the whole team.
You also have customers waiting to go live. A deal is stuck because nobody has time to build an integration. An experienced engineer keeps getting pulled into the same onboarding problem, which everyone agrees should have been fixed months ago.
I’d want to see what that team could deliver before cutting it.
Assume the AI works exactly as advertised. Why would a company with unfinished, valuable work make getting rid of the people who can now do it its first priority?
The salary savings are easier to put in a spreadsheet. I understand the attraction, especially when cash is tight. A CFO can estimate what removing two positions saves next quarter. The head of implementation has a harder argument: keep those people, give them different work, and expect more customers to get through onboarding.
One number looks solid. The other needs assumptions.
But the apparent certainty is misleading. The payroll reduction is measurable; the effect of losing those people is still a forecast. Someone is assuming the remaining team can absorb the exceptions, cover absences, and handle the next awkward customer without slowing delivery. Those assumptions deserve scrutiny too.
A growth proposal shouldn’t have to prove every future dollar while a cost-cutting proposal gets to ignore the work left behind.
Start with what actually became faster. If AI writes an integration in an afternoon, that’s useful. It doesn’t tell you whether the customer has agreed on what the integration should do.
In our example, sales promised to sync “active customers.” The customer’s finance team and account managers mean different things by active. An engineer has to find that out, get a decision, and keep it from becoming a production problem. Generating the connector was only part of the job.
Now suppose the AI gets good at flagging that ambiguity too. Fine. Give the engineer a better brief. There’s still a waiting customer whose project could move forward with the time saved.
The argument for keeping someone should survive improvements in the technology. If it depends entirely on AI continuing to make mistakes, it’s a weak argument.
The more interesting question is whether that employee can now take responsibility for work the company has been neglecting. That might mean handling another implementation, fixing the recurring onboarding problem, or turning a custom integration into something the next ten customers can use.
There is evidence that working with AI can improve performance, although it doesn’t settle staffing decisions. The 2023 NBER working paper Generative AI at Work reported roughly 14% more issues resolved per hour among customer support agents with AI assistance. Gains were concentrated among less experienced and lower-skilled workers, with minimal gains among the most experienced and highly skilled. Read the study.
The P&G experiment in The Cybernetic Teammate is uncomfortable for a simple “keep every team intact” argument: individuals with AI matched teams without AI on the innovation tasks studied. It also found that AI helped people produce proposals combining technical and commercial perspectives, and that human judgment retained value in selecting ideas. The results give leaders reasons to reconsider how work is divided. They don’t establish what staffing decision will grow your particular business. Read the study.
There’s a less comfortable part of this conversation that rarely fits into an AI productivity presentation.
Imagine you’re the employee who built the workflow. You tried the tools, figured out where they failed, and wrote down a process other people could use. Management celebrates it. Then a colleague loses their job because the team is now more efficient.
A few weeks later, management asks everyone to share more automation ideas.
You might have some hesitation.
You may still use AI. You might just stop advertising how much time it saves. Or avoid spending your own time teaching others a method whose reward appears to be another staffing review.
That is a plausible response to the incentives. If leadership wants people to expose inefficiencies and share what they know, it needs to think about what happens to the people who cooperate.
I wouldn’t solve this with a promise that nobody will ever lose a job. A company may not be able to keep it. I’d start with a narrower commitment people can evaluate: during a defined trial, use the released time to clear specific customer work, involve the team in choosing it, and judge the result before deciding what comes next.
Give people working hours to learn. Credit the employee who improves the shared process, including when someone else gets the resulting productivity gain. Be clear about which responsibilities are changing. Don’t announce that everyone is becoming more strategic and leave them with the same workload plus responsibility for checking AI output.
Back at our software company, this requires some fairly ordinary management work.
Pick the customers already waiting for implementation and confirm they’re ready to proceed. Assign owners. Agree on what has to be working for each customer to accept delivery. Reserve time for those projects by removing other commitments.
The AI can prepare project briefs from approved records, draft mappings, propose tests, and assemble documentation. Engineers can work through unresolved requirements with customers and check the parts where errors would be expensive. They should adjust that division as they learn what the system handles reliably.
A customer needs to be using the product sooner. If the team generates twice as many drafts and every draft waits a week for the same senior engineer, you’ve given that engineer a bigger queue.
So give the senior engineer time to improve the tests and review process. Have another employee turn the recurring onboarding issue into a documented fix. Let the people closest to the work tell you where the hours actually go; a manager’s guess from a ticket dashboard may miss most of the delay.
“We’ll use AI to grow” needs to get this specific.
When evaluating an enterprise AI provider such as Coryntas, bring the work your team keeps postponing: the integration nobody has time to build, the customers waiting for onboarding, the recurring problem everyone keeps fixing by hand. Ask what your existing team could get done with the right support.
Perhaps it can bring waiting customers live sooner, accept an integration-heavy deal it previously couldn’t service, or support additional customers without immediately hiring another implementation team.
These are different bets. Choose the one you can test against real demand.
For this example, a sixty-day trial could be enough to see whether comparable implementations are moving faster, how much correction they require, and whether the backlog is shrinking. It would not establish a long-term revenue effect by itself.
Count training, software, review, and maintenance costs. Check working hours too. If the team is finishing more because everyone works later, the experiment hasn’t shown what you think it has.
Finance belongs in that review. Ask it to help compare the contribution from additional work with the savings from a smaller team, over a period the company can actually afford.
And follow the result beyond engineering. Earlier delivery only brings revenue forward where the commercial terms make that true. An integration only helps win business if customers want it. A customer waiting on their own security review may remain blocked no matter how quickly your team writes code.
Keeping people is not automatically a growth strategy. Neither is buying them AI tools.
There are businesses with too little cash to wait for a redeployment experiment. There are teams whose workload has genuinely disappeared, with no useful adjacent work they can take on soon enough. Leaders have to make difficult decisions in those situations, and an article about augmentation shouldn’t pretend otherwise.
But that is a different situation from a company with demand it cannot serve, problems it cannot get around to fixing, and employees who have just found a way to free up some time.
In that company, I’d want the CEO to spend at least as much effort finding a productive use for those people as calculating the savings from removing them.
There is a hard decision hiding inside that request. Retaining the team means management has to choose work, clear obstacles, and take responsibility if the additional capacity produces little value. It is no longer enough to report that employees are using AI.
The implementation manager should come to the next budget meeting with named customers, delivery dates, the work being dropped, and an estimate of what completing those projects is worth. The CFO should challenge it. The team should have a chance to deliver it.
If the case falls apart, deal with that honestly.
But if the company can finally serve the customers it has kept waiting, why would making the team smaller be the obvious next move?
Top comments (0)