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...
For further actions, you may consider blocking this person and/or reporting abuse
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
Great read. Ownership without authority or psychological safety isn't ownership—it's accountability theater. Teams thrive when respectful pushback is encouraged, not punished.
Exactly! a team grows the more you encourage them to speak up!
and sorry for the late reply haha.
This changed how I think about my workflow. Thanks for sharing your journey!
and thank you for reading and i'm glad i help changed some things about your workflow!
In my experience as a freelancer, I've worked directly with clients or as a collaborator in large companies. My "genetic" nature, fortunately or unfortunately, has never allowed me to accept, even when I disagreed. If I thought it was right, I always expressed my doubts and proposed alternative solutions. Sometimes I was listened to, sometimes not, also for the reasons so well explained by @adamthedeveloper . However, I've learned that in any organization, no one is completely free to make decisions, even the "boss" has rules to which they must submit and comply, perhaps dictated by systems external to the organization, which ultimately impact everyone. Empathy and sincerity are the only winning strategies. If everyone knows why we must act a certain way and accepts it, even knowing that perhaps we could have done better, friction and retaliatory arguments like "You wanted it this way, now you keep it" will no longer exist. In my opinion, this is the only way to create a successful team with the right spirit of collaboration.
The "convenient confusion" framing is exactly right, and the incentive asymmetry you describe is the core of it. The person who Raises the architectural concern absorbs 100% of the social cost and gets 0% of the credit if the ship happens anyway.
The thing I'd add: the "ownership" framing also shifts responsibility without shifting authority. Engineers are told to "act like owners" but owners can say no to features, can delay shipping, can kill projects. When you have none of those levers, "ownership mindset" is just another way of saying "take responsibility for my decisions."
The interesting failure mode is when organizations actually do give engineers authority â and then the engineers freeze, because they're used to the implicit protection of "I'm just implementing what was asked." The ownership mindset narrative can actually prevent the psychological safety needed to exercise real ownership.
Do you think the solution is structural (rotating decision rights, written decision logs) or cultural (changing who gets promoted)?
I would say both ownership and accountability must go hand in hand. Great post!