Ask HN: Should I deploy my code and lay off 80 people? | Hacker News Reader

Ask HN: Should I deploy my code and lay off 80 people?

82 pointsnowherenice62 comments

Throw away account.

I work as a programmer at a medium sized old school insurance company in the midwest on an internal application which assigns documents to a group of analysts for review. Accurate data is very important but we frequently get missing, incomplete or incorrect data in our claims, insurance adjustments or estimates.

A few months ago I had the opportunity to spend some time in one of our analyst centers to learn how they work. We have a total 80 analysts who review and scrub data mostly based on experience, lookups, cross comparison or simply informed guesses.

I found the work rather mindless and depressing which immediately made me brainstorm how I could automate the process given that I saw most of the same patterns repeating over and over.

So...I spent the next few months after work writing a small component which uses the same heuristics, lookups, guesses and techniques used by the analysts to correct the data. From my testing and comparing already reviewed documents with my output, it's at least as effective as our analyst team in a majority of cases.

So...what do I do now? Do I tell my management and potentially cost 80 people their jobs or do I just keep it to myself? I know some of the analysts are single mothers or people close to retirement.

View on HN

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.

> 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.

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.

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.

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.

The reality is you won't be costing 80 people their jobs. Some might lose but in a lot of cases the analysts will switch duties slightly to first validating your output, then on to finding new issues etc. Some will likely be let go or asked to move to a different position over time but it won't happen immediately.

Either way, progress doesn't stop, so whether you do it or management hires some firm in the future to come do automate the process it will happen.

I know it seems a little cold, but what I found through being a consultant and automating processes like this is that rarely was there any significant layoff of people. Usually instead people get reassigned after some proof that the system works. And more likely the directors and managers of those departments start finding ways to use those people to improve other areas, because they can now, since mundane crap is off their plate.

Historically, extra efficiency does not mean less work, but rather more work.

For example: https://en.wikipedia.org/wiki/Jevons_paradox

What you should do is talk to sales and let them know your company can now handle far more business than before, at lower cost.

I call bullshit on the "potentially cost 80 people their jobs". For any "old-school insurance company", I'm confident there's a hell of a lot higher standard for firing 80 people than some program "at least as effective as our analyst team in a majority of cases" according to some IT guy.

> I'm confident there's a hell of a lot higher standard for firing 80 people than some program

From where do you manufacture this confidence? Insurance is a highly competitive business and we/you know virtually nothing about this company. No financials. No growth metrics. An unknown number of employees. Leverage? No. Cash on hand? nah.

We have a few sentences from a narrator with less credibility than Holden Caufield throwing out some lofty claim that sounds a lot more like a survey disguised as a question, than an engineer wrestling with the magnitude of a breakthrough. I would hesitate before projecting confidence with this little information. There are many hypothetical situations I could imagine that run counter to your appraisal, but I could never get comfortable with them because with no data or info it would be quite baseless.

Caveat, I believe the main post to be utter bullshit. I would assume someone thoughtful enough to build this system would likely have considered this before working for several months on this without consulting anyone in the company. Further, s/he doesn't participate in the discussion at all which is what I would expect from someone wrestling with an ethical issue. They would have likely made a decision and tried to justify and defend it in the comments section.

Sounds like they just whipped up a GUI using Visual Basic and used the IP address to generate the TPS reports using real-time-big-data-pattern-matching-artificial-intelligience-NLP.

Give the software to those 80 people and let them chill out until management finds out. But seriously, if your software does what you say it does, I would setup a SaaS and try to sell it to insurance companies.

This. I wrote some software that relieved admin assistants at a school from having to slog through spreadsheets to find room assignment conflicts. There was no shortage of far less mind-numbing tasks to fill up the time the program saved.

If this scenario exists as OP describes they would likely be bound by IP laws. Possibly having their employer owed the output of software written by the developer surrounding the business, and certainly using proprietary data and information to seed the program with, as well as test it.

