When I started my career in technology consulting, most of the experienced consultants I encountered were technology people with a head for business. More than a few had MBAs, most had lots of experience in a specific industry. The rate of technology change was low, so the knowledge tended to be very long-lived. With a few exceptions, the top dollar consultants had broad based knowledge in technology and in the industry or industries where they worked; narrow specialists could command high coin, but for only as long as their area of expertise was in vogue. Tech had to meet the business where it was at.
The increasing rate of technology change meant an acceleration in the rate of knowledge obsolescence, at least of the tech. The typical tech consultant went from being broad based in both the business and the tech to being primarily, if not exclusively, focused on the tech. That high rate of technology change created a deficiency (real or perceived) for business buyers, who contracted consultants almost exclusively for tech competency. The business met tech where tech was at.
The rate of technology change was compounded by the rate of technological complexity: in hosting infrastructure, front end development, security, and the like. Complexity resulted in labor specialization.
While the profile of tech consulting labor was changing, tech lost its economic anchoring. Twenty years of cheap capital and a decade of startups and board mandates to “disrupt through tech” meant that for a very long time, cost was not a limiting factor for tech. Meanwhile, specialized labor means it takes thirty people to create a solution that had previously taken four. Not because the business problems are more ambitious, but because the tech has become more complex.
Not surprisingly, estimation got deprioritized. It was already derided by many in the software community because “all estimates are wrong”. In its place, we got open loop planning: great precision as to how we start, but only a vague idea for how we finish. Either time and therefore cost is unlimited (it will take as long as it will take) or features are limited (we get done whatever we get done until the money runs out).
Capital is expensive again, and because it is expensive capital controls are tighter. Yet we still see a reluctance to give up open-loop planning. This reluctance is understandable if for no other reason than it effectively alleviates responsibility for financial accountability.
One of the things buyers of skilled labor value from experts is their ability to forecast with a reasonable degree of accuracy. Based on similarly sized goals, similar constraints, and the expected similar skeletons in the closet, this should take between x and y months and cost between n and m dollars, and toss in a contingency of z%. Investors ask this of general contractors of commercial and residential building projects, because investors have to line up the financing, and the financiers have to agree that the capital will yield an asset that will either throw off cash flows from tenants and / or be of sufficient value in the event of a default.
Which brings us back to the change in profile of the technology consultant. Being reluctant to do something often belies an inability to do something. The vast majority of problems being solved through tech today are not so new and so novel that they are truly voyages of discovery: they’re second or third generation solutions to problems long ago solved through tech. They’re pretty pedestrian. What has changed is that tech labor has moved away from tech fluency twined with domain familiarity and into increasingly narrow tech knowledge silos. Where tech consulting once led with expertise, it now hides behind expertise. In the process, it is the buyer, not the supplier, who is responsible for the efficacy of the experts.
This is a complete reversal of the transmission of value between the consultant and the consulted.
The next time a tech company touts its commitment to business value over tech, ask whether they put their money or your money where their mouth is.
Dear reader, I believe I have a fix so that The Agile Manager is accessible through https. I will attempt this fix in late June. It may disrupt access to the blog. I appreciate your patience, and of course your readership.
