In my previous article in the Engineering Leadership Playbook, I wrote about engineering budgets in the AI era.

The central idea was simple:

Don’t optimize engineering for lower cost. Optimize it for greater human leverage.

AI should not simply become a reason to ask, “How many engineers can we reduce?”, rather we ask:

“How can we make every engineer more capable?”

That naturally leads to the next question:

Where do we create that leverage?

One of the biggest opportunities, in my view, is Platform Engineering.

It is even more important in today’s time when AI is not only changing how we write software, but also the economics of how we build engineering capabilities themselves.

The engineering tax nobody talks about

In last two decade of serving modern engineering organizations and clients, I noticed something uncomfortable.

Some of the best engineers aren’t always working on customer problems.

Rather

• They’re fixing CI/CD pipelines.
• Waiting for environments, licenses
• Configuring cloud resources.
• Managing permissions.
• Setting up dashboards.
• Debugging deployment issues.
• Searching through documentation.
• Creating yet another service template.
• Setting up AI harness, prompt/context library

None of this work is inherently bad. In fact, somebody needs to do it, but the problem is - every engineering team does it independently, repeatedly.

Imagine 50 teams each spending time solving the same infrastructure, deployment, security or observability problem. At the end we haven’t created 50 solutions, rather we’ve created 50 copies of the same solution, and we continue paying for them through engineering time.

That is the hidden tax of modern software engineering. I call it engineering friction. And when you have hundreds or thousands of engineers, small amounts of friction become a very large number.

Platform Engineering: from infrastructure to leverage

This is where Platform Engineering becomes interesting. But it is generally described too narrowly as:

“The team that manages Kubernetes and CI/CD.”

For me, Platform Engineering is about something much bigger:

Building reusable engineering capabilities that allow product teams to focus on building products.

The platform team shouldn’t think of developers as internal users who need to consume infrastructure.

Developers are customers. - The platform is an internal product that should make lives easier.

Imagine joining an engineering organization where you can:

• Create a development environment yourself
• Start with a production-ready service template
• Get security controls automatically
• Have observability available by default
• Get testing built into the delivery path
• Provision infrastructure without raising tickets
• Deploy without understanding every underlying infrastructure detail
• Context library, prompt libraries, AI harness there to infer.

That’s a very different engineering experience.

The objective isn’t to hide complexity. It’s to remove unnecessary complexity from the people who don’t need to deal with it.

And then AI changes the equation

This is the part I find particularly exciting. For years, when organizations needed a new capability, we generally thought in terms of build vs. buy.

• Build it ourselves.
• Buy a product.
• Or consume it as a service.

Building internally was often considered expensive and slow but AI is changing that equation.

Today, a small team of experienced engineers, working with AI coding assistants, agents and automation, can build sophisticated internal capabilities much faster than before.

Think about what AI can now help us create:

• Infrastructure code.
• CI/CD workflows.
• Service templates.
• Testing frameworks.
• Documentation.
• Security automation.
• Observability configuration.
• Developer portals.
• Internal APIs.
• Engineering assistants.
• Specialized agents, skills.

This doesn’t mean “build everything yourself.” I strongly believe in buying mature commodity capabilities when they make sense.

• Why build another database?
• Why build another identity provider?
• Why build commodity infrastructure when excellent services already exist?

But the question becomes more nuanced when the capability is closely connected to how your organization engineers software. That’s where building starts becoming strategically interesting.

My simple principle is:

Buy commodities. Build leverage.

And AI makes the second option much more achievable.

This becomes even more important when building a GCC

This is something I think about particularly when looking at the evolution of Global Capability Centres and their growth, every other digital product companies are trying to setup GCC.

Typically, a GCC can easily become a collection of engineering teams.

• Team A builds its own pipeline.
• Team B creates another deployment model.
• Team C chooses another observability approach.
• Team D builds another developer tool.

Everyone is busy, and delivering. But are we building an engineering capability, or simply adding more engineering capacity?

There is a big difference.

A modern GCC should ideally create capabilities that can be reused across the organization.

• Build the capability once.
• Create the standards once.
• Automate it.
• Make it self-service.
• Let many teams benefit.

That’s when a GCC starts becoming more than a delivery organization. It becomes an engineering leverage engine and this is where Platform Engineering can play a foundational role.

From Platform Engineering to Self-Service Engineering

The next evolution is even more interesting.

Consider a developer who needs a new service. Today, the process might involve:

• A repository, A pipeline, Infrastructure, Security, Observability, Deployment and Documentation.
• Several tickets, several teams and several decisions.

Now imagine saying:

“Create a production-ready Java service using our standard architecture, security policies, observability model and deployment strategy.”

And getting most of it automatically.

You may answer as “AI can generate”, but it needs right platform to provide the context, and control it, as -

• It knows the organization’s standards.
• It knows the approved patterns.
• It knows the security guardrails.
• It knows the golden paths.
• The engineer provides the intent and judgment.

A powerful combination is :

AI + Platform Engineering + Human judgment.

I believe this is where Platform Engineering is heading :

Not simply self-service infrastructure, but self-service engineering.

The metric I care about most

I would measure what I want to improve the most

• I don’t want to know how many Kubernetes clusters the platform team manages.
• I don’t particularly care how many pipelines the platform team has created.
• Lines of Code, Number of tasks, documents, artifacts..

Those are activity metrics.

I’d rather ask:

• How much engineering time did we give back?
• How quickly can a new engineer make their first contribution?
• How quickly can a team get to production?
• How much time do engineers spend waiting for infrastructure?
• How many repetitive activities have disappeared?
• How much faster can teams experiment?
• Do developers actually want to use the platform?

That last question is important. Because a platform can be technically brilliant and still be a failure.

If developers don’t want to use it, we haven’t built a platform product. We’ve built another piece of infrastructure.

The leadership question

So when I think about Platform Engineering,

I don’t start with: ❌ “Which technology should we use?”

I start with: ✅ Where are our engineers losing time?

Then: ➡️ Which of those problems are repeated across teams?

Then: ➡️ Can we solve them once and make the capability reusable?

And finally, in today’s world: ✅ Can AI help us build that capability faster?

That sequence leads to a very different engineering strategy.

🧭 Engineering Leadership Playbook Takeaways

My previous article asked: 💰How should we invest our engineering budget in the AI era❓

My answer was: 🏋️‍♂️Invest in human leverage, not human replacement.

This article takes the next step:

How do we create that leverage at organizational scale?

Platform Engineering is one of the strongest answers. Because

AI can make an engineer faster and a great platform can make the entire engineering organization faster. and when AI and Platform Engineering come together, we can build something even more powerful:

For engineering leaders—and especially those building modern GCCs—the question is:

❌ Which services should we consume?
✅ Which engineering capabilities should we build, own and continuously improve ourselves?

That, to me, is the real opportunity in Platform Engineering in the AI era.

• Build where it creates leverage.
• Buy where it creates efficiency.
• Use AI to accelerate both.

That’s how we build engineering organizations that don’t just become bigger, but they become better.

Find more articles in Engineering Leadership Playbook (ELP)

＃planning ＃ai ＃genai ＃engineering ＃leadership ＃playbook ＃learnings ＃development ＃assistant ＃aiagent ＃elp ＃experience ＃devX ＃budget