This is great advice to become a pain in the ass that managers know they need to keep on a short leash.
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"
> This is great advice to become a pain in the ass that managers know they need to keep on a short leash.
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.
No. It's just CYA hedging.
If it's your job (per the "context"), then do it.
When you ask this question, it's either
A. escalating/DoA exception (not your authority)
B. Or giving yourself an out if something goes wrong for your existing DoA.
An easy example: you need 5 minutes of planned downtime (which is entirely within SLAs) to execute a major upgrade, but the system is also used by Sales for demos to major new clients. "We're going to take 5 minutes of downtime on Wednesday evening for an upgrade. Contact me ASAP if this is a problem for you." If you don't hear from the team, then it's OK to go.
You know the "no response" happens all the time.
OK. I'm your pointy haired boss Thursday morning.
> Hey, @waisbrot. You didn't mention anything in your note whether you got a response from the Sales team. I got a call from the VP Sales. He's pissed. You know they're at [big sales conference] and busy. The system outage impacted two Top 10 customer account demos. Why didn't you call me if you thought it was important or ask for an affirmative confirmation from the sales team before rolling out changes? Sorry, but I can't trust you. Bring all similar changes to me for approval from now on.
Of course there are routine things or items in your competency that allow for your boss to prioritize supervision elsewhere.
The prospect of going rogue, lighting a fuse, and then potentially setting off fireworks is the nuance being argued here by me and @slowcache.
Poor management will find a stick to beat you with whatever you do.
That's part of my point.
I'm assuming you don't disagree that this "lighting a fuse" approach on something you're unsure about without manager approval (and you think you need their permission -- which is said in the article) is way riskier for your corporate career. You're just taking asymmetric risk.
That's the main point.
Taking it at face value makes it good advice and interpreting it as CYA hedging makes it bad advice. My bet is the author intended the good advice they actually said rather than the bad faith guess to what they meant that makes it bad advice.
And there are plenty of things that are your job, but you would like the boss in the loop on without actually making it their job.
You say if it's your job then do it, and that's roughly what the advice given here is. The only place you're in disagreement is that you don't see any room for nuance when something is your job but worth notifying the boss about in advance.
> The only place you're in disagreement is that you don't see any room for nuance when something is your job but worth notifying the boss about in advance.
You read a different article.
FTA:
> ”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”
The parent's point is that lighting a fuse and saying you'll do something when the fuse runs out regardless of the boss' approval in a situation where you want to run something by them...is career suicide.
FTA:
> 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.
The qualifiers of "needing reassurance" and "asking for permission" combined with a notification on a fuse is way different framing than "notifying the boss about it in advance."
> The parent's point is that lighting a fuse and saying you'll do something when the fuse runs out regardless of the boss' approval in a situation where you want to run something by them...is career suicide.
It's not, if that action is a part of your job, something you COULD do just on your own but "you want a bit of reassurance or to let the boss know what you are up to".
It's not really a notification on a fuse, that's a framing you've put on it. It's giving sufficient advanced notice.
You left out:
> ask them for permission
I humbly submit you're still glossing over this. This framing is subtle. There's a difference between getting a peer review from your boss and asking your boss for permission when you think you might need it. Trust your gut.
Compare that to situations where you just want peer review/re-assurance. I agree with you on those situations to just pull the trigger.
The article is saying don't ask for permission! They're not really recommending anything different than what I see you saying throughout this thread.
They are saying it's common to ask permission in cases where you shouldn't, because it's actually your job and you only want a bit of reassurance / to give advanced notice.
Maybe you haven't run across people who do that, but that is what the author is responding to.
I agree directionally and appreciate your effort. I might just be misunderstanding and wrong, which forgive me if you feel like that's the case.
I just don't find the author's point consistent or nuanced about when to apply this (e.g., the size of the changes, the interface with your manager, the supervision/trust relationship).
Look at the closing sentence of the article.
"Offering a chance for feedback" when you're confident that "you don't need feedback" is weird. This is like some paradox. And doesn't match the phrasing of his initial example. This is bad advice that is way overdoing it.
> Again, pursue this approach [...] when you want to offer a chance for feedback, but you are confident enough in the course of action that you don’t need feedback.
Completely inverse to my lived experience.
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.
Some people have a much better instinct for when and how to ask for permission than others, including when "asking for no" is the right move. It's a dance with nuance and it's hard to capture it as advice in an article.
Huge disagree, as a manager. It depends on the thing, of course. If you're rushing into a giant re-architecture by Tuesday, that's dumb. If you have some change you want to make, go for it.
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.
Well a prerequisite is knowing what you’re doing. If you don’t, then yeah, don’t use this approach.
> This is great advice to become a pain in the ass that managers know they need to keep on a short leash.
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!
I've never seen anyone just "put something into prod" unless it was for a very small org.
Putting managers on babysitting duty is a workplace smell. A reckless dev is the least of your worries.
> I've never seen anyone just "put something into prod" unless it was for a very small org.
Missed the whole "move fast and break things" period?
No. Everyone else who survived was too busy building or fixing things.
I'm going to cause an expensive outage that will ruin the company, and our careers unless you say no to sugar in the coffee!!!!