Slide 01

28 Days to Ship. 10 Are Work. 18 Are a Leadership Problem.

CEO + COO + CTO

The only question that matters

Your VP of Engineering presents "28-day average cycle time." Nobody in the room asked: of those 28 days, how many are work?

Not waiting. Not sitting in a queue. Not blocked on an approval that takes four days because the approver is in meetings until Thursday. Not parked in a staging environment three teams share and one team monopolizes. Work. Fingers on keyboard.

The answer Ten days. Sometimes eight. Sometimes twelve if you're generous about what counts as "work." Ten days of work. Eighteen days of wait. 64% of your cycle time doing nothing.

Slide 02

A Designer Spends 2 Hours on a Mockup. It Sits in the Design Backlog for 5 Days Before She Picks It Up. Draw That Picture.

Where your time actually goes

Design step 2 hrs work / 5 days wait

The designer spends two hours on the mockup. But the ticket sat in the design backlog for five days before she picked it up. Write both numbers. Most orgs only track the two hours.

Code review 45 min review / 2 days wait

The reviewer spends 45 minutes. But the pull request sat in the review queue for two days because the reviewer was in meetings. Your CI pipeline made the 45 minutes 20% faster. The 2 days: untouched.

Security review 1 day work / 5 days wait

Your single security engineer reviews everything sequentially. Her backlog is measured in weeks. One day of work. Five days of wait. That gate adds a full week to every feature that touches anything security cares about.

The method Value stream mapping. Invented at Toyota in the 1950s. A whiteboard, sticky notes, two hours, and the people who actually do the work. Your CTO probably studied it in an operations management course and left it there.

Slide 03

Those 18 Days of Wait Exist Because of Decisions You Made. The Approval Gates. The Shared Staging Environment. The Weekly Change Advisory Board.

Who owns this

What you've been optimizing

The 10 days of work. You made the 2-day engineering task take 1.5 days. You saved maybe a day and a half across the entire stream.

New CI/CD tooling. AI coding assistants. Velocity improvement initiatives. Every investment aimed at the 10 days. You optimized 35% of your cycle time and left 65% untouched.

That is not a technology problem. That is a leadership problem. Those 18 days of wait exist because of decisions you made. Or decisions you inherited and never questioned.

Hard truth You designed the wait. Or you allowed it to persist because nobody drew the picture that made it visible.

What the wait is made of

The approval gates that protect decisions nobody is actually accountable for.
The shared staging environment that three teams share and one team monopolizes.
The weekly change advisory board that adds three days of latency to every deployment.
The six hours of daily meetings that keep your senior engineers out of code review.
The handoff from design to engineering that requires a spec document nobody will read twice.
The security review backlog that adds five days to any feature touching user data.

Slide 04

One Conference Room. One Whiteboard. Sticky Notes in Three Colors. The People Who Actually Touch the Code. Two Hours. That's the Whole Method.

The value stream map

Start

Right side of the whiteboard: "customer using the feature in production"

That's the finish line. Everything flows toward it. Left side: "idea approved" or "ticket created." That's the starting line. Now fill in the middle — every step, every wait. Not how your process documentation says it moves. How it actually moves.

Rule

Write both numbers: work time and wait time

For every step: how long does the actual work take? And how long does work sit waiting before the next step picks it up? Use actuals, not targets. The last three features your team shipped. Be honest. Be specific.

Who

Not the people who manage the people who do the work

The people who touch the code. File the tickets. Run the deployments. Approve the pull requests. Sign off on security reviews. Push the button that sends software to production. Get them in the room. No laptops.

The result Add up the work time. Add up the wait time. The ratio will surprise you. Or confirm what you already suspected but never drew a picture of.

Slide 05

You Have Metrics That Measure What Your Tools Capture. You Do Not Have Metrics That Measure What Actually Limits Flow.

Why you've been blind to this

What your current metrics capture

Jira ticket velocity (open to closed). Doesn't capture wait time between steps.
Sprint completion rates (% of planned tickets completed). Optimizes for estimating, not delivering.
Deployment frequency (how often you deploy). Doesn't capture how long features wait before they're ready to deploy.
Developer productivity (PRs merged, code commits). Captures generation speed. Doesn't capture flow speed.

What the value stream map reveals

Total cycle time vs. actual work time. The ratio that tells you where the leverage is.
Specific wait points: design backlog, review queue, staging contention, approval gates.
The constraint: the single step creating the longest wait downstream.
Where your $340,000 CI pipeline investment had zero effect on customer delivery time.

Taiichi Ohno Invented this at Toyota in the 1950s. Manufacturing has used it for 70 years to eliminate billions in waste. Your software org hasn't done it once.

Slide 06

Book a Conference Room. Get the People Who Touch the Code. Draw the Picture. This Is the One Meeting That Will Actually Change Your 28-Day Number.

Decision close

What happens after you draw it

Every wait time on that whiteboard is a leadership decision that can be unmade. The approval gates. The shared staging. The sequential security review. The change advisory board.

You will know exactly which ones to eliminate. Not because a consultant told you. Because you drew the picture yourself with the people who live inside the process every day.

Organizations that do this regularly report cycle time reduction from 28 days to 12 within 90 days. Not by hiring engineers. Not by buying more tools. By eliminating the decisions that created the wait.

The constraint Fix the constraint. Not the symptoms. The map will show you what the constraint is. The rest is leadership decisions, not engineering decisions.