3 ms·

It’s not US vs Europe thing, though perhaps this mindset is more common in certain countries. Succeeding but not asking for permission will result in a subtle,

It’s not US vs Europe thing, though perhaps this mindset is more common in certain countries. Succeeding but not asking for permission will result in a subtle, but vindictive backlash. Different enough?

wahern 7y ago
I get that there are differences of degree, and I won't argue that backlash might be greater in some cultures than others. But jealousy of someone's fortune, and fear that someone else's success diminishes or threatens your own, are pretty universal. Because I'm the smartest guy in the world, I've had a pretty good success rate at predicting success or failure of internal initiatives, including unofficial initiatives.[1] But when I'm wrong I always cycle between feeling like an idiot, an a-hole, and thinking that I was actually right and misrepresentations are being made. That makes things awkward even if you're not a malicious person. And if you're higher up the chain of command, it's easy to still think that someone's success is derailing your master plan (and sometimes it's even true). In the real world success is rarely unequivocal, free and clear of potential negative repercussions. This is especially true within large organizations. Part of the risk is taking the heat even when you succeed. [1] /s
- nobodyandproud 7y ago
  Would you feel like an a-hole if you weren’t consulted? If so, then is it appropriate to be a bottleneck for every technical decision?
  - wahern 7y ago
    Not, it's not appropriate to be a bottleneck. With varying success, I try to keep my feelings to myself. My point is that emotional conflict will always be there, we just need to be rational about it. Seeking premature validation in an attempt to avoid that conflict, or harboring resentment if validation never comes, simply shifts the burden. I try to follow the Hacker Ethos: he who writes the code gets deference. And I encourage people to write the code. I have literally told developers, countless times, that if they disagree with me or someone else to show me the code. Likewise, I've also let it be known many times even though I agreed with them, without the code their job--our job--is to faithfully execute after a decision has been finalized. Faithful execution doesn't necessarily preclude working on the alternative, but does necessarily preclude revisiting past debate absent changed circumstances. But the key point is that you write the code first; you don't ask for permission first. Useable code is empirical evidence about the strength (or weakness) of an approach. Without empirical evidence why should a subordinate expect any deference? But if the code is there and deference withheld, now you have objective criteria with which to criticize authority. If you have such evidence, focus on that, not the emotional conflict. The emotional conflict is the background to all human affairs; the way to overcome it isn't to complain about emotional failures but to model (as a manager, as a subordinate, as an adult) a focus on the objective. Maybe this was a horrible parenting idea (but if you can't experiment, what fun is parenting?), but I tried to teach my son when he was about 2 or 3 that it was okay to sigh, loudly, when he was asked to do something he didn't want to do as a way to help him reconcile his feelings with a rational decision to do as he's told. And for my part as a parent and empathetic human, as long as he obeyed I shouldn't take offense at the sigh, although the original idea was that over time he would learn to sigh silently out of respect--where respect implies a lack of lingering resentment--and ideally not need to sigh at all. (I hope that's what he's doing because he doesn't sigh so much anymore, though maybe he just learned other coping mechanisms.) Point being, what does it matter if a manager sighs and rolls their eyes and maybe even backstabs a little so as long as they're reasonable in accepting or rejecting a presented (not proposed) solution? More mature managers wouldn't do that, but I've yet to meet the mythical fully matured adult, let alone manager. In Catholic theology that happens, if at all, after death in purgatory; saints are those who by definition managed to attain that maturity before death. I don't think we can expect anybody to be saintly; the reasonable expectation is that someone--everyone--will reliably fall short almost every time.

wahern 7y ago

I get that there are differences of degree, and I won't argue that backlash might be greater in some cultures than others. But jealousy of someone's fortune, and fear that someone else's success diminishes or threatens your own, are pretty universal. Because I'm the smartest guy in the world, I've had a pretty good success rate at predicting success or failure of internal initiatives, including unofficial initiatives.[1] But when I'm wrong I always cycle between feeling like an idiot, an a-hole, and thinking that I was actually right and misrepresentations are being made. That makes things awkward even if you're not a malicious person. And if you're higher up the chain of command, it's easy to still think that someone's success is derailing your master plan (and sometimes it's even true). In the real world success is rarely unequivocal, free and clear of potential negative repercussions. This is especially true within large organizations. Part of the risk is taking the heat even when you succeed. [1] /s

nobodyandproud 7y ago
Would you feel like an a-hole if you weren’t consulted? If so, then is it appropriate to be a bottleneck for every technical decision?
- wahern 7y ago
  Not, it's not appropriate to be a bottleneck. With varying success, I try to keep my feelings to myself. My point is that emotional conflict will always be there, we just need to be rational about it. Seeking premature validation in an attempt to avoid that conflict, or harboring resentment if validation never comes, simply shifts the burden. I try to follow the Hacker Ethos: he who writes the code gets deference. And I encourage people to write the code. I have literally told developers, countless times, that if they disagree with me or someone else to show me the code. Likewise, I've also let it be known many times even though I agreed with them, without the code their job--our job--is to faithfully execute after a decision has been finalized. Faithful execution doesn't necessarily preclude working on the alternative, but does necessarily preclude revisiting past debate absent changed circumstances. But the key point is that you write the code first; you don't ask for permission first. Useable code is empirical evidence about the strength (or weakness) of an approach. Without empirical evidence why should a subordinate expect any deference? But if the code is there and deference withheld, now you have objective criteria with which to criticize authority. If you have such evidence, focus on that, not the emotional conflict. The emotional conflict is the background to all human affairs; the way to overcome it isn't to complain about emotional failures but to model (as a manager, as a subordinate, as an adult) a focus on the objective. Maybe this was a horrible parenting idea (but if you can't experiment, what fun is parenting?), but I tried to teach my son when he was about 2 or 3 that it was okay to sigh, loudly, when he was asked to do something he didn't want to do as a way to help him reconcile his feelings with a rational decision to do as he's told. And for my part as a parent and empathetic human, as long as he obeyed I shouldn't take offense at the sigh, although the original idea was that over time he would learn to sigh silently out of respect--where respect implies a lack of lingering resentment--and ideally not need to sigh at all. (I hope that's what he's doing because he doesn't sigh so much anymore, though maybe he just learned other coping mechanisms.) Point being, what does it matter if a manager sighs and rolls their eyes and maybe even backstabs a little so as long as they're reasonable in accepting or rejecting a presented (not proposed) solution? More mature managers wouldn't do that, but I've yet to meet the mythical fully matured adult, let alone manager. In Catholic theology that happens, if at all, after death in purgatory; saints are those who by definition managed to attain that maturity before death. I don't think we can expect anybody to be saintly; the reasonable expectation is that someone--everyone--will reliably fall short almost every time.