VOOZH about

URL: https://thenewstack.io/permissionless-ownership-raising-hand/

⇱ "I think this is costing us more than we realize": what permissionless ownership really asks of you - The New Stack


TNS
SUBSCRIBE
Join our community of software engineering leaders and aspirational developers. Always stay in-the-know by getting the most important news and exclusive content delivered fresh to your inbox to learn more about at-scale software development.
REQUIRED
It seems that you've previously unsubscribed from our newsletter in the past. Click the button below to open the re-subscribe form in a new tab. When you're done, simply close that tab and continue with this form to complete your subscription.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.
Welcome and thank you for joining The New Stack community!
Please answer a few simple questions to help us deliver the news and resources you are interested in.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Great to meet you!
Tell us a bit about your job so we can cover the topics you find most relevant.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Welcome!

We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.

What’s next?

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

PREV
1 of 2
NEXT
VOXPOP
As a JavaScript developer, what non-React tools do you use most often?
Angular
0%
Astro
0%
Svelte
0%
Vue.js
0%
Other
0%
I only use React
0%
I don't use JavaScript
0%
Thanks for your opinion! Subscribe below to get the final results, published exclusively in our TNS Update newsletter:
NEW! Try Stackie AI
From clobbered drafts to real-time sync
Apr 14th 2026 10:00am, by David Moore
TypeScript 6.0 RC arrives as a bridge to a faster future
Mar 14th 2026 9:00am, by Darryl K. Taft
Mastra empowers web devs to build AI agents in TypeScript
Jan 28th 2026 11:00am, by Loraine Lawson
2026-06-19 10:30:00
"I think this is costing us more than we realize": what permissionless ownership really asks of you
sponsor-webflow,sponsored-post-contributed,
Software Development / Tech Careers / Tech Culture

“I think this is costing us more than we realize”: what permissionless ownership really asks of you

Permissionless ownership means turning "someone should fix this" into "I can help." Learn how to bridge the gap and drive real impact.
Jun 19th, 2026 10:30am by Nicolás Vázquez
👁 Featued image for: “I think this is costing us more than we realize”: what permissionless ownership really asks of you
Kyunghee Yim for Unsplash+
Webflow sponsored this post.

Most people do not stay quiet because they have nothing to say.

They stay quiet because speaking up changes their relationship to the problem.

Before you say something, the gap is still outside of you. It is just something you noticed: a slow process, an unclear handoff, a decision that keeps getting deferred, a customer confusion everyone has learned to work around.

But the moment you raise your hand, you become part of what happens next.

That is why the hesitation is real.

Is this a real gap, or just my personal preference?

Do I have enough context to raise it responsibly?  

Will this create clarity, or just another thread?  

Am I willing to help move it forward, or am I just naming the problem?

We have all had that internal negotiation.

No one has assigned it to you. It does not yet belong to any plan, any owner, or any ticket with your name on it.

You can wait until someone turns it into official work, assigns an owner, and gives you permission to care about it. Or you can raise your hand.

That is where permissionless ownership starts.

Permissionless ownership  

noun

1. The practice of noticing what could be better before someone has to assign it to you.  

2. The act of raising your hand with enough context, judgment, and care to help move work forward.  

3. A way of contributing that starts with responsibility, not permission.

This is not about doing whatever you want, ignoring priorities, or turning every observation into a crusade. It is about learning how to turn “someone should make this better” into “I can help make this better” — without creating chaos for the people around you.

The burden of seeing

Ownership rarely announces itself.

It does not usually arrive as a clean assignment, a calendar invite, or a ticket with your name on it. More often, it starts as a small discomfort: something in the work that keeps bothering you because you know it could be better.

At first, it is easy to treat that discomfort as background noise.

The brief is unclear, but the team finds a way through it. The handoff loses context, but people compensate. The customer keeps running into the same confusion, but everyone has learned the workaround. The process is slower than it needs to be, but it has been slow for long enough that slowness starts to feel normal.

Then, at some point, noticing becomes harder to separate from responsibility.

That does not mean every problem you notice is yours to solve. It does not mean every irritation deserves a meeting, a thread, or a new project.

But it does mean that seeing clearly comes with a choice.

It is tempting to make that choice conditional on the environment around you. If the team had a better process. If the culture made more room for new ideas. If someone invited you to speak up. And yes, culture matters. A healthy team makes initiative safer, easier, and more welcome.