During a period of my life I played World of Warcraft. I eventually got banned for botting. After initially feeling anger, I felt free. Who wants to play a game so boring that a robot could do it? The 80 people are probably intelligent and reliable people. They will find something more challenging and rewarding.

A lot of great comments here. Firstly, we have to deal with an uncomfortable truth that software is indeed eating the world. The consequences of that won't be 100% layoffs, but the world will change, we can't stop it, and we have to accept that. I can't add anything to what's been discussed here already (again, a lot of great comments). So I thought I'd just point you to some related stories and other corresponding discussions, one of them a classic.

https://www.reddit.com/r/AskReddit/comments/tenoq/reddit_my_...

https://www.reddit.com/r/AskReddit/comments/vomtn/update_my_...

https://www.reddit.com/r/talesfromtechsupport/comments/277zi...

We should write software to handle the mundane aspects of existing jobs and empower our fellow humans to do more with their time than they could before.

There are three uncomfortable truths that get revealed when we do that:

1. Fewer people would be required to do the work, so layoffs would happen anyway. To what extent depends on the way the software was written and the way the tasks are traditionally done. But it happens.

2. There are people out there who find it difficult to do anything more than a mundane task. Issues of motivation and ability are rooted in personality, upbringing, education, and even mental health. Doing this punishes those people, sometimes fairly, and sometimes unfairly.

3. Among the people who get fired, there is a subset who find it difficult to retrain themselves for something else. They may not have a good life. For another subset, the experience of getting fired is devastating, and unemployment starts a long road of mental health issues. https://www.google.com/search?rls=en&q=unemployment+takes+a+...

If we want to be cold about it, it's survival of the fittest. Having done this type of automation work before, I found that I was uncomfortable with that concept when applied to society, even if it's seemingly true.

I'm probably taking the internet too seriously again but Reddit's tales of fancy are always hard to believe because of the overindulgence of the OPs. Two huge red flags in his story: 1) His efficiency was never questioned. If one employee is taking almost all of the bonus pool, I'd want to know what they're doing different so their peers could benefit. And 2) His boss firing him on the spot. While Dutch law does allow immediate dismissal, it has to be for very good reason like stealing or fraud. Otherwise they need a permit or need to go to court.[0] OP's program wasn't so clear-cut because he was only benefiting off bonuses which were awarded for accuracy anyway. Ignoring that, why would his boss fire him on the spot instead of discussing a program with big benefits like that, especially since it doesn't hurt the boss. Reddit loves to eat up these kinds of stories because it plays to their STEM egos, anti-authoritarian principles, and concept of justice.

Nevertheless, interesting stories in the replies to the stories. Thanks for sharing.

[0]: http://www.access-nl.org/living-in-the-netherlands/working/e...

My gut instinct is that we're providing feedback for somebody's ethics homework. That doesn't make this any less of an important or entertaining discussion to have.

I 100% concur. If you look at PakG1's post above he links several similar Reddit posts. The OP is active in every thread defending their decision/POV.

This thread is silent either because the troll got bored or because they didn't want to influence the discussion as they would compromise the objectivity of the exercise.

Having worked at an old school insurance company I witnessed many cases of inefficiencies that I could fix but they are VERY resistant to change. VERY. Where I was held on to long-standing processes because "that is the way it has always been done" and those people have usually been there 5, 10, 20 plus years. Be very careful suggesting that you will put any amount of people out of a job. Old school companies don't often appreciate someone disrupting the way they have been doing things, especially if they have been in business for a long time. I would approach it as you think you found a way to make jobs easier and more efficient rather than boldly claiming your code will immediately replace 80 people.

If you don't deploy it, eventually someone else will.

I agree that even if it implements perfectly, it's unlikely to mean 80 layoffs (versus redeployments, or using those people for more valuable work).

However, if you don't release this solution chances are the person who does will have discovered and implemented it at a competitor's company - and THAT could lead to a lot of job losses where you work, including yours.

