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.
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.
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.
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.
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.
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.
I’ve worked at several startups and I’m not at all sure the typical employee is more empowered. Yes, large companies have bureaucracy, but startups often have micromanaging founders who haven’t learned stuff like delegation.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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."
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."
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
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.”
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.
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.
“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.
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.
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.
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.
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
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.
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.
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.
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.
Probably most of so called software engineers consider themselves "competent". "Adults" are well aware of it, and apply to themselves, hence collect others opinion.
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.
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.
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.
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.
>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.
"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."
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"
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
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.
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.
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.
"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.
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.
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...).
“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!”
I often use: "I'm open to input as we move forward on this" to suggest it's already happening, with a clear and kind invitation for feedback.
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".
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.
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.
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).
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.
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
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.
> “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.
> 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.
> 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.
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.
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..
> "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.
> 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.
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.
> “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.
- 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 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.
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.
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.
> - 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.
> 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?
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.
> 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.
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.
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:
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.
The issue with `considering you don't deem it to be important` is that the statement presumes a particular attitude for the recipient which may or may not be true.
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.
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!
'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.
> 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.
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.
> 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.
Objection? No. Concerns yes, as have been detailed at length. No good trying to ram it through without doing the work. We can't manage the project for you etc. etc.
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.
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.
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).
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.
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.
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.
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.
> 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.
It depends on the context. My boss is so busy that he rarely answers to my emails, he is available to talk very rarely (once every few months) so I write him what I plan to do then I do it. He never answered "no". Even for vacations, I just let him know when I go and for how long, if it is up to a week. I am responsible of my own work and he is just around.
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.
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.
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.
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.
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.
> 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.
Yes, in big companies you can get away with a lot of weird shit, but it takes two to tango. If your XYZ depends on someone such an email is a surefire way to get them popping their corns when they will put your request for help into backlog with an estimated slot for a timebox in... 2027.
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.
> 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.
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.
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.
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.
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.
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.
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.
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."
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".
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
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.
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.
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."
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.
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.
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.
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.
284 comments
[ 3.8 ms ] story [ 59.9 ms ] thread(Also, not every decision that you need to communicate up to your manager is going to have a significant impact on your company. Sorry?)
In that case, remembering that "it's easier to get forgiveness than ask for permission" is a valuable tool to have in your repertoire.
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.
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?"
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.
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.
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.”
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.
“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.
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.
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.
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.
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.
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.
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.
"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?
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.
If I don't hear back from you by lunchtime, I WILL eat your leftovers.
"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.
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:
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.I just love HN, no downvote can stop me! Ever!
Today it's anything anti-Musk or pro-Musk it seems.
(edit: added formality)
Confrontation turns into a collaboration request.
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".
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.
“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.
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.
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.
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.
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.
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.
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.
The only other acceptable situation is for things that are low risk, high reward but can be important: like clean up, refactoring, whatever..
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.
I am planning to leave the company in 20 business days unless I get a substantial raise.
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.
- 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 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.
I think this is guaranteed to set fire to any goodwill you have in your organisation
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?
Sounds even more confrontational.
> 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.
Though I’d tone down the swearing
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.
Every time you send a message like this it's a chance to convert someone to your cause. Don't waste it!
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.
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.
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.
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.
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.
And so you can say what you will, but if the CFO does not approve, your stuff is not happening.
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.
Your recommendation will be the approach that you will continue doing if there is no one disagreeing.
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.
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.
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
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 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.
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.
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
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."
"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.
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/
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."
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.