4 ms·
Hiring Failure Tolerant Personalities
- nobodyandproud 7y agoI wish this were true everywhere. I once worked for a medium/large European firm where innovation was frowned-upon if it came from anywhere but the main office. It didn’t matter that this was need-driven innovation, what mattered was that innovation and approval must be top-to-bottom driven, because “obviously” the main office knew best. Any input and obviously bad decisions meant getting rank pulled on you. The ones that thrived and ended up promoted were the ones that played by the book no matter the cost. Awful.
- wahern 7y agoHow is that different than in the US? If you ask for permission at any medium or large firm you're likely to either get ignored or get an earful. That's why the credo is "ask for forgiveness, not for permission". With what little management experience I've had, I get why. First, no matter how open you are to ideas, the moment somebody starts pitching a concept invariably they're making a host of assumptions completely at odds with your own. How do you respond to that? Either by being polite (ignoring) or listing all potential problems you foresee. Second, if they're so sure of their idea why are they talking about in the future tense? Ideas are a dime a dozen, show me results. If you can't show results without being given substantial time and resources, then either the employee or the company is in the wrong line of business. There are plenty of great ideas that are just a poor fit for a company (or team or division). That there's no incremental or other convenient hook to get started is a strong hint that it's a poor fit. People get frustrated because they see a reward but are too afraid to take the risk. They want insurance. Well, if you want reward without the risk then just do the job you're told to do.
- nobodyandproud 7y agoIt’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 agoI 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 agoWould 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 agoNot, 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.