4 ms·

Oh, fire all the heroes, I have worked at one of those places. The people in the know were let go, as some kind of pre-emptive strike of just that nature. Hea

Oh, fire all the heroes, I have worked at one of those places. The people in the know were let go, as some kind of pre-emptive strike of just that nature. Heaven forfend that anyone but the organization have leverage. This was managed before I had a chance to get a Chesterson's Fence view of the processes. The result was not good: deciphering the how of things was bad enough, but the why, the contexts of the decisions was utterly gone. Nobody could say why things were done, and so it was either the old joke about the five monkeys or the Second System Effect. Glorious chaos, the confidence of our clients eroded, terror at making changes that might affect the way things had been, dread of not making changes to cope with extant problems. Thanks, but I'll take the M.A.D. that results from the threat of the nuclear option over someone getting to yank out my heartplug ala Lynch's Dune.

hinkley 5y ago
Yeah I'm not sure that's meant to be taken literally, anymore than I think "If you meet Buddha upon the road, kill him," is an incitement to homicide. The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have yelled "stop" years before and instead things just kept going, far past unreasonable into a first-rate dystopia. If you fire one belligerent hero as an example to the others, you might be able to make it work. But if you have one 'database guy' or 'backend person', odds are very good that they're going to go exactly as fast as they want to go and smile and say 'no' when people ask for major changes that would break up a logjam. If they aren't particularly articulate about why things are the way they are it's easy to get the impression they are running things instead of the titular managers.
- at_a_remove 5y ago
  Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular managers. Haven't we all been through enough "management heard X technology is hot so we are gonna use that" fiascos? Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.
  - deleted 5y ago
    [deleted]
  - lstamour 5y ago
    That assumes the experts are indeed experts and not just saying no to an experienced consultant/contractor that management hired. Though I agree from the perspective that if the system goes down after the consultant leaves, it’s not their problem. I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team… I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution. I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs. As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected. Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.
    - hn_version_0023 5y ago
      How do you handle the case where Technology X is being deployed because the C-suite was gifted Super Bowl tickets to deploy Technology X? I have been in this exact situation. I left the company as a result; kickbacks and graft aren’t my thing.

hinkley 5y ago

Yeah I'm not sure that's meant to be taken literally, anymore than I think "If you meet Buddha upon the road, kill him," is an incitement to homicide. The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have yelled "stop" years before and instead things just kept going, far past unreasonable into a first-rate dystopia. If you fire one belligerent hero as an example to the others, you might be able to make it work. But if you have one 'database guy' or 'backend person', odds are very good that they're going to go exactly as fast as they want to go and smile and say 'no' when people ask for major changes that would break up a logjam. If they aren't particularly articulate about why things are the way they are it's easy to get the impression they are running things instead of the titular managers.

at_a_remove 5y ago
Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular managers. Haven't we all been through enough "management heard X technology is hot so we are gonna use that" fiascos? Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.
- deleted 5y ago
  [deleted]
- lstamour 5y ago
  That assumes the experts are indeed experts and not just saying no to an experienced consultant/contractor that management hired. Though I agree from the perspective that if the system goes down after the consultant leaves, it’s not their problem. I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team… I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution. I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs. As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected. Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.
  - hn_version_0023 5y ago
    How do you handle the case where Technology X is being deployed because the C-suite was gifted Super Bowl tickets to deploy Technology X? I have been in this exact situation. I left the company as a result; kickbacks and graft aren’t my thing.