The odds that 1 script will make 80 expert analyst jobs' obsolete aren't big. However, perhaps your script will make their jobs easier, automating the mindless stuff freeing their time for the more challenging stuff. In that case, perhaps in time the department can become a bit leaner, the analyst's jobs get better. The analyst that aren't needed anymore can A) find a different job in the company if they are competent people or B) find work elsewhere of they are not competent people for your organization. Everybody wins.

You should deploy it; you are more likely to gain a valuable lesson in humility than cost 80 people their jobs.

There is some truth in this. Every time I have thought I knew how people would respond to my brilliant ideas, I was wrong.

I fully and unequivocally concur.

80 people probably won't lose their jobs. Some will be reassigned, some retire, others will leave, etc. However, you can probably achieve a significant cost saving. Put together something compelling, i.e. take 5-10 reports put together by people and 5-10 by your software. Ask management to pick the files put together by the team. Show your software is just as accurate.

What you do then is you leverage the heck out of this opportunity to increase your salary. If you can save the company $4M in annual staff expenses, ask (read: demand) for a one time $2m bonus and a $500k increase in salary. Get this stuff in writing. Make sure they can't screw you over and "steal" your system if they don't want to give you a decent bonus. This has value.

Don't talk about money before proving it actually works.

What do you want to do? Do you want to be the lead person adding automation to the analysts jobs? It sounds like you could catapult yourself up a few rungs on the ladder and have a staff working with you to improve the analysts' jobs with automation tools.

You do not explicitly state whether you created this software on company time or with company equipment. If you did it with personal equipment, I'd try to sell it to them. If that's unworkable, you could give the software to them and then offer to be their consultant to keep it working and to add features, at a hefty salary bump.

Ultimately we need to know what you are trying to optimize for: positioning in the company hierarchy, money, ...?

I'm pretty sure OP wrote it for their own personal enjoyment

I'll offer my earnest respect for thinking about your actions in a broad context, and not just looking at the neat code you've written, or the career ambitions which you may achieve by deploying this code, but rather the entirety of the consequences of your actions, both for the other employees in the company, the customers, the shareholders, the general public, etc.

I think that kind of thinking is commendable, and rare, and we would live in a better world if we had more of it, regardless of which path you choose to take in your current situation.

"In the majority of cases"

What happens in the rest of the cases? Does it get them wrong, or does it kick them out for manual review?

