DEV Community: Amit Malhotra

7 Problems That Start Hurting When Your Engineering Team Scales

Amit Malhotra — Mon, 17 Aug 2026 12:40:39 +0000

A small engineering team can run surprisingly well on a collection of scripts, manual processes, and tribal knowledge.

Then the team grows.

More developers. More services. More environments. More deployments.

And suddenly, the shortcuts that once helped the team move fast start creating friction everywhere.

Here are 7 problems that tend to appear as engineering teams scale.

1. Every new service becomes a provisioning project

A new service needs a project, IAM, a repository, a pipeline, a GKE namespace, and supporting infrastructure.

If each piece requires a separate ticket, onboarding quickly becomes a queue.

2. Security decisions land on developers

Developers shouldn't have to become IAM and security experts just to ship an application.

When secure patterns aren't built into the platform, teams often make one-off decisions under delivery pressure.

3. Environments start drifting

Dev, staging, and production are configured at different times by different people.

Eventually:

"It worked in staging."

becomes a familiar sentence.

4. Teams don't have enough environments to test

A few shared environments quickly become a bottleneck.

Ephemeral environments can give feature branches an isolated place to test, validate, and run security checks before merging.

5. New engineers spend too long figuring things out

When platform knowledge lives in the heads of a few senior engineers, every new hire starts by asking:

"How do we do this here?"

A standardized platform gives developers something consistent to learn and reuse.

6. Every audit becomes a fire drill

If security and governance aren't structural, teams have to reconstruct evidence whenever an audit or security review arrives.

Good platform guardrails should produce much of that evidence by default.

7. The platform team becomes the bottleneck

If every new service, environment, or deployment needs hands-on platform-team involvement, platform capacity has to grow with engineering.

That doesn't scale.

The common thread

These problems look different, but they usually have the same underlying cause:

The engineering organization has grown faster than its platform operating model.

The answer isn't seven separate initiatives.

It's to standardize the parts of infrastructure and delivery that shouldn't have to be reinvented for every service.

Self-service provisioning.

Secure defaults.

Consistent environments.

Reusable delivery patterns.

Ephemeral testing.

Built-in governance.

And fewer manual handoffs.

That's the idea behind an Internal Developer Platform.

Build, Buy, or Open Source? How to Choose the Right Internal Developer Platform

Amit Malhotra — Tue, 11 Aug 2026 06:59:26 +0000

The “build vs. buy” discussion around Internal Developer Platforms often starts with the wrong question:

What will the software cost?

The better question is:

What will it take to operate the platform successfully over the next 2–3 years?

An IDP is not just a developer portal. It sits across infrastructure provisioning, CI/CD, Kubernetes, identity, security, GitOps, observability, and developer workflows. That means the real investment includes engineering time, integrations, maintenance, upgrades, and adoption.

Build when control is the priority

Building internally makes sense when you have a mature platform engineering team, highly specialized requirements, and enough scale to justify owning the platform as an internal product.

The advantage is control. Your team owns the architecture, workflows, roadmap, and integrations.

But that also means owning the maintenance.

Open source when flexibility matters

Open-source frameworks can be an excellent foundation, particularly when your team already has strong platform engineering capabilities.

The important distinction is that open source reduces software licensing costs; it doesn't eliminate engineering work.

Someone still needs to integrate the tools, secure them, maintain plugins, manage upgrades, and turn individual components into reliable developer workflows.

Buy when speed-to-value matters

A commercial platform can make sense when the priority is getting standardized developer workflows into production without spending months building the underlying foundation.

The trade-off is usually around cost, customization, ownership, and vendor dependency.

But “buy” doesn't have to mean giving up control.

For example, a platform deployed within your own cloud environment can provide a faster starting point while allowing your engineering team to retain ownership of the underlying infrastructure and tooling.

The decision framework I recommend

Before choosing an approach, ask five questions:

How much platform engineering capacity do we actually have?
Which workflows are creating the most developer friction today?
How much customization is genuinely necessary?
Who will own upgrades, security, and operations long-term?
How quickly do we need measurable results?

The right answer may be different for every organization.

A large engineering organization with unique requirements may benefit from building.
A technically strong team may prefer an open-source foundation.
A team under pressure to improve developer experience quickly may benefit from a commercial or productized approach.

The goal isn't to choose the cheapest platform.

It's to choose the approach that removes more engineering friction than it creates.

That is the real measure of a successful Internal Developer Platform.

Golden Paths Aren't About Standardization. They're About Reducing Developer Decisions.

Amit Malhotra — Thu, 06 Aug 2026 07:39:48 +0000

TL;DR

Golden Paths aren't about forcing every team to work the same way. They're about removing repetitive infrastructure decisions so developers can focus on building software while platform teams ensure consistency, security, and governance by default.

When people hear Golden Path, they usually think of:

Project templates
Repository scaffolding
CI/CD pipelines
Infrastructure automation

Those are all part of it.

But they miss the real purpose.

A Golden Path isn't about standardization for the sake of standardization.

It's about reducing the number of infrastructure decisions developers have to make.

Every unnecessary decision removed from the development process means one less opportunity for inconsistency, delay, or misconfiguration.

