Ask for Advice, Not Permission (2015)(boz.com)
boz.com
Ask for Advice, Not Permission (2015)
https://boz.com/articles/advice-not-permission
109 comments
> 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
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'.
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'.
It’s the senior+ SWE’s responsibility to ask those questions at the design stage. If the design was approved without those details, that is a failure by technical leadership.
unless you're in the weeds everyday of a specific problem, it can be hard to ask the right questions. often times the most important details are the ones that are omitted
Yeah, exactly.
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
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
> 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
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 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 think this situation would've happened regardless of advice vs permission.
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.
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.
> bad actors are terrible to deal with especially when they hold power on like a PR review.
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).
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).
Not sure if you're being sarcastic or not but yes it is much nicer to deal with enthusiastic juniors than naysaying seniors.
I am totally sarcastic.
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.
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.
> 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?
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.
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.
> 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
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.
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.
Ok you must work with much worse juniors than me (or have an enormous ego) because generally I find that they are more or less competent but inexperienced.
> 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.
> 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.
> I would say "what's the benefit of that?"
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.
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.
Basically, you want juniors to work on critical components, but do not want the responsibility for the very predictable result of things not working. So, you want someone else to make the decision of assigning that junior and you want seniors then to parachute in to save the day ... while calling them old farts as they are telling you this was predictable and they said so.
The advice isn’t destructive, people applying it in the wrong context is. Engineering companies, software or otherwise, probably should know enough not to take advice from a web dev/social media company.
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?
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?
I used to think that, until my first experience with a 24 hour outage because nobody wanted to tell an enthusiastic junior to move slower. It’s possible and far from uncommon to be so overly critical that nothing can get done. But what I see substantially more often is juniors who don’t understand the downside risks of what they’re doing.
Why was it possible for the junior dev to bring down prod for 24 hours? That seems like your/the organizations failure, not the poor new person. Of course junior devs don’t know the downsides and risks of what they are doing. That’s one of the things you learn on the way to become senior.
Absolutely it was my failure. The junior dev discovered when the project due date was close that a small adjustment was needed to the design. I recognized that this small change was in fact a large change with significant risks, and I should have insisted that we go back to the drawing board and accept we'll miss the deadline.
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.
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.
> 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.
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.
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.
Yeah, I hate to be this person that has to constantly say no and no. Sometimes it's like I will say "yes" just so that everyone would see that I'm not saying "no" for nothing after the consequences.
I'm not saying it's just your fault, but that's not professional and will hurt the quality of your team. It's more fun for all to have less stress in your team. If you are the one responsible for having to say 'no' to things, than you should say no. A 'no' in work context, is nothing personal, it should not be regarded as such.
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.
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'm "that guy" that questions everything, leaving no stone un-turned and no assumption unquestioned. I came to this point after being told that saying "no, here's why" all the time made me "difficult to work with".
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.
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.
> they think you're difficult to work with too.
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.
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.
> they think you're difficult to work with too.
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?
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?
I think you took my comments a bit too literally and out of context. I'm not sure why you felt the need to be so uncharitable and mean-spirited, other than because I decided to have my little side-rant in your sub-thread.
> 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.
> 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.
A bit harsh.
I mean, if I don't say it, then there's no one else to say it. It's saying no to other engineers and to product and leadership as well. Also it's not just about saying "no", but then spending energy and time on why something should not be done. If it stopped after me saying "no" it would be easy enough.
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.
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.
I'd reframe what your task is. Your task is not explaining what should (not) be done, but helping both of you get a clear picture of what the situation (goal, challenge, problems, risk, etc) is.
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.
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 think all of it just doesn't fit very neatly to this type of framework. It's a combination of very many things, different teams, systems, legacy systems, lack of data, bureaucracy, politics, so it is overall just very messy. In many cases it feels impossible to make others understand what the true risks are if they are not intimately familiar with everything that's going on. It's the kind of thing like, not sure, if you've seen Krazam videos, but the one with Galactus (microservices). You kind of have to explain why some simple thing can't be done or some seemingly simple thing is just way too risky or time consuming.
I would actually rather not work on something like this, but it pays more than anything else I could currently get.
I would actually rather not work on something like this, but it pays more than anything else I could currently get.
> 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.
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.
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.
As described, I can't say who's at fault. What is outrageous about having few complaints about a high level design, but many more concrete complaints when there is a concrete implementation?
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.
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.
> What is outrageous about having few complaints about a high level design, but many more concrete complaints when there is a concrete implementation?
This is pure https://en.wikipedia.org/wiki/Law_of_triviality
This is pure https://en.wikipedia.org/wiki/Law_of_triviality
Sometimes its bike shedding, sure. Sometimes the actual implementation has flaws that weren't revealed in the early design. There's a reason we don't use waterfall and calling it an "early design review" doesn't make that better.
> 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.
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.
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.
> 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.
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).
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).
> critical of projects at the design stage but everyone is obligated to commit to the project once it starts to be implemented
Do you mind sharing a concrete example?
Do you mind sharing a concrete example?
> 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.
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.
How is related to sociopaths though?
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.
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.
> How is related to sociopaths though?
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.
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.
I mean the value itself, but also I have never seen someone intentionally steering someone to a wrong path. And then this value to make sense as a way to counter that.
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.
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.
This. I wish I could go back 5 years and teach my younger self this. Eventually burned out alright.
> Eventually burned out alright.
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 don't know if this is a typo or not but it's great.
(B and T are pretty far apart in QWERTY, so...)
>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.
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.
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.
That's not fine. That's an easy way to demotivate anyone. It's also a way to waste resources and make everyone busy while delivering nothing of value.
> it may have turned out to be not as important as originally thought.
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.
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.
definitely seen this. folks review, say nothing, then wait to critique in front of the bosses in a larger session. critique is only good if seen by someone important not in silence.
Hypothetically, could the implementation just not faithfully represent the design, or could enough time have elapsed for some critical detail in the target project to have changed?
I have seen these behaviors only when I work with toxic engineers.
> I have seen these behaviors only when I work with toxic engineers.
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.
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.
I can commit to your design, but if I think it is bad design damm sure I should be allowed to call it bad design. Both before and after the fact. If you create a system where my prior disagreement will be punished, I may choose not to say it prior, but that does not mean I can not speak about it later.
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.
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.
What if I really disagree with the design and the way we're going about the project and think it will fail. But I have been overruled, and have requested to be moved to another project?
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.
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.
> What if I really disagree with the design and the way we're going about the project and think it will fail.
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.
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.
No. In a teams and companies where it is safe to disagree, people disagree openly. If they are not, it is because management or you are punishing dissent. If that is the case, the solution is to stop punishing that dissent.
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.
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.
The rules exist to deal with these people.
Emphatic agreement.
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.
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.
That sounds like the very definition of a waterfall development process.
> critical of projects at the design stage but everyone is obligated to commit to the project once it starts to be implemented
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.
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.
…and when someone asks for your permission (probably because you’re in the person’s management chain), one response could be: “you don’t need my permission, if you think it is a good idea after getting input, go for it. If it turns out to be a bad idea, share your learnings so we don’t repeat the same mistake.”
Isn't it be essential to provide permission to him/her if he/she is in your your management chain?
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.
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.
If they answer is "you don't need my permission", that is permission. Then, and in any circumstance like it in the future.
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.
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.
> 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.
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.
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.
Yep delegation works. It works especially well when it’s matched to the scope the person is capable of exercising competently at, and when the boundaries and context of delegation is crystal clear. I’ve seen mismatches on both sides fail - too little context, employee drifts off into niche useless work (eg: green light to rabbit hole on impactless pet project) or lacks the tools available to succeed (eg: missing stakeholder or path to achieve traction). Too few boundaries, employee goes for grand ambitious changes and gets upset when their expectations don’t match reality (because they weren’t realistically set by the manager).
"So I deployed that hasty fix on friday..."
> …and when someone asks for your permission (probably because you’re in the person’s management chain), one response could be: “you don’t need my permission, if you think it is a good idea after getting input, go for it. If it turns out to be a bad idea, share your learnings so we don’t repeat the same mistake.”
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.
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.
Be careful not to burn bridges so quickly.
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.
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.
> Be careful not to burn bridges so quickly.
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 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 actually don’t have a problem with this because just because it looked good conceptually, doesn’t me it is going to look good before going live. There is a stark difference. It’s not that the people are being malicious or lazy. Everyone sees and thinks differently. This could be avoiding a disaster.
> I actually don’t have a problem with this because just because it looked good conceptually, doesn’t me it is going to look good before going live.
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.
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.
“That’s backstabbing”
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?
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?
I've been accused of being difficult and requiring changes at the last minute but really how it played out was:
- someone asked me to design review on something that was not an area within my responsibilities (turns out their business unit actually has nobody to do code review, so for everything they have to try to steal someone else's bandwidth)
- I review their design and it has a lot of issues. I point them out and we do a few rounds of this. I mention to their manager at their point that I think this might be outside the scope of their skillset. They ensure me that "they are a hard worker and always produce great results". Ok then.
- They go off the radar and then months later they drop an urgent 6500 line PR on me saying they need to get it into this release window. They said it's fully ready to go and tested and they are hoping to merge by tomorrow.
- I go to review it and every 50 lines has totally basic flaws in it like copy-pasted code, using GPL library in a closed-source corporate product that distributes a binary to customers, making sweeping changes to code that will affect other products, breaking existing public APIs with no plan to warn customers; the works.
- I spend a bunch of time explaining all the stuff that they need to rewrite or fix and all the basic mistakes they made. Then after all that, the dev gets sour with me and thinks I'm out to backstab them. If anything, I should be the one that's sour because they dumped this heaping pile of poor code at my feet and are trying to act like it's perfect and that I'm holding them up.
Lmao it’s not you
I’ve certainly had off days reviewing someone’s work and only realised certain feedback later. If I happened to surface that in a meeting with others, and got labeled a sociopath for it, I’d be concerned for sure.
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.
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.
> I’ve certainly had off days reviewing someone’s work and only realised certain feedback later.
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.
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.
It depends a little what the larger culture is at the company and what the stakes are.
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.
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.
One thing I’ve noticed is that people hate giving critical feedback to adults. Often people asking for advice just want affirmation.
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.
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.
Very culture based. In my country giving people unsolicited advice is basically a national sport.
Even if it's prevalent doesn't necessarily mean it's a good idea. There's always diversity in how people react to it - this is even a reason why some people move countries, to escape such things.
> 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.
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.
> I don't care about my manager's feedback, because he's not technical, and vice versa.
This is kind of a crappy attitude to have
This is kind of a crappy attitude to have
No, it's just reality. He knows his job and I know mine.
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.
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.
You seem to have developed an unhealthy negative association with feedback
I always ask my academic supervisor for an advice if I want his permission for something. I present my plan that involve what I want to do and then ask if they think this plan is good and if there is alternative. Usually it is yes go for it. And sometimes it is stupid enough that I get better suggestion anyway.
My last direct request of getting root access on our cluster did not go well. And this was for a good reason.
My last direct request of getting root access on our cluster did not go well. And this was for a good reason.
There is an important exception to this which is where Facebook/Meta sometimes gets into trouble: if what you are planning to do will negatively impact (temporarily or for whatever reason) another person, you definitely need to ask for permission. Only if you are not forcing a person to do something are you alright asking for advice. Coercion with good intentions is the root of all evil.
Great book recommendation that covers this topic and many more like it: Turn the Ship Around, by David Marquet. Highly influential for me when I started managing (and remains highly influential!)
https://davidmarquet.com/turn-the-ship-around-book/
https://davidmarquet.com/turn-the-ship-around-book/
This book was the first thing that came to my mind while reading the article. “I intend to” is a phrase that I find very apt.
My advice would have been not to write this blog post. If the author had asked for my permission I would have said "please, no."
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.
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.
Well, when I read the title, I would have thought the same, but I found the article to have a fairly good motivation behind it.
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.
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.
I agree that the article is thoughtful.
I totally agree with you.
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...
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...
> Ask advice, ask permission, whatever. It'll be okay.
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.
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.
That’s actually fairly good advice. I have always disliked the arrogance of “Ask forgiveness, not permission,” and was expecting something along those lines, but the OP was really talking about the psychology of the communication, and they have a good point.
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.
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.
Are you referring to this quote by Admiral Grace Hopper?
"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.
"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.
Not from her, it wasn't, but it tends to be, in the contexts that I've heard it. It's usually used to justify people making really bad, uninformed, unexamined, and unwise decisions, in a rash manner.
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.
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.
> 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.
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.
When I see big blanket statements of advice, I usually try to "unit test" them to see if they have any value. So I think of wildly different scenarios, and imagine whether this advice is useful, neutral/depends, or negative.
This is one that I can see not going well in a number of those scenarios.
This is one that I can see not going well in a number of those scenarios.
Usually, when I have a good idea, I will ask advise from my manager several times unitll she can't not provide more advise to me and give me with permission that I can start do that, I won't start that without permission. I'm too junior to take all responsibility of whole project or bear the risk of failure
Get with your manager - ask them where your autonomy ends.
Then you can get on with your job, without asking them for 'often advice'.
Those that work for me...i gave them the same 'power' I have. We talk when there's a problem they can't fix.
Very opinionated but some times some things are owned for accountability and it’s good professional practice to ask for permission in those cases.
Is there a list of these sort of behavioural anti patterns so to speak?
> The problem with permission is that you are implicitly asking someone else to take some responsibility for your decision. You aren’t inviting them to participate in its success — permission is hardly seen as a value adding behavior — 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 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.
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.
See this works great until it goes anywhere a potential legal issue.
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.
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.
"Should I make this stapler mine and take it home?"
"I wouldn't do that if I were you."
"I wouldn't do that if I were you."
> (...) 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.