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.
> “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'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.
"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 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.
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.
> - 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?
"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."
"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.
Dude, are you elon musk? Who names a kid $CHILD? That's really fuck...ing awesome man! I wish my country wouldn't regulate how one can name his children...
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...).
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.
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.
“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!”
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"
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.
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.
> 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.
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 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.
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.
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.
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.
> "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.
I call this “Don’t Ask, Tell” and it has so many uses inside but also outside work. It really is just a basic communication skill to hone. It leads to concise and decisive outcomes.
I actually have this conversation a lot with my wife. She’s more of an asker. A recent example from earlier this evening. We had arrangements set to meet a group for dinner. Her style is to send a text to the group, 8 people, saying “what time is everyone arriving?” Which is so open ended it would initiate a flurry of comms. But, we knew we would be there an hour early because of where/when we were dropping our kid off for the evening. So I just said TELL them when will be there and TELL them we’ll be at the bar if anyone wants to have a drink beforehand. So much more straight forward, everyone showed up early and it was perfect with minimal comms required. Sure it was a lucky accident that everyone had care for their kids lined up to and was able to make it but the point is It took no time and actually didn’t even require any response at all in the case someone was not monitoring their messages.
It’s somewhat related to the idea of “ask for forgiveness, not permission” which I’m a huge fan of in all kinds of ways. Sure it can be riskier but I’m a rebel at my core so it comes with the territory. But this has its place too, group collaborations like GitHub repos is probably not a good place to yolo big changes that effect other people.
> But, we knew we would be there an hour early because of where/when we were dropping our kid off for the evening. So I just said TELL them when will be there and TELL them we’ll be at the bar if anyone wants to have a drink beforehand.
I do this too. And it's not just better communication, it's better life. This way I'm not dependent on other people to have fun. I'm not waiting on coordination in order to start doing the thing I want. I'm doing the thing I want, and letting others know that they can join.
I often give similar advice to colleagues that ask me for pointers on getting their recommendations approved.
"Make it as easy as possible for them to say yes"
Don't dump 14 paragraphs in front of someone expecting them to get onto the same level that you've been after many hours of studying a problem. If you're confident in your approach (and you should be, if you want an easy yes!), then be succinct, briefly describe the problem and why your solution is correct. Optionally link to a document that has more information if a reader wants to go deeper. Make sure you've already gained "approval" from your other team mates or product owners.
"We're going to solve X by doing Y. Team are all onboard. Proposal document is at [link] if you want the detail. Going to begin on Tuesday unless there's any more feedback we need to address."
Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.
>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.
A manager that organized their team so that each team member makes concrete thought-out proposals with all details covered, so that it's their only job left is to give approvals and do nothing else? I'd say that's a brilliant manager
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.
While I doubt most people have sufficient "objective statistics" to truly remove ego from the equation, there's a middleground here.
Write up your detailed proposal as typical, but before you click send, put an "executive summary" at the top, with maybe two sentences. One to describe the problem and one to describe the solution. You can put all the detail you want in the rest of the document. But the onus remains on you the engineer to make a recommendation, not just list options. If you genuinely believe yourself to be a probabilities it should be easy!
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."
This seems like the sort of communication style that would immediately have me label someone as a liability.
It presents the communication as if it's saving someone time. In practice, it's a communication style that tells the manager that they need to always keep on top of whatever the employee is doing or else that employee might be taking unwanted action(s). The article treats it as a notification, but even with the best intentions and the best understandings, notifications have a habit of getting lost in a noise of signals. A lack of response does not indicate consent. It could, but it could also very well indicate that the message hasn't been received.
It might be fine if the problem was something the employee and manager previously talked about and this is simply moving forward with a solution, but it's a terrible way to introduce a problem that the other party hasn't even considered. It's a selfish take, and the antithesis of teamwork.
Feels like the sort of thing someone might have seen one of the mythical 10x, Rockstar engineers do. The sort of engineer that's always on top of their game, churning out feature after feature, knows what to do, and has enough respect from and mutual understanding with management that they're given the leeway to self-manage. And the someone, seeing this, decided that the same can apply to themselves, without understanding why that rockstar engineer gets that treatment, or how to go about earning it for themselves in the firstplace.
As with everything it's about the relationship. If you do this 3 times in a row and receive "stop, please don't" then obviously you're off in some regard. If you do it 3 times in a row and get praise, then keep going.
The liability person is someone that is told no, then figures out how to do most of it anyway. Then looks for a yes. Then the next task same thing. No responsiveness to feedback.
So, it's really not about the method described as much as the working relationship. It seems like a fine thing to try in a high-trust environment where people are busy.
That's a great point. There needs to be trust between the person doing this and the boss. That trust is earned.
You also need to pick the right scope of problems--not too big. If you are one month into a new job and use this technique, but the problem you are trying to solve is deep rooted and you don't understand it, you'll burn effort and credibility.
It also makes sense to respond to feedback from your manager, as you suggest above. Some managers may hate this (see other comments, including one that would fire anyone using this technique). In fact, you could even explicitly ask how a manager wants to weigh in on decisions that you feel are in your purview but that they might have feedback on. (Drawing out a manager's readme, as it were.)
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.
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.
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.
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.
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.
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 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.
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 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.
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."
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.
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.
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."
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.
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
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
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.
Nice; instead of burdening your boss with a decision, now you're burdening them with a ultimatum, with a deadline. I guess, as a manager, I wouldn't love anything more than a report saddling me with an arbitrary deadline, one I'd have to schedule along with the rest.
One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
Agreed. I actually think consensus amongst the team is more important than your boss. If a group of reports under some manager come to consensus on something they need to do, the opinion of the boss is kind of moot. I tend to operate using a bias for action, and the boss is clued in with information about our decision making, but asking for permission (or forgiveness) really just opens the door for micromanagement. This assumes basic trust has been established between the team and the manager, but in the end the technical decisions should be chosen by those on the team who are technical (read: not management).
Management (in my opinion at least) is primarily for resource allocation, career growth, and shielding the team from endless meetings and acting as a point of contact for upper management
> 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".)
> One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
So you are suggesting making the change without consultation and then waiting for it to be discovered?
I guess that makes sense for certain kinds of situations, but the ones I can imagine don't sound very pleasant. Maybe I'm missing something. What is an example of a situation where you'd take this approach?
It’s really about (a) the wording (b) the level of risk.
For something that isn’t risky, I trust my reports to make reasonable decisions and wouldn’t benefit from the “I’m going to do this tomorrow unless you say no” approach. Instead, they can just tell me they’re doing it (or let me know after the fact, or add/FYI me on the code review, or not even mention it, depending on what it is).
For a decision that is more important/higher risk, they should get affirmative agreement rather than just hoping that I see the ultimatum and silently approve.
That’s why I’m with the GP that the ultimatum-with-deadline doesn’t seem like the best choice in any situation.
Thanks for the feedback. I guess I'd put the 'ultimatum-with-deadline' in between the two risk profiles you outline--something just on the edge of risk.
> Just hoping that I see the ultimatum and silently approve.
I never would have thought of this as an ultimatum--to me it's more like a 'default decision' that makes my manager's life easier while still looping them in and giving them control should they choose to exercise it.
But now I can definitely see how it might be seen as one, depending on the type of decision and the relationship between employee and manager. I should probably update the post to say that you need a degree of trust and alignment for this technique to work; you shouldn't roll this out on the first day.
The advice refers to situations where you, the report, are both able and (well-informedly) willing to take full responsibility. "Ability" here means that, if your decision backfires, you can revert it, and/or contain the damage otherwise. Otherwise, you may be willing to take responsibility, but are unable to. In other words, this piece of advice applies to things that are ultimately under your control.
The background is that, even when something is (mostly) in your control, you may be tempted to ask for permission, in advance, just to distribute the responsibility to others (shift the blame, cover your ass). That delays things, and usually the manager will sense that they got burdened with the request-for-permission somewhat needlessly. In those cases, it's better to take initiative, and be accountable later on, because the latter is in your power, in the end.
(Of course, if you and your manager have dedicated time slots anyway, then bringing the topic up is prudent, as it will not require them to scramble for otherwise unallocated time.)
Conversely, if containing the potential damage is indeed not in your power, then you shouldn't go ahead without explicit permission. For things where you simply can't bear responsibility, a timeout from the approver is not a default "yes", but a default "no". If you can't bear responsibility, then you need explicit signoff from someone higher up that, should shit hit the fan, they will bear responsibility on your behalf -- and so a timeout is meaningless (it doesn't give you what you responsibly need).
Whenever you can afford to interpret a timeout whichever way you want, then you don't need to ask the question in the first place (--> don't ask for permission, just revert/contain the damage, if needed). Otherwise (--> the potential damage is beyond you), you need an explicit "yes" (which is the only case when you're off the hook).
The problem with your suggestion is that it assumes that you, as a report, are in a position to set deadlines for your superior(s); in other words, to allocate their time and priorities. Usually the exact opposite is true (by contract): it's your manager who sets your priorities. You can consider their (repeated?) failure to respond timely a true failure, but that doesn't give you the right to do whatever you want; it would be in bad faith / a form of vigilantism. Your option is to leave that manager.
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.
While I appreciate the OP's position, I suggest the preference of forgiveness over permission is highly contextual. If you're working on a social networking web site, certainly, move fast and break things. But if you're working on a nuclear launch control system, you probably want to model a "don't launch until authorized" control system instead of a "launch unless told not to" system.
That being said... I've used this technique in larger collaborative projects: "If we don't come to agreement by <date>, I'm going with the default choice that may not be optimal for everyone. (i.e.- don't waste time suggesting your alternatives.)" In my younger days I thought you needed to have a horrible default, but that only works a few times before your collaborators think they're just better off without you.
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.
I have done this my whole career some companies see it as being over eager, or even insubordinate. Do it anyway, because the companies worth working for will support you self assigning work that needs done, and hire other people capable of doing the same.
Hire people who can self manage instead of hiring managers.
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".
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?
To me this is a key change in a direct reports development.
When they first start they need to be told what tasks to do; then they develop to asking for permission to do tasks that find or know need to be done; and finally they are telling me they are doing a task so I know we are going in the right direction. These changes give much better autonomy within the team and I am know longer the blocker to progress. It also means I can get on and do more interesting tasks myself while working with the junior members of the team.
This is good advice that I've seen applied effectively many times, with one big difference: don't ask your boss, ask your team. Especially when it involves Github actions that will effect the way the team works. Chances are it impacts developers more than your boss, and they're likely to know more about it. Depending on circumstances also include your boss of course, or maybe they're already part of the team. But it can't hurt to cast a wider net asking for objections.
A technique I use regularly (mostly for decision-making in meetings) and successfully is the five finger approach.
Essentially, people have to hold up a number of fingers showing how strongly they feel about the decision that is proposed. If they strongly oppose it they can do, but they have to offer an alternate proposal at the same time.
What works very well about this is that it moves people away from “do I support this, and is this the perfect proposal?” to “do I hate this enough to block it?”
As such, I think it’s similar to the article’s approach – the default decision (in the absence of strong disagreement) becomes a yes.
This is such an interesting strategy, thanks for sharing. We typically get bogged down in meetings by people dropping constant nuances and edge cases and overly complicating things when a new proposal is presented. I might see if we can adopt a similar approach.
In my current job ... I write design documents that must be approved (in writing) by Key Users in two different companies.
Followed by test cases signature and then by user acceptance test documents.
This style could never work for me: "I'll push it to production on Day X, exactly as described here - unless you object" is not really applicable for me.
I've found "I presented this project to partners in Risk, Cyber, Compliance, and Legal and received no objection." is quite effective.
People in a large company want to know you're working with the right set of people and that nobody is going to be surprised. At some point if a large enough set of people have seen a project and are aware without objection, folks don't want to try to "push back the tide" and a thing will achieve momentum of its own.
"Gosh if Wendy and Bob and Jill are all okay with this...ehh sure."
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.
With great power comes great responsibility. People will think you went behind their backs, even though on paper you did everything correctly. If you abuse this trick, you’ll quickly lose people’s trust.
Use it carefully, always give a reason, and set reasonable deadlines.
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."
> Again, pursue this approach for problems you feel are in the scope of your role
If something is actually in scope of your role, you shouldn't be bothering your manager about it. Wait for them to come to you and then provide an update about your progress or new ideas/concerns. Every time you send an unsolicited email to your boss it costs time and money. Doesn't matter how it's worded. It's gonna consume some energy.
Yes I really like such approach. But it feels a little confrontational.
Maybe I haven't read all the comments but I would love to if somebody could give me certain examples where it doesn't sound confrontational and maybe as confrontational as asking for a yes.
I really like the approach but I think I would be looked as if rude , like look at that guy , he thinks he can do whatever he wants if I say nothing , Let me use politics to put him down unnecessarily.
Again , I really like this approach and am just asking for better / more examples. Something which I can apply practically.
"Hi, I want to switch our logging solution in our client from Console.WriteLine to NLog, because it's been bothering our tech support that we don't have log levels for errors. I've made an issue here: ... . I have some time end of next week due to XYZ, so unless you object, I'll do that on Friday and put it up for review."
And then bother them until you get some reaction that they have read it.
I like the general idea. I read the book “Start with no” a long time ago and the lessons stuck.
The first principle here is that people have an innate need for autonomy and giving them the option to say no gives them peace of mind. Highly recommended.
This is an excellent tool for the toolbox. My company has work from home days but the managers technically have to approve schedule changes/exceptions. Since they almost always approve it, we usually just say "I'll be working from home Tuesday if that's okay" and unless they object, you're good.
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.
This works great from a leadership perspective as well. If anyone is interested, I can recommend the book Turn the Ship Around! by David Marquet about this very subject.
It is all about backing up this question with confidence before asking it. Not about trust you earn over time but trust each time you ask it.
I require teams to do their own security reviews, that includes requirement gathering before shipping anything. If i get a "Anyone have any objections / concerns question"
I usually know directly if they just bullshitting and only done the minimal viable to get something out and want to be able to say "but i asked" or if they done their due dilligence.If the person only says short what they will do and just broadcast it. "Throws it over the fence". Imho is just bullshit. The people that are good have backed it up with explanations, proper knowledge about different areas what they are doing, presenting their thoughts and make sure stakeholders are informed in person or by good documentation and overall just come across like they know stuff. Then it is okey / good to ask like this to find out if you missed anything.
I like the perspective, but then the concrete example given (adding a new GitHub action) is such a trivial 2-way door that I am worried for the author. There are better companies out there!
>Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.
Great Pete, that means you've finished all the work from the current sprint and from the next and you've searched the backlog and didn't find anything to work on. Otherwise you wouldn't have wasted time on this.
Since you have this free time, I have a task for you.
Hey, boss, I am going to hand in my notice now, which should solve the boss problem we’ve been having. Won't be here this on Monday unless I hear differently from you.
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.
I think all this arguing over the phrasing is kinda missing the point.
It comes down to whether you expect this person really will have objections.
If you are going to do something you believe they won’t approve of, even the most polite wording will not stop it being a dick move and confrontational.
Likewise if it’s something you’re pretty sure they won’t object to, you can probably be quite abrupt and it’ll be fine.
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.
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)
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.
I don’t do sales, but I use this all the time with friends - not to force a particular schedule, but to remove ambiguity about my availability. Folks are generally happy to suggest another time if they aren’t available.
If I put “let’s catch up” out there with no information about when I am available, I’m giving the other person the mental labour of initiating the scheduling process.
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.
> .”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.”
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.
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
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.
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.
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.
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.
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.
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.
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.
> “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.
What about:
- If I don’t hear back from you in [N] days, I am not going to do XYZ, considering you don't deem it to be important.
>this cargo cult behavior of citing Amazon's leadership principles
Technical principles too: microservices. Firm size follow a Zipf distribution, thus in most case the decision was made it wasn't necessary and actually slowed down development.
> If I don’t hear back from you in [N] days, I am not going to do XYZ, considering you don't deem it to be important.
Sounds even more confrontational.
Yeah, let's soften it up:
> I'm going to proceed with XYZ in N days. If any of you fucking idiots have a problem with that, then scrawl it down in crayon and flush it down the jacks, which is where you'll end up if you dare question my decisions in future.
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.
That is much, much better, because you dropped the passive part from passive aggressive which people hate the most.
Additionally, the person is clearly signalling s/he is capable of getting shit done, without being afraid of making the occasional mistake.
Though I’d tone down the swearing
That's also passive-aggrsssive.
"I have scheduled beginning $X on $Date. Documentation:... Please remit any feedback, please and thank you"
And in the second example, unrelated to the first scenario: "I had planned to begin $X on $Date, but priorities have shifted and $X is being tabled for now. Documentation:... Please remote any feedback, please and thank you."
Don't lie or whatever, or do. I don't, but none of this feels manipulative, you're just managing your time and workload.
I may have missed some nuance.
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.
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.
"opt-out" is just a tool and it can be used for both good and evil. Same as a for kitchen knife or a political appointment.
> - 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."
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.
> 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?
How do you actually word this?
"We plan to defragment the thingamajig on March 1st. We're reaching out to those who might have an interest in case this might cause problems. Please let us know if you have concerns about the defragment. If we don't hear from you by March 1st, the thingamajig will be defragged."
Something like this?
That's a bit long.
"We're planning on defragging the thingamajig on March 1st unless objections are raised. Please send objections to manager@my.division.com"
Honestly, I've been doing this for decades with legal stuff: "Please confirm that my next pickup date for $CHILD is March 1st." often resulted in the other party just remaining silent and, when complaints against her not allowing the child out were made, she responded with "I never objected to that specific visit".
Using "Unless objections are received, I will fetch $CHILD on March 1st" stopped her from using that excuse.
It's a great way to deal with a difficult party who just wants to have as much creative misunderstandings as possible.
Dude, are you elon musk? Who names a kid $CHILD? That's really fuck...ing awesome man! I wish my country wouldn't regulate how one can name his children...
In pearl or php, $variable is standard syntax.
Also used in Bash, ruby, R when referencing elements of a list…
I’m going to guess the GP didn’t want to give their kid’s name here and decided not to insert a generic Billy in its place. So this being a forum with lots of people experienced in $programming_language it’s common to reference a generic placeholder in variable syntax.
Personally, I think comments on HN should use properly type safe syntax, in which case $CHILD is replaced by:
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...).
I just love HN, no downvote can stop me! Ever!
On desktop I vouch for stuff that's flagged like this. Can't on materialistic. Someone else should, though.
I vouched it. Dunno if it makes a difference unless others do it too.
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.
Hey, we need to do XYZ by April 1st. Let me know if you think that's a problem.
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.
Hey, we will do XYZ by April 1st. Let me know if you think that's a problem.
I am also wondering this , how can we do this without being confrontational and also not being too wordy that you lose interest
‘Going to do thing but wanted to get your input and any impacts you face before this date’
Confrontation turns into a collaboration request.
“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!”
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"
[flagged]
This sounds a bit like a fantasy or the rules you’re breaking are completely irrelevant.
“I’m going to do X in 5 days if you don’t respond” gives you absolutely no recourse if you do something that can result in reprimand.
About the only place where this works is violating some internal design decisions that are irrelevant to the business.
Have been doing all my life and it has never backfired.
It’s not about breaking rules. It’s that I already know what you want.
If I buy you ice cream without asking you for the flavor, it’s because I already know what you want because I pay attention to you.
And it doesn’t matter when I get it wrong because you appreciated the 500 other times I cared about you.
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
For sure - actions before words and all that.
I think the context is different if you’ve shown you care twice a day for a year before screwing up. Most people interpret messages in light of their experience of you.
If you don’t have that track record, the words probably have a different flavor.
> “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.
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.
> 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.
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.
> the rules you’re breaking are completely irrelevant.
This isn't for breaking rules. And definitely not for breaking ones that say "explicit approval needed".
Teamwork is complex and most of it is not covered by rules. If you are too biased towards asking vs just doing you get stuck.
In the military, it gets abbreviated “UNODIR” meaning “Unless otherwise directed”.
> 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.
It's also good in that it force a record that someone is blocking / vetoing your progress.
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.
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.
To whom it may concern,
I am planning to leave the company in 20 business days unless I get a substantial raise.
That's the implicit message in a 14 day notice
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.
All those complicated recruitment processes and companies cannot hire peoppe who know how to read...
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.
Its information overload. Everybody is super busy with 10,000 things to care of. My approach to repeat again and again. No hard feelings.
I wish I could do this with merge requests but unfortunately we'll have to find some other way.
> "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.
Objection! You don’t have Ace Attorney style court hearings at work where you can ”show the paper trail” as evidence?
So, an ultimatum?
Works great until you break the law by accident if you're in a regulated industry. Sometimes it isn't as easy to do that.
Yeah, opting in by default like that can backfire when something gets done and the boss gets in trouble.
I call this “Don’t Ask, Tell” and it has so many uses inside but also outside work. It really is just a basic communication skill to hone. It leads to concise and decisive outcomes.
I actually have this conversation a lot with my wife. She’s more of an asker. A recent example from earlier this evening. We had arrangements set to meet a group for dinner. Her style is to send a text to the group, 8 people, saying “what time is everyone arriving?” Which is so open ended it would initiate a flurry of comms. But, we knew we would be there an hour early because of where/when we were dropping our kid off for the evening. So I just said TELL them when will be there and TELL them we’ll be at the bar if anyone wants to have a drink beforehand. So much more straight forward, everyone showed up early and it was perfect with minimal comms required. Sure it was a lucky accident that everyone had care for their kids lined up to and was able to make it but the point is It took no time and actually didn’t even require any response at all in the case someone was not monitoring their messages.
It’s somewhat related to the idea of “ask for forgiveness, not permission” which I’m a huge fan of in all kinds of ways. Sure it can be riskier but I’m a rebel at my core so it comes with the territory. But this has its place too, group collaborations like GitHub repos is probably not a good place to yolo big changes that effect other people.
> But, we knew we would be there an hour early because of where/when we were dropping our kid off for the evening. So I just said TELL them when will be there and TELL them we’ll be at the bar if anyone wants to have a drink beforehand.
I do this too. And it's not just better communication, it's better life. This way I'm not dependent on other people to have fun. I'm not waiting on coordination in order to start doing the thing I want. I'm doing the thing I want, and letting others know that they can join.
I often give similar advice to colleagues that ask me for pointers on getting their recommendations approved.
"Make it as easy as possible for them to say yes"
Don't dump 14 paragraphs in front of someone expecting them to get onto the same level that you've been after many hours of studying a problem. If you're confident in your approach (and you should be, if you want an easy yes!), then be succinct, briefly describe the problem and why your solution is correct. Optionally link to a document that has more information if a reader wants to go deeper. Make sure you've already gained "approval" from your other team mates or product owners.
"We're going to solve X by doing Y. Team are all onboard. Proposal document is at [link] if you want the detail. Going to begin on Tuesday unless there's any more feedback we need to address."
Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.
>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.
A manager that organized their team so that each team member makes concrete thought-out proposals with all details covered, so that it's their only job left is to give approvals and do nothing else? I'd say that's a brilliant manager
I agree and that’s how I often get things greenlit.
Pro tip: have a quick conversation with a manager and have them make a decision on a $noncriticaldetail before the announcement.
And for some managers you really need to make it obvious what $noncriticaldetail is so they don't change something important: https://museumjorn.dk/wp-content/uploads/2021/05/48s-1.jpg
Maybe I should be a developer that just tries to get everything pushed off to someone else, or just reject the work for reasons so that's my only job.
> If you're confident in your approach
That's the thing. I'm not a narcissist, and my confidence in my approaches is driven by the objective statistics and uncertainties of the approach and NOT my ego.
If I think there's a 90% chance something will fail but there's a good reason to try it for the 10% scenario in which it succeeds, that's exactly my confidence and I'm not going to coat it in some bullshit pitch about how I'm confident it is going to work. If there's an 80% chance it is going to work, I will not lie about the 20%. And if I say 98%, it's actually pretty damn near that. The 2% accounts for my typical sick days per year.
Your job as a manager is to deal with these statistics and hedge the risks. Hedge funds do it with money, you do it with people and resources.
Unfortunately it's the people who say it's going to work 100% and actually fail 50% of the time that get the love of typical corporate managers.
While I doubt most people have sufficient "objective statistics" to truly remove ego from the equation, there's a middleground here.
Write up your detailed proposal as typical, but before you click send, put an "executive summary" at the top, with maybe two sentences. One to describe the problem and one to describe the solution. You can put all the detail you want in the rest of the document. But the onus remains on you the engineer to make a recommendation, not just list options. If you genuinely believe yourself to be a probabilities it should be easy!
Another take on this I like is "radiating intent". Broadcast what you want to do, when you plan to do it, and give stakeholders space to explicitly object, rather than explicitly chasing consensus / alignment / approval. Works in some scenarios, and generally requires baseline trust to have been earned.
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
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."
This seems like the sort of communication style that would immediately have me label someone as a liability.
It presents the communication as if it's saving someone time. In practice, it's a communication style that tells the manager that they need to always keep on top of whatever the employee is doing or else that employee might be taking unwanted action(s). The article treats it as a notification, but even with the best intentions and the best understandings, notifications have a habit of getting lost in a noise of signals. A lack of response does not indicate consent. It could, but it could also very well indicate that the message hasn't been received.
It might be fine if the problem was something the employee and manager previously talked about and this is simply moving forward with a solution, but it's a terrible way to introduce a problem that the other party hasn't even considered. It's a selfish take, and the antithesis of teamwork.
Feels like the sort of thing someone might have seen one of the mythical 10x, Rockstar engineers do. The sort of engineer that's always on top of their game, churning out feature after feature, knows what to do, and has enough respect from and mutual understanding with management that they're given the leeway to self-manage. And the someone, seeing this, decided that the same can apply to themselves, without understanding why that rockstar engineer gets that treatment, or how to go about earning it for themselves in the firstplace.
As with everything it's about the relationship. If you do this 3 times in a row and receive "stop, please don't" then obviously you're off in some regard. If you do it 3 times in a row and get praise, then keep going.
The liability person is someone that is told no, then figures out how to do most of it anyway. Then looks for a yes. Then the next task same thing. No responsiveness to feedback.
So, it's really not about the method described as much as the working relationship. It seems like a fine thing to try in a high-trust environment where people are busy.
That's a great point. There needs to be trust between the person doing this and the boss. That trust is earned.
You also need to pick the right scope of problems--not too big. If you are one month into a new job and use this technique, but the problem you are trying to solve is deep rooted and you don't understand it, you'll burn effort and credibility.
It also makes sense to respond to feedback from your manager, as you suggest above. Some managers may hate this (see other comments, including one that would fire anyone using this technique). In fact, you could even explicitly ask how a manager wants to weigh in on decisions that you feel are in your purview but that they might have feedback on. (Drawing out a manager's readme, as it were.)
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 totally agree with this comment.
I think this is a sort of art in communication which I have just discovered. Though in emails I am not sure if there is an option just for thumbs up , but I do wish so.
I am going to start to learn this art , like this is such a good way of working but it also has to be a little subtle , not rude and may or may not work , IDK just my two cents.
Seems like a reasonable middle ground between asking for permission and asking for forgiveness.
This is a recipe for disaster the first time you break something. Getting a yes or a no indicates that your boss is aware of it.
When you’re in the hot seat, and someone asks “Who approved this?”, the truthful answer is that no one approved it.
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.
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.
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.
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.
Owning things is breaking things (and fixing it).
If your boss has to sign off on everything you do, that's not a boss, that's a micromanager and you're both doing it wrong.
Yeah this only works for decisions you are basically allowed to make yourself.
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 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.
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 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 will not work in non-American companies where a boss might actually have a life and not work weekends, or heaven forbids have days/week(s) off.
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.
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."
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.
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.
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."
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.
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
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
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 like the framing of "defaults" too. Gives space for suggestion and change.
Nice; instead of burdening your boss with a decision, now you're burdening them with a ultimatum, with a deadline. I guess, as a manager, I wouldn't love anything more than a report saddling me with an arbitrary deadline, one I'd have to schedule along with the rest.
One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
Agreed. I actually think consensus amongst the team is more important than your boss. If a group of reports under some manager come to consensus on something they need to do, the opinion of the boss is kind of moot. I tend to operate using a bias for action, and the boss is clued in with information about our decision making, but asking for permission (or forgiveness) really just opens the door for micromanagement. This assumes basic trust has been established between the team and the manager, but in the end the technical decisions should be chosen by those on the team who are technical (read: not management).
Management (in my opinion at least) is primarily for resource allocation, career growth, and shielding the team from endless meetings and acting as a point of contact for upper management
> 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".)
An ultimatum implies the manager has no choice- but they can just as easily say "hold up, don't do that until I get a chance to look at it".
But if a manager is suspicious of their reports and generally doesn't want them taking initiative, they probably have bigger problems.
> but they can just as easily say "hold up, don't do that until I get a chance to look at it"
This still requires them to take notice of your query, within the deadline of your choice; and that may not be a given.
> One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
So you are suggesting making the change without consultation and then waiting for it to be discovered?
I guess that makes sense for certain kinds of situations, but the ones I can imagine don't sound very pleasant. Maybe I'm missing something. What is an example of a situation where you'd take this approach?
It’s really about (a) the wording (b) the level of risk.
For something that isn’t risky, I trust my reports to make reasonable decisions and wouldn’t benefit from the “I’m going to do this tomorrow unless you say no” approach. Instead, they can just tell me they’re doing it (or let me know after the fact, or add/FYI me on the code review, or not even mention it, depending on what it is).
For a decision that is more important/higher risk, they should get affirmative agreement rather than just hoping that I see the ultimatum and silently approve.
That’s why I’m with the GP that the ultimatum-with-deadline doesn’t seem like the best choice in any situation.
Thanks for the feedback. I guess I'd put the 'ultimatum-with-deadline' in between the two risk profiles you outline--something just on the edge of risk.
> Just hoping that I see the ultimatum and silently approve.
I never would have thought of this as an ultimatum--to me it's more like a 'default decision' that makes my manager's life easier while still looping them in and giving them control should they choose to exercise it.
But now I can definitely see how it might be seen as one, depending on the type of decision and the relationship between employee and manager. I should probably update the post to say that you need a degree of trust and alignment for this technique to work; you shouldn't roll this out on the first day.
The advice refers to situations where you, the report, are both able and (well-informedly) willing to take full responsibility. "Ability" here means that, if your decision backfires, you can revert it, and/or contain the damage otherwise. Otherwise, you may be willing to take responsibility, but are unable to. In other words, this piece of advice applies to things that are ultimately under your control.
The background is that, even when something is (mostly) in your control, you may be tempted to ask for permission, in advance, just to distribute the responsibility to others (shift the blame, cover your ass). That delays things, and usually the manager will sense that they got burdened with the request-for-permission somewhat needlessly. In those cases, it's better to take initiative, and be accountable later on, because the latter is in your power, in the end.
(Of course, if you and your manager have dedicated time slots anyway, then bringing the topic up is prudent, as it will not require them to scramble for otherwise unallocated time.)
Conversely, if containing the potential damage is indeed not in your power, then you shouldn't go ahead without explicit permission. For things where you simply can't bear responsibility, a timeout from the approver is not a default "yes", but a default "no". If you can't bear responsibility, then you need explicit signoff from someone higher up that, should shit hit the fan, they will bear responsibility on your behalf -- and so a timeout is meaningless (it doesn't give you what you responsibly need).
Whenever you can afford to interpret a timeout whichever way you want, then you don't need to ask the question in the first place (--> don't ask for permission, just revert/contain the damage, if needed). Otherwise (--> the potential damage is beyond you), you need an explicit "yes" (which is the only case when you're off the hook).
The problem with your suggestion is that it assumes that you, as a report, are in a position to set deadlines for your superior(s); in other words, to allocate their time and priorities. Usually the exact opposite is true (by contract): it's your manager who sets your priorities. You can consider their (repeated?) failure to respond timely a true failure, but that doesn't give you the right to do whatever you want; it would be in bad faith / a form of vigilantism. Your option is to leave that manager.
I like to appeal to person interest more.
I'm gonna do X, that should remove some of the arguments in our *insert meeting/discussion" (removes problems from that stakeholder) and speed up this so we're never the blocker when other teams are involved (puts your stakeholder like a pm ahead of his peers and in the corporate rat race).
The more you know the stakeholder (a colleague, a manager, an owner) the more you understand his goals and his pains the more surgical you can be.
E.g.
"I am going to rewrite this in typescript because typed languages are nicer to use" => "I am going to rewrite this in typescript as it will provide a better experience and make hiring easier" (might be important if youre looking for extensive Magento experience in the middle of countryside Germany to drop it and PHP).
"I will only provide feedback under the form on mobile because that's the only screen where they won't see it without scrolling"
=> "I will only provide feedback under the form on mobile so we don't confuse users on desktop and lose sales".
Again, it is very important to understand what drives the particular stakeholder and try to sell general ideas under the light of how it benefits him.
Your website lacks accessibility? Don't appeal to ethics of disabled people. Explain it's your managers head on the line if someone complains due to the EU accessibility act and there's legal responsibilities.
While I appreciate the OP's position, I suggest the preference of forgiveness over permission is highly contextual. If you're working on a social networking web site, certainly, move fast and break things. But if you're working on a nuclear launch control system, you probably want to model a "don't launch until authorized" control system instead of a "launch unless told not to" system.
That being said... I've used this technique in larger collaborative projects: "If we don't come to agreement by <date>, I'm going with the default choice that may not be optimal for everyone. (i.e.- don't waste time suggesting your alternatives.)" In my younger days I thought you needed to have a horrible default, but that only works a few times before your collaborators think they're just better off without you.
I'm the author. Thanks for your feedback.
Lots of nuance here! I agree that different kinds of orgs and projects and decision scopes all play a role. As does trust between you and your manager, knowledge of what requires feedback, what doesn't, and what is risky enough to require an affirmative response.
But having a bias towards action has been really important for my career. That doesn't mean I haven't flamed out at times, but when I found the right environment with the right level of trust, this technique was super helpful to me.
I have done this my whole career some companies see it as being over eager, or even insubordinate. Do it anyway, because the companies worth working for will support you self assigning work that needs done, and hire other people capable of doing the same.
Hire people who can self manage instead of hiring managers.
NATO runs on this principle, “silent procedure”.
TIL: https://simple.wikipedia.org/wiki/Silence_procedure
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".
You can also phrase it a little more gently.
"I plan to start on this on X date, let me know if you have any concerns."
And send a reminder so that you're giving them multiple chances to respond.
I do this. I got too impatient asking for yes so I ask for no with deadline. Unless it's very risky, then you do a DACI or call a meeting etc.
Try to make most of your operations 2 way doors with safety fallbacks.
If you have good tests, you'll be able to get away with more.
How does this work in a Scrum context?
I want to get stuff done but I need to raise a ticket, have the priority agreed, and get it planned into a sprint. Then after these layers of 'asking for yes' I am allowed to work on something without scrutiny. Let's say I wasn't subject to this process, my pull request would still need someone to approve it.
Is there a way I can adopt the approach of 'asking for no' with these constraints? Or does it only apply in high autonomy workplaces?
To me this is a key change in a direct reports development.
When they first start they need to be told what tasks to do; then they develop to asking for permission to do tasks that find or know need to be done; and finally they are telling me they are doing a task so I know we are going in the right direction. These changes give much better autonomy within the team and I am know longer the blocker to progress. It also means I can get on and do more interesting tasks myself while working with the junior members of the team.
This is good advice that I've seen applied effectively many times, with one big difference: don't ask your boss, ask your team. Especially when it involves Github actions that will effect the way the team works. Chances are it impacts developers more than your boss, and they're likely to know more about it. Depending on circumstances also include your boss of course, or maybe they're already part of the team. But it can't hurt to cast a wider net asking for objections.
A technique I use regularly (mostly for decision-making in meetings) and successfully is the five finger approach.
Essentially, people have to hold up a number of fingers showing how strongly they feel about the decision that is proposed. If they strongly oppose it they can do, but they have to offer an alternate proposal at the same time.
What works very well about this is that it moves people away from “do I support this, and is this the perfect proposal?” to “do I hate this enough to block it?”
As such, I think it’s similar to the article’s approach – the default decision (in the absence of strong disagreement) becomes a yes.
This is such an interesting strategy, thanks for sharing. We typically get bogged down in meetings by people dropping constant nuances and edge cases and overly complicating things when a new proposal is presented. I might see if we can adopt a similar approach.
In my current job ... I write design documents that must be approved (in writing) by Key Users in two different companies.
Followed by test cases signature and then by user acceptance test documents.
This style could never work for me: "I'll push it to production on Day X, exactly as described here - unless you object" is not really applicable for me.
Before reading the article, I parsed the title as "ask for permission only if you want a 'no', otherwise don't ask for permission and just do it".
I initially parsed as text variant of this video: https://youtu.be/-vZXgApsPCQ
I've found "I presented this project to partners in Risk, Cyber, Compliance, and Legal and received no objection." is quite effective.
People in a large company want to know you're working with the right set of people and that nobody is going to be surprised. At some point if a large enough set of people have seen a project and are aware without objection, folks don't want to try to "push back the tide" and a thing will achieve momentum of its own.
"Gosh if Wendy and Bob and Jill are all okay with this...ehh sure."
I’m reminded of an infamous occasion when this technique was used: https://en.m.wikipedia.org/wiki/Cable_243#Preparation
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.
With great power comes great responsibility. People will think you went behind their backs, even though on paper you did everything correctly. If you abuse this trick, you’ll quickly lose people’s trust.
Use it carefully, always give a reason, and set reasonable deadlines.
A related technique is:
In student council in high school we implemented a similar approach.
Any vote was a vote to deny, not approve because basically nobody bothered voting, so that was the way to make things happen.
It's fair to bias for action in this way.
But offering a negative option to object could be more likely to induce mistake and undue reliance. (Remember: negative options are illegal per FTC.)
But the real question is not the form of the ask but what information to include.
You have to tell deciders what they need to know to decide. Don't queue them up for a research project or to go survey stakeholders on your behalf.
Deciders need at least to know the range of consequences and likelihoods, and when and how there will be new information or opportunities for monitoring/managing. Usually that means you also propose their management plan.
e.g., "I'm updating dependencies on Sunday. If it fails we'll roll-back, which is ~2 minutes of downtime (within this quarter's SLA). If it works, offshore will need to refresh their devenv, but we can reduce the security notice Monday. I'll preflight Saturday if you want to confirm with me Sunday beforehand, and I'll cc you on offshore/security go-ahead's."
I wish I’d found this article earlier. My biggest frustration at work was literally this.
Having to propose ideas a million times before any one of them saw the light of day.
> Again, pursue this approach for problems you feel are in the scope of your role
If something is actually in scope of your role, you shouldn't be bothering your manager about it. Wait for them to come to you and then provide an update about your progress or new ideas/concerns. Every time you send an unsolicited email to your boss it costs time and money. Doesn't matter how it's worded. It's gonna consume some energy.
Yes I really like such approach. But it feels a little confrontational.
Maybe I haven't read all the comments but I would love to if somebody could give me certain examples where it doesn't sound confrontational and maybe as confrontational as asking for a yes.
I really like the approach but I think I would be looked as if rude , like look at that guy , he thinks he can do whatever he wants if I say nothing , Let me use politics to put him down unnecessarily.
Again , I really like this approach and am just asking for better / more examples. Something which I can apply practically.
"Hi, I want to switch our logging solution in our client from Console.WriteLine to NLog, because it's been bothering our tech support that we don't have log levels for errors. I've made an issue here: ... . I have some time end of next week due to XYZ, so unless you object, I'll do that on Friday and put it up for review."
And then bother them until you get some reaction that they have read it.
I like the general idea. I read the book “Start with no” a long time ago and the lessons stuck. The first principle here is that people have an innate need for autonomy and giving them the option to say no gives them peace of mind. Highly recommended.
https://www.goodreads.com/book/show/689417
This is an excellent tool for the toolbox. My company has work from home days but the managers technically have to approve schedule changes/exceptions. Since they almost always approve it, we usually just say "I'll be working from home Tuesday if that's okay" and unless they object, you're good.
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.
This works great from a leadership perspective as well. If anyone is interested, I can recommend the book Turn the Ship Around! by David Marquet about this very subject.
I think this person has also interesting content regarding No and Yes
https://youtube.com/shorts/DjuC8xauWWk?si=VkGFbgbqyzKqPjLD
Another interesting one https://youtube.com/shorts/tWthV06ZIDo?si=JdKPvykIuv5q7RGY
This is basically asking for forgiveness instead of asking for permission
It is all about backing up this question with confidence before asking it. Not about trust you earn over time but trust each time you ask it.
I require teams to do their own security reviews, that includes requirement gathering before shipping anything. If i get a "Anyone have any objections / concerns question"
I usually know directly if they just bullshitting and only done the minimal viable to get something out and want to be able to say "but i asked" or if they done their due dilligence.If the person only says short what they will do and just broadcast it. "Throws it over the fence". Imho is just bullshit. The people that are good have backed it up with explanations, proper knowledge about different areas what they are doing, presenting their thoughts and make sure stakeholders are informed in person or by good documentation and overall just come across like they know stuff. Then it is okey / good to ask like this to find out if you missed anything.
I like the perspective, but then the concrete example given (adding a new GitHub action) is such a trivial 2-way door that I am worried for the author. There are better companies out there!
How to phrase it if you need code review from other team and deploy code into their code base?
Or just do it, in testing. If it's reviewed by colleagues and looks good then ask for no.
Yup, this is the meatspace equivalent of "opt out" vs "opt in", and works for pretty much the same reasons.
>Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.
Great Pete, that means you've finished all the work from the current sprint and from the next and you've searched the backlog and didn't find anything to work on. Otherwise you wouldn't have wasted time on this.
Since you have this free time, I have a task for you.
Hey, boss, I am going to hand in my notice now, which should solve the boss problem we’ve been having. Won't be here this on Monday unless I hear differently from you.
This is the famous pattern that we see in building interfaces. "Tell, don't ask".
I've used this technique ever since I read DHH's article about the book "Turn The Ship Around" [1]. The book's author, a Naval officer, had a policy of "Don't come to me for permission, come to me with intent." Hearing that phrase changed my professional life for the better in so many ways.
Admittedly I haven't included a deadline nearly as often, but I've found a huge difference between saying "Can I do XYZ?" to my team lead (or even worse, "What should I do?"), vs. "Unless you object, I plan to do XYZ." The latter is frankly much more empowering as an employee, and it doesn't hurt that it sounds so much more senior. If I come with intent, I have to be prepared to defend that intent, which gives me more ownership in my role on a team.
1. https://signalvnoise.com/svn3/you-dont-have-my-permission/
I believe the phrase is “Ask forgiveness not permission”.
In this case it is different, you are implicitly asking for permission on a timeout clause.
I think all this arguing over the phrasing is kinda missing the point.
It comes down to whether you expect this person really will have objections.
If you are going to do something you believe they won’t approve of, even the most polite wording will not stop it being a dick move and confrontational.
Likewise if it’s something you’re pretty sure they won’t object to, you can probably be quite abrupt and it’ll be fine.
403s here, guess they're geoblocking entire continents.
27 years professionally and I naturally do this.
... However I suffix it with "if that's okay" or "unless there is something more pressing".
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.
This is a variation of a sales tactic which says to not give people the option to say no but instead only give them affirmative options.
E.g., Not "When can we talk about this deeper?" But "Would Tuesday at 1 or Wednesday at 3 be better for a follow-up?"
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)
Yes and it’s very obvious
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.
I don’t do sales, but I use this all the time with friends - not to force a particular schedule, but to remove ambiguity about my availability. Folks are generally happy to suggest another time if they aren’t available.
If I put “let’s catch up” out there with no information about when I am available, I’m giving the other person the mental labour of initiating the scheduling process.
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.
I think it’s less about putting pressure on a prospect as it is making the follow up meeting as easy as possible to schedule.
To many people, me included, it does come off a bit abrasive, but it does reduce the number of decision to make into a yes or no.
i just say no thank you, then get impolite if they don’t drop it.
I'd fire him
> .”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”
No thank you. I'm the boss. Don't push me around
Author here.
Ah, this is interesting feedback. I think that there's some nuance to this approach that I didn't capture in the post. You have to have some level of trust between yourself and your boss, which you've earned over time by being right and/or fixing mistakes you've made if you were wrong.
The idea isn't to push the boss around; it's to make the boss' job easier by making default decisions for them, but letting them weigh in.
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 pretty much work this way.
In my experience, they completely ignore what I’m doing (“yeah…whatevs”), then pitch a fit, when they see the result. I get a lot of whining about how come I don’t have clairvoyance, and didn’t interpret their ignoring me, as a “no.”
Annoying AF, but I still do it, as I can point to my statement of intent, and tell them that they had their chance. Often, I don’t just ask for a “no.” I also ask for specific input and feedback (which I also don’t get). That gives me more ammo, when they get butthurt.
The trick is to not do something that will really upset them. That takes experience and empathy.
It is an irrelevant optimization unless you own a lot of equity in the company.
No, it also helps you progress in your career faster, boosting your own ability to get things done and hence your bargaining position.
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.
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.
I would rather just work at a place where my hands weren't so tied. The actions you noted only come in the way of it.
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.
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 would rather just work at a place where my hands weren't so tied. The actions you noted only come in the way of it.
Unless you have a limited pool of opportunities. If so, educate and demonstrate value. Maybe even if pool isn’t super limited.
Or, if your job is decent, don't let perfect be the enemy of good.
(Also, not every decision that you need to communicate up to your manager is going to have a significant impact on your company. Sorry?)
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.
It usually takes 2-3 years of bad actions for a team to torpedo itself, so no, 4 months doesn't relate.
This is important wisdom.
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.
[dead]
[flagged]