7 ms·

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 t

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 2y ago
This. I wish I could go back 5 years and teach my younger self this. Eventually burned out alright.
- FooBarBizBazz 2y ago
  > 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 2y ago
I have seen these behaviors only when I work with toxic engineers.
- chipdart 2y ago
  > 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 2y ago
    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 2y ago
      > 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 2y ago
        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.
wiradikusuma 2y ago
> 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 2y ago
  > 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.
  - dangsux 2y ago
    [dead]
  - mewpmewp2 2y ago
    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 2y ago
      > 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.
irjustin 2y ago
> 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 2y ago
  > 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 2y ago
  > 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 2y ago
    Not sure if you're being sarcastic or not but yes it is much nicer to deal with enthusiastic juniors than naysaying seniors.
specialist 2y ago
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 2y ago
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 2y ago
> 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 2y ago
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?
dangsux 2y ago
[dead]
jayd16 2y ago
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 2y ago
  > 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 https://en.wikipedia.org/wiki/Law_of_triviality
  - jayd16 2y ago
    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 2y ago
> 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 2y ago
> 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 2y ago
>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 2y ago
  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 2y ago
  > 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 2y ago
> 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 2y ago
That sounds like the very definition of a waterfall development process.
sesm 2y ago
> 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 2y ago
  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 2y ago
  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.
  - jvans 2y ago
    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

neonsunset 2y ago

This. I wish I could go back 5 years and teach my younger self this. Eventually burned out alright.

FooBarBizBazz 2y ago
> 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 2y ago

I have seen these behaviors only when I work with toxic engineers.

chipdart 2y ago
> 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 2y ago
  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 2y ago
    > 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 2y ago
      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.

wiradikusuma 2y ago

> 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 2y ago
> 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.
- dangsux 2y ago
  [dead]
- mewpmewp2 2y ago
  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 2y ago
    > 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.

irjustin 2y ago

> 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 2y ago
> 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 2y ago
> 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 2y ago
  Not sure if you're being sarcastic or not but yes it is much nicer to deal with enthusiastic juniors than naysaying seniors.

specialist 2y ago

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 2y ago

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 2y ago

> 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 2y ago

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?

dangsux 2y ago

[dead]

jayd16 2y ago

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 2y ago
> 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 https://en.wikipedia.org/wiki/Law_of_triviality
- jayd16 2y ago
  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 2y ago

> 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 2y ago

> 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 2y ago

>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 2y ago
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 2y ago
> 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 2y ago

> 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 2y ago

That sounds like the very definition of a waterfall development process.

sesm 2y ago

> 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 2y ago
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 2y ago
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.
- jvans 2y ago
  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