It can. DORA notes that platform engineering often follows a J-curve: early gains, then a dip as complexity increases, then recovery to a higher level as the platform matures. Tell stakeholders about the dip in advance, track a few signals, and keep the first release small.
What the J-curve is
Picture a letter J lying in front of you. Performance starts at a baseline, falls for a while, then rises past where it started. DORA describes this pattern for platform engineering: organizations may see initial performance gains, followed by a dip as complexity increases, before finally recovering and stabilizing at a higher level as the platform matures.
For a security golden path the dip has familiar causes. New checks produce findings nobody has triaged. Teams spend time moving onto the template. The shared pipeline has rough edges. People ask for exceptions because the road does not yet fit their stack.
Another warning from the same source
DORA also says that while platforms improve productivity and organizational performance, they can sometimes lead to a decrease in throughput and change stability if not carefully managed. It recommends a balanced scorecard: delivery measures such as change lead time, deployment frequency, failed deployment recovery time, change failure percentage and deployment rework rate, plus developer satisfaction and adoption.
That is a useful guard rail. A security program that just counts findings could miss a slowdown that developers feel acutely.
Common causes of a dip, and a response
| Cause of the dip | Response |
|---|---|
| A backlog of old findings appears | Gate on new findings first, schedule the backlog separately |
| Teams spend time migrating | Provide a migration guide and offer help sessions |
| Checks are noisy | Tune, filter by reachability and review rules weekly |
| The road does not fit some stacks | Add a variant or a documented exception |
| Failures are confusing | Rewrite messages with the fix and exception route |
What to tell stakeholders
- Name the dip. Say that a rough period is normal and cite the research.
- Describe the shape. Gains first, then friction, then a better steady state.
- Agree on signals. Pick a short list, such as time to a secured pipeline, developer satisfaction and change failure rate.
- Set a review date. Look at the data after a fixed number of weeks, not after every complaint.
- Have a stop rule. Decide in advance what result would make you pause or change course.
How to soften the dip
- Start small. DORA recommends a minimum viable platform, building just enough to make one journey better.
- Warn before you block. Run new checks in report mode first.
- Pilot first. One team finds the rough edges before everyone else does.
- Fix feedback fast. Reduce time between a complaint and a change.
Signs you are climbing out
- Time from creating a service to a green security check is falling.
- Exception requests are fewer and shorter.
- Developers choose the road for new work without being asked.
- Satisfaction scores rise and complaints shift from "it is broken" to "it would be nice if".
If after a reasonable period none of those move, the problem may not be the J-curve. It may be the road. Go back to the users and ask.
Where Safeguard fits
Safeguard's policies and gates can be introduced in stages, and its reachability analysis helps keep early findings focused on what matters. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How long does the dip last?
DORA does not give a duration, and it varies by organization. Set a review date and judge by your own signals.
Does a dip mean the project is failing?
Not necessarily. Compare it with your signals and your stop rule. If the dip persists and the signals do not improve, change course.
Sources
Last reviewed: 19 October 2026.
