Your IT Department Is a Procurement Office

I want you to do something uncomfortable.

Go look at your IT department's organisational chart. Count the people. Now sort them into two buckets:

Bucket A: People who build things. Developers, engineers, architects who actually create software, systems, or capabilities that didn't exist before.

Bucket B: People who buy things. Vendor managers, procurement specialists, contract negotiators, implementation consultants, system administrators managing software someone else built.

What's your ratio?

In most organisations I've seen, it's 1:10. Sometimes 1:20. Sometimes there's no one in Bucket A at all.

Your IT department isn't a technology function. It's a procurement office with a technology label.

The Capability Vacuum

Here's how it happens.

Twenty years ago, your organisation had people who built things. Maybe a small development team. Maybe some database specialists who wrote custom queries. Maybe just a few people who could hack together solutions when needed.

Then came the SaaS revolution. "Why build when you can buy?" The logic was compelling. Vendors had dedicated teams, economies of scale, continuous updates. Building seemed expensive, risky, slow.

So you bought. CRM from Salesforce. HR from Workday. Finance from Oracle. Marketing from HubSpot. Project management from Monday. Communication from Slack. Storage from Box. Analytics from Tableau.

Each purchase seemed rational. Each vendor seemed competent. Each decision avoided the "risk" of building.

But something else happened with each purchase: capability left the building.

The people who might have built a CRM learned to configure Salesforce instead. The people who might have created custom analytics learned to drag and drop in Tableau. The people who might have developed integrations learned to manage vendor relationships.

Over time, the builders left for companies where they could actually build. What remained were buyers. Administrators. Integrators. People whose entire job is managing software that someone else created.

You didn't notice the shift because each step was small. You didn't notice the loss because you were solving immediate problems. You didn't notice the vacuum until you needed capability that couldn't be purchased.

Then you discovered your IT department doesn't know how to build anything.

The Procurement Mindset

There's a particular mindset that develops when buying is all you do.

Every problem becomes a purchasing decision. Need to solve something? Find a vendor. Issue an RFP. Evaluate proposals. Sign a contract. The question "could we build this?" doesn't even surface because building isn't something you do.

Success is measured by implementation, not outcome. Did we deploy the system on time? Did we stay within budget? Did we hit the go-live date? These are procurement metrics. They say nothing about whether the system actually solved the problem or created value.

Expertise means knowing products, not domains. Your "experts" know Salesforce configuration. They know Workday workflows. They know how to navigate vendor support. What they don't know is your actual business: how it works, what it needs, where technology could create advantage.

Innovation is whatever vendors sell. Your roadmap is driven by vendor announcements, not business needs. You implement features because vendors release them, not because users need them. Your "strategy" is a list of products you plan to buy.

Risk means project failure, not strategic irrelevance. You're optimised to avoid failed implementations. You're blind to the risk of falling behind competitors who build their own capabilities.

This mindset becomes self-reinforcing. The more you buy, the less capability you have to build. The less capability you have, the more dependent you become on buying. Eventually, purchasing is all you know how to do.

The Integration Tax

Here's what nobody tells you about the all-purchase approach: integration is where it falls apart.

You've bought fifteen best-in-class systems. Each one is excellent at what it does. None of them were designed to work with each other.

Now you need customer data from your CRM to sync with your marketing platform, which needs to connect to your analytics tool, which needs to pull from your data warehouse, which needs to receive inputs from your ERP.

This is where you discover the dirty secret of enterprise software: integration is a nightmare.

Vendors design for their own ecosystem, not yours. APIs are inconsistent, poorly documented, or paywalled. Data models don't align. Authentication schemes conflict. What should be a simple data flow becomes a Rube Goldberg machine of middleware, custom scripts, and prayer.