But permissionless ownership cannot depend entirely on explicit invitation. If you only take ownership when the system has already made room for it, you are still waiting for permission — just in a more acceptable form.

“If you only take ownership when the system has already made room for it, you are still waiting for permission — just in a more acceptable form.”

You can keep working around the gap, waiting for someone else to name it. Or you can raise your hand.

Not necessarily with a full solution. Not with certainty. Not with a heroic plan to fix everything yourself.

Sometimes raising your hand is simply saying: “I think this is costing us more than we realize.”

This is where ownership often gets misunderstood.

Responsibility does not mean heroics.

Taking ownership of a gap does not mean disappearing for two weeks and coming back with a fully baked solution. It does not mean assigning yourself a shadow roadmap, bypassing the team, or trying to prove that you can carry the whole thing alone.

Most of the time, ownership starts smaller than that.

It might mean writing down the problem clearly enough for others to react to it. It might mean asking whether someone is already thinking about it. It might mean creating the first ticket, proposing a small plan, gathering context, or breaking the work into pieces the team can reason about. Sometimes it means owning one part yourself and helping route the rest to the right people.

The important shift is that you are no longer just pointing at the gap. You are helping make it actionable.

Before the problem has a name

Some work is visible enough to frustrate everyone, but not official enough to belong to anyone.

It sits between roles. Between handoffs. Between “we should fix this” and “who owns it?”

A brief keeps arriving incomplete, so every project begins with the same confusion. A review process raises more questions than it answers, so people start preparing for the review rather than improving the work. A campaign ships, but the learning never makes it back into the next one. A customer asks the same question for the third time because the answer exists somewhere, but nowhere useful.

“Some work is visible enough to frustrate everyone, but not official enough to belong to anyone.”

In engineering, it might be a recurring bug that has never become important enough to prioritize, a product pattern that keeps creating the same support questions, or an internal workflow held together by memory and goodwill.

None of these things look dramatic at first.

That is part of the problem.

They become normal before they become named. And once something becomes normal, it becomes easy to mistake it for the cost of doing business.

And once something has no name, it becomes very easy to defend your distance from it.

No one asked me to.  

No one assigned it to me.  

It is outside the scope of my task.

Sometimes, those are honest boundaries. Not every problem you notice deserves your time, and not every loose end is yours to close. Permissionless ownership is not about absorbing every unresolved thing around you.

But scope can be both a boundary and a hiding place.

You might not have time to fix the problem. You might not be the right person to own it. It might genuinely belong to another team, function, or area of expertise.

Still, you can often take a first step.

You can name what is happening. You can ask whether someone is already looking at it. You can create a ticket so it stops living only in conversation. You can write a short draft, collect a concrete example, or route it to someone closer to the issue. You can say, “I do not have capacity to take this on right now, but I noticed this pattern and wanted to make sure it is visible.”

That is not overstepping. That is ownership at the smallest useful scale.

Permissionless ownership does not always mean owning the entire solution. Sometimes it means refusing to let a real problem stay invisible just because it did not arrive with your name on it.

A complaint, or a confession of responsibility

A complaint is not always a bad place to start.

Sometimes a complaint is the first honest signal that something deserves attention. It means you noticed the friction. You felt the cost. You saw the same confusion repeat enough times that it stopped feeling accidental.

The problem is not the complaint.

The problem is staying there.

There is a particular kind of comfort in naming what is wrong without becoming responsible for what happens next. “This process is broken.” “This should be clearer.” “Someone should fix this.”

“The problem is not the complaint. The problem is staying there.”

All of those may be true. But truth, by itself, does not move the work.

At some point, a complaint has to decide what it wants to become.

It can remain a release valve: a way to express frustration, gather agreement, and return to the same pattern tomorrow.

Or it can become a confession of responsibility.

Not responsibility for the whole solution. Not responsibility for fixing everything yourself. But responsibility for making the observation useful.

That is where raising your hand changes shape.

The language changes. It becomes less about declaring a defect and more about offering the team something it can use:

> “I noticed this keeps happening.”  

> “Here is where I think it is costing us.”  

> “Here is one example.”  

> “Here is a small first step.”  

> “Here is what I can realistically help with.”

The difference is not politeness. It is usefulness.

A useful signal gives the team something to inspect. It brings context instead of pressure. It respects priorities instead of pretending they do not exist. It does not volunteer for work you do not have time to do, just to sound committed.

