DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
ā” Community Insights
Discussion Sentiment
64% Positive
Analyzed from 1976 words in the discussion.
Trending Topics
#need#things#ask#manager#something#unless#don#responsibility#doing#yes
Discussion (36 Comments)Read Original on HackerNews
if you tell somebody you're going to to do something, you're not asking them to take responsibility. you're telling them that you're taking responsibility for whatever you're going to do. If you ask somebody's permission, you're asking them to take some portion of responsibility for what you're doing.
which is the same risk that the sibling comment is warning about - if you're trying to do this for things that you aren't ultimately responsible for, you're goign to piss people off. only take responsibility for things that are actually within your area of responsibility.
This is a point that tends to kill introverted/insecure people I think. They assume that asking for permission is making things easier for people, but there's a limit where you're not allowing others to delegate responsibility onto you. Your job is for others to not have to think about the things you take care of.
Personally, I tend to assume accountability for things I lead, but as a manager, of course, I am also responsible and accountable for my team; including both things I signed off on and things I didn't (because I entrusted that independence to them.) It's an interesting line to walk.
In proper function, ownership is an essential identity of any government.
Unsurprisingly no state which ever implemented communism ever took that part seriously.
We think we like more choices, but it's generally proven that having less makes it easier to decide.
One path is: "fuck sake, I need to review all of this and make an informed decision". The other is: "If I have time I'll check it otherwise who cares".
There's another benefit in the change of tone: you're preserving their authority, while at the same time making things easier.
There's a big difference between "I'm going to put this into prod on tuesday unless you tell me otherwise" vs "I'm going to put a prototype together for review on Tuesday unless you tell me this is a waste of time"
Not really. The advice is prefixed with this context.
> When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to
Basically it's saying if it's your job to make this decision, but it's something where the boss needs to know (or you need them to know because you need a small amount of reassurance), then asking for "yes" fails to communicate your understanding in that regard.
Asking for "yes" says it's the boss's job to make this decision - but we're talking about decisions where you believe it's your job make it.
If abused.
I've used this a few times for things that are in my remit, or very close to, that need doing or there will may well be more problems down the line for me or the local team more generally. If there isn't a particular problem with the intended action, I'm removing the need for someone else to make a proper positive decision. It is particularly useful when things are getting delayed by too many cooks trying to season the broth, or when it is going to require out-of-hours work and I want to push things towards a timeframe convenient for me.
Of course there are some large caveats:
* You need to be trusted, i.e. have a record of doing things both right and well, being appropriately careful with back-out plans and such, and if there have ever been mistakes on your part you need to have owned and rectified them quickly. It isn't going to fly if you are new or otherwise unknown, etc.
* You have to be complete but concise in the description of what you are doing, including what your āoh, fuckā roll-back plans are.
* You have to include everyone relevant in the announcement of your planned action, and send the notification at a time when they are likely to read it before you do the do. If there is someone key missing and others notice they will stop you, and if they don't notice and something goes wrong you have lost your trusted status for quite some time for being deceptive.
* Be prepared to be told no. Check just before the appointed time, and delay yourself a little and check again in case of a last minute āshit, no, don't do thatā if someone spots a problem with the plan a little late.
* You need to trust the others around you to speak up if there is a problem, though getting negative decision can be a lot easier than getting a positive one so this isn't the most important part of this point. The most important part is you need to trust them to speak up and not enjoy watching you make a mess so they can hang you out later :)
Though having been taken over by a larger company this year, I don't think I'll ever do this again because the layers of bullshit are just too vast for it to be a safe tactic. Younger me might still have taken the chance, but I have a healthier level of not giving a shit these days - instead of āI'm doing X at time Y unless you say noā because āI really should do X at time Y otherwise problems A, B & C will ariseā and if I don't get the go-ahead and problems do arise I'm the one enjoying schadenfreudeā° and demanding overtime rates if they want me to work extra to deal with issues due to not doing the thing.
--------
[0] I know this is a slightly unhealthy attitude, and this is one of the reasons that I'm increasingly thinking that I need a significant career changeĀ¹.
[1] the main two reasons being not being happy working remoteĀ², it isn't good for my mental health, and not caring to engage with A-bleedin'-I, two massive things that increasingly mark me as not fitting in with the dev industry.
[2] I know I'm fairly unusual here and it seems to work better for many (most?) people, no need to take this as an insult to those of you gleefully working on remote teams or wanting to and jealous of those that can!
My default is to trust engineers based on my experience with and expectations for them. If they want inputāanything from a deep review to a gut checkāI'm happy to help. If you're looking for a gut check, this is a fine way to do it. It communicates your level of confidence, which is an important data point for me.
If someone is adding a GH action, do we need a prototype? Maybe! But also maybe not. Bias towards action. Not YOLOing, not hacked together crap, not vibe code merged without review. But I've found that great engineers are often more hamstrung by permission checks than the issues they're meant to prevent.
I have always used this method and my managers love me because they know I get important shit done without much supervision or needing dozens of planning meetings. It doesnāt even feel like there is any leash at all.
Of course the company i work at isnāt extremely disfunctional and a growing startup, so once we move into enterprise territory it might change the culture and itās more about saving your ass and less about doing actual work.
Putting managers on babysitting duty is a workplace smell. A reckless dev is the least of your worries.
"Heads-up: I plan to delete the old scratch volume at Tue 14:00 ET, unless anyone objects before then. (It only contains the old Debian APT cache, and 974 copies of the same YouTube video.)"
> When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, itās common to reach out and ask them for permission. Donāt. Donāt ask for a yes. Instead, offer a chance to say no, but with a deadline.
If something is not in scope for your responsibility, obviously you must ask for permission.
If something is in scope for your responsibility, then just do the thing.
If it's in some weird edge case where you "feel" it is "in scope for your position" but you "want a bit of reassurance", then pick a lane. Either do the thing or ask for permission. Probably default to asking for permission unless a knowledgeable colleague tells you it's your call.
But setting some kind of deadline for your manager to opt-out is extremely disrespectful. If I ever had a report try to pull a stunt like that, it would be the first thing we'd talk about in our next 1-1.
Because if you have a manager who usually responds promptly, then you can ask for permission and get a quick reply. "Asking for no" is not making it more convenient for your manager, it comes across as trying to usurp their authority. "Hey, I'm going to tell HR you gave approval for a raise unless I hear from you by noon." That's... just not how anything works.
And if you have a manager who often misses e-mails or takes forever to respond, then it comes across as trying to take advantage of that to do stuff they wouldn't approve, in a sneaky way.
This is a bad look in every possible situation. Do not do this.
Like, if you're a journalist telling a source you'll print the story unless you get a correction by a deadline, OK fine. If you're looping in a peer as a courtesy (NOT a manager), then OK. But with your manager? That's crazy.
> And if you have a manager who often misses e-mails or takes forever to respond, then it comes across as trying to take advantage of that to do stuff they wouldn't approve, in a sneaky way.
I strongly disagree with that. Such a person is not a good manager. Their job is to be on top of things and keep their reports unblocked. If their reports are stuck waiting on them, or they claim ignorance of things they've been told about but neglected, they're not doing their job and have to be routed around.
I have a code change that is so vital to the survival of our company that:
1. It requires your immediate review.
2. If you fail to respond by Monday, I will push it to production.
---
Can anyone suggest what is wrong here?
It's different from "Ask forgiveness; not permission," because it still loops in the manager.
The only problem, is that if you ask Legal, they say "no," pretty much by default.
It will be new to someone.
https://xkcd.com/1053/
But even amongst those for whom it isnāt, sometimes a reminder of things you know is useful and may come at just the right time.
If there is a decision that you need to make donāt ask me for input, do the thing that you think makes sense and then write down what you did and why.
If itās the wrong thing Iāll update the docs to make it clear for next time.
Without this I would always wake up in the morning to an inbox full of questions and no work done, rather than an inbox full of finished tasks and maybe a couple of corrections.
With LLMs if I ask for a code analysis and plan to fix something they tend to put a list of questions at the end about which they want confirmation.
Then I have to waste time saying yes or no or coming up with the solution. If I tell them to instead just make assumptions and record them all at the end then I only need to correct 1 or 2 assumptions if required.
2025 https://news.ycombinator.com/item?id=43144611
Answer: no, because you need the other person to actually do something.
These kinds of things work when youāre already in a relationship.