Developers Already Have Enough Problems to Solve

Developers should be thinking about:

Business logic
User experience
Performance
Reliability
Testing

Instead, many teams spend time deciding things like:

Which Google Cloud project should I deploy to?
Which Kubernetes namespace should I use?
What CPU and memory limits should I configure?
Which IAM permissions are required?
How should secrets be managed?
Which CI/CD pipeline should I follow?
What monitoring and logging standards apply?

None of these decisions differentiate the application.

Yet every new service often requires making them again.

Every Manual Decision Creates Variability

When every team makes these choices independently, the platform gradually becomes inconsistent.

One service has resource limits.

Another doesn't.

One workload uses the correct identity model.

Another still depends on long-lived credentials.

One namespace follows networking standards.

Another doesn't.

These problems don't happen because developers lack expertise.

They happen because every deployment starts with too many decisions.

What a Good Golden Path Actually Provides

A mature Golden Path removes repetitive platform work by providing secure, opinionated defaults.

Instead of asking developers to configure everything themselves, it provisions:

A standard repository structure
CI/CD pipelines
Kubernetes namespaces
Resource quotas and limits
Workload Identity
Network policies
Logging and monitoring
Security defaults

Developers focus on delivering applications.

The platform takes care of the platform.

A Simple Example

Instead of every team defining resource limits differently—or forgetting them altogether—the platform provides consistent defaults.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: app-quota
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi

Developers don't have to decide the right starting point every time.

The platform provides it automatically.

Golden Paths Improve Developer Experience

The biggest benefit isn't automation.

It's reducing cognitive load.

When onboarding follows the same predictable workflow every time:

Developers become productive faster.
Platform standards remain consistent.
Fewer deployment mistakes reach production.
Teams spend less time searching documentation.

Consistency becomes the default instead of something people try to remember.

But Golden Paths Aren't Enough

This is where many platform initiatives stop.

A Golden Path creates the preferred way to build and deploy software.

It doesn't prevent someone from bypassing that workflow.

Configuration drift can still happen.

Policies can still be ignored.

Resources can still be created outside platform standards.

That's why mature platform engineering combines:

Golden Paths for developer experience
Policy enforcement for governance
GitOps for continuous reconciliation
Admission controls for validation

Golden Paths guide developers.

Guardrails protect the platform.

You need both.

The Biggest Winner Is the Platform Team

People often say Golden Paths improve developer productivity.

That's true.

But they also transform the work of platform engineers.

Instead of repeatedly answering requests like:

"Can you create a namespace?"

"Can you configure IAM?"

"Can you set up CI/CD?"

The platform automates those tasks through a consistent workflow.

The result?

Fewer repetitive requests.

More time improving the platform instead of supporting it.

Final Thoughts

A successful Golden Path isn't measured by how many templates it generates.

It's measured by how few infrastructure decisions developers have to think about.

Developers should spend their time solving business problems—not remembering platform standards.

The best platforms don't expose infrastructure.

They quietly remove its complexity.

What About Your Team?

Does your Golden Path simply standardize onboarding?

Or does it work together with governance, policy enforcement, and GitOps to keep your platform consistent as it scales?

What's one infrastructure decision your platform has successfully removed from developers? I'd love to hear your experience in the comments.

The Hidden Cost of Manual Application Onboarding on Google Cloud

Amit Malhotra — Wed, 29 Jul 2026 03:26:09 +0000

When people think about application onboarding, they usually think about creating a Kubernetes namespace or provisioning a new project.

In reality, that's only a small part of the work.

A typical onboarding request often involves:

Creating or selecting a Google Cloud project
Provisioning a GKE namespace
Configuring IAM permissions
Creating Workload Identity bindings
Setting up CI/CD pipelines
Managing secrets
Applying security policies
Connecting observability

None of these tasks are particularly difficult.

The challenge is that they are repeated for every new service.

The Real Bottleneck

As engineering teams grow, these repetitive requests gradually accumulate.

Developers wait for environments.

Platform engineers spend more time responding to tickets.

Knowledge becomes concentrated within a small number of experienced engineers.

Instead of improving the platform itself, the team spends its time maintaining the same onboarding process over and over again.

Standardization Beats Repetition

Many organizations try to solve this by documenting onboarding steps.

Documentation certainly helps.

However, documentation still relies on someone executing the same sequence of tasks repeatedly.

A more scalable approach is to standardize those decisions into reusable workflows.

The goal isn't to remove platform engineering.

The goal is to remove repetitive operational work so platform engineers can focus on building better platforms.

Questions Worth Asking

If your team provisions new environments regularly, ask yourself:

Which onboarding steps are repeated every time?
Which decisions are already standardized?
Which tasks still require manual intervention?
How much engineering time is spent on repeatable work?

Even small improvements in these areas can significantly improve developer experience and engineering productivity.

Final Thoughts

Application onboarding isn't just an infrastructure task.

It's one of the first experiences developers have with your platform.

The simpler and more consistent that experience becomes, the more time your engineering teams can spend delivering software instead of waiting for infrastructure.

Have you standardized your application onboarding process, or is it still driven by tickets and manual requests? I'd love to hear how your team approaches it.