Why “Shift Left” Keeps Failing
Misunderstandings around a vague slogan are holding teams back. Here’s how to get clear and make real progress.
We’ve all been there. You’re in a meeting. Testing comes up as a bottleneck to delivery. There’s talk of too much manual testing, and eventually, someone says it:
“We need to shift left.”
Everyone nods. Everyone agrees. Some even say they’re already trying. But issues still slip through. Developers seem reluctant to work more closely with QAs, worried it’ll slow them down.
And no one stops to ask:
When we say "shift left," do we all mean the same thing?
Usually, we just assume we’re on the same page. But start digging and you’ll find everyone has a slightly different take:
For some, shift left means testing earlier.
For others, it’s all about automation.
Some see it as better collaboration between developers and QAs.
Others mean continuous testing across the whole software life cycle.
And the thing is - none of these are wrong. We probably need a bit of all of them. But if we don’t stop to clarify what we actually mean, these perspectives never get shared. Everyone walks away thinking they know what needs to happen, but nothing changes, or what does happen isn’t what anyone expected.
When everyone agrees but no one understands
This is where shifting left can cause more harm than good. Not because the idea is bad, but because the phrase is vague.
When teams try to “shift left” without a shared understanding, their approaches are more likely to fail. At that point, they think it's too hard and blame the people trying to make things better or worse, they give up.
“Shift left shouldn’t be a slogan. It should be a conversation.”
"Shifting left" starts to become a slogan, which, as W. Edward Deming said in his 14 for Points for Management:
Slogans are a way to say you care about quality without actually demonstrating you care. To improve results the system needs to be improved. Slapping up a slogan doesn’t improve the system. Normally all a slogan does is result in blaming people for not delivering what the slogan promises.
So how do we improve the system?
I’m speaking at Agile Manchester this May with my new talk, Building Quality in: A Framework for Engineering Teams. If you can make it, I’d love to see you there. The programme is available at https://agilemanchester.net, and you can get a 10% discount by using the code '10Jitesh'.
Be specific. Say what you mean.
Don’t just say, “We need to shift left.” Instead, say:
We need to test earlier in the lifecycle and say which points.
Developers and QAs should collaborate on automation.
QAs should be part of the design process to bring in product knowledge.
We want to reduce risk through phased rollouts and canary releases.
Whatever your vision is, say that. Be specific about the outcomes you’re aiming for and the behaviours you’d like to see. This helps limit the chance of misunderstandings based on assumptions, and people see exactly what you're after and why you want those things. It also opens up the opportunity to ask questions.
Frame change as an experiment
Trying new things will rarely work the first time. That’s normal.
So treat these changes as experiments. Try something. Learn from it. Iterate.
Make it safe to fail and safe to keep going.
When teams work together in this way, they can move testing out of the mad rush at the end and into something more continuous, collaborative, and valuable.
Next time someone says “shift left”…
Get curious. Ask:
“What does shift left mean to you?”
“What do you hope it will achieve?”
“Where’s the easiest place we could start?”
From there, you can work together to build confidence and momentum, then take on the harder stuff.
Bit by bit, we can make testing a continuous, integrated part of the whole development lifecycle - not just a shift to the left.
If this post made you think twice about how your team talks about quality, consider forwarding it to a colleague or sharing it with your team.
🤔 I'd love to hear your take. How do you make “shift left” work in practice?