I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Tuesday, November 30, 2021

Do we need IT Departments?

The WSJ carried a guest analysis piece on Monday proclaiming the need to eliminate the IT department. While meant to be an attention-grabbing headline, it is not a new proposition.

Twenty years ago, the argument for eliminating the IT function went like this: while IT was once a differentiator that drove internal efficiency, it was clearly evolving into utility services that could be easily contracted. And certainly, even in the early 2000s, the evidence of this trend was already clear: a great many functions (think eMail and instant messaging solutions) and a great many services (think software development and helpdesk roles) could be fully outsourced. Expansive IT organizations are unnecessary if tech is codified, standardized and operationalized to a point of being easily metered, priced and purchased by hourly unit of usage.

While the proponents of disbanding IT got it right that today’s differentiating tech is destined to become tomorrow’s utility, they missed the fact that tomorrow will bring another differentiating tech that must be mastered and internalized before it matures and is utilified. Proponents of eliminating the IT function also ignored the fact that metered services - particularly human services - have to be kept on a short leash lest spend get out of hand. That requires hands-on familiarity with the function or the service being consumed, not just familiarity with contract administration.

The belief that enterprise IT departments should be disbanded is back again. This time around, the core of the argument is that a silo’d IT organization is an anachronism in an era when all businesses are not just consumers of tech but must become digital businesses. There is merit in this. Enterprise IT is an organization-within-an-organization that imperfectly mirrors its host businesses. IT adds bureaucracy and overhead; hires for jobs devoid of the host business’ context; and by definition foments an arms-length relationship between “the business” and “IT” that stymies collaboration and cooperation and, subsequently, solution cohesiveness. Not a strong value prop there by today’s standards.

Today, [insert-your-favorite-service-name-here]-aaS has accelerated the utilifcation of IT even further than most could imagine two decades ago. And, or at least so the argument goes, modern no-code / low-code programming environments obviate the need for corporate IT functions to hire or contract for traditional language software developers. Higher-level languages that non-software engineers can create solutions with reduces the traditional friction among people in traditional roles of “business” and “IT”.

Best of all, there is a reference implementation for disbanding centralized IT: the modern digital-first firm. While a digital-first firm may have a centralized techops function to set policies, procure and administrate utility services, it is the product teams that are hybrids of business and tech knowledge workers create digital solutions that run the business.

If you had the luxury of starting a large enterprise from scratch in Q4 2021, you would have small centralized teams to create and evolve platform capabilities and standards from cloud infrastructure to UX design standards, while independent product teams staffed with hybrid business and technology knowledge workers to build solutions upon the platform. The no-code / low-code tech notwithstanding (these tend to yield more organizational sclerosis and less sustainable innovation, but that’s a post for another day), this is a destination state many of us in the tech industry have advocated for years.

So why not model legacy enterprise IT this way?

Why not? Because enterprise IT isn’t the problem. I wrote above that enterprise IT is an imperfect mirror of its host organization. However, the converse is not also true: the host business is not an imperfect mirror of its enterprise IT function. In the same way, enterprise IT is a reflection of an enterprise problem; the enterprise problem is not a reflection of an IT problem.

Companies large and small have been reducing equity financing in favor of debt for over a decade-and-a-half now. A company with a highly-leveraged capital structure runs operations to maximize cash flow. That makes the debt easily serviceable (high debt rating == low coupon), which, in turn, creates cash that can be returned to equity holders in the form of buybacks and dividends. Maximizing cash flows from operations is not the goal of an organization designed for continuous learning, one that moves quickly, makes mistakes quickly, and adapts quickly. Maximizing cash flow is the goal of an organization designed for highly efficient, repetitive execution.

The "product operating model" of comingled business and tech knowledge workers requires devolved authority. Devolved authority is contrary to the decades-long corporate trend of increased monitoring and centralized control to create predictability, and consolidated ownership to concentrate returns. Devolved decision-making is anathema to just about every large corporate.

Framing this as an “IT phenomenon” is the tail wagging the dog. As I wrote above, enterprise IT is an imperfect reflection of its host organization. Enterprise IT is a matrix-within-a-matrix, with some parts roughly aligned with business functions (teams that support specific P&Ls, others that support business shared services such as marketing), while other IT teams are themselves shared services across the enterprise (in effect, shared services across shared services). Leading enterprise change through the IT organization is futile. Even if you can overcome the IT headwinds - staffing lowest-cost commodity labor rather than sourcing highest-value capability, utility and differentiating tech under the same hierarchy - you still have to overcome the business headwinds of heavy-handed corporate cultures ("we never making mistakes"); studying mistakes and errors for market signals indicating change rather than repressing them as exceptions to be repressed; and capital structures that stifle rather than finance innovation. Changing IT is not inherently a spark of change for its host business, if for no other reason than no matter how much arm waving IT does, IT in the contemporary enterprise is a tax on the business, a commitment of cash flows that the CEO would prefer not to have to make.

To portray enterprise IT as an anachronism is accurate, if not a brilliant or unique insight. To portray enterprise IT as the root of the problem is naive.