You have heard of shift left. Test earlier, catch issues sooner, move quality upstream in the development lifecycle. It is good advice and it works. But there is a version of it that goes further — further left than requirements, further left than design, further left than the first conversation about a feature.

I call it shift-left-left. And it starts when you walk through the door in the morning.

The team

The team I am thinking of was not dysfunctional. Everyone was skilled. Everyone had experience — some from large enterprises, some from startups, some from agencies. That was precisely the problem.

Each person had learned quality differently. Code reviews meant different things to different people — a formality for some, a genuine quality gate for others. The daily standup was treated as a status report by most: what I did yesterday, what I will do today, said quickly and forgotten immediately. Conversations about a feature happened in fragments — a Slack message here, a hallway comment there — with no shared expectation of what “thinking it through” even meant.

The result was not bad work. It was inconsistent work. And inconsistency at the human level — in attitude, in approach, in how seriously people took small things — eventually shows up in the product. It always does.

What we actually fixed

The instinct in this situation is to reach for process. Add a checklist. Mandate a template. Create a definition of done and paste it in the wiki where no one will read it.

We did not do that. We started earlier.

The first thing we changed was the daily. Not the format — the purpose. We shifted it from reporting to thinking. Instead of “what did I do and what will I do,” we started asking “what is in my way and what does the team need to know.” Small change in wording, significant change in what the conversation was for. People started arriving at the daily having already thought about their day, rather than summarising it on the spot.

The second thing was how we talked about work before it became work. When someone raised an idea — in a one-to-one, in a team meeting, informally over coffee — we started applying the same quality thinking we would later apply to code. Is this well defined? What could go wrong? Who is affected? Not formally, not with a framework, just as a habit of conversation. Quality as a default mode of thinking, not a phase that comes later.

The third thing was consistency in small things. Code reviews done properly every time, not just when someone remembered. Tickets written with enough context that a stranger could pick them up. Estimates treated as a thinking tool rather than a number to put in a box. None of these are revolutionary. All of them require the same thing — people deciding that the small things matter, every day, not just when there is a deadline.

Why mindset before process

The standard shift-left argument is about timing — catch the bug in requirements rather than in production, write the test before the code rather than after. It is correct and worth doing. But it assumes that the people doing it share a common understanding of what quality means and why it matters.

When they do not — when a team is assembled from different backgrounds, different habits, different definitions of “good enough” — shifting left in the process does not help much. You are moving quality earlier in a workflow built on inconsistent foundations.

Shift-left-left is about building those foundations first. It is about the culture that exists before the SDLC begins — the way people approach their work, the conversations they have, the standards they hold each other to informally before any formal process kicks in.

It is not about skill. Every person on that team was capable. It was about alignment — shared expectations about what good looked like, applied consistently, starting from the first interaction of the day.

What changed

Within a few weeks the dailies had a different energy — shorter, more useful, more honest. Within a couple of months, the code reviews were consistent enough that feedback was predictable and therefore easier to give and receive. Within a quarter, new team members were absorbing the way of working naturally, because it was visible in every conversation, not just documented somewhere.

The product quality improved. But that was the outcome, not the goal. The goal was a team that thought about quality as a default, not a phase — and got there before a single line of code was written.

The principle

Shift left tells you to move quality earlier in your process. Shift-left-left tells you that your process starts earlier than you think — in the culture, in the conversations, in the habits people bring through the door every morning.

Fix the mindset first. The process will follow.