[HN Gopher] Ask for no, don't ask for yes (2022)
___________________________________________________________________
Ask for no, don't ask for yes (2022)
Author : mooreds
Score : 603 points
Date : 2025-02-22 23:55 UTC (23 hours ago)
(HTM) web link (www.mooreds.com)
(TXT) w3m dump (www.mooreds.com)
| gred wrote:
| Before reading the article, I parsed the title as "ask for
| permission only if you want a 'no', otherwise don't ask for
| permission and just do it".
| mglvsky wrote:
| I initially parsed as text variant of this video:
| https://youtu.be/-vZXgApsPCQ
| OutOfHere wrote:
| Why bother. If the company doesn't want to respond in the
| affirmative to a valuable idea that has been communicated
| clearly, let it torpedo itself and dig its grave. Whatever the
| answer, the outcome will be righteous. In the bigger scheme of
| things, it is better to evolve companies that answer optimally.
| There is no need to ever bend over backwards to save a company
| that is not your own.
| _boffin_ wrote:
| Unless you have a limited pool of opportunities. If so, educate
| and demonstrate value. Maybe even if pool isn't super limited.
| NegativeK wrote:
| Or, if your job is decent, don't let perfect be the enemy of
| good.
|
| (Also, not every decision that you need to communicate up to
| your manager is going to have a significant impact on your
| company. Sorry?)
| readthenotes1 wrote:
| You just may, at some point, find yourself in a situation where
| your goal is not to "evolve a company", but instead to work
| with the people at hand to get something done.
|
| In that case, remembering that "it's easier to get forgiveness
| than ask for permission" is a valuable tool to have in your
| repertoire.
| hackerknew wrote:
| Sometimes the ask is something that _you want_ to improve your
| own experience at the company. Let 's say the ask involves
| improving the quality of the code that you work on every day.
| You know your boss will not say "yes" because refactoring does
| not have an apparent value. But you are confident that if you
| can some time to work exclusively on some refactor, it will be
| a benefit not only to the company, but to your future self. I
| think the advice in the article is a solid way to go about
| asking for that.
| OutOfHere wrote:
| I would rather just work at a place where my hands weren't so
| tied. The actions you noted only come in the way of it.
| mazambazz wrote:
| I hardly think wanting to be more productive/efficient on your
| own behalf is "bending over backwards" to save a company.
|
| It could be a project with a deadline, and you want to knock
| some things out earlier so that there is less crunch time
| needed in a few weeks.
|
| Maybe you want to get some of your work done early so you can
| take it easier in near future where you anticipate yourself
| being preoccupied with other responsibilities.
|
| Or, hear me out. You feel secure in your job position, and
| simply take pride in your work. You will be there working
| anyways. I would rather get stuff done and feel productive at
| work than to have meaningless down time twiddling my thumbs,
| waiting for a response.
| OutOfHere wrote:
| I would rather just work at a place where my hands weren't so
| tied. The actions you noted only come in the way of it.
| brookst wrote:
| It's quite a luxury to work in a company where every
| interaction is perfectly empowered.
|
| Many of us have jobs that are on the whole very good, but
| where inter-departmentmental or inter-personal challenges
| come up from time to time. I'm definitely not one who's
| willing to quit in search of the elusive perfect company in
| that case.
| OutOfHere wrote:
| Startups often offer it, and it doesn't have to be so
| early stage that one has to work more hours either. Once
| a company gets older, it adds layers of damaging
| bureaucracy that comes in the way of innovation.
| zulban wrote:
| Your career isn't going to go very far if you have no
| strategies to overcome roadblocks and deadweight employees in a
| large org. "Let it torpedo itself" and then what? Find a new
| job any time you encounter stupid obstacles? That's a new job
| every 4 months.
| caseyy wrote:
| This is important wisdom.
| OutOfHere wrote:
| It usually takes 2-3 years of bad actions for a team to
| torpedo itself, so no, 4 months doesn't relate.
| xyzzy9563 wrote:
| It is an irrelevant optimization unless you own a lot of equity
| in the company.
| dsjoerg wrote:
| No, it also helps you progress in your career faster, boosting
| your own ability to get things done and hence your bargaining
| position.
| readthenotes1 wrote:
| This is a variation of a sales tactic which says to not give
| people the option to say no but instead only give them
| affirmative options.
|
| E.g., Not "When can we talk about this deeper?" But "Would
| Tuesday at 1 or Wednesday at 3 be better for a follow-up?"
| OutOfHere wrote:
| That's a high-pressure sales tactic, and the obvious answer to
| such a question is "Let me get back to you." If I am forced to
| schedule, I will schedule and then cancel.
| danielheath wrote:
| I don't do sales, but I use this all the time with friends -
| not to force a particular schedule, but to remove ambiguity
| about my availability. Folks are generally happy to suggest
| another time if they aren't available.
|
| If I put "let's catch up" out there with no information about
| when I am available, I'm giving the other person the mental
| labour of initiating the scheduling process.
| bee_rider wrote:
| I often say something along the lines of "I suggest X day,
| but I picked it completely at random just to get the ball
| rolling, so feel free to overrule."
|
| I do find that people tend to just sort of be overwhelmed
| by the options when scheduling stuff, so it is easier to
| just suggest something. But, I hope/think putting all my
| cards on the table and explicitly pointing out how
| arbitrary it is makes it seem less presumptuous.
| kianN wrote:
| I think it's less about putting pressure on a prospect as it
| is making the follow up meeting as easy as possible to
| schedule.
|
| To many people, me included, it does come off a bit abrasive,
| but it does reduce the number of decision to make into a yes
| or no.
| dec0dedab0de wrote:
| i just say no thank you, then get impolite if they don't drop
| it.
| aqueueaqueue wrote:
| For internal meetings here is the trick. Let your team edit
| your calendar! It is a high trust thing but it means you tell
| them you booked a meeting. They can decline or move it without
| the ping pong. Google Calendar works well here. (Google
| Calendar is so good now you may not need one of the many
| calendar SaaS offerings)
| tennisflyi wrote:
| Yes and it's very obvious
| aqueueaqueue wrote:
| I do this. I got too impatient asking for yes so I ask for no
| with deadline. Unless it's very risky, then you do a DACI or call
| a meeting etc.
|
| Try to make most of your operations 2 way doors with safety
| fallbacks.
|
| If you have good tests, you'll be able to get away with more.
| AdieuToLogic wrote:
| A related technique is: It is easier to ask for
| forgiveness than permission.
| glitchc wrote:
| I think this kind of approach, and I've used it in the past, only
| works in American companies or bosses who are familiar with the
| American way of business. It can backfire badly if the boss
| doesn't like it. During a performance review, the boss inevitably
| labels you as insubordinate and all of the evidence needed was
| handed to them on a platter. Sometimes asking for permission
| really is the best way, even in the US. Doubly so where resources
| are concerned.
| coffeemug wrote:
| I don't think I've ever worked for a boss who would have
| disliked this approach, and I had many (good and bad). Assuming
| of course what you're doing isn't idiotic. All of them were
| steeped in American culture, though.
| foobarian wrote:
| Honestly it's not my boss I worry about, more like a sibling
| team or service client that would have a stake in the
| decision but is known to drag their feet.
| ulfw wrote:
| This will not work in non-American companies where a boss might
| actually have a life and not work weekends, or heaven forbids
| have days/week(s) off.
| Jolter wrote:
| This would have worked fine in a Scandinavian company where
| managers are expected to delegate (some/most) technical
| responsibility. If boss was off, and couldn't react in time,
| their eventual reaction would depend entirely on the outcome.
| If you were successful, they'll appreciate that you didn't
| hold up the decision by asking them.
| chgs wrote:
| Works fine in my British company that is almost as old as
| America, it's called "out of office". If they aren't in the
| decisions are delegated to someone else.
| jampekka wrote:
| There are a lot of variety in non-American ways of doing
| business. E.g. in Scandinavian cultures management can be very
| hands-off, with workers largely assumed to make a lot of
| decisions independenly or among themselves.
| kaashif wrote:
| I wonder how those managers can delegate, or how anything gets
| done in society at large, if independent decision making is
| considered insubordinate.
|
| Also, effective military decision making relies heavily on
| units on the ground being able to adapt and not needing to
| phone home to act.
| jamiek88 wrote:
| Insubordination is for the military. The very idea that a grown
| person can be 'insubordinate' is ridiculous to me.
| locusofself wrote:
| I like this approach to communication, except the the "deadline"
| part. I'd prefer my reports just let me know if they are working
| on something which I may want to veto (because I may have more
| context as to why it's a waste of time or not a priority). Giving
| a "deadline" to your manager is strange, and almost like a weird,
| annoying threat. I also would like to think I would give people
| on my team enough autonomy to make their own decisions about
| something as trivial as a github action.
| afarviral wrote:
| I really like the idea of seeking a no (e.g. let me know if I
| shouldn't go ahead) but as soon as I add something like, "I
| will do this on this date, unless I hear otherwise", is a
| little aggressive feeling. It might be easy enough to simply
| mention the time the work will take place, but leave it
| unspoken that they could decide it's best to not proceed, "I
| should get it done around this time". Then again, it's been a
| goal of mine forever to be assertive. Cowing only takes you so
| far.
| post-it wrote:
| It's just a matter of phrasing. "Hi, I wanted to give you a
| heads up that XYZ needs doing, and I'll be doing it on
| Wednesday. Let me know if that doesn't work."
| wavemode wrote:
| Agreed, stating a deadline on something that is still just an
| idea, is weird and aggressive. Usually, a deadline is used to
| communicate "I have already decided I'm doing this, and
| received approval/consensus to do it, so now I'm informing you
| of the fact that I'm doing it."
| seansmccullough wrote:
| A lot of times you have to set a "deadline" when interacting
| with other teams/orgs, or they will just never get back to
| you.
| burnished wrote:
| I feel like a deadline on your own actions can also be a
| courtesy, in the sense that you are communicating the notice
| window as well as letting someone catching up on old emails
| gauge how relevant it now is
| zmgsabst wrote:
| If I don't tell you when I'm doing the work, how will I know if
| you've said no or not? If I think one day is enough time, so
| proceed, but you take two days to respond, now I've done
| something against your instructions.
|
| Adding a date avoids that:
|
| "I'll be migrating the build system on Wednesday (26th); please
| let me know if you have any concerns."
| imajoredinecon wrote:
| For what it's worth, this seems like the fatal flaw in the OP
| to me. If you need input on whether something is good to do,
| it's very easy for someone to reply "yes" or "sounds good,"
| so just ask for input. If you don't need input, just send an
| FYI instead of the weird asymmetric asking-for-objections-
| but-not-approval.
| wvenable wrote:
| I think the article does a disservice calling it a deadline. I
| had the same concerns at that point until I read the example
| and it clicked. It's really just the date you will do the
| thing, not really a deadline.
| mooreds wrote:
| Author here. It's a deadline for feedback, which is why I
| used the word. Other comments have called it an ultimatum.
|
| Both of those might be unnecessarily aggressive terms, but
| I'm not sure what another one-word term for "time something
| is going to get done unless you object" is.
| AlexSW wrote:
| Timeline, maybe.
| wvenable wrote:
| It's only a deadline for feedback because after you do it,
| obviously, feedback can no longer be provided. Timeframe
| might be less aggressive than deadline.
| tdiff wrote:
| Second that. It is actually a threat to a manager that if he
| does not put aside all his work and spend time to figure out
| what the suggestion is, an overly enthusiastic employee would
| make something she thinks is reasonable
| latexr wrote:
| Agreed. I would add the "unless I hear differently from you"
| falls in the same category. You're already sending an email
| describing what you're going to do, _of course_ your boss can
| object and you're open to it, that's exactly the point of
| informing them of your plans.
| ChrisMarshallNY wrote:
| I pretty much work this way.
|
| In my experience, they completely ignore what I'm doing
| ("yeah...whatevs"), then pitch a fit, when they see the result. I
| get a lot of whining about how come I don't have clairvoyance,
| and didn't interpret their ignoring me, as a "no."
|
| Annoying AF, but I still do it, as I can point to my statement of
| intent, and tell them that they had their chance. Often, I don't
| just ask for a "no." I also ask for specific input and feedback
| (which I also don't get). That gives me more ammo, when they get
| butthurt.
|
| The trick is to not do something that will _really_ upset them.
| That takes experience and empathy.
| emmelaich wrote:
| Or just do it, in testing. If it's reviewed by colleagues and
| looks good then ask for no.
| jrexilius wrote:
| This is a great way to frame it with the caveat that you've done
| a fair bit of homework to support your assertion. And the other
| thing I would add is context-aware time padding. The "deadline"
| should be adjusted to respect the bosses schedule AND the
| potential impact. i.e. if it could hit production, give them more
| time. If it can't easily be rolled back, give them more time,
| etc.
|
| But in general, if you are an adult, competent at your job,
| taking initiative, and have spent a bit of time thinking through
| the second and possibly third order effects, this is great.
| tdiff wrote:
| Probably most of so called software engineers consider
| themselves "competent". "Adults" are well aware of it, and
| apply to themselves, hence collect others opinion.
| ryandrake wrote:
| This is a critical skill in big companies where everyone is
| swamped and busy and things get lost. I do this all the time when
| I'm dealing with people who don't answer their email, or who tend
| to stall and delay approvals, or people who are just very busy.
| I'll Email and describe the problem and then say the magic phrase
| " _If I don't hear back from you in [N] days_ , I am going to do
| XYZ on [DAY N]." This way I'm not asking for approval and then
| helplessly waiting and pinging. I'm putting them on notice. XYZ
| is going to happen unless you get off your butt and stop me.
|
| Occasionally someone will come back weeks later, angry that I did
| XYZ without telling them, and I always have a paper trail showing
| that they were the ones who dropped the ball.
| sieabahlpark wrote:
| Works great until you break the law by accident if you're in a
| regulated industry. Sometimes it isn't as easy to do that.
| gukov wrote:
| Yeah, opting in by default like that can backfire when
| something gets done and the boss gets in trouble.
| kmoser wrote:
| These days I almost take it for granted that somebody isn't
| going to read my email, or won't read it thoroughly, or will
| read it but will fail to acknowledge it. One can use this to
| their advantage if they want to skirt a hard "no" but as you
| said, it may backfire.
|
| And the "boss" may have a point: relying on them to read,
| understand, and acknowledge your email, especially when it's
| important, is somewhat disingenuous. At the very least one has
| an obligation to confirm that the recipient actually read and
| understood what was sent, before taking the default action.
| tempestn wrote:
| One thing I've eventually managed to learn after failing at
| it many, many times is that in the vast majority of cases an
| email can only say one thing; if you try to ask multiple
| questions, or give multiple pieces of information, best case
| people will actually read one of them. Worst case it'll
| overwhelm and they'll ignore the whole thing.
|
| It's obviously different if you know the recipient and that
| they're able to handle more, but my default assumption is
| that people will read the first 1-3 sentences of an email, so
| I do my best to keep it to that, and if I have more to say
| I'll make a note to myself for once they reply.
| rvba wrote:
| All those complicated recruitment processes and companies
| cannot hire peoppe who know how to read...
| tempestn wrote:
| I think it's more a matter of people being overworked, so
| they just skim and answer the first thing that pops out.
| Or in some cases it may even be strategic, like in a
| negotiation, ignoring the parts that aren't beneficial to
| answer, while still responding.
| mlboss wrote:
| Its information overload. Everybody is super busy with
| 10,000 things to care of. My approach to repeat again and
| again. No hard feelings.
| pixl97 wrote:
| >n after failing at it many, many times is that in the vast
| majority of cases an email can only say one thing;
|
| This sounds much. Quite often I have to send people
| complicated lists of instructions to complete a task.
| Around half the time the remote party only does the first
| step.
|
| With this type of user I've started removing the top entry
| on the list and sending the first email.
|
| Around the 4th time I do this the user tends to catch on
| and completes the original list of instructions solving the
| problem at hand.
| hippari2 wrote:
| It's also good in that it force a record that someone is
| blocking / vetoing your progress.
| Buttons840 wrote:
| How do you actually word this?
|
| "We plan to defragment the thingamajig on March 1st. We're
| reaching out to those who might have an interest in case this
| might cause problems. Please let us know if you have concerns
| about the defragment. If we don't hear from you by March 1st,
| the thingamajig will be defragged."
|
| Something like this?
| kevinlou wrote:
| That seems like a much more diplomatic (and work-appropriate)
| way of framing it rather than just saying "hey, if I don't
| hear from you by x date i'm gonna do something"
| danmaz74 wrote:
| Hey, we need to do XYZ by April 1st. Let me know if you think
| that's a problem.
| dylan604 wrote:
| That's still ambiguous. There's no default action listed if
| no response is given. Listing the default action is your
| CYA that a non response is approval of the default
| fmbb wrote:
| Hey, we will do XYZ by April 1st. Let me know if you
| think that's a problem.
| ineedasername wrote:
| Well, the CYA in less healthy workplaces could be to
| leave things vague, if the person doesn't respond then do
| what you want when the time comes, and if anything goes
| wrong you can pin it on the person who ghosted you on a
| response. Bonus points if you send that first email and
| immediately seek an in person response. The other person
| will then figure an email response is unnecessary, thus
| guaranteeing your ability to play things however you
| want.
|
| After you've been on the wrong side of this dynamic you
| learn to always confirm things in writing. And to wait
| for the other person to go to the bathroom and unplug
| their desk phone so it looks like they're ignoring phone
| calls. At the same time, you use your personal vpn to try
| a few dozen failed logins to their email from 2 or 3
| other continents, then drop a hint to their boss alluding
| to a vague but urgent problem in their domain so the boss
| will want to get in touch with them immediately.
| genewitch wrote:
| I never would do what you suggest but I always had the
| network room door codes. Scotch tape and a thin plastic
| needle to rub it down to blend the colors on the copper
| part of the cable, then into the patch panel.
|
| I once playfully threatened a helpdesk senior manager: if
| you dont tell your team to shut to coffee pot off in the
| evenings I'm gunna start putting your LTO tapes into the
| carafe whenever Im forced to be here at 2AM cleaning a
| coffee pot so I don't take a box cutter to the entire
| patch panel.
| wes-k wrote:
| Our team currently relies on thingamajig's responsiveness and
| cannot tolerate a change in performance. We will setup a
| temporary replica of thingamajig. Can you please hold off
| until our thingamajig replica is stable. My team expects this
| to be done by March 8th.
|
| If I don't hear back from you by lunchtime, I WILL eat your
| leftovers.
| lelanthran wrote:
| That's a bit long.
|
| "We're planning on defragging the thingamajig on March 1st
| unless objections are raised. Please send objections to
| manager@my.division.com"
|
| Honestly, I've been doing this for decades with legal stuff:
| "Please confirm that my next pickup date for $CHILD is March
| 1st." often resulted in the other party just remaining silent
| and, when complaints against her not allowing the child out
| were made, she responded with "I never objected to that
| specific visit".
|
| Using "Unless objections are received, I will fetch $CHILD on
| March 1st" stopped her from using that excuse.
|
| It's a great way to deal with a difficult party who just
| wants to have as much creative misunderstandings as possible.
| endofreach wrote:
| Dude, are you elon musk? Who names a kid $CHILD? That's
| really fuck...ing awesome man! I wish my country wouldn't
| regulate how one can name his children...
| ineedasername wrote:
| In pearl or php, $variable is standard syntax.
|
| Also used in Bash, ruby, R when referencing elements of a
| list...
|
| I'm going to guess the GP didn't want to give their kid's
| name here and decided not to insert a generic Billy in
| its place. So this being a forum with lots of people
| experienced in $programming_language it's common to
| reference a generic placeholder in variable syntax.
|
| Personally, I think comments on HN should use properly
| type safe syntax, in which case $CHILD is replaced by:
| with Ada.Strings.Unbounded; use
| Ada.Strings.Unbounded; Name :
| Unbounded_String;
|
| Sure it's more verbose but, while there are tradeoffs,
| the comment is likely to avoid certain types of bugs when
| executed on readers' brains, a notoriously bug-prone
| hardware platform.
| endofreach wrote:
| I would have expected the downvotes for not being funny.
| But i would have never thought to be taken serious on
| this. But thank you for taking the time to explain.
| (Un-?)fortunately, i have been writing php for years. And
| my bash/zsh setup is slightly insane. But truly
| appreciate your sincere response (except the last
| sentence, which makes me think, the sincerity of your
| comment is equal to the on of my first comment...).
|
| I just love HN, no downvote can stop me! Ever!
| genewitch wrote:
| On desktop I vouch for stuff that's flagged like this.
| Can't on materialistic. Someone else should, though.
| lelanthran wrote:
| I vouched it. Dunno if it makes a difference unless
| others do it too.
| kmstout wrote:
| In Common Lisp, it's common for special variables' names
| to have "earmuffs" (i.e., asterisks at each end), so
| Luke's sister could be *princess-leia*.
|
| (edit: added formality)
| Imustaskforhelp wrote:
| I am also wondering this , how can we do this without being
| confrontational and also not being too wordy that you lose
| interest
| RHSman2 wrote:
| 'Going to do thing but wanted to get your input and any
| impacts you face before this date'
|
| Confrontation turns into a collaboration request.
| ncallaway wrote:
| "After looking at all the options I think XYZ is the best
| path forward. Our team will implement that on June 3rd. If
| anyone has any concerns about this approach, please reach
| out before then. Thanks!"
| ozim wrote:
| Everything can be considered confrontational if receiving
| party is unreasonable.
|
| Maybe receiving party should also take active part in
| understanding the communication so we don't put whole
| burden on sender.
|
| Because that's causing people to stop communicating which
| is the worst outcome.
|
| I already had couple team mates - that people didn't want
| to communicate with.
| kortilla wrote:
| This sounds a bit like a fantasy or the rules you're breaking
| are completely irrelevant.
|
| "I'm going to do X in 5 days if you don't respond" gives you
| absolutely no recourse if you do something that can result in
| reprimand.
|
| About the only place where this works is violating some
| internal design decisions that are irrelevant to the business.
| gr3ml1n wrote:
| Well, definitely don't phrase it exactly like that.
|
| Most decisions that would be made in the context where this
| is a useful technique are irrelevant and/or obvious. They
| should be made by someone lower down the chain, but
| organizational dysfunction requires tricks like this to get
| anything done.
| fendy3002 wrote:
| this is a silver bullet for something that needs to be done
| on a specific timeframe, otherwise it'll be bad. Since the
| "Boss x do not give approval for it" won't cut in as a
| reason, and boss x needs to know this before you're doing it.
|
| Of course criticality matters. The more critical it is, the
| more required for you to do a more personal message with said
| boss, like slack, dms, up to meeting face to face for
| approval.
| donalhunt wrote:
| This is an important insight. While the "bias towards
| action" approach works for smaller things, larger efforts
| may require change management protocols that capture
| explicit approvals. In regulated industries, you may have
| no choice but to capture approvals in some official manner
| (with ink sometimes).
| fendy3002 wrote:
| Of course condition and situation matters, as you've said
| in regulated industries. Be selfish, if you taking action
| will net you a worse outcome for you, better wait for
| approval.
| tabony wrote:
| Have been doing all my life and it has never backfired.
|
| It's not about breaking rules. It's that I already know what
| you want.
|
| If I buy you ice cream without asking you for the flavor,
| it's because I already know what you want because I pay
| attention to you.
|
| And it doesn't matter when I get it wrong because you
| appreciated the 500 other times I cared about you.
| pmg101 wrote:
| And decision fatigue is a real thing. Even if the ice cream
| flavour/engineering decision is maybe not perfectly
| optimal, there's some value in not having to make the
| decision myself
| contrast wrote:
| For sure - actions before words and all that.
|
| I think the context is different if you've shown you care
| twice a day for a year before screwing up. Most people
| interpret messages in light of their experience of you.
|
| If you don't have that track record, the words probably
| have a different flavor.
| kortilla wrote:
| Again, you're just doing it for things that aren't real
| rules.
|
| Try:
|
| - Intentionally violating a safety protocol in a hardware
| lab
|
| - taking company property for yourself
|
| - stealing from a vendor
|
| - sexually harassing your direct reports
|
| What this thread seems to be talking about is violating
| soft process norms.
| lelanthran wrote:
| > "I'm going to do X in 5 days if you don't respond" gives
| you absolutely no recourse if you do something that can
| result in reprimand.
|
| Surely you wouldn't use this for any action that could result
| in a reprimand?
|
| "Unless we receive objections, we're dropping the domain $X
| on March 1st and switching to the domain $Y instead" is _not_
| something you 'd do.
|
| OTOH, "Unless we receive objections from you, we're
| proceeding with (the current mocked-up UI|the last discussed
| tech-stack|deployment date|refactor|)" is not going to result
| in a reprimand.
| fmbb wrote:
| > About the only place where this works is violating some
| internal design decisions that are irrelevant to the
| business.
|
| I don't know why you feel the need to put "design" in there,
| but what you are describing seems like all rules governing
| how teams work together in any organization.
| praptak wrote:
| > the rules you're breaking are completely irrelevant.
|
| This isn't for breaking rules. And definitely not for
| breaking ones that say "explicit approval needed".
|
| Teamwork is complex and most of it is not covered by rules.
| If you are too biased towards asking vs just doing you get
| stuck.
| Cthulhu_ wrote:
| > if you do something that can result in reprimand.
|
| If it's not obvious if your actions can result in a
| reprimand, then you can't do the thing, simple as that.
| Either you have the ownership and can take responsibility, or
| your boss needs to step up.
| lrvick wrote:
| if it is possible to do anything that causes irreversible
| damage as a single engineer, then the fault for any damage is
| shared with whoever gave a single engineer that much power.
| swat535 wrote:
| This strategy should only be used for things that are
| "required". i.e _not_ doing it will cause you / your team /
| division more harm than attempting but failing or running
| into issues.
|
| The only other acceptable situation is for things that are
| low risk, high reward but can be important: like clean up,
| refactoring, whatever..
| exodust wrote:
| > _" Occasionally someone will come back weeks later, angry
| that I did XYZ without telling them..._"
|
| Something fishy about this comment. Apparently you "do this all
| the time", spelling out the magic phrase you use like a
| template. Are you sure this is your anecdote and not a
| projection of how you'd like to be operating at work, as per
| the main article?
|
| I'm trying to imagine the scene where you "show the paper
| trail" to achieve victory over your angry colleagues! That's
| when my bullshit detector is all up in the red zone.
| toxik wrote:
| Objection! You don't have Ace Attorney style court hearings
| at work where you can "show the paper trail" as evidence?
| dqv wrote:
| > I'm trying to imagine the scene where you "show the paper
| trail" to achieve victory over your angry colleagues! That's
| when my bullshit detector is all up in the red zone.
|
| The scene is someone sitting at a computer replying to a
| chiding email with a blurb about having previously sent a
| notice and said notice attached. It's not really that
| theatrical or hard to imagine.
| pastage wrote:
| One of the good things with process frameworks like ITIL is
| the way to keep track of who needs to know what. You
| basically are required to inform everyone if no one protest
| to you or some manager you can do whatever.
|
| It is alot better when you have someone who keeps track of
| these changes and says no if needed. As always a drama free
| work environment makes this easier.
| DeathArrow wrote:
| To whom it may concern,
|
| I am planning to leave the company in 20 business days unless I
| get a substantial raise.
| aiiizzz wrote:
| That's the implicit message in a 14 day notice
| motorest wrote:
| > "If I don't hear back from you in [N] days, I am going to do
| XYZ on [DAY N]." This way I'm not asking for approval and then
| helplessly waiting and pinging.
|
| I feel this tone is needlessly confrontational.
|
| You can very well state "II'm going to do XYZ because of
| [REASONS]. I'm going to do XYZ on [DAY N]. If anyone objects or
| has any reservations, please reach out to me."
|
| This approach also forces you to present a sound justification
| beforehand. You might not be aware, but there is always some
| likelihood what you're hoping to do is a mistake or you're
| missing out on some key constraints. When you reach out to
| anyone for feedback, you're hoping to get input to avoid
| mistakes.
|
| Also, this cargo cult behavior of citing Amazon's leadership
| principles as if they were a solution to problems is mind-
| boggling. For example, the reason why "bias for action" works
| at Amazon is survivorship bias: those who unilaterally take
| action which results in a failure will ultimately be
| scapegoated and fired. You won't see those guys posting blog
| entries on the virtues of bias for action.
| Xmd5a wrote:
| What about:
|
| - If I don't hear back from you in [N] days, I am not going
| to do XYZ, considering you don't deem it to be important.
|
| >this cargo cult behavior of citing Amazon's leadership
| principles
|
| Technical principles too: microservices. Firm size follow a
| Zipf distribution, thus in most case the decision was made it
| wasn't necessary and actually slowed down development.
| genewitch wrote:
| That's also passive-aggrsssive.
|
| "I have scheduled beginning $X on $Date. Documentation:...
| Please remit any feedback, please and thank you"
|
| And in the second example, unrelated to the first scenario:
| "I had planned to begin $X on $Date, but priorities have
| shifted and $X is being tabled for now. Documentation:...
| Please remote any feedback, please and thank you."
|
| Don't lie or whatever, or do. I don't, but none of this
| feels manipulative, you're just managing your time and
| workload.
|
| I may have missed some nuance.
| close04 wrote:
| No matter how it's formulated it looks exactly like the
| "opt-out" everyone on HN hates when it's done to them.
| It's effective so it's great when it works for you not
| against you.
| Eddy_Viscosity2 wrote:
| "opt-out" is just a tool and it can be used for both good
| and evil. Same as a for kitchen knife or a political
| appointment.
| buran77 wrote:
| The key, as always, is in successfully answering the
| question (good or evil) "for whom". Everyone thinks they
| are on the right side of the story.
| mewpmewp2 wrote:
| I think something like this to make sure they don't
| reject the idea:
|
| Planning to move forward with X on $Date. Docs are here,
| but if you object, I totally understand and will
| respectfully accept your decision... though I'd hate for
| this to be one of those decisions that comes back to
| haunt you.
| petesergeant wrote:
| > though I'd hate for this to be one of those decisions
| that comes back to haunt you
|
| I think this is guaranteed to set fire to any goodwill
| you have in your organisation
| motorest wrote:
| > - If I don't hear back from you in [N] days, I am not
| going to do XYZ, considering you don't deem it to be
| important.
|
| It's still needlessly confrontational. Why are you accusing
| someone of failing to understand the importance of
| something?
|
| Ask yourself this: do you need someone else's input? If you
| do not need it, you do not need to ask questions. If you
| feel the need to request input then in the very least you
| need to reach out to them in a way you value their input.
| tracker1 wrote:
| I consider it an extension of, "it's easier to ask for
| forgiveness than permission."
|
| This can work for or against you. If your goal is
| movement, then waiting at every step for a pedantic
| discussion with back and forth can kill entropy.
| motorest wrote:
| > I consider it an extension of, "it's easier to ask for
| forgiveness than permission."
|
| It's not. The key difference is that you're needlessly
| throwing blanket accusations towards other stakeholders.
| Is there a way to ask for forgiveness without throwing
| people under the bus?
| SpaceNoodled wrote:
| Maybe they should get their shit together and get the
| fuck out from under the bus.
| docmars wrote:
| It also kills motivation.
| stavros wrote:
| The problem is that, sometimes, "no input" looks very
| much like "I have input, but I haven't had the time to
| give it", so you end up waiting for nothing. This way you
| put the responsibility on the other person, to say
| "please don't do this yet, I'll explain soon why not"
| instead of just staying silent.
| schubart wrote:
| > If I don't hear back from you in [N] days, I am not going
| to do XYZ, considering you don't deem it to be important.
|
| Sounds even more confrontational.
| closewith wrote:
| Yeah, let's soften it up:
|
| > I'm going to proceed with XYZ in N days. If any of you
| fucking idiots have a problem with that, then scrawl it
| down in crayon and flush it down the jacks, which is
| where you'll end up if you dare question my decisions in
| future.
| mewpmewp2 wrote:
| That is much, much better, because you dropped the
| passive part from passive aggressive which people hate
| the most.
| Gud wrote:
| Additionally, the person is clearly signalling s/he is
| capable of getting shit done, without being afraid of
| making the occasional mistake.
|
| Though I'd tone down the swearing
| Xmd5a wrote:
| English is not my first language and I have communication
| issues. Having said that you may be onto something
| unironically. Respectful conversations often pack more
| tensions than downright disrespectful approaches, such as
| the way "cabron" can be used affectionately in a group of
| Spanish friends.
| thaumasiotes wrote:
| > English is not my first language
|
| In that case, the most likely mismatch between the
| language you provided and the responses you're getting is
| your use of the word "considering".
|
| If you're using it to describe the state of mind you'll
| be in after you fail to receive a reply, that was a
| mistake. It is a common connective in English that
| explains the reason for something:
|
| https://www.merriam-webster.com/dictionary/considering
|
| https://en.wiktionary.org/wiki/considering#Preposition
| (the preposition)
|
| What this means is that the sentence "I will go ahead
| with changing X, considering you don't think it's
| important" is equivalent to "I've noticed that you don't
| think X is important, so I'm not looking for your input
| on my proposed change".
|
| Learning a language well is a double-edged sword - if you
| look like you know what you're saying, and you make a
| mistake, people will assume you meant what you said. You
| can get away with really outrageous things if you come
| off as someone who can barely talk. But long after that
| point, there will still always be things that you never
| quite learned.
| skeeter2020 wrote:
| you're making a value judgement about people pre-emptively;
| this feels like a big mistake. I'd suggest you 1. explain
| what you want to do and why, 2. include relevant context,
| 3. how others can contribute and provide feedback. YOU may
| want to do something, but should be motivated by the US.
|
| Every time you send a message like this it's a chance to
| convert someone to your cause. Don't waste it!
| nuancebydefault wrote:
| 'considering you don't find it important' feels a bit too
| judgemental.
|
| In such case why not just ask: 'Since [reason x] I propose
| to do y. Please let me know if I should proceed.
|
| If they don't find it important enough to answer, you can
| just follow your own good judgement, backed with a
| papertrail.
|
| Still personally I find all above tactics a bit pedantic
| and not enough to the point... often I just communicate
| what I am doing and what my next intended steps are, in
| standups and followup meetings. Or in-between, I just send
| mails with stakeholders in copy. I will hear it soon enough
| if someone does not find it a good idea or has a better
| idea.
| mooreds wrote:
| > You can very well state "I'm going to do XYZ because of
| [REASONS]. I'm going to do XYZ on [DAY N]. If anyone objects
| or has any reservations, please reach out to me."
|
| Love this phrasing.
|
| As other comments have mentioned, you probably don't want to
| go into the full depths of reasons in the email. Rather have
| a high level summary with a link to a long form doc or RFC.
| And of course, the appropriate level of detail depends on how
| big and wide reaching the action is.
| harry8 wrote:
| IME you often get a response that seeks to turn it into s
| "conversation." Keeping everything super vague but
| something that can be pointed to on s paper trail as "I
| expressed reservations"
|
| Neither approval, nor disapproval just straight up
| quagmire.
|
| There's no silver bullet to getting things done
| successfully in any large organisation of humans.
| motorest wrote:
| > Neither approval, nor disapproval just straight up
| quagmire.
|
| That's ok. Setup a meeting with said stakeholder, clarify
| your position, ask for input, and in the end ask straight
| up if they have any objection. Save the meeting minute
| and send it to everyone who attended the meeting.
|
| They need to put up or shut up. Playing games does not
| work.
| baxuz wrote:
| I really dislike this approach as well. You basically light a
| fuse on a bomb and place the responsibility on others.
|
| Saying "I will do things my way unless someone manages to
| convince me to do otherwise this within x days" is toxic and
| places a ton of pressure on your coworkers.
| takinola wrote:
| I have the exact opposite reaction. Asking people for
| permission puts pressure on them to think about what you
| are doing (your responsibility) and make the decision about
| whether it is the right or wrong course of action. When I
| am asked to make a decision, I switch into a different
| thinking mode than when I am simply told the implications
| of a decision someone else is making as an FYI.
|
| The majority of decisions being made in a company are two-
| way doors - they can be reversed if needed without great
| consequence. Those decisions should be made quickly by
| whomever is close to the topic and everyone else should
| just be an inform (as a sanity check).
| SR2Z wrote:
| It really depends on the culture - it's pretty frequent,
| for example, that coworkers prefer the option that keeps
| their workload small and predictable even when that option
| is bad for the health of the business.
| docmars wrote:
| Tone is crucial to these conversations, yes.
|
| Permission-based cultures are a real drag for everyone
| though. If no one feels empowered to do anything without
| the approval of their boss, it defeats the purpose of
| bringing them on in the first place - for their expertise
| and capacity to contribute meaningfully in a reasonable
| time frame.
|
| There are appropriate times to slow down and sort out
| priorities, especially when other disparate teams are
| involved in the process (think Product vs. Engineering),
| but when there's a clear vision to execute on, it's almost
| always better to delegate to senior contributors to sort
| out the technical details and let their direct reports
| contribute to building on that vision.
|
| Some gatekeeping is okay, but having a singular PoC to vet
| all efforts leads to bean-counting, which frustrates
| talented / capable team members and robs contributors of
| their autonomy.
| skeeter2020 wrote:
| I like your balanced & nuanced approach; unfortuntaley
| it's unlikely to make a viral blog entry or tweet :(
| brokencode wrote:
| You have to use your best judgement. If you are confident
| in your approach, then I think it makes sense.
|
| You are then also owning this decision, and would have to
| face more consequences for it going awry. So I don't think
| it "places a ton of pressure on your coworkers" as you say.
| It relieves them of pressure since they don't have to
| decide and won't be held accountable.
|
| But if you think an action will be controversial or are
| unsure, then you need to make sure you are getting feedback
| and buy in from other stakeholders before proceeding.
|
| This is not only to make sure you are making the right
| decision, but also spreading accountability for this
| potentially bad decision to other members of the team. This
| accountability will put more pressure on your coworkers,
| but it is needed to help make the right decision.
| mv4 wrote:
| This is absolutely the way to go.
| thaumasiotes wrote:
| > For example, the reason why "bias for action" works at
| Amazon is survivorship bias: those who unilaterally take
| action which results in a failure will ultimately be
| scapegoated and fired.
|
| I think this is missing something. If everything works in
| exactly the way you just described, that can still be a
| strategy that Amazon intentionally implements and derives
| benefits from. We could rephrase it as "hire people who make
| good decisions, and then don't weigh them down".
|
| It doesn't look obvious to me that this is a _bad strategy_ ,
| or that the success we see people achieve by using it is
| illusionary. It's a strategy that many people/companies might
| find difficult to implement, but that's most strategies and
| essentially all good ones.
| whiplash451 wrote:
| Good point. But either way, you can't decide much in a bigco
| because most decisions are bounded to money and therefore the
| CFO.
|
| And so you can say what you will, but if the CFO does not
| approve, your stuff is not happening.
| rzzzt wrote:
| So, an ultimatum?
| whazor wrote:
| For teams where there is more document scrutiny and more
| involved team members, the key is to have two or three
| proposals and make a really strong case for your
| recommendation. And don't even start a big review before having
| a recommendation. If you are stuck, I would suggest talking one
| on one with team members to get further. Also, try to remove
| all information that is not needed for the decision process to
| the appendix (or just fully remove it).
|
| Your recommendation will be the approach that you will continue
| doing if there is no one disagreeing.
| Cthulhu_ wrote:
| I wish I could do this with merge requests but unfortunately
| we'll have to find some other way.
| magic_hamster wrote:
| This sounds like it could result in a chaotic culture where
| everyone does whatever they want unless actively stopped. For a
| busy tech lead or staff engineer this sounds like a total
| nightmare. If you're already asking someone about your plan,
| there's probably a reason for that and maybe there are
| limitations or dependencies you're not aware of.
| Salgat wrote:
| You generally reserve this tactic for people who act as
| blockers for everything, or for people who aren't critical to
| the project/action but still need to be notified.
| pixl97 wrote:
| The problem with busy tech whatevers is they will quite often
| not reply nor give a reasonable timeliness on which something
| can be done.
|
| This method forces them to lay out the timeline they can
| adhere to, and it works as a CYA as it shows you/your group
| is ready to act and is being blocked by others.
|
| It's up to upper management at that point to deconflict
| blockers.
| Xenoamorphous wrote:
| > This is a critical skill in big companies where everyone is
| swamped and busy and things get lost.
|
| Tangential but I work at a moderatly big company (no idea how
| many employees) but the tech department where I work is like 50
| people, so rather small; and that's what I consider "the
| company". I'm so busy I'm really close to burning out. And
| except for a couple of slackers, everyone is really busy too.
| So I'm not sure the size of the company correlates a lot with
| how busy people are.
| thevarmint wrote:
| In the military, it gets abbreviated "UNODIR" meaning "Unless
| otherwise directed".
| dctoedt wrote:
| Glad I searched for UNODIR before making this comment!
|
| And that'd be a useful code to include in the subject line of
| the email, e.g.:
|
| To: Boss
|
| From: Me
|
| Subj: UNODIR by [DATE], upgrading the production database
| maeil wrote:
| 403s here, guess they're geoblocking entire continents.
| JackFr wrote:
| This is a recipe for disaster the first time you break something.
| Getting a yes or a no indicates that your boss is aware of it.
|
| When you're in the hot seat, and someone asks "Who approved
| this?", the truthful answer is that no one approved it.
| ludston wrote:
| It really depends on the culture of your organisation and how
| effective management is. If there is nobody that can act like
| this at your org it shows that your leadership team suffers
| from failure to delegate.
| lelanthran wrote:
| > It really depends on the culture of your organisation and
| how effective management is. If there is nobody that can act
| like this at your org it shows that your leadership team
| suffers from failure to delegate.
|
| I think it's more than just that - upthread I posted that I
| used this technique for over a decade against a _difficult_
| party.
|
| This approach is, briefly, for CYA: It's for when you are in
| the following situation:
|
| _You have to do something and will be punished if you don
| 't, but a stakeholder is being difficult and/or hostile. They
| can delay you or outright sabotage you just by silence and/or
| bike-shedding._
| Imustaskforhelp wrote:
| Thanks. Made things a lot more clearer. It seemed that my
| natural response reading the article was to use such
| approach everytime no matter what & some people in the
| comments also said that they use this approach everytime.
| prh8 wrote:
| This is such a helpful way of viewing it. I have a
| principal at work that will comment on things to delay or
| slow down, and then never revisit after their comments are
| addressed.
| sdwr wrote:
| Yeah this only works for decisions you are basically allowed to
| make yourself.
| brookst wrote:
| The key insight is that the concept of "allowed" is flawed.
| Most of us are responsible for _outcomes_ , not actions.
|
| If you communicate well that an action is necessary for the
| outcome you are responsible for, that's enough. Obviously
| with notice, and with a genuine effort to get
| acknowledgement, but ultimately it's not about what you're
| allowed to do, it's about what you're expected to achieve.
|
| Now, if you're wrong, or capricious, or disingenuous... well
| all bets are off. But done responsibly this is a completely
| appropriate and defensible approach.
| rendaw wrote:
| I think this isn't for your superior, it's for lateral people
| who need to be involved some the work. Like person X in team Y
| is arguing against something.
|
| If your boss 1. tells you that something needs to be done, 2.
| refuses to approve any plans, then you just don't do it - in
| that case it's on them to direct the work in a way that it gets
| done.
| capkutay wrote:
| Owning things is breaking things (and fixing it).
| Cthulhu_ wrote:
| This is why (at least in software), nobody should be able to do
| anything on their own. The "I will do this" is fine, but it
| can't go to production without a review and of course automated
| testing and the like.
|
| Of course, then you create a bottleneck; if you write a MR but
| nobody reviews it in a timely fashion, nothing happens. But
| this is where you have to make agreements, and probably on a
| management level (= team lead, doesn't need to be heavier)
| about e.g. acknowledging and reviewing within a certain time
| period.
| Etheryte wrote:
| If your boss has to sign off on everything you do, that's not a
| boss, that's a micromanager and you're both doing it wrong.
| pixl97 wrote:
| Or it's a regulated industry
| finnigja wrote:
| Another take on this I like is "radiating intent". Broadcast what
| you want to do, when you plan to do it, and give stakeholders
| space to explicitly object, rather than explicitly chasing
| consensus / alignment / approval. Works in some scenarios, and
| generally requires baseline trust to have been earned.
|
| https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
| kashyapc wrote:
| Thanks, this _is_ an interesting take. The 4 reasons for
| "radiating intent" make sense. It works in moderately high-
| trust organisations.
|
| I also appreciate the author (Eliz Ayer) adding the below
| nuance:
|
| _" In all fairness, you might get less done by radiating
| intent. It does give obstructive or meddling folks a way into
| your thing. Also, advice like this is very situation- and
| organization-dependent and won't be appropriate all the time."_
| tempestn wrote:
| You can even do this kind of thing without going as far as
| stating that you'll take action unless overridden. It can be as
| simple as rephrasing a question from a "yes" to a "no", like
| "Does this work for you?" -> "Do you have any objections?" Even
| when the request is logically equivalent, people often find it
| easier to say "no" than "yes".
| allset_ wrote:
| You can also phrase it a little more gently.
|
| "I plan to start on this on X date, let me know if you have any
| concerns."
|
| And send a reminder so that you're giving them multiple chances
| to respond.
| reader9274 wrote:
| Ah yes, do what all these slimy companies do to get you to accept
| their new terms: "These terms take effect on this date unless you
| send us certified mail to opt out". Works every time
| 42772827 wrote:
| I call this "creating sane defaults." That is, rather than going
| to people and asking that they make decisions about every detail,
| pick a set of sane defaults that demonstrate your knowledge of
| the situation and just tell them you're going to run with it.
| This will build trust with people, and they'll be more likely to
| give you attention when you really need it -- because they'll
| know you're not wasting their time.
| wes-k wrote:
| I like the framing of "defaults" too. Gives space for
| suggestion and change.
| toomanyrichies wrote:
| I've used this technique ever since I read DHH's article about
| the book "Turn The Ship Around" [1]. The book's author, a Naval
| officer, had a policy of "Don't come to me for permission, come
| to me with intent." Hearing that phrase changed my professional
| life for the better in so many ways.
|
| Admittedly I haven't included a deadline nearly as often, but
| I've found a huge difference between saying "Can I do XYZ?" to my
| team lead (or even worse, "What should I do?"), vs. "Unless you
| object, I plan to do XYZ." The latter is frankly much more
| empowering as an employee, and it doesn't hurt that it sounds so
| much more senior. If I come with intent, I have to be prepared to
| defend that intent, which gives me more ownership in my role on a
| team.
|
| 1. https://signalvnoise.com/svn3/you-dont-have-my-permission/
| w10-1 wrote:
| It's fair to bias for action in this way.
|
| But offering a negative option to object could be more likely to
| induce mistake and undue reliance. (Remember: negative options
| are illegal per FTC.)
|
| But the real question is not the form of the ask but what
| information to include.
|
| You have to tell deciders what they need to know to decide. Don't
| queue them up for a research project or to go survey stakeholders
| on your behalf.
|
| Deciders need at least to know the range of consequences and
| likelihoods, and when and how there will be new information or
| opportunities for monitoring/managing. Usually that means you
| also propose their management plan.
|
| e.g., "I'm updating dependencies on Sunday. If it fails we'll
| roll-back, which is ~2 minutes of downtime (within this quarter's
| SLA). If it works, offshore will need to refresh their devenv,
| but we can reduce the security notice Monday. I'll preflight
| Saturday if you want to confirm with me Sunday beforehand, and
| I'll cc you on offshore/security go-ahead's."
| robertclaus wrote:
| I personally try to nudge even my junior team members towards
| this. I would never admonish them for taking this type of
| initiative working with me. I WOULD however have some difficult
| conversations if they thought this meant they could cut corners
| on communicating with stakeholders or execute on something
| without appropriate planning or review. There's a big difference
| between showing initiative and ignoring process that exists for
| good reason.
| _kb wrote:
| If you extrapolate this to larger / more bureaucratic
| organisations this is a change advisory board. You advise that
| change X will happen to system Y at time Z along with details of
| prep work, risks, and conditions for back-out. This gives a
| window for questions or concerns to be raised. In lieu of a nope,
| it then proceeds.
| 4dregress wrote:
| I believe the phrase is "Ask forgiveness not permission".
| 4gotunameagain wrote:
| In this case it is different, you are implicitly asking for
| permission on a timeout clause.
| seanwilson wrote:
| Part of this "I'm going to do this unless you let me know
| otherwise" trick is not phrasing it like a question to reduce
| communication overhead. That way the receiver doesn't have to
| write a reply and you don't get another email to read (and for
| anyone CCed).
|
| Saying that, I like emoji reaction features like on GitHub and
| Google Docs where you can just give a thumbs up to acknowledge
| you read and agreed to something. Seems really unpopular with
| some on HN for some reason, but emoji reactions are a useful
| lightweight way to communicate that you're on the same page,
| rather than making someone go through the motions of sending a
| "Okay, makes sense!" comment for every little thing. A bit like
| an upvote.
| Imustaskforhelp wrote:
| I totally agree with this comment.
|
| I think this is a sort of art in communication which I have
| just discovered. Though in emails I am not sure if there is an
| option just for thumbs up , but I do wish so.
|
| I am going to start to learn this art , like this is such a
| good way of working but it also has to be a little subtle , not
| rude and may or may not work , IDK just my two cents.
| DeathArrow wrote:
| >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.
|
| Great Pete, that means you've finished all the work from the
| current sprint and from the next and you've searched the backlog
| and didn't find anything to work on. Otherwise you wouldn't have
| wasted time on this.
|
| Since you have this free time, I have a task for you.
| megadata wrote:
| Hey, boss, I am going to hand in my notice now, which should
| solve the boss problem we've been having. Won't be here this on
| Monday unless I hear differently from you.
| bingemaker wrote:
| This is the famous pattern that we see in building interfaces.
| "Tell, don't ask".
| conductr wrote:
| I call this "Don't Ask, Tell" and it has so many uses inside but
| also outside work. It really is just a basic communication skill
| to hone. It leads to concise and decisive outcomes.
|
| I actually have this conversation a lot with my wife. She's more
| of an asker. A recent example from earlier this evening. We had
| arrangements set to meet a group for dinner. Her style is to send
| a text to the group, 8 people, saying "what time is everyone
| arriving?" Which is so open ended it would initiate a flurry of
| comms. But, we knew we would be there an hour early because of
| where/when we were dropping our kid off for the evening. So I
| just said TELL them when will be there and TELL them we'll be at
| the bar if anyone wants to have a drink beforehand. So much more
| straight forward, everyone showed up early and it was perfect
| with minimal comms required. Sure it was a lucky accident that
| everyone had care for their kids lined up to and was able to make
| it but the point is It took no time and actually didn't even
| require any response at all in the case someone was not
| monitoring their messages.
|
| It's somewhat related to the idea of "ask for forgiveness, not
| permission" which I'm a huge fan of in all kinds of ways. Sure it
| can be riskier but I'm a rebel at my core so it comes with the
| territory. But this has its place too, group collaborations like
| GitHub repos is probably not a good place to yolo big changes
| that effect other people.
| kjrfghslkdjfl wrote:
| > But, we knew we would be there an hour early because of
| where/when we were dropping our kid off for the evening. So I
| just said TELL them when will be there and TELL them we'll be
| at the bar if anyone wants to have a drink beforehand.
|
| I do this too. And it's not just better communication, it's
| better life. This way I'm not dependent on other people to have
| fun. I'm not waiting on coordination in order to start doing
| the thing I want. I'm doing the thing I want, and letting
| others know that they can join.
| vmurthy wrote:
| I like the general idea. I read the book "Start with no" a long
| time ago and the lessons stuck. The first principle here is that
| people have an innate need for autonomy and giving them the
| option to say no gives them peace of mind. Highly recommended.
|
| https://www.goodreads.com/book/show/689417
| worik wrote:
| I'd fire him
|
| > ."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."
|
| No thank you. I'm the boss. Don't push me around
| mooreds wrote:
| Author here.
|
| Ah, this is interesting feedback. I think that there's some
| nuance to this approach that I didn't capture in the post. You
| have to have some level of trust between yourself and your
| boss, which you've earned over time by being right and/or
| fixing mistakes you've made if you were wrong.
|
| The idea isn't to push the boss around; it's to make the boss'
| job easier by making default decisions for them, but letting
| them weigh in.
| xerox13ster wrote:
| Yes you're the boss and no one can take that away from you. You
| must have worked very hard to get there if you're blocking your
| team from taking initiative and making independent
| contributions to the organization. Based on this attitude I'd
| assume you suffer from an extreme inability to delegate and are
| going to be stuck in whatever direct supervisor position you're
| in for the remainder of your career.
|
| If I showed initiative like this and your response was "I'm the
| boss. Don't push me around." I'd quit on the spot and I
| sincerely hope you only have lackeys too dumb to understand how
| detrimental this egoist attitude to your own authority is to
| productivity and creating organizational value.
| kstenerud wrote:
| Yup, this is the meatspace equivalent of "opt out" vs "opt in",
| and works for pretty much the same reasons.
| weitzj wrote:
| I think this person has also interesting content regarding No and
| Yes
|
| https://youtube.com/shorts/DjuC8xauWWk?si=VkGFbgbqyzKqPjLD
| weitzj wrote:
| Another interesting one
| https://youtube.com/shorts/tWthV06ZIDo?si=JdKPvykIuv5q7RGY
| thornycrackers wrote:
| Chris Voss, former FBI Hostage Negotiator and author of Never
| Split The Difference. Has lots of great tips.
| hamandcheese wrote:
| I like the perspective, but then the concrete example given
| (adding a new GitHub action) is such a trivial 2-way door that I
| am worried for the author. There are better companies out there!
| notpushkin wrote:
| With great power comes great responsibility. People _will_ think
| you went behind their backs, even though on paper you did
| everything correctly. If you abuse this trick, you'll quickly
| lose people's trust.
|
| Use it carefully, always give a reason, and set reasonable
| deadlines.
| Feathercrown wrote:
| This is an excellent tool for the toolbox. My company has work
| from home days but the managers technically have to approve
| schedule changes/exceptions. Since they almost always approve it,
| we usually just say "I'll be working from home Tuesday if that's
| okay" and unless they object, you're good.
| Pamar wrote:
| In my current job ... I write design documents that must be
| approved (in writing) by Key Users in two different companies.
|
| Followed by test cases signature and then by user acceptance test
| documents.
|
| This style could never work for me: "I'll push it to production
| on Day X, exactly as described here - unless you object" is not
| really applicable for me.
| Imustaskforhelp wrote:
| Yes I really like such approach. But it feels a little
| confrontational.
|
| Maybe I haven't read all the comments but I would love to if
| somebody could give me certain examples where it doesn't sound
| confrontational and maybe as confrontational as asking for a yes.
|
| I really like the approach but I think I would be looked as if
| rude , like look at that guy , he thinks he can do whatever he
| wants if I say nothing , Let me use politics to put him down
| unnecessarily.
|
| Again , I really like this approach and am just asking for better
| / more examples. Something which I can apply practically.
| lionkor wrote:
| "Hi, I want to switch our logging solution in our client from
| Console.WriteLine to NLog, because it's been bothering our tech
| support that we don't have log levels for errors. I've made an
| issue here: ... . I have some time end of next week due to XYZ,
| so unless you object, I'll do that on Friday and put it up for
| review."
|
| And then bother them until you get some reaction that they have
| read it.
| jsmeaton wrote:
| I often give similar advice to colleagues that ask me for
| pointers on getting their recommendations approved.
|
| "Make it as easy as possible for them to say yes"
|
| Don't dump 14 paragraphs in front of someone expecting them to
| get onto the same level that you've been after many hours of
| studying a problem. If you're confident in your approach (and you
| should be, if you want an easy yes!), then be succinct, briefly
| describe the problem and why your solution is correct. Optionally
| link to a document that has more information if a reader wants to
| go deeper. Make sure you've already gained "approval" from your
| other team mates or product owners.
|
| "We're going to solve X by doing Y. Team are all onboard.
| Proposal document is at [link] if you want the detail. Going to
| begin on Tuesday unless there's any more feedback we need to
| address."
|
| Managers etc don't have time to get into the detail of every
| little thing, and appreciate when you've done the work, including
| gaining support from the wider team, so if they need to approve,
| they can just approve.
| whoknowsidont wrote:
| >Managers etc don't have time to get into the detail of every
| little thing, and appreciate when you've done the work,
| including gaining support from the wider team, so if they need
| to approve, they can just approve.
|
| This is how popularity contests start lol. Managers that work
| this way are ineffective / pointless.
| nlitened wrote:
| A manager that organized their team so that each team member
| makes concrete thought-out proposals with all details
| covered, so that it's their only job left is to give
| approvals and do nothing else? I'd say that's a brilliant
| manager
| andrei_says_ wrote:
| I agree and that's how I often get things greenlit.
|
| Pro tip: have a quick conversation with a manager and have
| them make a decision on a $noncriticaldetail before the
| announcement.
| silvestrov wrote:
| And for some managers you really need to make it obvious
| what $noncriticaldetail is so they don't change something
| important: https://museumjorn.dk/wp-
| content/uploads/2021/05/48s-1.jpg
| hnthrow90348765 wrote:
| Maybe I should be a developer that just tries to get
| everything pushed off to someone else, or just reject the
| work for reasons so that's my only job.
| nlitened wrote:
| You can! The job is called VP of Engineering
| dheera wrote:
| > If you're confident in your approach
|
| That's the thing. I'm not a narcissist, and my confidence in my
| approaches is driven by the objective statistics and
| uncertainties of the approach and NOT my ego.
|
| If I think there's a 90% chance something will fail but there's
| a good reason to try it for the 10% scenario in which it
| succeeds, that's exactly my confidence and I'm not going to
| coat it in some bullshit pitch about how I'm confident it is
| going to work. If there's an 80% chance it is going to work, I
| will not lie about the 20%. And if I say 98%, it's actually
| pretty damn near that. The 2% accounts for my typical sick days
| per year.
|
| Your job as a manager is to deal with these statistics and
| hedge the risks. Hedge funds do it with money, you do it with
| people and resources.
|
| Unfortunately it's the people who say it's going to work 100%
| and actually fail 50% of the time that get the love of typical
| corporate managers.
| jldugger wrote:
| While I doubt most people have sufficient "objective
| statistics" to truly remove ego from the equation, there's a
| middleground here.
|
| Write up your detailed proposal as typical, but before you
| click send, put an "executive summary" at the top, with maybe
| two sentences. One to describe the problem and one to
| describe the solution. You can put all the detail you want in
| the rest of the document. But the onus remains on you the
| engineer to make a recommendation, not just list options. If
| you genuinely believe yourself to be a probabilities it
| should be easy!
| darkest_ruby wrote:
| This is basically asking for forgiveness instead of asking for
| permission
| puapuapuq wrote:
| How to phrase it if you need code review from other team and
| deploy code into their code base?
| bob1029 wrote:
| > Again, pursue this approach for problems you feel are in the
| scope of your role
|
| If something is actually in scope of your role, you shouldn't be
| bothering your manager about it. Wait for them to come to you and
| then provide an update about your progress or new ideas/concerns.
| Every time you send an unsolicited email to your boss it costs
| time and money. Doesn't matter how it's worded. It's gonna
| consume some energy.
| A_No_Name_Mouse wrote:
| This works great from a leadership perspective as well. If anyone
| is interested, I can recommend the book Turn the Ship Around! by
| David Marquet about this very subject.
| lrvick wrote:
| I have done this my whole career some companies see it as being
| over eager, or even insubordinate. Do it anyway, because the
| companies worth working for will support you self assigning work
| that needs done, and hire other people capable of doing the same.
|
| Hire people who can self manage instead of hiring managers.
| dweekly wrote:
| I've found "I presented this project to partners in Risk, Cyber,
| Compliance, and Legal and received no objection." is quite
| effective.
|
| People in a large company want to know you're working with the
| right set of people and that nobody is going to be surprised. At
| some point if a large enough set of people have seen a project
| and are aware without objection, folks don't want to try to "push
| back the tide" and a thing will achieve momentum of its own.
|
| "Gosh if Wendy and Bob and Jill are all okay with this...ehh
| sure."
| zb wrote:
| I'm reminded of an infamous occasion when this technique was
| used: https://en.m.wikipedia.org/wiki/Cable_243#Preparation
| epolanski wrote:
| I like to appeal to person interest more.
|
| I'm gonna do X, that should remove some of the arguments in our
| *insert meeting/discussion" (removes problems from that
| stakeholder) and speed up this so we're never the blocker when
| other teams are involved (puts your stakeholder like a pm ahead
| of his peers and in the corporate rat race).
|
| The more you know the stakeholder (a colleague, a manager, an
| owner) the more you understand his goals and his pains the more
| surgical you can be.
|
| E.g.
|
| "I am going to rewrite this in typescript because typed languages
| are nicer to use" => "I am going to rewrite this in typescript as
| it will provide a better experience and make hiring easier"
| (might be important if youre looking for extensive Magento
| experience in the middle of countryside Germany to drop it and
| PHP).
|
| "I will only provide feedback under the form on mobile because
| that's the only screen where they won't see it without scrolling"
|
| => "I will only provide feedback under the form on mobile so we
| don't confuse users on desktop and lose sales".
|
| Again, it is very important to understand what drives the
| particular stakeholder and try to sell general ideas under the
| light of how it benefits him.
|
| Your website lacks accessibility? Don't appeal to ethics of
| disabled people. Explain it's your managers head on the line if
| someone complains due to the EU accessibility act and there's
| legal responsibilities.
| keyle wrote:
| 27 years professionally and I naturally do this.
|
| ... However I suffix it with "if that's okay" or "unless there is
| something more pressing".
| jonplackett wrote:
| I think all this arguing over the phrasing is kinda missing the
| point.
|
| It comes down to whether you expect this person really will have
| objections.
|
| If you are going to do something you believe they won't approve
| of, even the most polite wording will not stop it being a dick
| move and confrontational.
|
| Likewise if it's something you're pretty sure they won't object
| to, you can probably be quite abrupt and it'll be fine.
| mcv wrote:
| This is good advice that I've seen applied effectively many
| times, with one big difference: don't ask your boss, ask your
| team. Especially when it involves Github actions that will effect
| the way the team works. Chances are it impacts developers more
| than your boss, and they're likely to know more about it.
| Depending on circumstances also include your boss of course, or
| maybe they're already part of the team. But it can't hurt to cast
| a wider net asking for objections.
| grahamm wrote:
| To me this is a key change in a direct reports development.
|
| When they first start they need to be told what tasks to do; then
| they develop to asking for permission to do tasks that find or
| know need to be done; and finally they are telling me they are
| doing a task so I know we are going in the right direction. These
| changes give much better autonomy within the team and I am know
| longer the blocker to progress. It also means I can get on and do
| more interesting tasks myself while working with the junior
| members of the team.
| mooreds wrote:
| I want to work for you!
| EtCepeyd wrote:
| > finally they are telling me they are doing a task so I know
| we are going in the right direction
|
| Yes, but. :)
|
| Assume a high-profile open source project where your direct
| report is a maintainer. The higher-profile the project is, the
| more political it becomes, of course. Your report will not need
| your (= the manager's) input on technical decisions; instead,
| they will inform you (in the optimal case) of where things have
| been heading. However, if that maintainer also participates in
| community governance -- which is quite likely --, they won't be
| able to avoid decisions that are more political than technical
| in nature. And whatever they decide _there_ may easily reflect
| on their employer or client, one way or another. That kind of
| stuff is something that they should consult you on, regardless
| of their technical seniority.
| geomcentral wrote:
| How does this work in a Scrum context?
|
| I want to get stuff done but I need to raise a ticket, have the
| priority agreed, and get it planned into a sprint. Then after
| these layers of 'asking for yes' I am allowed to work on
| something without scrutiny. Let's say I wasn't subject to this
| process, my pull request would still need someone to approve it.
|
| Is there a way I can adopt the approach of 'asking for no' with
| these constraints? Or does it only apply in high autonomy
| workplaces?
| mooreds wrote:
| I don't see how this works in the context of scrum as I've seen
| it done, except in the weak case of you getting to raise the
| ticket of whatever topic you'd like.
|
| I guess you could ask for no around specific implementation
| details too? So if you are working on ticket XYZ that could be
| solved in N ways, you could pick one that might be a bit out of
| the norm (but still solves the problem) and 'ask for no'.
| mozzieman wrote:
| It is all about backing up this question with confidence before
| asking it. Not about trust you earn over time but trust each time
| you ask it.
|
| I require teams to do their own security reviews, that includes
| requirement gathering before shipping anything. If i get a
| "Anyone have any objections / concerns question"
|
| I usually know directly if they just bullshitting and only done
| the minimal viable to get something out and want to be able to
| say "but i asked" or if they done their due dilligence.If the
| person only says short what they will do and just broadcast it.
| "Throws it over the fence". Imho is just bullshit. The people
| that are good have backed it up with explanations, proper
| knowledge about different areas what they are doing, presenting
| their thoughts and make sure stakeholders are informed in person
| or by good documentation and overall just come across like they
| know stuff. Then it is okey / good to ask like this to find out
| if you missed anything.
| wodenokoto wrote:
| In student council in high school we implemented a similar
| approach.
|
| Any vote was a vote to deny, not approve because basically nobody
| bothered voting, so that was the way to make things happen.
| demarq wrote:
| I wish I'd found this article earlier. My biggest frustration at
| work was literally this.
|
| Having to propose ideas a million times before any one of them
| saw the light of day.
| OhMeadhbh wrote:
| While I appreciate the OP's position, I suggest the preference of
| forgiveness over permission is highly contextual. If you're
| working on a social networking web site, certainly, move fast and
| break things. But if you're working on a nuclear launch control
| system, you probably want to model a "don't launch until
| authorized" control system instead of a "launch unless told not
| to" system.
|
| That being said... I've used this technique in larger
| collaborative projects: "If we don't come to agreement by <date>,
| I'm going with the default choice that may not be optimal for
| everyone. (i.e.- don't waste time suggesting your alternatives.)"
| In my younger days I thought you needed to have a horrible
| default, but that only works a few times before your
| collaborators think they're just better off without you.
| mooreds wrote:
| I'm the author. Thanks for your feedback.
|
| Lots of nuance here! I agree that different kinds of orgs and
| projects and decision scopes all play a role. As does trust
| between you and your manager, knowledge of what requires
| feedback, what doesn't, and what is risky enough to require an
| affirmative response.
|
| But having a bias towards action has been really important for
| my career. That doesn't mean I haven't flamed out at times, but
| when I found the right environment with the right level of
| trust, this technique was super helpful to me.
| ysavir wrote:
| This seems like the sort of communication style that would
| immediately have me label someone as a liability.
|
| It presents the communication as if it's saving someone time. In
| practice, it's a communication style that tells the manager that
| they need to always keep on top of whatever the employee is doing
| or else that employee might be taking unwanted action(s). The
| article treats it as a notification, but even with the best
| intentions and the best understandings, notifications have a
| habit of getting lost in a noise of signals. A lack of response
| does not indicate consent. It could, but it could also very well
| indicate that the message hasn't been received.
|
| It might be fine if the problem was something the employee and
| manager previously talked about and this is simply moving forward
| with a solution, but it's a terrible way to _introduce_ a problem
| that the other party hasn 't even considered. It's a selfish
| take, and the antithesis of teamwork.
|
| Feels like the sort of thing someone might have seen one of the
| mythical 10x, Rockstar engineers do. The sort of engineer that's
| always on top of their game, churning out feature after feature,
| knows what to do, and has enough respect from and mutual
| understanding with management that they're given the leeway to
| self-manage. And the someone, seeing this, decided that the same
| can apply to themselves, without understanding why that rockstar
| engineer gets that treatment, or how to go about earning it for
| themselves in the firstplace.
| bentt wrote:
| As with everything it's about the relationship. If you do this
| 3 times in a row and receive "stop, please don't" then
| obviously you're off in some regard. If you do it 3 times in a
| row and get praise, then keep going.
|
| The liability person is someone that is told no, then figures
| out how to do most of it anyway. Then looks for a yes. Then the
| next task same thing. No responsiveness to feedback.
|
| So, it's really not about the method described as much as the
| working relationship. It seems like a fine thing to try in a
| high-trust environment where people are busy.
| mooreds wrote:
| That's a great point. There needs to be trust between the
| person doing this and the boss. That trust is earned.
|
| You also need to pick the right scope of problems--not too
| big. If you are one month into a new job and use this
| technique, but the problem you are trying to solve is deep
| rooted and you don't understand it, you'll burn effort and
| credibility.
|
| It also makes sense to respond to feedback from your manager,
| as you suggest above. Some managers may hate this (see other
| comments, including one that would fire anyone using this
| technique). In fact, you could even explicitly ask how a
| manager wants to weigh in on decisions that you feel are in
| your purview but that they might have feedback on. (Drawing
| out a manager's readme, as it were.)
| pigbearpig wrote:
| Agree, if someone did this to me and I didn't know them, I
| would find it presumptuous and annoying. If I had worked with
| them and had trust and I knew they were doing it out of respect
| for my time, then that's a different story.
| mft_ wrote:
| A technique I use regularly (mostly for decision-making in
| meetings) and successfully is the five finger approach.
|
| Essentially, people have to hold up a number of fingers showing
| how strongly they feel about the decision that is proposed. If
| they strongly oppose it they can do, but they have to offer an
| alternate proposal at the same time.
|
| What works very well about this is that it moves people away from
| "do I support this, and is this the perfect proposal?" to "do I
| hate this enough to block it?"
|
| As such, I think it's similar to the article's approach - the
| default decision (in the absence of strong disagreement) becomes
| a yes.
| s3p wrote:
| This is such an interesting strategy, thanks for sharing. We
| typically get bogged down in meetings by people dropping
| constant nuances and edge cases and overly complicating things
| when a new proposal is presented. I might see if we can adopt a
| similar approach.
| EtCepeyd wrote:
| Nice; instead of burdening your boss with a decision, now you're
| burdening them with a _ultimatum_ , with a deadline. I guess, as
| a manager, I wouldn't love anything more than a report saddling
| me with an arbitrary deadline, one I'd have to schedule along
| with the rest.
|
| One of my managers used to tell me this, instead: ask for
| forgiveness, not permission. That one seems way saner to me.
| mooreds wrote:
| > One of my managers used to tell me this, instead: ask for
| forgiveness, not permission. That one seems way saner to me.
|
| So you are suggesting making the change without consultation
| and then waiting for it to be discovered?
|
| I guess that makes sense for certain kinds of situations, but
| the ones I can imagine don't sound very pleasant. Maybe I'm
| missing something. What is an example of a situation where
| you'd take this approach?
| imajoredinecon wrote:
| It's really about (a) the wording (b) the level of risk.
|
| For something that isn't risky, I trust my reports to make
| reasonable decisions and wouldn't benefit from the "I'm going
| to do this tomorrow unless you say no" approach. Instead,
| they can just tell me they're doing it (or let me know after
| the fact, or add/FYI me on the code review, or not even
| mention it, depending on what it is).
|
| For a decision that _is_ more important /higher risk, they
| should get affirmative agreement rather than just hoping that
| I see the ultimatum and silently approve.
|
| That's why I'm with the GP that the ultimatum-with-deadline
| doesn't seem like the best choice in any situation.
| mooreds wrote:
| Thanks for the feedback. I guess I'd put the 'ultimatum-
| with-deadline' in between the two risk profiles you outline
| --something just on the edge of risk.
|
| > Just hoping that I see the ultimatum and silently
| approve.
|
| I never would have thought of this as an ultimatum--to me
| it's more like a 'default decision' that makes my manager's
| life easier while still looping them in and giving them
| control should they choose to exercise it.
|
| But now I can definitely see how it might be seen as one,
| depending on the type of decision and the relationship
| between employee and manager. I should probably update the
| post to say that you need a degree of trust and alignment
| for this technique to work; you shouldn't roll this out on
| the first day.
| EtCepeyd wrote:
| The advice refers to situations where you, the report, are
| both able and (well-informedly) willing to take full
| responsibility. "Ability" here means that, if your decision
| backfires, you can revert it, and/or contain the damage
| otherwise. Otherwise, you may be willing to take
| responsibility, but are unable to. In other words, this piece
| of advice applies to things that are ultimately under your
| control.
|
| The background is that, even when something is (mostly) in
| your control, you may be tempted to ask for permission, in
| advance, just to distribute the responsibility to others
| (shift the blame, cover your ass). That delays things, and
| usually the manager will sense that they got burdened with
| the request-for-permission somewhat needlessly. In those
| cases, it's better to take initiative, and be accountable
| later on, because the latter is in your power, in the end.
|
| (Of course, if you and your manager have dedicated time slots
| anyway, then bringing the topic up is prudent, as it will not
| require them to scramble for otherwise unallocated time.)
|
| Conversely, if containing the potential damage is indeed
| _not_ in your power, then you shouldn 't go ahead without
| explicit permission. For things where you simply _can 't_
| bear responsibility, a timeout from the approver is not a
| default "yes", but a default "no". If you can't bear
| responsibility, then you need explicit signoff from someone
| higher up that, should shit hit the fan, _they_ will bear
| responsibility on your behalf -- and so a timeout is
| meaningless (it doesn 't give you what you responsibly need).
|
| Whenever you can afford to interpret a timeout whichever way
| you want, then you don't need to ask the question in the
| first place (--> don't ask for permission, just
| revert/contain the damage, if needed). Otherwise (--> the
| potential damage is beyond you), you need an _explicit_ "yes"
| (which is the _only_ case when you 're off the hook).
|
| The problem with your suggestion is that it assumes that you,
| as a report, are in a position to _set deadlines_ for your
| superior(s); in other words, to allocate their time and
| priorities. Usually the exact opposite is true (by contract):
| it 's your manager who sets your priorities. You _can_
| consider their (repeated?) failure to respond timely a true
| failure, but that doesn 't give you the right to do whatever
| you want; it would be in bad faith / a form of vigilantism.
| Your option is to leave that manager.
| untrust wrote:
| Agreed. I actually think consensus amongst the team is more
| important than your boss. If a group of reports under some
| manager come to consensus on something they need to do, the
| opinion of the boss is kind of moot. I tend to operate using a
| bias for action, and the boss is clued in with information
| about our decision making, but asking for permission (or
| forgiveness) really just opens the door for micromanagement.
| This assumes basic trust has been established between the team
| and the manager, but in the end the technical decisions should
| be chosen by those on the team who are technical (read: not
| management).
|
| Management (in my opinion at least) is primarily for resource
| allocation, career growth, and shielding the team from endless
| meetings and acting as a point of contact for upper management
| EtCepeyd wrote:
| > Management (in my opinion at least) is primarily for
| resource allocation, career growth, and shielding the team
| from endless meetings and acting as a point of contact for
| upper management
|
| Agreed! (And we can also call "resource allocation" "setting
| priorities".)
| causal wrote:
| An ultimatum implies the manager has no choice- but they can
| just as easily say "hold up, don't do that until I get a chance
| to look at it".
|
| But if a manager is suspicious of their reports and generally
| doesn't want them taking initiative, they probably have bigger
| problems.
| EtCepeyd wrote:
| > but they can just as easily say "hold up, don't do that
| until I get a chance to look at it"
|
| This still requires them to _take notice_ of your query,
| within the deadline of your choice; and that may not be a
| given.
| causal wrote:
| Right, that's called communication. Communication also
| enables you to ask your manager if this approach is okay to
| begin with, or ask that they acknowledge when you give them
| such heads up notifications. There's a lot of ways to make
| this work well.
| lokimedes wrote:
| NATO runs on this principle, "silent procedure".
| mooreds wrote:
| TIL: https://simple.wikipedia.org/wiki/Silence_procedure
| EtCepeyd wrote:
| Yes, but NATO members are not bound by contracts that
| classify them into superiors and subordinates. Whereas at
| work, you'll have some form of contract in which you _agree_
| to taking -- and usually: soliciting -- direction from your
| superior or client. Silence procedure works between equals,
| where each party is required, from the get-go, to (a)
| announce their intent to the shared message bus, (b)
| diligently listen to the shared message bus, and take action
| whenever necessary. The communication pattern between manager
| and report is totally different; the parties are not equals
| there.
| rererereferred wrote:
| The same is for requests/procedures in my government. Unless
| they respond within a predetermined time, the request is
| considered granted.
| k__ wrote:
| Seems like a reasonable middle ground between asking for
| permission and asking for forgiveness.
| tofflos wrote:
| Just do the thing. I'll have your back if it goes wrong.
| Sincerely Your non-toxic boss.
| jcutrell wrote:
| I'll add to the conversation another interesting technique from
| Chris Voss, which is to use no-oriented questions.
|
| People like to say no. (I'm not sure what this cognitive bias is,
| but anecdotally I agree.)
|
| So, if you can frame your requests in a way that "no is
| permission", it will often get a red light a bit easier.
|
| Example: replace "Is this a good idea?" with "is this a bad
| idea?"
|
| Now, of course "not a bad idea" is not the same thing as "good
| idea", but it's a lot more likely. Even reading that, I imagine
| most people would respond more intuitively, because it helps us
| avoid a commitment we don't necessarily want to adopt.
| docmars wrote:
| This is roughly how I've operated for the past 5 years in my
| career and it's only benefited everyone. Sure, I get pushback
| sometimes when a stakeholder feels strongly about taking a
| different approach or maybe waiting to find out whether certain
| features or scope are needed, but most of the time, like this
| blog mentions, people will develop respect for you that you can
| make confident decisions in the work you're doing, and that
| you've spent the right time understanding how to solve a certain
| problem without needing to disrupt their flow.
| deadbabe wrote:
| This is such bad advice all around. Everyone already knows the
| "ask for forgiveness, not permission" trick.
|
| The problem is if you don't get forgiven, you are absolutely
| fucked and the other side is perfectly justified in raking you
| over the coals. If you had permission, you'd be excused.
|
| Imagine your boss reads your email and knows what you want to do
| is a bad idea. So they ignore you. You do it. It fucks shit up,
| now your boss has your ass. You can't assume they saw your
| message, they never said yes or no.
|
| Don't do this. Get a yes.
| righthand wrote:
| Humanoid task runners are learning to log the scheduling of their
| tasks! Panic?
| skeeter2020 wrote:
| Lots of good conversation here; I'd argue this isn't a better
| approach, but different and in many circumstances one of the few
| ways to get anything done. I put it in the "ask for forgiveness"
| bucket, but done responsibly. Sometimes it's actually the nicest
| thing to do, because busy people who don't care enough to step up
| get to avoid (yet another) distraction. It helps calibrate how
| much someone really cares, as it takes some energy to provide
| input vs. just objecting out of principle or as a default
| position.
| kmstout wrote:
| Years of listening to C-SPAN have taught me the value of
| declaring what I intend to do and then proceeding "without
| objection." [1]
|
| (I'm still waiting to "yield myself such time as I may consume.")
|
| ---
|
| [1] https://en.wikipedia.org/wiki/Unanimous_consent
| toss1 wrote:
| The version I've found most useful is "UOD", as in "Unless
| Otherwise Directed..."
|
| As in "Unless Otherwise Directed, I'll be updating the Foo
| project next week to include the Bar modules..." or "UOD, I'll
| call Alice tomorrow to update her on Bob's plans..."
|
| Works well, concise, shows you are on it and proactive, and works
| both as a proper status/planning update and/or an opportunity for
| the person to weigh in to change course... (and documents the
| chain of events).
| cynicalsecurity wrote:
| > Now, let's take the alternative approach."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."
|
| That's how people get fired.
| dctoedt wrote:
| As pointed out by @thevarmint, UNODIR is a longstanding military
| abbreviation for "unless otherwise directed."
|
| And that'd be a useful code to include in the subject line of the
| email as an attention-getter and summary, e.g.:
|
| =========
|
| To: Boss
|
| From: Me
|
| Subj: UNODIR 2/23/25: Upgrading production database
|
| =======
|
| And the body of the email could provide more background.
| 1vuio0pswjnm7 wrote:
| https://www.wsj.com/politics/policy/federal-agencies-push-ba...
|
| "Musk over the weekend, in a post on X, said that "all federal
| employees will shortly receive an email requesting to understand
| what they got done last week Failure to respond willbe taken as a
| resignation."
|
| The email, which asked "What did you do last week?" in the
| subject line, told federal workers to respond by 11:59 p.m.
| Monday with a list of "5 bullets of what you accomplished last
| week.""
|
| Perhaps this might also be sent to Silicon Valley employees given
| the numerous instances where we have seen them bragging online
| about how little work they actually do whilst still getting paid.
___________________________________________________________________
(page generated 2025-02-23 23:00 UTC)