Some lessons you learn before the baby arrives. Some you learn at two in the morning with no wipes in reach.
On the surface, changing a diaper seems like a reactive task. Baby is dirty, you fix it. Simple. But anyone who has done this sleep deprived in the middle of the night with an impatient newborn knows that the difference between a smooth diaper change and a full-on catastrophe has almost nothing to do with what happens during the change itself and has everything to do with what you set up before the baby ever hits the table.
Clean diaper open and ready. Wipes open (you do NOT want to deal with a sealed container of wipes!). Diaper rash cream within arm's reach. A clean outfit unzipped and laid flat. Space in the Diaper Genie so you're not trying to stuff a diaper into a full bin with one hand while holding a squirming baby with the other...
When everything is ready to go, a diaper change is three minutes of calm. It can be, dare I say it, enjoyable. When you're unprepared, however, it's absolute chaos. Mess everywhere (how did it get on the ceiling?!), baby screaming, you scrambling to find things with zero hands free and zero time to spare.
You don't set up the changing station after the baby is already on the table. By then it's already too late.
Unprepared diaper changes and late-stage testing have a lot in common. Both are chaotic, both are expensive, and both were completely avoidable.
The tester sits down, opens the ticket, and the clock starts. They need to read the requirements, if there are any. Track down credentials. Find or build test data. Ask the questions that should have been answered two weeks ago during grooming. And then, somewhere in the middle of all of this, they surface the thing nobody thought about. Did anyone consider what happens when a user does X? Of course they hadn't. The ticket goes back. The developer context-switches. The sprint takes the hit.
Or this one, which might be even more painful: the ticket is ready for testing, the QE is prepared, but it can't actually be tested yet because it depends on another ticket that isn't finished. Nobody mapped the dependencies. Test driven development wasn't part of the conversation when the work was planned. So the QE waits. Blocked. Not because they did anything wrong, but because quality was treated as the last step rather than a participant in the process.
Both of these scenarios feel like operational failures. They're not. They're planning failures. The baby was already on the table before anyone checked if the wipes were out.
Shift-left gets talked about a lot in engineering circles and it often gets reduced to "involve QE earlier." That's true but it undersells what's actually required. Involving QE earlier only works if the whole team changes how they plan, not just when they hand things off.
It means asking "how will we test this?" before a single line of code is written. Not as a QE question, as a team question. It means mapping dependencies before work begins so nobody is blocked waiting for something that should have been sequenced first. It means QE having access to requirements, context, and risk information early enough to actually influence the work, not just validate it.
It means treating the changing table as a shared responsibility. Everyone knows where the wipes are. Everyone knows when the Diaper Genie needs emptying. Nobody finds out mid-change.
When this is actually working, when shift-left isn't a principle on a slide deck but a lived practice, it feels a specific way. The QE team knows what's prioritized. They know the risks. They know the tradeoffs. They're in the planning conversations, not receiving the output of them. They're not scrambling to catch up because they were never left behind.
The thing that surprises people who haven't experienced it is this: you're not feeling rushed, but you're moving faster.
That sounds like a contradiction. It isn't. Rushing is what happens when quality is an afterthought, when you're cramming testing into whatever time is left at the end of a sprint, cutting corners because the deadline doesn't move, and shipping things you're not confident in. Speed without preparation is just controlled chaos.
What shift-left actually creates is momentum. Work flows because the questions were answered early. Tickets don't bounce back because the risks were identified before anyone wrote code. QE isn't a bottleneck because they were part of the process from the start. You move faster because you're not spending half your time cleaning up messes that didn't have to happen.
My diaper-change routine took a few weeks to figure out and there certainly were some memorable disasters along the way! But once the system was in place, once preparation was the default, not the exception, everything downstream got easier.
The mess didn't stop entirely. It never does. But we were ready for it.
That's all shift-left is, really. Not eliminating the mess. Just making sure you're never caught without the wipes.
What would it look like in your org if "how will we test this?" was the first question asked, not the last?