How the Tide Is Made

In roadmap meetings, a certain kind of customer request begins as a specific problem and ends as an architecture diagram.

A customer needs a new approval path. Another wants permissions that don't quite match the existing hierarchy. Sales has three deals stalled on variations of the same issue, and Support has developed a workaround involving a spreadsheet, two Slack messages, and one person who knows which setting can't be changed after launch. The immediate request is usually clear. What takes longer is deciding whether to solve that request or treat it as evidence of something underneath it.

Early in my career, a product manager described the second choice as raising the waterline. Instead of moving from one loud customer to the next, you invest in the capability that makes an entire category of problems easier. You rebuild permissions rather than adding another exception. You fix the contracting workflow rather than assigning one more person to shepherd unusual deals through Legal. The edge cases get documented, the handoff changes, or someone finally removes the dependency that has required the same act of organizational heroism every quarter.

The phrase appealed to me immediately, which should have been the first warning. It gave patient work a larger moral shape and made the refusal to chase every urgent request sound like evidence of discipline rather than distance. I'm a distance runner. Of course this was going to appeal to me.

There's real wisdom in it. Companies accumulate small accommodations faster than they notice, and each one makes sense when viewed from close enough. A special field gets added for one customer, then becomes required by an integration nobody owns. Pricing exceptions are copied into the next contract because the person drafting it assumes there was a reason. Manual reviews introduced during an early launch remains in place two years later, even though nobody remembers what failure it was truly meant to prevent. Eventually the organization is spending more time preserving its exceptions than serving the needs that created them.

Work beneath the surface can reverse that accumulation. Improvements might not appear in the timeframe when the underlying work begins, but six months later fewer deals require escalation, new hires can follow the process without being taught a full oral history, and the people who once spent their weeks catching dropped handoffs are available to do something other than compensate for the system around them.

The difficulty is that nearly every delayed payoff can be described this way.

A team can spend a year building a generalized platform for requests that three customers were willing to pay for in their original, inconvenient form. An operations group can redesign a workflow whose real problem was that nobody wanted to make an unpopular decision. A leader can dismiss repeated objections as symptoms of an underlying issue, then continue searching for the underlying issue long after the objections have become evidence that the current approach is failing.

The language of leverage makes this especially hard to see. Immediate work is narrow, reactive, and difficult to celebrate. Foundational work compounds, creates capacity, and makes the organization more durable. Once the choice has been described in those terms, choosing the foundation begins to feel like choosing adulthood.

It also creates an unusually forgiving standard of proof. The customer request can be judged now because someone is waiting for an answer. The larger investment is judged against a future in which its benefits have had enough time to emerge, adjacent work has been completed, adoption has spread, and the company has become the version of itself the project was designed to support. When that future doesn't arrive, the explanation is often that the work was interrupted, underfunded, or never given a fair chance.

Sometimes that explanation is correct. Infrastructure is frequently abandoned just before it becomes useful, and teams that demand an immediate return from every investment eventually condemn themselves to solving the same problems by hand. But the opposite failure has its own persistence. Once a project has been designated foundational, every additional month can become evidence of its importance rather than evidence that the original theory was wrong.

The distinction can't rest on whether the work feels strategic, because almost everything can be made to feel strategic from far enough away. The teams that give themselves some chance of seeing the difference can usually say which recurring problem the investment is supposed to remove, what behavior should change if it works, and roughly when they expect to see that change. They say it before the work begins, while stopping is still an available decision, not because those answers guarantee that the investment is right but because they leave something behind that the project can later be judged against.

I've never been able to tell the difference reliably in advance. It's easiest to see afterward, once the work has either removed something or hasn't, which is not when the decision has to be made. The best you can do beforehand is make the promise specific enough that failure cannot later be redescribed as patience.

Raising the waterline eventually leaves a mark somewhere visible: fewer exceptions, shorter escalations, decisions made by the people closest to the work, customers who stop asking for the same accommodation because the product now handles the underlying need. Something that used to require explanation, intervention, or a person who knew the workaround no longer does.

Without that change, the metaphor becomes a way of keeping every promised benefit safely offshore. The team remains busy beneath the surface, confident that the water is rising, while the same requests keep arriving from people who have started making other plans.