Path of Vision

If your work isn't making anyone uncomfortable, you're probably not pushing hard enough.

I've been thinking about this a lot lately. Not as some motivational platitude, but as a diagnostic tool. A way to measure whether you're actually doing something that matters or just rearranging furniture in a burning building.

Here's what I've observed over years of building things inside organizations: the work that creates the most value is almost never the work that was pre-approved, budgeted, roadmapped, and blessed by seventeen committees. The work that moves the needle is the work that someone saw needed doing and just... did.

The Gap Between What Exists and What Should Exist

There's a particular kind of frustration that comes from seeing a gap clearly — a painful, obvious gap between what engineers need and what they have — and watching nothing fill it. Committees form. Roadmaps get drafted. Strategy documents circulate. And the gap remains.

I've been in that position. Seeing opportunities to connect systems, to give developers actual leverage over their own work, to turn scattered knowledge into something usable. The kind of work that could serve multiple purposes at once — accelerating onboarding, improving documentation, making architecture decisions visible and queryable.

You can spend months trying to build consensus for work like this. Organizing alignment sessions. Explaining the vision to stakeholders who have their own priorities. Waiting for budget cycles. Watching the gap persist while the org chart sorts itself out.

Or you can build.

In the past, I chose to build. Not alone — real work never happens alone — but with conviction. With a vision that I knew would be easier to demonstrate than to explain. Some things you have to show people before they can see them.

Process as Protection

When you move fast and build with conviction, you'll hear familiar refrains:

"It wasn't tracked." "It wasn't approved." "It's in my scope." "There's no budget for this." "Key areas weren't aware."

Let me be direct: most of the time, this isn't feedback. It's friction. It's a system optimising for its own preservation rather than for outcomes.

I'm not saying process has no value. Good process creates guardrails that prevent disasters. Good process captures institutional knowledge. Good process makes coordination possible at scale.

But there's a difference between process that enables and process that protects. Process that enables asks: "How do we help people do the right thing safely?" Process that protects asks: "How do we ensure nothing happens without our involvement?"

One creates value. The other captures it.

The tell is simple: when someone builds something useful, does the process response focus on "how do we make this better and safer?" or does it focus on "why wasn't I consulted?" The former is engineering. The latter is territory.

The Scope Trap

"It's in my scope" might be the most innovation-killing phrase in enterprise technology.

Scope is a useful concept for accountability. Someone needs to own things. Someone needs to be responsible when systems break at 3 AM. I'm not arguing against ownership.

But scope has a shadow side. It becomes a fence. It becomes a way to prevent others from solving problems because those problems belong to someone else — even when that someone else isn't solving them.

Here's what I've learned: if you're building something genuinely useful, and someone's primary objection is that it falls within their scope, you've already won the argument. They're not saying your solution is bad. They're not saying it doesn't work. They're saying it's theirs to build — which is an admission that it should exist.

The question then becomes: why didn't it exist before? And why is the response to someone building it not gratitude, but grievance?

I've seen this pattern repeat. Someone creates something that helps developers for example — tooling, automation, a better way to access information. And instead of asking "how do we build on this?" the response is "this should have gone through us." The focus shifts from the value created to the process violated.

This is a system protecting itself. And systems that protect themselves at the expense of outcomes are systems that deserve to be disrupted.

What Actually Matters

Let me be clear about what I think matters and what doesn't.

What matters: Does it work? Does it help people? Is it secure? Is it maintainable? Does it make the right behavior the easy behavior? Can we expand it?

What matters less than people pretend: Was it on a roadmap? Did it go through the right committee? Is there a budget line item? Does it appear in the official strategy document?

The first set of questions is about engineering. The second set is about bureaucracy.

I'm not saying the second set is worthless. In large organizations, coordination matters. Tracking matters. Knowing what exists matters. But these are means, not ends. They serve the work; the work doesn't serve them.

When the process becomes more important than the outcome, you've lost the plot. You're optimizing for legibility over value.

The Multiplier Effect

Here's something I've come to believe deeply: the best solutions serve multiple purposes.

When you build something that only solves one problem, you've created a tool. When you build something that solves one problem in a way that naturally extends to others, you've created infrastructure.

This is why I think in terms of platforms rather than projects. A single capability — say, making architectural knowledge queryable and accessible — doesn't just help with one use case. It accelerates onboarding and contribution. It improves decision-making. It reduces the time spent hunting for information that someone, somewhere, already documented.

The vision isn't about building one thing. It's about building the thing that makes building other things easier.

But try explaining that in a roadmap review. Try getting budget approval for "infrastructure that will enable things we haven't thought of yet." The system wants specificity. It wants bounded scope. It wants predictable outcomes and ROI.

Sometimes you have to prove the multiplier effect before you can get permission to pursue it. Sometimes the only way to show what's possible is to make it exist.

A Note on Teamwork

I've noticed that appeals to unity often come loudest when someone is trying to slow down work that makes them look bad. "Teamwork" becomes a way to enforce the lowest common denominator, to ensure that nobody moves faster than the slowest approval process.

Real teamwork isn't about everyone moving at the same pace. It's about everyone moving toward the same goal. Sometimes that means one person sprints ahead to prove something is possible, and others follow once the path is clear.

The alternative — waiting for perfect consensus, perfect tracking, perfect alignment — is how organizations slowly become irrelevant while congratulating themselves on their governance maturity.

I'm not advocating for chaos. I'm advocating for trust. Trust that people who see problems clearly and have the skills to solve them should be empowered to act. Trust that working software is a better starting point for discussion than a slide deck. Trust that the goal is outcomes, not process compliance.

The Discomfort Is the Point

When your work pulls people out of their comfort zone, you're probably on the right path. It means you're creating something that didn't exist before. Something that challenges the way things have always been done. Something that makes visible what was previously invisible.

This isn't comfortable. It won't earn you friends in every corner. Some people will see you as a threat rather than an asset.

But here's what I know: the path of vision is rarely paved with consensus. It's paved with results.

The builders I respect most share a common trait. They don't wait for permission to solve problems they can see clearly. They don't let org charts determine what they're allowed to care about. They build first and work through the politics second — because they understand that working software is the best argument.

Does this create friction? Yes. Does it sometimes step on toes? Definitely. Is it the only way to actually move things forward in organizations that have optimized themselves into paralysis? Also yes.

Keep Building

So here's my advice, for whatever it's worth:

Keep building. Keep shipping. Let the work speak.

When someone tells you that your working solution isn't valid because it wasn't properly tracked, ask yourself: would they be happier if the solution didn't exist at all?

Usually, the answer tells you everything you need to know about priorities on the table.

The future belongs to people who build it. Not to people who schedule meetings about building it.