What happens when the rules change? (Example: if your data involves ICD codes, there's the recent ICD-10 rollout.)

It needs to fail gracefully, and it needs to allow for whatever amount of manual review/supervision the "old school" people in charge are comfortable with, and for that comfort level to change.

If it doesn't do those things, telling management probably won't get much (except maybe "cool, can you make it actually useful?" or "quit sticking your nose in where it's not wanted").

If it does... that's not what you're there to do. You'll probably still have to fight for management buy-in etc. As an insurance company, they'll probably be against taking unknown risks (like replacing a known working process with untested software someone wrote at home).

If you really want to get them to use your project, you're more-or-less dabbling in a somewhat watered-down version of enterprise sales (minus the enterprise price point, since work-related software you wrote is quite possibly owned by your employer regardless of being written at home during off-hours). Is that something that actually interests you?

> I spent the next few months after work writing a small component which uses the same heuristics.

While not unheard of, I find it pretty peculiar you spent several months of your personal time:

* Developing some speculative software which is very likely to be protected IP from your company.

* Not telling managers you were using proprietary data to build an application for which they are your only possible customers.

* Only after all of the leg work is done building an app to process info do you yourself process the only info you had all along

> I know some of the analysts are single mothers or people close to retirement.

I mean, what were you doing this whole time where this didn't occur to you until hundreds of hours later?

Just casually break out your GUI interface via visual basic, plug the ip address into heuristics, lookups, guesses and techniques[0] and get missing, incomplete or incorrect data?

It's not an impossible task but in several months I find it hard to believe you alone would be able to find the correct address for "Dan Palmer from Kansas" or identify that he moved from the apartment a few months ago. I would assume if you were clever enough to pull this off you would have been forward thinking enough to consider the ramifications.

[0] list of arbitrary nouns related to prediction.

As others have mentioned there's the risk of outlier cases consuming any potential savings on the happy path. But what I think is more important is a potential pitfall involving the company's mission. Saving money is not a core business operation, making money is. Thus the disruption of changing processes and laying people off is often not worth the opportunity cost of creating new products or refining pricing models. Using the $4 million in wages per year conjectured elsewhere, that's rounding error compared to a percentage point improvement in returns when many billions of dollars of assets are under management [as is typical for a big insurance agency].

There's also a role for queueing theory. The 'slack' staffing in normal times can be redeployed in outlier events such as a natural catastrophe that spikes claims and invokes fine print policy terms. Experienced claims reviewers might be considered an in-house form of re-insurance. And insurance companies only survive over the long term because there is re-insurance to pool outlying risks.

Good luck.

Yes. That's your job. Or, you should quit.

People getting laid off is not your responsibility. If it happens, that's a problem with the company.

Empathy. Look it up.

Shouldn't you try and sell it to them? It sounds like your software is worth at least 3 million dollars a year.

Sounds legally fraught if you've already developed it using anything vaguely resembling company time, property or data.

You could always go to your boss and tell him you've had an idea and that you'll need two years on an increased salary plus two assistants to implement it, though. Then spend six man-years implementing what you've already done.

Speaking as a hiring manager I always look for achievements like this when parsing a resume or interviewing a candidate. The best candidates always have a few standout achievements that really grab your attention.

If you had to summarise your time at your current employer to just a few dot points this one will immediately get noticed: - In my own time I developed a system that helped semi-automate the work of 80 analysts. Overall cost savings in year one were X and time to delivery reduced to Y.

You could also look to launch a business around what you have built but it sounds like it may be too small of a niche to just drop into any business without extensive customisation.

We find it's always better to fire people on a Friday. Studies have statistically shown that there's less chance of an incident if you do it at the end of the week.

Why not after Christmas? You avoid the suicide season.

Of course everyone's overspent and used up their holidays relaxing where they could have been saving and job seeking.

Here's some reasons not too.

- You did this on your own time - stop selling yourself and every other programmer short by giving away your work for free. If this could save them X in wages then the software is worth at least double that assuming a two year ROI and if you only sold it to them.

- You're not going to get a promotion or a raise for doing this. If a pat on the back from management is going to be the highlight of your life, go ahead.

I would suggest holding off until you leave. Make it stand alone and generalised. Anything that smells like their IP should be gone or containable in an editable ruleset. Throw out the ruleset you have and make populating it part of the setup and work with them to define their own rules.

License the system as a SAAS at a price that gives them a reasonable saving.

Find more customers and repeat.

You obviously didn't get the reference ;) http://www.imdb.com/title/tt0151804/quotes

No, but thanks for reminding me that I really need to watch it sometime.

Do it. If not you, somebody else will do it, and that may make you repent later on, if you don't.

Not to be insensitive to the loss of employment of so many people. But if its possible to automate the process by you in spare time, then its likely that few others in the company at the top, also know of that possibility, and are just plain busy with other things, to think of it right now. Happens all the time in companies.

What you are looking at as saving 80 people's jobs is also costing customers millions in aggregate. It's pretty clear cut what to do here.

While some jobs may diminish with DevOps, others will emerge These people you will likely be positioned very well for the next job, often with the same company. Companies need their effecient people or they will not be successful.

You can convert your small app to "suggestion engine" to make your analysts work easier. Maybe some review-tracking for their performance report, which is win-win for you, your company and making 80 people life easier.

>80 analysts who review and scrub data mostly based on experience, lookups, cross comparison or simply informed guesses.

Nice to know you wrote IA. Thanks to you for emulating the complete intricacies of the human brain!

You should just ask them to use your tools and sell it internally as a productivity tool. Tell the management that it will increase the output by 10X and they can get 10X more work done in the same time.

If your going to deploy it, you should find a way to capitalize on it. Either create a SaaS or ask for a higher salary.

Just pack up your code and put it away.

What counts in life is how many people turn up to see you off.

Look into your soul. You know what sort of person you are. Are you the sort who needs a pat on the back for being clever (at the cost of the wellbeing of other people), or do you need an inner, private satisfaction that you do the right thing by other people.

It would be different if you were the owner of the company, you would then have different obligations, but you're not.

> What counts in life is how many people turn up to see you off.

If you judge the value of your life based on other people's opinion of you, you will never be happy. We all do it to a degree, but making it the ultimate goal will only lead to failure.

How many great men or woman, who did wonders for humanity (on a micro or macro level), died alone? Many I think, Tesla springs to mind.

Judge your life on how you treat others, for that is someone you can control, not how popular you are at the end (something you can't control).

(Stoicism 101)

My point is that if you hold in your hand the fate of 80 people including single mothers and people late in their career, and you choose to end the income of those people when it is really neither here nor there for you personally, then you are a jerk.

hi nowherenice,

I think you should go ahead and tell your management about your component with a certain mention that it is based on analysts' inputs.

By the time your component is production ready, the management should consider repurposing the existing analysts or give them heads up to find new jobs.

bvenkysubbu (I write automations for my living)

Reducing manual labor through automation is the entire point of your job.

Be smart about it, or those 80 people may decide to lay you off.

You should just quit and build a unicorn.

I would do whatever you feel is in your best interests. Don't worry about the finances or jobs of other people, it's not your responsibility. Also don't worry about the well-being of the company unless you have a large financial stake in it. Who cares if they're wasting money on employing them.

Your role as an engineer is to write code. I wouldn't step too far outside of that. Let management do what they want.

Perhaps you should have gotten a go ahead to do the work. But now that you have done it, demonstrate it to your manager. Present the pros & cons.

Doing so you demonstrate your initiative and abilities.

Then as already suggested, let management do what they are paid to do.

Business is not a social justice exercise, especially not for engineers.

Writing the tools in the first place demonstrate their initiative and abilities.

Present the tools to the analysts and let them see what strengths and weaknesses they find that you can use to refine your tools. Their inter-departmental praise (if such is the case) will lift your ship more than allowing your manager to claim credit for managing you to develop the solution.

>>Business is not a social justice exercise, especially not for engineers.

Says one person.

> Business is not a social justice exercise, especially not for engineers.

Actually, ethics are especially important for engineers, as they are often the ones with the skills to bring about impactful changes to society.

Makes me think the IEEE and ACM codes of ethics should be more known: * http://www.ieee.org/about/corporate/governance/p7-8.html * http://www.acm.org/about/se-code

> I would do whatever you feel is in your best interests. Don't worry about the finances or jobs of other people, it's not your responsibility.

It is his responsibility--I would say duty--to not be a shitty person. Whether or not the ramifications of his actions would make him a shitty person (and while I tend to think, in the case that has been described and assuming the unlikely case that he is right about its impact, it would not, that does not have any bearing on the greater, more important issue that you have stomped upon), it speaks rather well of him that he is concerned about those ramifications upon those around him. The advocacy of unthinking selfishness is one of the worse diseases of tech workers. Were it that everyone in this industry gave such a damn about the people around them, yeah?

Comedy option:

Go to their manager, explain that your software might cause the loss of their department/minions, and instead see if they're willing to pay you extra for your tool/consulting on using the tool/guarantee you won't share your tool.

Everyone can win in this situation.

That sounds more like extortion.

Reply on news.ycombinator.com