Lean Thinking for Platform Engineering: Finding the Muda in Your Platform

Toyota revolutionized manufacturing by relentlessly eliminating waste—muda in Japanese.

Your platform has waste too. Developers waiting for CI. Unnecessary approval steps. Defects that cause rollbacks. Features nobody uses.

Lean thinking provides a framework to find and eliminate this waste. Let’s apply the seven wastes to platform engineering.

Toyota identified seven categories of waste. Each has a direct parallel in platform engineering.

Waste Manufacturing Platform Engineering
Transport Moving parts unnecessarily Moving data between systems
Inventory Excess stock Over-provisioned resources
Motion Unnecessary worker movement Context switching, navigation
Waiting Idle time Queue time, approval delays
Overproduction Making too much Building unused features
Overprocessing Unnecessary work Excessive compliance, redundant checks
Defects Rework, scrap Incidents, rollbacks, debugging

Let’s examine each in detail.

Manufacturing: Moving parts between workstations adds time but no value.

Platform engineering: Moving data, artifacts, or requests between systems unnecessarily.

Code artifact journey: a seven-step pipeline from Git through Jenkins, Artifactory, Jenkins again, Kubernetes, Registry, and back to Kubernetes, asking why the artifact touches 6 systems and whether it could be simplified to Git to Build to Registry to Kubernetes
Log data transport pipeline: App to Fluentd to Kafka to Logstash to Elasticsearch to Kibana, where each hop adds latency, complexity, and failure risk
Request routing pipeline: User to CDN to Load Balancer to API Gateway to Service Mesh to Service, asking whether every hop is necessary
Exercise: Draw your deployment pipeline

For each arrow between systems:
  - Why does this transition exist?
  - What value does it add?
  - Could we eliminate or combine steps?
Before and after deploy pipelines: the Before panel chains Git to Jenkins to Artifactory to Spinnaker to Kubernetes, the After panel chains Git to GitHub Actions to Kubernetes (direct deploy), removing 2 system transitions and 3 integration points for faster deploys and fewer failure modes

Manufacturing: Excess stock ties up capital and hides problems.

Platform engineering: Over-provisioned resources, unused capacity, accumulated queues.

Resource inventory:
  Reserved instances at 30% utilization
  Kubernetes nodes with 20% pod density
  10TB of "just in case" storage
  Environments that nobody uses anymore

Work inventory (WIP):
  50 open PRs waiting for review
  20 tickets "in progress" for weeks
  12 half-finished platform features

Data inventory:
  Logs retained for 2 years (policy requires 90 days)
  Backups of decommissioned systems
  Metrics at 10-second granularity stored forever

Resource audit:
  - What's the utilization of each resource type?
  - What's the oldest unused environment?
  - How much data is past retention policy?

Work audit:
  - How many items are in WIP?
  - What's the average age of WIP?
  - What's blocked and why?

Little's Law: Lead Time = WIP / Throughput

To reduce lead time, reduce WIP:
  - PR limit: Max 3 open PRs per developer
  - Feature limit: Max 2 features in progress per team
  - Environment cleanup: Delete after 7 days of inactivity

Resource right-sizing:
  Before: 20 nodes at 20% utilization
  After:  8 nodes at 50% utilization
  Savings: 60% compute cost

Manufacturing: Workers walking to get tools or materials.

Platform engineering: Developers navigating systems, context switching, hunting for information.

Deployment motion:
  1. Open Jenkins (find the right job)
  2. Check the logs (scroll, scroll, scroll)
  3. Open Kubernetes dashboard (find the namespace)
  4. Check pod status (wait for it to load)
  5. Open Datadog (create the right query)
  6. Verify metrics (adjust time range)

6 different systems, 6 context switches.
Debugging motion sequence: the question of where the logs for this service are leads to Slacking the on-call, being told to check Kibana, not finding the right index, asking again, learning the service uses CloudWatch, finding CloudWatch, and ending up in the wrong region
Information hunting sequence: asking what the config for this service is leads to checking Git (which repo?), the wiki (outdated), Confluence (wrong version), and finally asking in Slack (wait for response)
Shadow a developer for a day:
  - How many systems do they touch?
  - How many times do they context switch?
  - How much time finding vs doing?
  - What questions do they ask repeatedly?

Single pane of glass:
  Before: 6 tools to check deployment status
  After:  1 dashboard with deployment, logs, metrics, alerts

Reduced motion: 5 context switches eliminated

Self-service answers:
  Before: Slack questions about config, access, status
  After:  Internal developer portal with search

Reduced motion: No more hunting, asking, waiting

Manufacturing: Workers or machines idle, waiting for inputs.

Platform engineering: Developers waiting for builds, tests, approvals, environments.

CI/CD waiting:
  Build queue time:       15 minutes
  Build execution:        10 minutes
  Test queue time:        10 minutes
  Test execution:         20 minutes
  Deploy approval wait:   4 hours
  Deploy execution:       5 minutes

Total: 5 hours
Active work: 35 minutes
Waiting: 4.5 hours (90% of time is waste)
Environment waiting sequence: a request for a staging environment goes through submitting a request ticket, waiting a day for approval, waiting a day for provisioning, and the environment being ready two days later
Human bottleneck waiting:
  Code review:            2 days average
  Security review:        1 week average
  Architecture review:    2 weeks average

Measure queue times at each step:
  Time in queue / Time being processed = Wait Ratio

Wait ratio > 1 = More waiting than working
Wait ratio > 5 = Severe waiting waste

Build queue time:
  Before: 15 minutes (shared build agents)
  After:  0 minutes (auto-scaling build agents)

Test parallelization:
  Before: 20 minutes (sequential)
  After:  5 minutes (parallelized)

