Technology services firms are going heavy on AI in delivery of services. This is motivated by need: services have been a tough market for a couple of years now, and AI is one of the few things every potential client is interested in. But it’s been difficult for services firms to get a lot of AI gigs. It’s a crowded field with not enough case studies to go around; this makes it difficult for potential customers to justify renting consulting labor when the starting point with their own staff is no different. Not to mention, most companies regard their AI investments as core intellectual property: they want the skills and knowledge that creates it indigenous to their payroll.
Tech services firms are instead applying AI to their own offerings to do things like accelerate the reverse-engineering of existing code and expedite forward engineering of new solutions. Those firms are developing proprietary products to do this (e.g., McKinsey last week posted a blog touting their proprietary AI platform for “rejuvenating legacy infrastructure”). The value prop is that by using AI tools, solution development takes less time and therefore costs less money and presents less risk.
This has ramifications for the consulting business model. The “big up front design” phase that lasts for months (if not quarters) is going to be a tough sell when the AI brought to bear is touted as a major time saver: in the minds of the buyers, either the machines speed things up or they don’t. But the real problem here isn’t just erosion of services revenue, but something far more elemental: bulge bracket consulting firms use that big up front design phase to train their employees in the basics of business on the customer’s dime. Not the customer’s business. The basics of business. A lot of workshops during that up front design time cover Principals of Financial Accounting I for the benefit of inexperienced staff.
(Before scuffawing at that notion, if you’ve ever worked in order management, think about the number of consultants who had no grasp of order-to-cash; who did not understand the relationship, let alone the difference, between sales orders and invoices; who did not understand the relationship of payments to invoices; who did not understand RMA. This is not “learning the customer’s business.” This is learning business. I could go on.)
And, of course, AI tools are accessible to anybody - not just to people in tech. This means that anybody can compose a prompt and get a response. To get value from the tools requires that the consumer be able to adjudicate what the tools produce. Even the most thoroughly articulated prompt is prone to yielding a GenAI response that is syntactically correct but does not actually work. That statement doesn’t apply just to code. Humans make solution design mistakes all the time; any synthetically produced response will require human validation. Adjudication requires expertise and first hand knowledge, and not just of the tech but of the problem space itself.
AI tools make verbs like solution definition, construction, and deployment less inaccessible to non-technology people. The more that progresses, the less valuable the knowledge in those areas becomes because it reduces knowledge asymmetry between tech person and non-tech person. At the same time, as long as AI generated responses must be verified and validated, there will be a premium on adjudication.
Please understand what I am not saying here. I am not saying AI has or is about to make those verbs highly accessible to non-technology people; I am saying AI - specifically, GenAI - has made those verbs less inaccessible to non-technology people. I am also not saying AI generated responses are instantly production ready; I am saying the opposite.
The net effect is a disruption of the traditional tech--business relationship. Tech labor is at a disadvantage from this disruption.
Giving AI tools to people who are unable to assess fitness for purpose of the output those tools produce will not increase labor productivity. A product manager who is not knowledgeable in the domain cannot exercise the one decision right a product manager is required to exercise: prioritization. Similarly, a developer or QA engineer who doesn’t understand the domain can only certify code as far as “nobody can tell me it isn’t right”. The more AI tools are used to produce something - requirements, technical architecture, code, tests - the more important the human evaluation of that output becomes. Anybody who cannot evaluate the fitness for purpose of what their AI tools produce will be reduced to being implementers and stage managers for those who can.
Stage management does not command a premium rate.
Tech services firms will eventually cannibalize the consulting business model with AI. Well, perhaps it’s more accurate that AI will eventually cannibalize the consulting business model of tech services firms. To avoid being caught out in a market shakeout, services firms have to do two things. One is to no longer rely on knowledge of technology and get much, much more in-depth in their knowledge of business, and in particular the knowledge of their customer’s business. The second is, armed with that knowledge, to define entirely new categories of technology-informed services to sell.
Tech services firms are in an AI arms race in a war for contracts. It’s not obvious they’re preparing to win the peace that follows.
