Ask for Advice, Not Permission (2015)
boz.com
boz.com
> (...) but if it goes wrong you might end up involving them in the failure: “Hey, I asked that team and they said it was fine.”
I've seen this play out in teams. The part that's omitted is how some unscrupulous team members set up their team members for failure.
I've personally witnessed a case where a team member went out of his way to propose a rewrite of an important feature and reached out to a couple of senior members to do a system design review and provide feedback. They initially told him the design was good as is and required no feedback and change, but once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail, including on the need to rewrite the component.
There are plenty of good reasons why some FANGs enshrine the need to be thorough and extremely critical of projects at the design stage but everyone is obligated to commit to the project once it starts to be implemented. Teams need to commit to projects after they are prompted to give their opinion during the design process, and once their opinions are heard there should be no room for weaseling out and go the backstabbing route to throw everyone around under the bus. There is a time and place to provide feedback, and if you're prompted to deliver your feedback then you should not pretend the project does not reflect your input.
I don't know if this is a typo or not but it's great.
(B and T are pretty far apart in QWERTY, so...)
I think it is pretty clear that the need to have all team members commit to projects after the design review is to prevent backstabbers to stab other team members in the back with sudden epiphanies and claims they would never make such a mistake.
You only need seat belts and airbags if you crash your card too.
Which is happening atm in a project I'm in right now. They're not letting me move, I'm trying to just do the work but there's just no way I can be at my most productive in situations like this.
You just need to grow a spine and express your concerns.
Alternatively, if growing a spine is not an option, you forego any entitlement to point fingers the moment you avoid your responsibility of voicing concerns in a timely manner.
The spineless, sociopath route of not voicing any concerns and proceeding to throw everyone around you under the bus by feigning you knew better is something that's the worst of all options.
Second, you can not use theoretical option of formal review as a way to avoid responsibility. Just because you sent your 150 long pages pdf to people to read and they actually read it in allocated 2 hours they could afford for it and did not seen issues does not mean you dont have responsibility.
This is case of you wanting reward if it goes well, but also wanting to hide behind review if it goes bad.
If I find out the design is bad in the middle of implementing it or after I see how to nice sounding words were implemented in practice, again, I should have right to say so.
All of these rules are just attempts to make yourself look better by preventing criticism.
Do you mind sharing a concrete example?
If you're interested on the topic, you can start by reading up on "disagree and commit".
To weed out sociopaths, Amazon even went to the extent of coining their leadership principle "have backbone - disagree and commit". The emphasis on having backbone underlines how they explicitly target people throwing others under the bus.
To me it's just something that for example someone only got motivated during the commitment line. Maybe they were lazy, had other priorities or just didn't come to realize a key piece of information due to the complexity of the project. What does this have to do with sociopathy?
Also doesn't that value instead mean that you can disagree before hand, but even if you keep disagreeing you still have to commit once everyone decides on it. So you might have been critical before hand and also still disagreed, but in order to at least go some direction you have to still commit.
From Wikipedia:
> Disagree and commit is a management principle that individuals are allowed to disagree while a decision is being made, but that once a decision has been made, everybody must commit to implementing the decision. Disagree and commit is a method of avoiding the consensus trap, in which the lack of consensus leads to inaction.
It's about avoiding a case where things can't move on because people are disagreeing.
Are you really asking what sociopaths have to do with setting up their team member for failure by intentionally steering them into a wrong path so that they could throw them under the bus?
> Also doesn't that value instead mean that you can disagree before hand, but even if you keep disagreeing you still have to commit once everyone decides on it.
That's the whole point. If you are asked to provide your input, whatever it might be, once the decision is made to push the initiative onward then not only are you expected to support the project but you also lose the right to pretend you had no say or responsibility in it's outcome. You cannot suddenly throw everyone under the bus by pretending you had no say or responsibility on the outcome.
If there's a sociopath on your team who does things like that, then maybe remove them from the team rather than try to counter it with some odd methodology like that?
I'd imagine sociopath can find other means if they truly wanted to throw someone under the bus for whatever reason.
I think this situation would've happened regardless of advice vs permission. So it's not really talking directly towards the article, but yeah, bad actors are terrible to deal with especially when they hold power on like a PR review.
I don't think so. If you have a process in place where everyone can and should be heard during the design process and once the design is approved it is owned by everyone and everyone is obligated to fully commit to it, you prevent the sociopaths within your ranks from weaseling out and throw anyone under the bus. You eliminate the motivation to steer people in your team down a bad path to afterwards portray yourself as the only sane, competent guy in the ranks, because you have to explicitly sign off on the project. Once you sign off on the project, any extraordinary miraculous epiphany that happens after the fact is something that you must be held liable for, because it becomes obvious that you were never acting on behalf of the team's best interests. Therefore this sociopath move is no longer something that benefits you, and so the perverse incentives to screw over your team members is no longer there.
It's much nicer to deal with overly enthusiastic junior developers that want to rewrite one out of the company's 30 typescript microservices in rust (because they read somewhere it's cool).
But I didn't want to be the guy who "once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail". (Even now I remember how annoying that guy felt when I was a junior dev!) So I let it go forwards with too little scrutiny of what might go wrong. Now I hope I've learned my lesson, and insist on doing things safely even if it might make me seem annoying or obstructive in the moment.
If that doesn't suit your character, as it can be, than you can discuss with your team how to come up with a better process. Perhaps someone else has no problem with that, or you rotate the responsibility, etc.
I've picked a strategy at times where I will say that something is a bad idea for the reasons X, Y and Z, and then when they still want to go on with it, I'll let them, so it would be possible to win some trust with them so I don't have to spend so much energy again on explaining why something should not be done. I will refrain from "I told you so", hoping that it allows to build some confidence to move on quicker next time.
But then at some point people rotate and I have to start building that trust all over again.
I guess with other engineers I just hate it when someone is really enthusiastic about something and I think the idea is truly impractical and will do more harm than good. I have to kind of find a way to direct them to do something else without hurting the enthusiasm.
If you made things clearer for both of you, you can feel good about what you did. You helped the other person make better choices. Now this still can be something different than your choice. But if it's their responsibility, then that's fine.
In situations where I don't agree with my boss or colleague I focus on two parts:
First; do we fully understand each other? Are we aiming for the same thing, and do we agree that X, Y, Z are risks? Are there other aspects you perhaps didn't know that are important for the other to weigh, etc.
Second; what is the earliest we can test who's right on the important part where we differ. You can suggest a short brainstorm for a proof of concept, etc.
I would actually rather not work on something like this, but it pays more than anything else I could currently get.
New lesson learned: They don't like you questioning everything and being super thorough either. And no matter how politely[1] you say it, they think you're difficult to work with too. The decision to rewrite, or do something a certain way was made by someone that is "in the decision room", and they'll play along with you for a while, but you best eventually acquiesce to the way they want it done.
Being a bit more meta about it: I'd say the real problem is that the tech field has ridiculous levels of "flat hierarchy". In this case it means that simultaneous everyone and no one has a say in any one particular decision. And even if there is a title for whatever responsibility or area you are to have final say in, there is always the room for suggestion and criticism, which means you have to "consider it". Thus opening the flood gates of all this non-sense.
[1]. I don't even know the word to use here. Politely doesn't do it justice to how much I have to bend over backwards to be considerate, calm, and appreciative of everyone.
Sounds like they're right. That attitude is difficult to work with.
> no assumption unquestioned
That's just unhelpful and a hindrance. Assumptions are good! They are huge time savers. Occasionally they are wrong and that can lead to bad things but questioning every assumption is just pointless and going to piss everyone off.
People have told you you're difficult to work with, and you can't really argue with that anymore than you can argue with someone saying they don't like you. You can't say "yes you do!".
> there is always the room for suggestion and criticism, which means you have to "consider it".
Erm yeah! Why would you not want to consider people's suggestions?
Maybe instead of complaining about people finding you difficult to work with you could try and change your attitude so that they don't?
> Erm yeah! Why would you not want to consider people's suggestions?
This was in the context of a lack of definitive authority and a flat-hierarchy. People that work with me know I genuinely consider everyone's opinion, and everyone always gets a clean slate with me.
Can be a cultural thing. Here in the Netherlands, it's expected that you give honest feedback. In other cultures Dutch people are known to be blunt or impolite because of this trait.
In general you can ask beforehand; "Would you like some feedback on your proposal? I have some thoughts about it I'd like to share".
> Thus opening the flood gates of all this non-sense.
Am I misunderstanding you? It seems here you call suggestions and criticism non-sense. Where earlier you say that when you give suggestions and criticism, you hate it when it's viewed as non-sense.
I'd say that if there is so much negativity regarding feedback, you need a process to structure it. This at the very least stops it from 'hanging in the air' all the time.
I'm not sure you have learned the right lesson - you already admitted that you let the change go forward, so it isn't a case of junior vs senior. You both made a mistake.
The correct lesson to draw from something like that is that you didn't have enough systems in place to prevent a mistake.
In my experience, it's much worse to deal with enthusiastic juniors.
Another especially bad take coming from the same company is 'move fast and break things', which is one of the most destructive pieces of advice in our industry.
We got Boeing software defects costing lives, SolarWind pwnages, the npm crashes, we got the Cloudstrike fiasco, Tesla self driving bugs, and who knows how many failures of software engineering. And we, the software engineers wanna be moving faster and breaking things? What happened to writing correct and reliable programs?
We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? You guys do you, then.
I’m not sure about moving fast in a safe environment. In general it might be good for the individual devs to have initiative. A safety critical code requires a safe process, which should not rely too much on the prudence of an individual developer. Have really good devs is not a plan, right?
Nobody suggested that. And nobody suggested using junior devs' code in critical components.
But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something. It's so tedious.
The whole idea that juniors are somehow the people who know what improvements need to be made, and the seniors are the gatekeepers stopping them, is hilarious.
Juniors:
- don't know the domain
- juniors don't know why the existing ecosystem is how it is
- juniors probably can't even ascertain as good as a senior whether there is really a problem that actually needs solving
- hell, juniors don't even know half the capabilities of the language/framework/infrastructure you are using
Imagine that you are a teacher in school, and you find that somebody wrote a book "Whatever your teacher says, don't listen, just do what you feel like" and is actively pushing it to your students. That's what this BS "Ask advice, not permission" advice does to junior developers.
> It's so tedious.
It's tedious to have 3 junior engineers in a typescript/react shop, each from a different team, one wanting to rewrite everything in rust, one wanting to switch to deno, and one wanting to rewrite everything in vue, while there is no actual problem to solve.
This is a real situation that happened to somebody I know. And he, the senior, was the old fart, gatekeeping the great and always-learning juniors from all that potential rust greatness.
What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me?
There is seniority in software engineering, and in companies in general, so somebody can stop stupid ideas from proliferating and occupying the whole company's time. Sure, there is a problem of bureaucratic middle management that doesn't allow good ideas to come to fruition, but to not acknowledge that a huge percentage of ideas coming from juniors belong to the waste bin, that's just pure hypocrisy.
> What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me?
I would say "what's the benefit of that?" and if you can convince me then I would let you try rewriting part of it as an experiment. No gatekeeping.
But no junior devs I've worked with have suggested anything like that anyway.
And I'd say:
"There's no other scripting language that makes it as easy to add scripting abilities to native applications.
It is lightweight, simple, easy to learn, and not that hard to master. You can use it for anything: as a substitute for ini or json files, or to code entire games in it. Just like JS, just easier to embed and easier to use.
LuaJIT, in the hands of a skilled programmer, is a marvel when it comes to performance."
(Taken from reddit, by the way)
At the end, we'd go over some things that are probably not okay in typescript and Lua does better, but we'd be missing the point. The whole idea that it's not worth to rewrite whole systems in Lua just because you don't like some syntactic sugar's absence in typescript is totally lost on a junior dev. You can convince them, of course, but probably not to a full extent, and you'd still be considered a gatekeeper.
> and if you can convince me then I would let you try rewriting part of it as an experiment
What's wrong with a straight up opinion and saying: "this is probably not a good idea, considering we have 30 repositories, all using typescript, and no in-house knowledge of Lua"? Why do we have to endlessly coddle people and mislead them?
Imagine this scenario: somebody asking you to do something ludicrous and you enabling them, multiplied by the number of junior developers you have, month after month, busy with new experiments. Eventually, you'd have to allow some of these proofs of concepts into the codebase, or they’ll realize you’re just leading them on, right? Congratulations, your 30 repo react/typescript codebase is now 15 different versions of react, vue and angular, Lua, python and rust rewrites, and they are deployed (or are they) randomly on all your major cloud providers.
This is how, by being afraid to assert authority and not wanting to appear as a “gatekeeper,” you end up on a slippery slope, allowing junior developers to do whatever they want and dragging the quality of the codebase and the velocity of your team with it. How many competing experiments can your teams juggle?
If the junior devs want to learn, they should do so on existing systems, trying to understand and improve them, rather than we all pretending they are god's gift to humanity and giving them entire systems to develop from scratch and wasting months of work on experimentation.
You are doing the junior devs a disservice by leading them on like this, imo it's much better to coach them why existing systems are how they are, and help them improve along the way.
Towards that ends, I played the enforcer over the products I managed. I focused on the structures and processes, trusting the resulting outcomes. More referee than BDFL.
Everyone was invited to participate in design & decisions. Joint application design, project kickoffs, approval voting for triage, go/no-go events, post mortems, etc.
And once a decision was made, I enforced it. If a decision needed to be revisited, fine, but it'd be revisited as a team. No unilateral decisions. No hiding in the elephant grass and sniping works in progress. No "I told you so". Nobody pulling rank to get what they want.
Once each project/product found its release cadence (eg every 6 months), this team decision making process worked great. Because everyone knew they'd have another bite at the apple in just a few months, it lowered the stakes for each decision. So everyone could emotionally "disagree and commit", confident their personal priorities would be addressed in short order.
Design phase? Commitments that can't be changed on a sprint-by-sprint basis? That's not very Agile. /s
The worst offenders are those that can't be bothered to participate in the design process but somehow feel justified in raising concerns many months later, at the 11th hour. I've had to say "sorry, decisions are made by those that show up" more than once in my career. You can't get anything done if every decision is up for re-litigation whenever a senior dev gets a bug up their ass.
And part of the problem is Agile-Scrum since there is no design phase in which these decision are made explicit. Decisions are scattered everywhere if they're documented at all. And they're often decided in the sprint planning phase where everything is rushed to meet the arbitrary sprint deadline and where you have the least amount of empirical data to make high-quality decisions. So it's no wonder that teams struggle with commitment - under Agile, they barely known what they've committed to.
If someone can derail the project they should have been giving feed back iteratively, otherwise we fall into a water fall trap.
I don't really like the "senior design review" because of this lack of continued involvement.
This is pure https://en.wikipedia.org/wiki/Law_of_triviality
I think I've probably been on both sides of this coin. It takes some experience to recognize, and I don't think it's entirely on the individuals.
I think it comes about when the people being asked "if it's fine" probably have a completely separate set of day to day concerns than the people doing the asking. They probably have not enough context on why, or the impacts. And they probably don't have the time or support to ask for more time to give a real answer.
It's on management for not asking for more analysis or aligning needs or overextending the staff.
The term 'ownership' has also done a disservice. 'Stewardship' would be better.
Even assuming people can see every potential issue at the design stage (because design mistakes never slip through and everyone has perfect foresight, right?), what also sucks is when you're not in the set of people asked for input in the design stage to begin with (maybe you weren't high level enough, or maybe you weren't on the project or team at that point, or whatever) and then you end up having to implement something where the design seems wrong or nonsensical to you.
I think this is fine? It sucks, but sometimes priorities change, and due to the additional attention paid to that feature, it may have turned out to be not as important as originally thought. Staying critical throughout the development process is important, to ensure the implementation is as good as the design. And, keeping a broad view can help alleviate tunnel-vision syndrome, although it can suck for everyone involved.
all those things could have happened, but I doubt they were just 'discovered' at launch, and are so critical and diametrically opposed that there was no ability to communicate that at some point beforehand.
Had that happen, too, as a PM. All stakeholders greenlight things, no more feedback to be had, let's build this out as a POC.
Then...
"Why did we spend X months building this?" (yes, POC and 'months' because other responsibilities).
Because the design usually is presented in a way that looks the most plausible, default-looking and approvable, hiding the real problems and decision points. And when the project is close to being deployed, the problems become visible.
Very rarely I see design being presented like 'here is the problem we need solve, here are the constraints, here are the unknowns, by this logic we come to this solution'. One of the reasons this rarely happens, is that in big organisations there is often a hidden agenda like 'I want as many people and departments as possible to start depending on me so I can get my promotion'.
The real problem I see is that nobody other than the 1 dev was involved in writing an entire feature until the code was done
That's all fine and dandy, but once you decide to weasel out of giving your input once asked then you lose your right to feign ignorance and surprise about hypothetical "mistakes" because you too failed to spot them, let alone address them. You had your chance to avoid a mistake when the mistake could be avoided. That was why your input was requested. If the mistake was still made it was because either you were not able or were not willing to spot them, so you have no right to point fingers at anyone but yourself.
If there's anything ruining teams, it's the sociopaths that try to get ahead by setting up their team members for failure and backstabbing them while feigning ignorance.
This isn’t particularly helpful advice in domains where unknown unknowns really do appear. Not everything can be surfaced at design time. Having said that, design time is the perfect time to align on rules of engagement for surfacing and managing unknown unknowns.
It’s also possible that it occurs in genuine miscommunications. It happened to me two weeks ago when my team lead had a different interpretation to a doc I wrote than what I intended. Shit happens. There are mechanisms a team can put in place to mitigate these eg: forcing user stories to be clearly enumerated and matched to parts of the design; third party review; definitions and glossaries; office hours for document review. But it does happen.
If this hypothetical scenario comes up with genuinely avoidable issues, is not due to miscommunication, then this seems like a culture problem. If a person’s approval was explicitly requested, given, and rescinded for political or personal reasons, yes that’s when management needs to step in and navigate the team out of those fucked up dynamics.
I don't think your comment makes sense. You're talking about a scenario where, when you ask someone to review your design, their feedback is literally "all good, looks fine to me",but when you present your design to management or you roll out your design them that same person suddenly changes their tune and has all kinds of epiphanies on design mistakes that they wouldn't have made if it's up for them.
Are you really doing the bridge-burning if you call them out for throwing you under the bus?
I can’t speak to your personal situation or experience, but it’s important to caution against labelling people sociopaths because there are many variations of this scenario where that’s simply not the case. It can and will damage relationships.
It's one thing to get back to the review and say "hey I just noticed something I didn't noticed earlier, and I feel it's important to address."
It's another thing entirely to afterwards accuse the designer of oversight and proceed to claim that the oversight is so glaringly obvious and that you would never have missed it if you were tasked with the design. As if you didn't missed it yourself when you were prompted to give your feedback.
If this is a collegial environment where people are unlikely to get fired, then a "late epiphany" is unlikely to be strategic behavior. It might be unselfaware ego, sure, but it probably isn't a person setting out to screw you.
If this is an environment with internal competition and stack-ranking -- if this is Amazon, where "leaders are right", and you lose the ability to be seen as a "leader" if you ever acknowledge a mistake -- then absolutely you might see this as a nasty strategic behavior.
Compared to many other industries, Silicon Valley has more-competitive people, higher stakes, and shorter tenures. You are more likely to see this there, I think. And people who have only ever seen that environment will probably be more on the lookout for it. Hence the attention it gets in this thread on HN.
That's perfectly fine. That's also not the case, though. The case in question is that when asked to review a design your assessment is that it's perfect, but only when the project comes to fruition you suddenly somehow have a series of epiphanies on how there's all sorts of problems with the design and how if you were tasked or even asked to design something you would never ever made those mistakes. That's a little different than stumbling upon emergent requirements. That's backstabbing plain and simple.
I think if this happens often then I would acknowledge there is a major disconnect amongst team members that this requires elevating to management. If it’s a one off, then it’s a lesson to be learned.
But if it’s happening often I would want to know if it’s me or them. What can I do to make this process smoother?
Is there a so ideal work environment, employee can do what they want when they think they have a good idea without the permission of superior? It will be so great if there is.
When it fails, the underling can say "boss said I don't need to ask permission for that", and it appropriately falls upon the boss instead.
I would never say that except in extremely simple circumstances. Anyone asking permission is unsure, and you should help them be sure.
Yes, I can attest those exist. In my experience it helps if you built a proven track record, and smaller teams probably work best. You should still inform them of what you’re working on, ideally after having thought through potential problems, especially if it’s something big. Basically, give them an easy option to say “no” but not a reason to.
Learn to anticipate how they like things done and be sure to do it in a way they’d have no complaints. If their usual method wouldn’t be feasible in a given situation, mention that and your suggestion before they even have to ask.
Essentially, if you get to a point where you deliver consistently in a way that they think “this is exactly how I would’ve done it or better”, they have a pretty good incentive to continue to let you be and do your thing.
It helps if there’s mutual respect between you and you share similar values on what constitutes good work and where to spend effort in.
If asking for advice to truly help with a decision, it’s often useful to clarify that you want their full opinion, not just the PR-approved version of their thoughts.
The average person hates giving critical feedback to another adult.
The average person isn't qualified or skilled enough to give good critical feedback that is actionable to another professional, unless it's a direct mentor role.
E.g. I don't care about my manager's feedback, because he's not technical, and vice versa.
This kind of feedback just isn't relevant in most cases, so people just give their "PR-approved" thoughts, because everyone understands it.
This is kind of a crappy attitude to have
If the team accomplishes all goals on time and the client is happy, why does there even need to be feedback?
Don't make mandatory feedback some kind of misguided target.
My last direct request of getting root access on our cluster did not go well. And this was for a good reason.
I don't see anything wrong with checking with people to see if they have an objection. It is in NO way disrespectful, and strikes me as bizarre to suggest otherwise.
Posts like this seem to be written from a philosophy of anxiety about ever saying or doing the wrong thing, and then proceed to problematize ordinary behavior, which only creates MORE opportunity to say the wrong thing. How about this: don't worry about it! Ask advice, ask permission, whatever. It'll be okay.
It's fairly vague, though, as all these things are.
My own experience, with almost everything in life, is "It depends."
There's really no such thing as "One Pithy Aphorism to Rule Them All." In my experience, every philosophy works best as a heuristic, to be adapted to the context, and almost every context is different.
That said, we can't be too flexible, or we won't get anything done. I feel that each context needs to have "hard" parameters established and enforced.
It's just that, in my experience, we need to respect each individual context, and many folks are spectacularly bad at that.
This chap is/was the CTO of Meta, though, so he has some fairly solid background in one particular context.
Real people in the real world (not imaginary people in a fictional blog story) don't overthink every word someone is saying.
Asking for "advices" or asking for "permissions" or just - plain asking - is all the same. People don't see the difference, no one is imagining a scenario based on how the question has been asked, people are probably not even going to remember...
Let's take that at face value for the moment.
The person making the request cannot know ahead of time that the person they are asking treats advice/permission interchangeably. Their interlocutor could instead be what the author calls a gatekeeper, in which case permission-seeking will trigger the gate but advice-seeking will not.
On the flip side, someone fielding a question cannot know ahead of time that their interlocutor essentially randomly chooses between advice/permission-seeking, and that their interlocutor would treat the response the same either way. The person asking the question could be a narcissist looking for a place to lay blame if things go wrong.
Where such a choice is possible, standardizing on advice-giving therefore minimizes gatekeeping and ass-covering. Permission-seeking invites one or the other, with no apparent gain.
The results are even more in favor of advice-seeking when you take into account the number of people who have an easy time claiming what you've written-- be direct, we're all adults here-- but end up being gate-keepers/ass-coverers in practice. That discrepancy between words and deeds characterizes the vast majority of narcissists I've ever met.
There are a lot of narcissists out there, so I don't see any reason not to take the author's advice. At worst the standard has no effect at all, and realistically it will probably do what the author says it will.
But it really is up to the management culture, and the mindset of the manager, themselves.
One of my basic management postures, used to be easy permission. I wanted my staff to take chances, and my permission deliberately took the risk onto my own shoulders, giving them cover.
But my staff was composed of sober, highly-experienced engineers. I don’t think it would work for a team of youngsters.
That's the key difference. The ideas of highly-experienced, sober engineers will be high-quality, and most of all, sober.
The ideas of a team of youngsters are almost guaranteed to be...less sober.
"It's easier to ask forgiveness than it is to get permission."
I never thought of it as arrogant, but I guess it depends on context.
There's a lot of quotes that have been "repurposed," to afford unhealthy behavior.
Another one that is abused like hell, is "The perfect is the enemy of the good." People usually use that as an excuse for creating ... less than perfect, shall we say ... product.
This is one that I can see not going well in a number of those scenarios.
I can see where that's coming from but that statement conflates many problems into one and sounds like the author has the opposite problem of just wanting mostly credit and not accountability?
- Many people who ask for permissions are genuinely asking for permissions to be given the chance to _try_ something that they believe may be the correct solution. You'd only be in the position to say now if you have the authority to do so: if you say yes, then you'd better be comfortable with being accountable for saying yes because... they trust your opinion enough to ask you in the first place? If you say no, chances are they will respect your opinion and suddenly it's no longer about permission because chances are, in a professional setting, they just won't do it because they trust your experience.
- If you work with people who only blame you for failures and don't acknowledge you for success, then it's a different problem? Anecdotal: the last job I had people rarely say "I asked [someone] and they said it was fine” — even if it's said exactly like that it's rarely about blaming someone else but more about adding context so that we can all come together to find a better solution (a lot of things get lost in translation especially when people with less experienced but well-meaning are involved). I do feel sorry for anyone who works in an environment where everyone is just trying to offload responsibilities onto someone else.
- If you're in a position to give permissions, then shouldn't you do that _and_ take some responsibilities for it even when the person asking don't expect you to do so? I don't think it's right for people asking for permissions use that as a means to offload responsibilities, but I also don't think it's right for people who are in the position to authorise someone asking for permission to do something to not hold themselves accountable?
- Following from the above, if someone is asking you for advice, then chances are you are not one to give them permission to do something but they respect your opinions, or they want to draw that boundary extra clear (again, just because someone is asking for permission doesn't mean they want to hold you accountable): shouldn't any reasonable person giving advice still hold themselves accountable for the advice they give?
- There is nothing stopping people who ask for advice from you offloading just as much responsibilities onto you than if they were to ask for permission. People who want to offload responsibilities will always find a way to do that — and it doesn't matter whether they asked for permission or advice.
- If it's not something that someone can just go ahead and do, even if they ask you for advice instead of permission, they still have to ask for permission elsewhere?
It's great if you are in a position of power where people come to you for both advice and permissions. If you're someone's manager then you'd better be prepared to give permissions and hold yourself accountable; otherwise, you'd still better be prepared to hold yourself accountable to the advice you give.
For example, in the US if you can't afford a defense lawyer you get one provided to you. They are swamped and rushed but at least you get a defense in a criminal case.
Now say I want to start a hobby or have a legal question, but can't afford a laywer. Example would be questions about how can I do X or Y as a hobby legally and how do I have fun without breaking the law. If you can't afford a laywer you don't really have any options. Chemistry, and hobby rocketry or similar hobbies you might want to get into but the law is so complex and if your broke you basically have to give up and hope in the future you can be rich enough to afford lawyer consulting fees.
TLDR: if it isn't a criminal case and you can't afford a lawyer then your basically screwed and better off avoiding whatever it was you wanted to know or get into doing.
"I wouldn't do that if I were you."