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.

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.

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.

Neither approval, nor disapproval just straight up quagmire.

There’s no silver bullet to getting things done successfully in any large organisation of humans.

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.

There is no silver bullet. You have to treat each one in the way that works for them. Those who do it well, it's a talent.

Or have the compromising photos of the boss and copies of the bank statements so he's scared and backs you publically always and then just roll anyone who isn't effusively enthusiastic. That works too. Wouldn't recommend it.

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.

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).

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.

It’s a pattern for action, not for making decisions. I’ve been trained and my job is well understood by managers and decision makers in my organization. Many situations arise which are in scope of my job, but are new or appear different but are not.

I use this technique every week. I don’t need to provide deep reasons. If what I’m doing or why I’m doing it is not already apparent to managers, then they have this opportunity to check in.

If I already know what I’m working on is unusual and needs explanations, then this pattern isn’t appropriate, and a detailed email followed by heads up phone call is my go to.

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.

- 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.

> 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.

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.

Maybe they were sick for a couple days. Or were recently on vacation (and you haven't been notified yet). Or dealing with some higher priority emergency. Or just genuinely missed the email for some reason (accidentally sent to spam folder?)

Also even if it is true that the recipient thinks it is unimportant, it doesn't follow that the thing should be done. If somebody sends me an email asking me whether they should swallow bubblegum (or something on that level of trivial stupidity), I'd think they shouldn't -- but probably wouldn't bother to respond, or at least I wouldn't write a lengthy email explaining why not.

I'm not even joking, these days I often scroll through social media with a mild kind of twisted amusement watching people do and believe in stupid things -- while I can reply to each of them explaining why they're wrong, it's a well-known fallacy due to xkcd386. Coworkers are admittedly "closer" and thus I probably should warn them about potential hazards, but if it's a large org and I was just among a long list of cc-ed people... I might decide not to bother.

Though I’d tone down the swearing

"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.

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.

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.

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.

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?

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.

Every time you send a message like this it's a chance to convert someone to your cause. Don't waste it!

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.

My former manager used to do the same. He is a 40 year veteran, retiring in the next few months and for the past 6 years since I met him he wrote many emails telling people what he plans to do and just did it. It works for us very well.

And so you can say what you will, but if the CFO does not approve, your stuff is not happening.

"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?

"We're planning on defragging the thingamajig on March 1st unless objections are raised. Please send objections to [email protected]"

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.

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;

(edit: added formality)

I just love HN, no downvote can stop me! Ever!

If I don't hear back from you by lunchtime, I WILL eat your leftovers.

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.

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.

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.

What often happens if my manager objects is the urgency of "it's already happening" will result in him wanting to pause on it, if it's important to him.

Most of the time it's "ok, sounds good" where there's a clear trust between us. Or it might result in a "ok, sounds good -- just make sure so-and-so is aware too".

“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.

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.

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.

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.

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.

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.

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.

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.

The only other acceptable situation is for things that are low risk, high reward but can be important: like clean up, refactoring, whatever..

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.

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.

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.

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.

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.

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

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.

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.

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.

Your recommendation will be the approach that you will continue doing if there is no one disagreeing.

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.

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.

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.

Idk if it’s a men vs women thing or me specifically, but I just like to have a bias for action and make quick decisions with efficiency in communication. I think saying that briefly online in a comment probably makes sound like a bossy jerk but there’s a lot of nuance and skill to hone with this style of communication that is more difficult to elaborate on here, but the key is doing it without rubbing people the wrong way.

"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.

This is how popularity contests start lol. Managers that work this way are ineffective / pointless.

Pro tip: have a quick conversation with a manager and have them make a decision on a $noncriticaldetail before the announcement.

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.

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!

If you’re not fully confident and think an experiment is worth while, lead with that, and provide assurances there are mitigations in place or a decision is easy to back out of. That’s still doing the work.

If you want an easy decision, you need to do the work. Not expect others to get into all the detail you did. There’s still room for those decisions - they’re just not as quick/easy.

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."

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.

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.

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.)

When you’re in the hot seat, and someone asks “Who approved this?”, the truthful answer is that no one approved it.

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.

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.

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.

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.

Also, effective military decision making relies heavily on units on the ground being able to adapt and not needing to phone home to act.

Adding a date avoids that:

“I’ll be migrating the build system on Wednesday (26th); please let me know if you have any concerns.”

“I'm planning on migrating the build system on Wednesday (26th); please let me know if you have any concerns.”

The original wording makes it sound like it's already been settled, so nobody will bother responding. But by saying planning, you might get some feedback.

https://www.goodreads.com/book/show/16158601-turn-the-ship-a...

We’re informing the manager of our intention, but we already decided it was a good idea at the engineering level. We’re not really soliciting input, eg, whether that’s a good idea or not. However, there might be conflicts we’re not aware of, eg, “Wednesday is bad, since there’s a demo that day.”

Asking if there are concerns is soliciting that information — but being clear about what you’re asking.

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.

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.

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.

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.

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.

"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.

That being said... I've used this technique in larger collaborative projects: "If we don't come to agreement by , 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.

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.

Hire people who can self manage instead of hiring managers.

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.

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.

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.

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."

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.

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.

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.

Use it carefully, always give a reason, and set reasonable deadlines.

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?"

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.

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.

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.

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).

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.

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.

And then bother them until you get some reaction that they have read it.

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."

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?

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'.

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.

One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.

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".)

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?

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.

> 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.

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.

But if a manager is suspicious of their reports and generally doesn't want them taking initiative, they probably have bigger problems.

This still requires them to take notice of your query, within the deadline of your choice; and that may not be a given.

> .”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

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.

Thanks for confirming your impotence as a leader and your inability to delegate.

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.

Yes.

What you are suggesting is corrosive to trust though.

Frank discussion is good. Stating what you need and what you expect.

Game playing is no good and I would probably not fire you for it, I was being hyperbolic, but the point I am making is do not play games.

At work, or anywhere. Relationships thrive on honesty.

Any vote was a vote to deny, not approve because basically nobody bothered voting, so that was the way to make things happen.

Having to propose ideas a million times before any one of them saw the light of day.

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/

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.

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.

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.

In that case, remembering that "it's easier to get forgiveness than ask for permission" is a valuable tool to have in your repertoire.

(Also, not every decision that you need to communicate up to your manager is going to have a significant impact on your company. Sorry?)

"Small heads up: I plan to do [thing] at [time/day], unless I hear any objections before then.

[optional following paragraph(s), with link to the issue-tracking task, and/or inline rationale/detail]"

This is for things that probably don't need to be discussed, with people with whom you have a good working relationship, but for which a low-friction opportunity for correcting my mistaken assumption is good.

If you do it for something that you should've realized probably needs to be discussed, or that you should've realized probably needs an affirmative approval, then bypassing that was a mistake of yours, and damages trust.

If you do it when there's some kind of trust problem, then it's dripping with subtext. Like you might be looking to bypass them with weak paper trail, or maybe you're being passive-aggressive in the way you nominally keep them in the loop. Until you fix the trust problem, err on the side of avoiding new misunderstandings.

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.

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.

That's how people get fired.

... However I suffix it with "if that's okay" or "unless there is something more pressing".

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.