One of the most useful habits I’ve developed as a leader is pausing before any significant initiative, project, or decision to ask a deceptively simple question: what does good look like here? Not great. Not perfect. Not world-class. Just good. It sounds almost too simple to be meaningful, but I’ve found that this single question prevents more dysfunction than almost any other framing I use. Without a deliberate answer, teams drift toward one of two failure modes : either they chase perfection and burn out pursuing diminishing returns, or they unconsciously lower the bar until mediocrity feels like success. Both are corrosive, and both stem from the same root cause: nobody took the time to define the acceptable range of outcomes before the work began.
Good Is Always a Range, Not a Point
One of the nuances that took me years to internalize is that “what good looks like” is never a single number or a single outcome. It’s a range. There’s a bottom below which the result isn’t acceptable : it doesn’t meet the need, it creates risk, or it fails to justify the investment. And there’s a top above which you’re spending more effort, time, or money than the marginal improvement warrants. The space between those two boundaries is where good lives. I’ve seen leaders, especially technically-minded ones, struggle with this because it feels imprecise. They want a target, not a zone. But insisting on a precise target in an inherently uncertain world is how you end up with teams that are either perpetually disappointed or perpetually re-scoping.
Think about it in practical terms. If you’re building a new internal tool, what good looks like might be: it handles the core workflow reliably, it’s adopted by at least 80% of the target users within the first quarter, and it reduces the manual effort by half. That’s the bottom of the range ; below that, you haven’t solved the problem. The top of the range might be: it handles edge cases gracefully, adoption is near-universal, and it reduces effort by 80%. Anything beyond that , say, building an elegant plugin architecture for extensibility that nobody has asked for , is above the range. It’s not that it wouldn’t be nice; it’s that the cost of getting there isn’t justified by the value. Defining both boundaries before you start gives you the ability to make rational tradeoff decisions throughout the work rather than arguing about them at the end.
Why We Lose Perspective
The reason this discipline matters so much is that perspective is fragile, especially under pressure. I’ve watched teams lose their sense of proportion in both directions, and the mechanisms are predictable:
- Perfectionism creep : A technically excellent team sets out to build something good and gradually raises the bar as they go, because each incremental improvement feels small and justifiable in isolation. Before anyone realizes it, they’ve spent three months polishing something that was ready to ship after six weeks. Nobody made a bad decision at any individual moment, but the aggregate was a significant misallocation of effort.
- Standards erosion : A team under deadline pressure starts making small concessions. Each one is defensible on its own, but over time the cumulative effect is a product that barely functions or a process that barely holds. They ship something, declare victory, and then spend the next year dealing with the consequences.
- Anchoring to the wrong reference point : Sometimes teams calibrate “good” against what a competitor has built, or what they built at a previous company, or what they read about in a blog post, without considering whether that reference point is actually relevant to their context, their resources, or their customers. What good looks like for a company with a thousand engineers and a billion dollars in revenue is rarely what good looks like for a team of twenty building their first product.
All of these failures share a common trait: the absence of an explicit, agreed-upon definition of the acceptable range before the work started. When you don’t define the range up front, you leave it to be defined implicitly by whoever has the strongest personality, the most anxiety, or the most influence in the room at any given moment. That’s not a strategy; it’s an accident waiting to happen.
Making This Practical
I’ve found the most effective way to apply this is to make the conversation explicit and collaborative. Before kicking off a meaningful piece of work, I ask the team and the stakeholders to answer three questions together:
- What is the minimum outcome that would make this investment worthwhile? What’s the floor below which we’ve failed?
- What is a realistic outcome that we’d be genuinely satisfied with, given our constraints?
- At what point would further improvement no longer justify the cost , where do we hit diminishing returns?
The conversation itself is often more valuable than the answers. It surfaces misaligned expectations early, before they become conflicts. I’ve seen cases where a CTO assumed the team was building a robust, scalable platform while the product lead assumed they were building a quick proof of concept. Both were reasonable positions, but they were incompatible, and without the explicit conversation about what good looks like, that incompatibility would have surfaced six weeks later as frustration and finger-pointing.
There’s another benefit that’s easy to overlook: defining the range gives people permission to stop. Some of the best engineers I’ve worked with have a natural inclination to keep refining, keep improving, keep making things better. That instinct is one of their greatest strengths, and I never want to extinguish it. But without a clear definition of “good enough for now,” that instinct can become a liability. When you’ve defined the top of the range, you’ve given them a principled reason to move on rather than asking them to accept something they feel is unfinished. It transforms the conversation from “stop caring” to “redirect your caring where it will have the most impact next.”
I’ve also learned that the range needs to be revisited, not just set and forgotten. Circumstances change : new information emerges, constraints shift, the competitive landscape evolves. What good looked like three months ago might not be what good looks like today. The discipline isn’t about rigid adherence to an initial definition; it’s about always having a current definition that everyone understands. The teams I’ve seen operate most effectively are the ones that treat this as a living conversation, revisiting it at natural checkpoints rather than treating the initial definition as immutable.
Ultimately, this practice is about maintaining honesty with yourself and your organization about what you’re actually trying to achieve and what success actually requires. It’s easy, especially for ambitious leaders and talented teams, to conflate good with exceptional and burn resources chasing a standard that wasn’t necessary. It’s equally easy, under pressure, to convince yourself that something subpar is acceptable because you’re tired of fighting for better. The range , honestly and collaboratively defined , keeps you grounded in reality, and reality is where all the value actually gets created.




