A few companies back, my manager and I inherited a group of teams after layoffs. Confidence was already low. People didn't believe in the systems we maintained. Stakeholders lost trust in what we did. Results were inconsistent, and even routine work needed more verification than it should have. We tried to steady things, but it was hard to know what good even meant. The question my manager kept coming back to was simple: what does good actually look like here?
We were solving very similar problems in different areas, but using different methods and different strategies. There was no way to bring unity to these efforts, and it was also hard to say what was actually good. We needed a reference point. Something that created a baseline. We first did this for a data processing project. We introduced a template that clearly defined the input, the output, unit tests, sample data, how to validate it, how to run it, and so on. That template effectively became what good looks like (WGLL).
Now, years later, I’m advocating for the same idea again, but not just for projects. For processes. For collaboration. For reviews. For career growth. For leadership. In this post, I’ll go through it.
WGLL meme
Ambiguity Is the Hidden Tax
Ambiguity isn’t something you consider in day to day work. Nonetheless, ambiguity has a cost. It shows up when people hesitate before making decisions. It shows up in reviews that take longer than they should, in work that gets revisited late in the process, and in projects that feel almost done for far too long.
Most of the time, no one can point to a single mistake, because nothing is technically wrong in isolation. The work is not wrong. It is misaligned, which is worse, because misalignment hides behind effort. This is what makes ambiguity expensive. The cost does not show up as a failure. It accumulates quietly similar to tech debt. It spreads across many small decisions, many small delays, many small misunderstandings about what “good” actually means.
As teams grow, this only gets worse. More people means more interpretations. Without a shared reference point, quality stops being something you can reason about. Someone else says it’s over-engineered. In the end, effort without a shared definition of success only produces motion, not progress.
This is the tax. And it is paid whether you acknowledge it or not.
Furthermore, engineers who grow up in chaotic environments normalize the chaos. Broken builds, flaky tests, midnight pages, unclear ownership. The system is unreliable, the processes are messy, and everyone quietly assumes this is just how things work.
When someone proposes better automation or clearer standards, the reaction is skepticism, not because the idea is bad, but because it feels unrealistic. If you have never experienced a stable system, you start treating instability as a law of nature. At that point, ambiguity becomes a belief system. The team stops aiming for good because they no longer believe good is achievable.
WGLL Is a Baseline, Then a Ratchet
Once you remove the ambiguity, a more interesting question appears. What do you actually do with this idea of “what good looks like”?
Most teams treat “good” as a one-time definition, usually because anything more explicit feels uncomfortably close to bureaucracy. They agree on a standard, write it down somewhere, and move on. But that misses the real power of the concept. WGLL is not a static description of quality. It is a mechanism that first creates a baseline, and then gradually raises it.
First, you make good visible. Then you make it hard to go back. Over time, that quiet ratcheting effect is what actually changes how an organization works.
Baseline
The first step is not improvement. The first step is making “good” visible. Most teams describe quality with vague words. Without something concrete to point at, each person carries their own interpretation.
A baseline turns that abstraction into something real. It is an artifact people can see and copy: a template, a pull request, a reference service, a well-structured project, a clear definition of done. It shows what success looks like in practice. Good has to be visible to be believable, especially for people who have only experienced chaotic environments.
Once a baseline exists, you don’t have to debate what the expectations are. Reviews become faster, onboarding becomes easier, and decisions require less interpretation. The team is no longer guessing what good looks like. They are starting from a shared reference point.
Ratchet
A baseline on its own is not enough. This is why WGLL cannot be a one-time definition. It has to behave like a ratchet. It’s part of vision and strategy. Each time the team discovers a better way of working, that improvement becomes the new default. It gets encoded into templates, checklists, documentation, or automation, so the next project starts from that higher baseline instead of reinventing everything from scratch.
The key idea is simple. Any improvement should be easy to adopt and hard to undo. When “good” is turned into artifacts and defaults, the organization moves forward almost quietly. Each cycle raises the standard a little, and the old, worse state becomes harder to return to. Over time, that ratchet effect is what actually changes how the system behaves.
The Compounding Loop
The loop only works if it is ritualized. Not as an occasional retrospective, but as a deliberate cycle. It becomes part of engineering health, not an afterthought.
Once you do that repeatedly, WGLL becomes infrastructure. Your baseline keeps getting updated by small clarifications that prevent the next cycle of confusion.
WGLL Depends on the Thing
Once you start defining WGLL, another pattern appears. The same vague standards tend to leak across very different contexts. Words like clean, production-ready, or senior-level get reused everywhere. A one-week spike, a core service, a code review, and a promotion decision all end up judged with the same language, even though the risks and tradeoffs are completely different. Nobody decides this consciously. It just happens when the definitions are never made explicit.
I’ve fallen into this trap myself. That is why WGLL has to be specific to the thing you are improving. Each domain needs its own conditions of satisfaction. Otherwise, the old definition carries over. You then still have to deal with ambiguity in a different form.
The mistake is assuming that once you have defined “good,” you are done. In practice, the definition only holds within a specific boundary. The moment you move from projects to processes, from execution to collaboration, or from individual output to leadership, the shape of “good” changes. If you do not redraw that boundary explicitly, people will unconsciously reuse the last definition they learned. That is how teams end up applying delivery standards to exploratory work, judging collaboration with the same lens as code quality, or evaluating senior growth using criteria meant for mid-level roles. Each context needs its own explicit conditions of satisfaction. Otherwise, the ambiguity simply re-enters through the back door, wearing the mask of consistency.
How WGLL Becomes Infrastructure
Defining WGLL is your very first step. The harder part is making it survive scale. At the start, WGLL lives in conversations, reviews, and the instincts of a few experienced people. But as the organization grows, alignment cannot depend on memory or proximity. Standards that rely on people remembering them eventually drift or are forgotten. New teams interpret them differently. Old teams carve out exceptions.
WGLL becomes real only when it stops being advice and becomes the path of least resistance. When the easiest thing to do is also the right thing to do. When good is not something you argue for, but something the system quietly enforces.
This is where templates, documentation, and automation come in. Each of them turns WGLL from an idea into a default.
Templates
A template says this is what good looks like here and gives you one. The real value of templates is not consistency for its own sake. It is the removal of unnecessary decisions. When every team structure works differently, the organization spends time debating format instead of solving problems. Templates eliminate those debates by defining the starting shape of work.
This is where platform engineering got the concept right. It recognized that standards do not scale as documents. They scale as defaults. Instead of writing best-practice guides, platform teams created golden paths where the expected approach was already built into the starting point.
That same idea applies beyond code. A project brief template, a hiring scorecard, a promotion packet, or an incident review format all serve the same purpose. They encode WGLL into the structure of the work. Instead of asking what good should look like, people begin with it.
Templates make WGLL the starting condition.
Documentation
Documentation is how WGLL becomes independent of individuals. As organizations grow, knowledge naturally concentrates in a few experienced people. They become the ones who know how things are supposed to work, how decisions are made, and what standards actually mean in practice. This creates a hidden dependency. The standard exists, but only inside a person.
Documentation breaks that dependency. It captures decisions, expectations, and examples in a form that survives team changes. A clear project brief, a well-written post-mortem, or a structured design doc becomes a concrete reference point. It decreases cognitive load by making these obvious.
If “good” lives in one person’s head, you do not have a standard. You have a hero. Heroes do not scale. They become bottlenecks, and when they leave, the organization is forced to relearn lessons it already paid for. Documentation converts hero knowledge into institutional memory. It lowers the bus factor not by adding more heroes, but by making hero knowledge unnecessary.
Automation
Automation is the cleanest form of WGLL because it removes interpretation. Any standard that depends on someone remembering to apply it will eventually drift. People are busy. Over time, the intended standard and the actual system diverge.
Automation closes that gap. Whether it is a CI gate, a required scorecard, or a process that cannot advance without defined success criteria, the effect is the same. The baseline is applied every time.
There is no debate and no reliance on memory. The system simply executes the definition of “good.” When templates shape the starting point, documentation preserves the knowledge, and automation enforces the baseline, WGLL becomes infrastructure. And infrastructure is what actually scales.
Leadership Is Calibration
Most of the leadership job is calibration. When WGLL is vague, performance becomes emotional. People feel judged instead of evaluated. Managers feel like they are delivering personal criticism instead of feedback. Teams argue about effort, attitude, and interpretation, because the target was never clearly defined in the first place.
If WGLL is explicit, then everything is clear from both ends. The question becomes simple: does this match the definition we agreed on? Leadership then becomes less about control and more about keeping the organization calibrated around shared standards. Most organizations believe they have standards. What they actually have are shared instincts.
In management, we often call these instincts taste. It feels subjective, but it is actually the internalized aggregate of what good looks like. Good leadership is the ability to apply this taste to make decisions that are meaningfully better because you were present. When you define WGLL explicitly, you are democratizing your taste so the team can operate with your discernment even when you aren't in the room.
Removing Surprises
A good manager removes surprises from the system. Most difficult performance conversations are not actually about poor work. They are about misaligned expectations. The engineer believed they were doing the right thing. The manager was evaluating them against a different definition of good. Because that definition was never written down, the outcome feels arbitrary.
Defining WGLL early is one of the highest-leverage things a manager can do. It turns performance from a judgment into a comparison against a known target.
Quarterly Synthesis
One simple way to do this is through periodic synthesis. Every quarter or so, step back and align on priorities. For each major item, write down what good looks like at completion. This needs to be on concrete outcomes. What would make everyone involved say, “yes, this is done”?
You want conditions of satisfaction for both. A simple ritual is to have both manager and report independently list their top 5 priorities, then meet to reconcile them. The value is in removing the friction. You might discover their #1 was your #5. For every agreed item, write down the specific outcome WGLL.
Performance Becomes Less Emotional
Once success criteria are agreed upfront, performance conversations become calmer and more objective. You are no longer debating intentions or effort. You are checking alignment against a shared definition.
This does not remove difficulty, but it removes ambiguity. People know what they were aiming for. They can see the gap. And more importantly, they know how to close it.
Why This Creates Psychological Safety
Psychological safety is often framed as a cultural issue, but a large part of it comes from clarity.
When people do not know what good looks like, they are forced to guess. Every decision carries hidden risks. Over time, people stop taking initiative because they are unsure how it will be judged.
Clear WGLL changes that dynamic. People know the target. They know the constraints. They know what success looks like. Within those boundaries, they can act with real autonomy. Autonomy with a clear definition of good creates psychological safety.
What good looks like flow
In Conclusion
WGLL’s value comes from what you do next. When you consistently convert “good” into artifacts and defaults, improvement happens almost quietly. Less drama, fewer surprises, faster decisions, cleaner handovers. The baseline rises, and the old state becomes harder to return to.
If you do not make that conversion, you will keep paying the ambiguity tax. It shows up as revisited work, slow reviews, vague feedback, and endless alignment meetings that exist only because nobody can point to what “good” actually looks like.