[HN Gopher] Ask for Advice, Not Permission (2015)
___________________________________________________________________
Ask for Advice, Not Permission (2015)
Author : BerislavLopac
Score : 235 points
Date : 2024-08-16 15:38 UTC (2 days ago)
(HTM) web link (boz.com)
(TXT) w3m dump (boz.com)
| andsoitis wrote:
| ...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."
| rnmmrnm wrote:
| "So I deployed that hasty fix on friday..."
| chipdart wrote:
| > ...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.
| diatone wrote:
| 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.
| chipdart wrote:
| > 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?
| diatone wrote:
| 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.
| chipdart wrote:
| > 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.
| FooBarBizBazz wrote:
| 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.
| firesteelrain wrote:
| 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.
| chipdart wrote:
| > 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.
| firesteelrain wrote:
| "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?
| idunnoman1222 wrote:
| Lmao it's not you
| sigseg1v wrote:
| 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.
| diatone wrote:
| 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).
| informal007 wrote:
| 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.
| wccrawford wrote:
| 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.
| latexr wrote:
| > 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.
| ChrisMarshallNY wrote:
| 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.
| ath3nd wrote:
| > 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.
| nntwozz wrote:
| 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.
| chipdart wrote:
| From the article:
|
| > (...) 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.
| neonsunset wrote:
| This. I wish I could go back 5 years and teach my younger self
| this. Eventually burned out alright.
| FooBarBizBazz wrote:
| > 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...)
| evgwugegwhwgeg wrote:
| I have seen these behaviors only when I work with toxic
| engineers.
| chipdart wrote:
| > 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.
| Scarblac wrote:
| 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.
| chipdart wrote:
| > 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.
| watwut wrote:
| 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.
| watwut wrote:
| 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.
| esafak wrote:
| The rules exist to deal with these people.
| wiradikusuma wrote:
| > 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?
| chipdart wrote:
| > 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.
| mewpmewp2 wrote:
| 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.
| chipdart wrote:
| > 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.
| mewpmewp2 wrote:
| 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.
| irjustin wrote:
| > 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.
| chipdart wrote:
| > 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.
| ath3nd wrote:
| > 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).
| IshKebab wrote:
| Not sure if you're being sarcastic or not but yes it is
| much nicer to deal with enthusiastic juniors than naysaying
| seniors.
| SpicyLemonZest wrote:
| 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.
| buildbot wrote:
| 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.
| SpicyLemonZest wrote:
| 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.
| mewpmewp2 wrote:
| 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.
| juliushuijnk wrote:
| 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.
| mewpmewp2 wrote:
| 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.
| juliushuijnk wrote:
| 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.
| mewpmewp2 wrote:
| 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.
| zo1 wrote:
| 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.
| IshKebab wrote:
| > 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?
| juliushuijnk wrote:
| A bit harsh.
| juliushuijnk wrote:
| > 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.
| IshKebab wrote:
| > 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.
| ath3nd wrote:
| 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.
| bee_rider wrote:
| 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?
| IshKebab wrote:
| > 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.
| ath3nd wrote:
| > 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.
| IshKebab wrote:
| 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.
| watwut wrote:
| 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.
| specialist wrote:
| 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.
| shombaboor wrote:
| 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.
| perrygeo wrote:
| > 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.
| hansvm wrote:
| 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?
| jayd16 wrote:
| 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.
| michaelcampbell wrote:
| > 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
| jayd16 wrote:
| 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.
| chrsig wrote:
| > 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.
| dataflow wrote:
| > 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.
| bloggie wrote:
| >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.
| kccqzy wrote:
| 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.
| FireBeyond wrote:
| > 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.
| FireBeyond wrote:
| > 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).
| stkdump wrote:
| That sounds like the very definition of a waterfall development
| process.
| sesm wrote:
| > 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'.
| dartos wrote:
| 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
| pfannkuchen wrote:
| 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.
| elashri wrote:
| 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.
| diatone wrote:
| 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/
| laserlight wrote:
| 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.
| informal007 wrote:
| 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
| Ylpertnodi wrote:
| 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.
| satisfice wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| satisfice wrote:
| I agree that the article is thoughtful.
| NotACracker wrote:
| 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...
| jancsika wrote:
| > 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.
| iambateman wrote:
| 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.
| drdrek wrote:
| Very culture based. In my country giving people unsolicited
| advice is basically a national sport.
| Panini_Jones wrote:
| Which country?
| antisthenes wrote:
| > 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.
| syndicatedjelly wrote:
| > 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
| antisthenes wrote:
| 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.
| lijok wrote:
| You seem to have developed an unhealthy negative
| association with feedback
| la64710 wrote:
| Very opinionated but some times some things are owned for
| accountability and it's good professional practice to ask for
| permission in those cases.
| tmsh wrote:
| 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.
| h4ny wrote:
| > 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.
| zug_zug wrote:
| 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.
| kazinator wrote:
| "Should I make this stapler mine and take it home?"
|
| "I wouldn't do that if I were you."
___________________________________________________________________
(page generated 2024-08-18 23:00 UTC)