So you pay more. Integration platforms. Middleware consultants. Custom development (except you don't have developers, so you hire contractors who build something fragile and leave).

The integration tax is often higher than the software costs. And it's recurring, because every time a vendor updates their product, your integrations break.

I've seen organisations spending more on integration than on all their SaaS subscriptions combined. They've optimised for purchasing software and are drowning in the cost of making it work together.

The Knowledge Drain

When you outsource all building to vendors, you also outsource knowledge.

Your vendors understand your systems better than you do. They know how the architecture works. They know where the bodies are buried. They know what's possible and what isn't.

You don't.

This creates a dependency that goes beyond contracts. You're not just buying software; you're renting expertise. When you need to understand how something works (really understand, at a deep level) you have to call the vendor. And the vendor's incentive is to keep you dependent, not to educate you.

I've watched organisations try to make basic decisions about their own systems and fail because no one internally understands how anything works. They're not even sure what questions to ask.

This knowledge drain compounds over time. Senior people who understood the original implementations retire. Documentation was never created or is hopelessly outdated. Institutional memory evaporates.

What's left is a department that operates systems it doesn't understand, maintained by vendors who have no loyalty to your success.

The Career Consequences

Here's something we don't talk about enough: what happens to people who work in procurement-mode IT?

They become unemployable.

Not officially. They'll have impressive-looking resumes with recognisable company names and vendor certifications. But their actual skills have atrophied.

They know how to evaluate RFPs. They know how to manage vendor relationships. They know how to configure specific products. What they don't know is how to create anything.

In a world where AI is making building easier and faster, these people are on the wrong side of the capability divide. They've spent years developing skills that are being commoditised, not by AI, but by the very vendors they've been buying from.

The vendor ecosystem is designed to create certified administrators who can configure products and escalate to support. It's not designed to create people who can solve novel problems or build new capabilities.

When these people look for new jobs, they discover that "10 years of Salesforce administration" isn't as valuable as "built things that solved problems." They've traded building skills for buying skills, and the market is starting to notice.

The cruelest irony: the same "safe" career path that led them to procurement-mode IT is now the risky one. They avoided the uncertainty of building and ended up with skills that are becoming obsolete.

The Strategic Blindness

Procurement-mode IT creates a particular kind of strategic blindness.

When you can only buy capabilities, you can only have capabilities that are for sale. Your strategic options are constrained to whatever vendors offer. If no one sells what you need, you can't have it.

This matters more than it used to.

Differentiation increasingly comes from technology. The companies pulling ahead are the ones using technology in ways their competitors can't replicate. They're building proprietary systems, custom algorithms, unique integrations.

If your technology strategy is "buy best-in-class from vendors," you have exactly the same capabilities as every competitor who buys from the same vendors. You've purchased parity, not advantage.

Worse, you can't even see the opportunities you're missing. When building isn't in your vocabulary, you don't think about what you could build. You don't imagine capabilities that don't exist yet. You don't see the problems that could be solved with custom technology.

Your competitors who build are exploring territory you don't even know exists. They're creating capabilities you couldn't purchase if you wanted to. And they're compounding those advantages while you're comparing vendor proposals.

The Transformation Theatre

When organisations realise they have a capability problem, the response is usually: hire consultants.

This creates what I call transformation theatre.

A big consulting firm comes in. They do assessments. They create roadmaps. They produce beautiful slide decks with frameworks and maturity models. They recommend (wait for it) a bunch of technology purchases. Plus, conveniently, ongoing consulting engagements to manage the implementation.

Nothing actually changes. The organisation remains dependent on external parties. The capability vacuum persists. The only difference is that now there's a strategy document explaining the dependency.

I've seen organisations go through three, four, five "digital transformations" without developing any internal capability. Each transformation is a new set of consultants, a new set of vendor selections, a new set of implementations. The organisation remains as dependent as ever.

The consultants have no incentive to build your capability. Their business model depends on your continued dependence. They'll talk about "capability building" and "knowledge transfer" while structuring engagements that ensure you'll need them again next year.

True transformation would mean developing the ability to build: internal teams, internal skills, internal knowledge. But that threatens the consulting model, so it rarely gets recommended.

The Way Out

If your IT department has become a procurement office, here's how to start changing it.

Acknowledge the problem. The first step is admitting that your "technology function" doesn't actually create technology. This is uncomfortable, but honesty is required.

Start small. You don't need to transform everything overnight. Pick one small problem (something contained, something where failure is acceptable) and build a solution instead of buying one. Prove it's possible.

Hire differently. You need people who build, not just people who buy. This might mean different job descriptions, different interview processes, different compensation structures. Builders have different expectations than buyers.

Protect the builders. Early building capability is fragile. Procurement-mode thinking will try to kill it: "why are we building this when we could buy it?" You need executive protection for building initiatives until they've proven value.

Accept transition costs. You'll be paying for existing vendor systems while building new capability. This isn't waste, it's investment. The alternative is permanent dependency.

Redefine success. Stop measuring IT by projects delivered and systems implemented. Start measuring by problems solved and capabilities developed. The metrics you use shape the behaviour you get.

Build on AI. Here's the opportunity: AI makes building faster and more accessible than ever. A small team with AI assistance can create capabilities that would have required a large team a few years ago. You can rebuild capability faster than you lost it.

The Real IT Function

Let me describe what a real technology function looks like.

A real technology function understands the business deeply. Not surface-level, deeply. They know how value is created, where inefficiencies exist, what would change the game.

A real technology function identifies problems worth solving. Not problems vendors want to sell solutions to, problems that actually matter to the business.

A real technology function builds solutions. Not always (sometimes buying makes sense) but building is a genuine option, evaluated fairly against buying.

A real technology function owns its systems. Not in the legal sense, in the knowledge sense. They understand how things work. They can modify, extend, or replace systems without complete dependence on external parties.

A real technology function creates advantage. Technology isn't just a cost centre to be minimised. It's a source of differentiation, efficiency, and competitive advantage.

Does this describe your IT department?

Or does your IT department issue RFPs, negotiate contracts, manage vendors, and integrate purchased products?

The Uncomfortable Question

Here's what it comes down to:

If your IT department disappeared tomorrow and was replaced by a procurement team with technology buying authority, would anything actually change?

If the answer is "not much" (if the main activities are vendor management, contract negotiation, and system administration) then you don't have an IT department. You have a procurement office with a technology label.

And that procurement office is not going to help you compete in a world where technology capability is increasingly the difference between winners and losers.

Your competitors who can build are creating options you can't match. They're moving faster. They're differentiating in ways you can't purchase. They're compounding capability while you're compounding dependency.

The gap is widening.

You can close it. You can start building capability again. You can transform procurement-mode IT into a real technology function.

But first, you have to admit what your IT department has become.