3 ms·
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 sur
by diatone 2y ago
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 2y ago> 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 2y agoI’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 2y ago> 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 2y agoIt 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 2y agoI 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 2y ago> 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 2y ago“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 2y agoLmao it’s not you
- sigseg1v 2y agoI'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.