That last part matters.

Permissionless ownership is not about pretending you have infinite capacity. It is about being honest with the capacity you do have.

Sometimes that means owning the next step. Sometimes it means creating the ticket. Sometimes it means writing the first draft. Sometimes it means saying, “I do not have bandwidth to take this on, but I wanted to make the pattern visible.”

That is still ownership.

Because you are no longer asking the team to carry your frustration. You are helping the team understand what your frustration is trying to reveal.

When ownership becomes theater

There is a version of ownership that is no longer about the work.

It looks like initiative from a distance. It has motion, energy, updates, opinions. It is visible. Sometimes very visible.

But something is off.

The goal has shifted from making the work better to being seen as making the work better.

That is when ownership becomes theater.

Visibility itself is not the problem. Good work should be visible. Teams need to know what is happening, who is helping, where progress is being made, and where decisions are stuck.

But visibility and posturing are not the same thing.

You can usually feel the difference.

Posturing tries to be everywhere because being involved everywhere looks valuable. Ownership knows that focus is part of responsibility.

Posturing rushes to attack the gap because action looks better than patience. Ownership asks whether now is the right time, whether the team has higher priorities, and whether someone else is already closer to the problem.

Posturing disappears into a problem and returns with “I already fixed this.” Ownership says, “I noticed this; is anyone already working on it?”

The danger is not only wasted effort.

It is trust.

When ownership becomes theater, initiative starts to look suspicious. People become slower to welcome it because they have seen it arrive with hidden costs: duplicated work, surprise decisions, ignored context, unnecessary urgency, and attention diverted from what matters most.

Permissionless ownership should make the work easier to trust, not harder.

Sometimes that means acting. Sometimes it means waiting. Sometimes it means naming the gap and leaving it alone for now. Sometimes it means saying, “I noticed this, but I do not think it is more important than what we are focused on.”

That restraint matters.

Because the goal is not to be seen owning the work.

The goal is to make the work better.

To make the work better

The opposite of permissionless ownership is not laziness.

It is indifference.

It is what happens when the unclear brief no longer bothers you. When the broken handoff becomes “just how this team works.” When the same customer confusion shows up again and again, and you no longer feel the urge to ask why. When the problem is visible, but no longer feels like something that concerns you.

That is a quiet thing. It rarely looks like failure from the outside. You may still be doing your job. You may still be delivering what was assigned. You may still be meeting expectations.

But something important has been lost.

Permissionless ownership is one way to resist that loss.

It is the practice of staying awake to the work around you: noticing what could be better, caring enough to name it, and having the judgment to know when to act, when to ask, when to wait, and when to route the problem to someone closer to it.

This is also why the idea feels connected to the kind of work we care about at Webflow.

We are thinking a lot about what it takes for teams to stay closer to the work: fewer unnecessary layers, fewer handoffs that slow simple decisions, and more room for direct ownership by the people closest to the problem.

That matters when building product. It matters when creating marketing experiences. And it matters in the way teams operate day to day.

The best moments are not always dramatic. Sometimes they look like someone leaving the right comment in a document, creating the first ticket, pulling the right people into a conversation, or naming a problem clearly enough that the team can finally see it together.

That is the same instinct this essay is about: shortening the distance between noticing something and improving it.

Permissionless ownership starts with a small refusal:

Not to look away from what you can clearly see.

Not to wait for every problem to arrive perfectly packaged.

Not to confuse “no one asked me to” with “this does not matter.”

And, eventually, to turn “someone should make this better” into something quieter, more useful, and more responsible:

“I can help make this better.”

This article was originally published on June 16, 2026, on webflow.com.

Webflow is the agentic web marketing platform where AI and teams design, build, optimize, and publish in one governed system. Visual authoring, structured CMS, managed hosting, and developer extensibility through APIs, code components, and cloud deployments. Not just content. The full experience.
Learn More
Hear more from our sponsor
TRENDING STORIES
Nicolás Vázquez is a Senior Software Engineer at Webflow, working on Applied AI. He cares about the full shape of software: the systems behind it, the interfaces people touch, and the team habits that help good ideas become real. With...
Read more from Nicolás Vázquez
Webflow sponsored this post.
SHARE THIS STORY
TRENDING STORIES
SHARE THIS STORY
TRENDING STORIES
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.