> …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.
This isn’t particularly helpful advice in domains where unknown unknowns really do appear. Not everything can be surfaced at design time. Having said that, design time is the perfect time to align on rules of engagement for surfacing and managing unknown unknowns.
It’s also possible that it occurs in genuine miscommunications. It happened to me two weeks ago when my team lead had a different interpretation to a doc I wrote than what I intended. Shit happens. There are mechanisms a team can put in place to mitigate these eg: forcing user stories to be clearly enumerated and matched to parts of the design; third party review; definitions and glossaries; office hours for document review. But it does happen.
If this hypothetical scenario comes up with genuinely avoidable issues, is not due to miscommunication, then this seems like a culture problem. If a person’s approval was explicitly requested, given, and rescinded for political or personal reasons, yes that’s when management needs to step in and navigate the team out of those fucked up dynamics.
I don't think your comment makes sense. You're talking about a scenario where, when you ask someone to review your design, their feedback is literally "all good, looks fine to me",but when you present your design to management or you roll out your design them that same person suddenly changes their tune and has all kinds of epiphanies on design mistakes that they wouldn't have made if it's up for them.
Are you really doing the bridge-burning if you call them out for throwing you under the bus?
I 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.
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.
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’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 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.
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.