My 2nd article this week, I'm supposed to keep it to just once per week but whateverrr, I've had this in drafts for a while now, let's get straight into it.
Here's the thing about "ownership mindset" that nobody on the management side wants to admit: you love the slogan. You hate the behavior.
You want engineers who care. Who think about scale. Who ask "wait, will this melt in four months?" Who treat the product like it's theirs.
Cool. Then someone actually does that in a meeting, and suddenly they're "being difficult," "not a team player," "too negative," or my personal favorite — "can you just build what I asked for?"
I've sat through this movie enough times that I can recite the script.
The Script
Manager / PM / whoever is currently wearing the "decider" hat:
We need someone with real ownership on this. Someone who cares whether the product actually works.
Someone raises a real concern about the architecture. Not vibes. Constraints. Data model. Failure modes. The stuff that will wake someone up at in the middle of the night later.
Same person, 90 seconds later:
Why are you pushing back so hard? Why are you being so difficult? We're already behind. Just ship it.
So which is it?
You asked for ownership. They gave you ownership. Now you're mad that ownership came with opinions.
You're Not Confused. You're Convenient.
I used to think this was a communication problem. It's not. It's incentives.
You feel the delay today. You don't feel the outage later. Design pushback slows the thing you want shipped this sprint. The mess it prevents shows up next quarter, under someone else's KPI. Of course you optimize for the pain that's in the room.
Hierarchy feels like efficiency when you're on top of it. A senior decision getting questioned doesn't feel like engineering. It feels like disrespect. Even when the question is "this will corrupt data under concurrent writes." You wanted a yes. You got a reason. Those feel different to the ego.
Compliance feels like progress. An engineer saying "yeah, I'll build it" gives you a hit of motion. An engineer saying "we should rethink the data model" feels like friction. Your brain does lazy math: less friction = better leadership. No. Less friction = quieter failure.
And "ownership" means two different things depending on who's talking. When you say it, you often mean "make sure it ships and don't bother me." When I hear it, I mean "make sure it doesn't screw us." Those conflict. You keep using the same word like that's my problem.
The Quiet Engineer Is Not Owning Anything
Here's the part that should piss you off more than it does: the engineer who just implements what you ask, every time, with a smile, is not demonstrating ownership.
They're optimizing for approval.
They're minimizing confrontation.
They're following orders.
None of that is ownership. That's liability transfer.
When it breaks, they've got the perfect line: "I built exactly what was specified." Clean hands. Diffused responsibility. You got the compliant builder you rewarded.
The person who says "this is going to bite us" is the one actually treating the outcome like theirs. They're spending social capital in a room that usually punishes that spend. If you punish them, don't act shocked when the next three people learn to shut up.
What Ownership Actually Looks Like From Our Side
It's not being a dick in design reviews. It's this:
Concerns come early. During design. Not three weeks into implementation when changing direction costs a sprint and a relationship.
Reasoning, not vibes. "This N+1 dies at 10k users on our current growth curve" beats "this feels off." If an engineer can't explain the failure mode, push back. If they can — listen.
Alternatives, not just no. "What if we index on user_id?" is ownership. "This won't work, good luck" is theater.
Knowing when to escalate vs. when to build-and-learn. Sometimes you need to ship something imperfect to learn. Sometimes you're walking into a known footgun. A good owner can tell you which meeting you're in.
Staying for the outcome. "I told you so" is not ownership. Owning it means if you were wrong, you help clean it up. If you were right and ignored, you still help clean it up — and you remember who ignored you.
What You Get When You Train That Out of People
I've watched this culture settle in. It's not subtle.
- Engineers who optimize for "not getting blamed" instead of "building something that lasts"
- Debt that accumulates in silence because speaking up is career-limiting
- Smart people quietly updating their LinkedIn
- Meltdowns that somehow still surprise leadership
- "Team player" becoming code for "doesn't question bad decisions"
You buy short-term speed. You pay medium-term chaos. Then you schedule a retrospective where everyone agrees "we should have spoken up earlier," and nobody asks why they stopped.
If You Actually Want It
Stop asking for ownership like it's a personality trait. Build the conditions where it's safe to exercise.
Separate design talk from implementation talk. Let people think out loud about whether something will work before you've already committed the sprint. Thinking hard and shipping fast aren't enemies. Collapsing them into one meeting is.
Reward the pushback you say you want. If someone raised a legitimate concern and you overrode them, make that a visible decision. Don't pretend the conversation didn't happen. If they were right later, say so. Out loud. In front of people. If they were wrong, they learn the domain. Either way, the signal is: speaking up was the job.
Be specific. "Take ownership" is useless. Do you mean "ship this by Friday even if it's dirty"? Then say that. Do you mean "this has to survive 10x traffic"? Say that. Vague slogans produce people guessing what will get them yelled at least.
Listen when we push back. Not because we're always right — we're not. Because we live in the codebase you only see through tickets. That's not attitude. That's the job you hired us for.
Normalize disagreement. The best teams I've been on argue about design and still trust each other the next morning. Disagreement isn't personal. Making it personal is how you get yes-men and broken systems.
Bottom Line
You probably do want engineers with an ownership mindset.
What you don't want, and keep accidentally selecting for, is engineers who smile, implement, and let you walk into the wall so they can stay popular.
Ownership is annoying. It asks inconvenient questions. It slows the "just ship it" meeting. It makes seniors defend decisions they wanted to treat as settled.
If that sounds exhausting, good. That's the cost of building something that doesn't fall apart the second real users touch it.
You don't get "people who care" and "people who never push back." Pick one.
And if you pick compliance, at least stop calling it ownership. That word still means something to the rest of us.
Top comments (29)
I totally agree! Unfortunately, that's the sad reality.
Quite often, if you want to change something, you end up having to convince stakeholders by highlighting the risks, and security concerns are usually the one argument that gets everyone's attention. 😅
Sometimes I think, "I became a developer because I wanted to build software, not because I wanted to become a psychologist who's constantly figuring out how to persuade people to make better technical decisions." 😂
Seriously!
We end up spending way more time playing armchair psychologist trying to convince people to make basic technical decisions than actually building. The 'security risk' card really is the only cheat code they understand! 😤
The 90-second pivot from "we need ownership" to "just ship it" is painfully relatable. What I've noticed is that the word "ownership" in most orgs actually means "care about outcomes" — but only when those outcomes align with the timeline.
The real issue is that genuine ownership requires a feedback loop where the person raising the concern is also the one who has to deal with the consequences. When ownership is decoupled from consequence (as it almost always is in corporate structures), what management actually wants is "responsible execution" — not ownership.
The engineers who get labeled "difficult" aren't lacking ownership. They have too much of it for the incentive structure to tolerate. The fix isn't cultural — it's structural. Give people actual decision authority over the things they're asked to own, and suddenly the "difficult" ones become the most valuable.
True and to sum it all up, many managements just can't seem to see that friction doesn't always mean "difficult" and some times, the friction just means the supposed owners actually care.
Exactly — and that friction is usually a signal that someone's actually thinking through the consequences. The problem is that management optimizes for "issues raised" and treats silence as success. So the teams that flag things early get labeled as slow, while the ones that ship and discover problems later get credit for "moving fast." It's a broken incentive loop that rewards the wrong behavior.
Yes sirrrr
The 90-second pivot from 'we need ownership' to 'just ship it' is painfully relatable because true ownership is inherently inconvenient. If leadership treats engineering opinions as 'friction' to be optimized away rather than critical feedback, they aren't actually looking for owners—they are looking for compliant renters who will build exactly what is asked, watch it break, and hand over the receipt. You simply cannot expect people to care about the structural integrity of the house if you punish them the second they point out a leak in the roof.
Preach!
Ownership mindset gets harder to demand honestly once a meaningful share of the code wasn't written by the person being asked to own it. Worth being explicit about whether "own this" means "understand every line" or "be accountable for the outcome," because AI-assisted teams increasingly can't do the first.
right and some times, the first one, even if they know every bit of the code also doesn't mean they'll account for the outcome.
I like you.
I am 100% a "own it person". (I'm a top level engineer. "Lead, Chief, Principle Engineer" whatever people want to call me. I go about getting others to own things, very differently than this approach. (which btw, everything you're saying here is completely 100% true).
This is definitely a management vs leadership question.
The way I've won out over what you're speaking about here is to out own the project over them. (This is leadership, not management) Not for the feign of heart though. Gotta show up, everyday, more, harder than management. Be strategic with what you battle and argue about. (I like to choose the things nobody thinks about, or cares about).
Its worthwhile to actually understand who ends up going into management, and how the culture existing in most management circles. What's funny, is the compliance thing, is the ACTUAL culture that is impacting them, and yet, just like they are relaying to you they are being told from above to "own it". So they parrot it, and push it down. (That's compliance).
I'm not a big fan of management personally, but I'd recommend being empathetic to their predicament.
Thank you! isn't being empathetic, the only proper, long term way to survive in such chaos in every corporate/startup hell?
I'm also not a big fan of management...
Like, I can say all these things straight to a manager's face with no repercussions but I don't really get anything back in return except the consequences and I get to say: " I told you so "
I may be frustrated with the way a decision is being irrationally made but then again, it's not really worth it long term. you can disguise breaking ties as disconnecting yourself from toxic people but in this world, connection is everything. I fix things quietly behind management's back most of the time but then again, quietly fixing things can also be a double-edged sword, it lets leadership believe their process works while you absorb the hidden cost and the question becomes how do you stay empathetic without being complicit?
I only get to rant here and with everyone else agreeing because they've been wanting to say things like this out loud too and we get to share our problems and engage like what we're having now.
This is spot on. The classic corporate paradox is wanting 'owners' but treating engineers like 'renters.' Renters don't spend their own money to fix a leaky roof or upgrade the plumbing; they just report it, and if nothing happens, they live with it or move out. If management doesn't give engineers actual agency over the technical direction (or punish them when they raise valid concerns), they shouldn't be surprised when people act like compliant renters who build exactly what is specified, watch it break, and hand over the receipt
Haha I love the comparison!
We can also compare the "quiet engineer" to the short-term renters too. these people have no will to act like an owner.
If they're only renting for 6 months, they couldn't give a damn about a leaky roof because they won't be here long anyway.
Ownership mindset only means something if the team also gives people the information and authority to act. Otherwise it becomes a polite way to ask for accountability without control. I like measuring ownership by what decisions a person can safely make without waiting for a meeting.
The person who says this is going to bite us is showing the strongest ownership signal, and traditional hiring filters them out because they were difficult in the interview. This is exactly why negative requirements matter in professional matching. The boundaries someone draws, what they refuse to ship, what they push back on, are stronger identity signals than any self-reported skill. Opportunity Skill's impression system treats those rejection patterns as first-class data for semantic matching. The people who say no well are the ones you actually want to find.
Right and to be honest, I can't see how long is this behavior from management's gonna last but hopefully, we can all have an environment where we can work by raising concerns without being labeled a friction.
This resonates so much. The quiet engineer who just builds whatever is asked
isn't demonstrating ownership — they're optimizing for not getting blamed.
I've been on both sides of this. As a solo builder working on a security tool,
I've had moments where I had to push back against my own "just ship it" instinct
because the architecture genuinely needed rethinking. Nobody was in the room to
hear the argument — but the codebase would've paid for it later.
The line that hit hardest: "You buy short-term speed. You pay medium-term chaos."
Saving this one for the next time I need to explain why I'm asking questions
instead of just shipping.
mmmm, the human mind is not, by default, wire to see the long term consequences and the price they have to pay because looking into the future requires effort. big effort.
The Michael Jackson AI slop header is diabolical
Tried to fix that 3rd hand, didnt work. left it there haha
Some comments may only be visible to logged-in visitors. Sign in to view all comments.