3 ms·

Obviously, I don't know the details of the situation, but here's my 2 cents. You're saying that your program is already as effective as your team in the majori

by vorador 11y ago

Obviously, I don't know the details of the situation, but here's my 2 cents. You're saying that your program is already as effective as your team in the majority of cases. I've done my fair share of automation, and very often people underestimate the amount of work required to bring a script to the level of an human (which is normal! You're the person who wrote the script after all). Your script is most likely going to be 30% to 50% as productive as a normal person, at least in the beginning. Another thing to keep in mind is that there's a lot of work that can't be automated. These people may have domain-specific knowledge that you don't have. Very often domain experts take decisions which look like guesses but aren't. What I would do in your place would be to redesign your program to be a tool to supplement humans. You could sell it as such to your higher-ups, and help some of those people keep their jobs. Also note that it's somewhat unlikely to have a massive lay-off happen. Most people will get reaffected to another role or a slightly different mission. Managers don't like shrinking headcount. Finally, don't forget to take credit for this. You've been toiling on this for months after all, on your own. You deserve credit for it.

robzyb 11y ago
> These people may have domain-specific knowledge that you don't have. Indeed. They implicitly apply domain-specific knowledge during the execution of the tasks that you observed. It's great that your tool is as effective as the team in the majority of cases, but the flesh-and-blood are better in the minority cases - and that might be enough to prevent your script from being able to replace them. The minority of cases might actually outweigh the majority of cases. For example - your script might be able to reduce expenses by 80 * 50,000 = $4M/year, but that's not very good if a single mistake on one of the minority cases will cost the company $10M. That being said, it seems quite likely that your script could at least be integrated into their workflow - which is great, and ought to get you big kudos.
jamespitts 11y ago
Definitely, on all of these points. To vorador: You could be overestimating what the software can do, and underestimating what it can do in a more augmentative role. Whether it helps the company at the expense of these workers -- or whether it helps everyone way more -- is all about how you position this software, and how people actually use it. I'd talk to these users more, and be gradual with deployment. Find ways that they can use what they know along with what you have built in order to push the envelope on productivity or even explore unforeseen opportunity. I'd also slow this down and be more deliberate in how you approach and communicate the situation. If you're not careful, you might be the one who gets fired first.
sdenton4 11y ago
Yeah, I work on an Eng team that works very closely with analysts. Basically, you can't build good tooling if you don't have your hands in the data, and analysts are employed to have their hands in the data... You'll do best if you can get the analysts using your tools, freeing them up to find new, useful features, which eventually get worked into the tooling, and so on.
- wavefunction 11y ago
  Not only is this a productive use of automation but a humanistic one. If you can enable/empower other people your solutions will be far more successful than simply trying to bring your existing solution up to parity with the existing domain experts, as far as the job is concerned.

by vorador 11y ago

robzyb 11y ago

> These people may have domain-specific knowledge that you don't have. Indeed. They implicitly apply domain-specific knowledge during the execution of the tasks that you observed. It's great that your tool is as effective as the team in the majority of cases, but the flesh-and-blood are better in the minority cases - and that might be enough to prevent your script from being able to replace them. The minority of cases might actually outweigh the majority of cases. For example - your script might be able to reduce expenses by 80 * 50,000 = $4M/year, but that's not very good if a single mistake on one of the minority cases will cost the company $10M. That being said, it seems quite likely that your script could at least be integrated into their workflow - which is great, and ought to get you big kudos.

jamespitts 11y ago

Definitely, on all of these points. To vorador: You could be overestimating what the software can do, and underestimating what it can do in a more augmentative role. Whether it helps the company at the expense of these workers -- or whether it helps everyone way more -- is all about how you position this software, and how people actually use it. I'd talk to these users more, and be gradual with deployment. Find ways that they can use what they know along with what you have built in order to push the envelope on productivity or even explore unforeseen opportunity. I'd also slow this down and be more deliberate in how you approach and communicate the situation. If you're not careful, you might be the one who gets fired first.

sdenton4 11y ago

Yeah, I work on an Eng team that works very closely with analysts. Basically, you can't build good tooling if you don't have your hands in the data, and analysts are employed to have their hands in the data... You'll do best if you can get the analysts using your tools, freeing them up to find new, useful features, which eventually get worked into the tooling, and so on.

wavefunction 11y ago
Not only is this a productive use of automation but a humanistic one. If you can enable/empower other people your solutions will be far more successful than simply trying to bring your existing solution up to parity with the existing domain experts, as far as the job is concerned.