Self-service environments:
  Before: 2 days (ticket + approval + provision)
  After:  10 minutes (automated provisioning)

Async approvals:
  Before: Block on human approval
  After:  Deploy to staging immediately, require approval for prod

Reduced wait without reducing safety.

Manufacturing: Making more than customers need.

Platform engineering: Building features that aren’t used, over-engineering solutions.

Platform feature graveyard:
  - Custom deployment strategies (nobody uses)
  - Advanced caching layer (one team tried once)
  - Multi-region support (never activated)
  - Plugin system (no plugins built)

Premature optimization:
  "We built this to handle 10x our current scale"
  (Scale never came)
  (Complexity remains)

Documentation overproduction:
  100-page architecture doc (never read)
  Detailed runbooks (outdated before finished)
  Video tutorials (nobody watches)

Feature usage audit:
  For each platform capability:
    - How many teams use it?
    - How often is it used?
    - If removed, who would notice?

Build only what's needed:
  Before: Design for hypothetical scale
  After:  Build for current needs + clear extension points

Kill unused features:
  If usage < 5%:  Deprecate it
  If usage = 0%:  Remove it
  
Sunsets reduce maintenance burden.

Minimal documentation:
  Before: Comprehensive docs (never read, always stale)
  After:  README + runbook + examples (actually maintained)

Manufacturing: More precision or steps than needed.

Platform engineering: Excessive process, redundant checks, unnecessary rigor.

Approval overhead:
  Deploy to dev:     Requires approval (why?)
  Change config:     Requires CAB ticket (really?)
  Add team member:   Requires 3 sign-offs (necessary?)

Compliance theater:
  Security scan on every commit (same code, same result)
  Vulnerability report nobody reads
  Audit logs nobody audits
  Checklist nobody checks

Process for process's sake:
  "We need a design doc for this 10-line change"
  "Let's schedule a review meeting" (for trivial changes)
  "Fill out this template" (fields don't apply)

For each process step:
  - What risk does this mitigate?
  - Has that risk ever materialized?
  - Is there a lighter-weight alternative?
  - Who would notice if we skipped it?

Risk-based approvals:
  Before: All changes require approval
  After:  
    Low risk (dev, config):  Auto-approve
    Medium risk (staging):   Peer approve
    High risk (prod):        Lead approve

Smart scanning:
  Before: Full security scan on every commit
  After:  Full scan on changed files only
          Full scan nightly
          
  Reduced: 80% scan time with same coverage

Manufacturing: Scrap, rework, quality failures.

Platform engineering: Incidents, rollbacks, debugging, incorrect configurations.

Deployment defects:
  Failed deployments:     15% of deploys
  Rollbacks:              5% of deploys
  Time to fix:            2 hours average
  
  If 100 deploys/week:
    15 failures × 2 hours = 30 hours of rework/week
Configuration defect sequence: asking why this environment is broken leads to config drift from production, 4 hours of debugging, a manual fix, and the note that it will happen again
Platform defects:
  CI randomly fails (flaky tests)
  Environments randomly break (resource limits)
  Deploys randomly timeout (network issues)
  
  "Random" = Unresolved defects

Track defect metrics:
  - Deployment failure rate
  - Mean time to recovery
  - Rollback frequency
  - Repeat incidents (same cause)
  - Escaped defects (caught in production)

Build quality in:
  Before: Test in production, fix defects
  After:  Fail fast in CI, prevent defects

Poka-yoke (mistake-proofing):
  Before: Config as free-form YAML (easy to break)
  After:  Config as typed schema (invalid = won't deploy)
  
Reduced: 80% of config-related incidents
Root cause elimination: before means fix the incident and move on, after means fix the incident and fix the system that allowed it, following the chain Incident to Post-mortem to Prevention to No repeat

Walk through your platform with the waste lens:

For each developer workflow:

1. Map the value stream (every step from code to production)

2. Categorize each step:
   - Value-add: Customer would pay for this
   - Non-value but necessary: Required (compliance, safety)
   - Waste: Neither valuable nor necessary

3. For each waste, identify the type:
   - Transport: Unnecessary movement of artifacts/data
   - Inventory: Excess resources, WIP, data
   - Motion: Developer context switching, hunting
   - Waiting: Queue time, approval delays
   - Overproduction: Unused features, premature optimization
   - Overprocessing: Unnecessary rigor, redundant checks
   - Defects: Failures, rework, debugging

4. Prioritize by impact:
   - How much time/money does this waste?
   - How hard is it to eliminate?
   - Focus on high-impact, low-effort first

Lean isn’t a one-time audit. It’s a culture.

Daily:
  - Notice waste when you see it
  - Quick fixes for small waste

Weekly:
  - Team discusses biggest waste encountered
  - Prioritize improvement items

Monthly:
  - Measure waste metrics (lead time, failure rate, utilization)
  - Track improvement trends

Quarterly:
  - Value stream mapping exercise
  - Major waste elimination initiatives

The seven wastes in platform engineering:

Waste Platform Symptoms Elimination
Transport Artifacts touching too many systems Simplify pipeline
Inventory Over-provisioned, excess WIP Right-size, limit WIP
Motion Context switching, hunting Single pane of glass
Waiting Queue time, approval delays Parallelize, self-service
Overproduction Unused features Build only what’s needed
Overprocessing Excessive process Risk-based controls
Defects Failures, rollbacks Build quality in

The lean mindset:

Ask constantly:
  - Is this step adding value?
  - Who is waiting? Why?
  - What did we build that nobody uses?
  - What failed? How do we prevent it?

Toyota didn’t become Toyota in a day. They improved relentlessly for decades.

Your platform can too. One waste at a time.

Start today: Pick one workflow. Map it. Find the muda. Eliminate it.

Then do it again tomorrow.