Suppose I have a low-level job in Peloton operations. Our Phalange
Team must ensure that, before a bike's in-home delivery date is
confirmed, the delivery technician has placed an internal order for a
left phalange. Each of us spends all day navigating between the Sales
app and the Internal Order app.
My daughter tells me how I can automate this. But I never do it. Why?
1. Even if I were 100% sure the coding would be finished in one day,
the daily metrics for the Phalange Team would still signal a problem.
2. It introduces uncertainty. I can tell my manager exactly how long
the manual process takes, but I can't tell her how long it takes to
3. It trades off the mean for the variance. Suppose it handles 99.44%
of the cases but there's a rare bug where it never sends a delivery
date if the Internal Order backend has a timeout error. On average,
scheduling is 90% faster but some customers aren't scheduled at all.
Not an acceptable outcome.
4. If I successfully automate it, all of my coworkers lose their jobs.
Then someone in the process changed things that the scripts did not understand.
Management came running to me upset that this thing I automated didn't work. Being technical support managers most didn't understand (not all but most) that when you change things you need to tell people before the day of and they were quite upset with me.
I had saved them enormous time over several years ... but the result was I really just kept doing the same job I always was, not rewarded, and then the day they changed their processes without telling anyone they got upset with me.
My incentive to automate anything for them ever again was gone.
Current example: I have a script I run for my wife that de-duplicates some data against historical excel files and submits it via an API to Mailchimp, to tag members for a triggered email. I run this manually for her about once a week. It does not alter anything unless I supply the '--go' option. That lets me check the output to see that it makes sense (sometimes they add extra data columns or she forgot to do contact/tag setup on her end).
I absolutely never have the computer run stuff without me watching unless I control the entire process end to end, it's non-critical, or management has requested it officially so I can point to specs when it goes wrong. Usually when I have a semi-automated process that is proven to work, then that's the time to bring it up with management to try and make it more official (if they're not the sort to drown it in red tape).
My scripts ran, then quit as soon as they saw something wonky.
The real result was that they didn't do anything other than check the data.
I had tried to get them handed off to IT for official support but it got lost in the years due to silly politics.
I see software as a new form of literacy, and this argument is, for me, a clincher.
Imagine a world where, you were the reader/writer in the company. And if there was a problem with the letters sent from head office, then because you are the reader/writer guy who does all the writing the problems are all yours
Yes, that is correct, as the only reader writer they are your problems. but the wider problem is why are you the only one?
If you're head of human resources at your company, any human resource problem the company has, is your problem, because you're the human resources guy.
To be fair, most of those departments demand certification to participate in, but if everyone was able to make spot fixes to the companies software, then I'd start demanding that only certified software people be allowed to touch our git repo.
Sorry, bud, that one’s on you. If you don’t understand your users—really get in their shoes and walk around in them—how can you hope to build automation that works for them?
Change is Risk, and here you are trying to sell them on the mother of all Changes. Burn them, they won’t give you another chance.
[And yeah, I know some users will always be obtuse reactionary assholes who blindly reject any sort of change as a direct threat to their status quo. Work to accommodate them—if you can make your solution work for them then it’ll work for anyone—and if they’re just being a petty sabotaging asshole after you’ve done all that then bump the issue with the full papertrail up the management stack. Let their superiors handle their crap; they don’t pay you to deal with it. Take solace in knowing that once all their rivals at smashing it with terrific automation, those backwards losers will be first out their jobs.]
Congrats on finally realizing: Not your paygrade, not your problem to fix.
First rule of automation success: choose the jobs that are amenable to it, not the ones that aren’t. And never forget that people, not machines, are the heart of it.
I feel that a lot people have this exact problem.
There's not a word for it, but there should be. It's definitely an anti-pattern.
In my case, the way I got into "software development" was by automating things in my work. It has a lot of pluses and it looks like delightful magic to people who aren't expecting it. It can bring enormous value in places that desperately need it.
But there's a dark side to it. The dark side is that you find yourself alone dealing with problems using only stuff that you built. Like you said, you're at the focal point when things go wrong. No Q/A, no help-ticket system, no buffer, no one to manage expectations.
To make it worse, your boss, your peers and your PM's eventually find that, all of sudden, their workplace has a mini "software development department" that is integral to the mission. That's kind of jarring if they're not adaptable enough to handle it. If you try to get involved with actual software development folks in other teams, you're shunned because you aren't "really" a software engineer until you prove yourself to them (which may never happen depending on how rigid the org is).
I've find that to make this kind of arrangement work, I have to be willing to be a "one man band" for much longer than I feel comfortable.
Change control is an utter pig in any system, and bad process is bad process anywhere. The difference is that humans, being highly adaptable, tend to dynamically mask defects in manual processes, whereas automation—efficient but utterly unforgiving—reveals those defects for all to see.
“when you change things you need to tell people before the day of and they were quite upset with me”
And this is why we always put things in writing.
In an ideal world, the organisation’s [manual] processes would all be nailed down and documented first, before any automation is introduced. This not being an ideal world, it’s not until the automation is being brought in that anyone stops to think about how things work. Alas, you can talk till you’re blue in the face about how the company really needs to formalize and document all of its change management processes, especially now that automation is in the mix, but you can’t make the bastards do their jobs; especially when they don’t even understand what those jobs now entail.
Thus the challenge in achieving successful automation is not in delivering a task-specific software but in cultivating a more general culture change across the organisation; one that understands that the purpose of automation is not to replace humans but to provide them tools to do their jobs more efficiently. Which means providing those humans the additional information and resources they require to use those tools both safely and effectively, even as the organisation and its processes and requirements continue to evolve.
If software design is about managing complexity, systems design is about managing liability.
You can be the best task automator in the world, but if you can’t protect the greater system—or at least ensure a damn good CYA papertrail—then you should seriously consider if introducing automation at this stage is the right thing to do. Never underestimate the strengths of manual processes, nor the immediate incremental benefits to be had in fine-tuning those first; even as you play the long game in your head.
Management will be pleased and then ask the team to achieve 20-50% more per day because your automation sped things up and now you have more free time to do stuff. This adds stress to the team because the script isn't 100% reliable, and when it fails the team is still expected to maintain the 20-50% more benchmark. Your ass is being burnt to fix the script ASAP, and everyone has to work long hours to hit the "new normal" benchmark.
Oh, and of course, you don't get any real reward for improving the team's productivity because "It's awesome you did this but writing scripts isn't what we hired you to do".
I've lived this guy's life:
And after a bunch of similar experiences there I decided that I'd never work again in a team where management exhibited such behavior. If improving the team's performance adds stress to everyone in the team, I'm not going to automate. But I became an engineer to solve problems and not to pointlessly spin wheels. The only good option: Leave and find another job (which I thankfully did).
The cynical advice here is: automate your own tasks and keep the extra slack you gain from it - unless there's a compelling reason to do otherwise.
I think the flaw with the scenario you described is that your programs are “replacing” these peoples’ “jobs”, when, in reality, we’re building tools that empower them to perform their jobs more effectively.
In the case where we create a self-service option for our customers, such that they no longer need to call in, our ops friends are grateful that we’ve removed a tedious task from their day to day work. From my POV, internal users are as much our customers as external users are.
Of course, there’s a fine line between “empowering” and “replacing”. As our tools become more powerful, we need fewer hours to do a greater number of tasks, so ops’ headcount can scale sub-linearly with the number of tasks they need to complete.
While that gives us a business edge, it also means that we can invest in making our fewer people more generally-skilled, so that we avoid the case you describe (where a person’s job description is encapsulated in a single task, which is eventually automated away). We can also afford to pay them well, and their work is generally more varied and interesting. It’s a clear win for those on the inside.
The only losers are the hypothetical 100 or so unskilled people we’ll never hire or invest in, because our existing 100 are adequately supported. I don’t know a solution to that problem, but it can’t be to hire 200 people and give them terrible tools.
> I think the flaw with the scenario you described is that your programs are “replacing” these peoples’ “jobs”, when, in reality, we’re building tools that empower them to perform their jobs more effectively.
I took this as an attempted refutation of that comments parent based on the anecdotal account given.
I think that the secret sauce that makes our automation “good”, is that we’re growing as a company, which effectively dictates that both the supply of new ops tasks and the magnitude of existing ops tasks are growing along with us.
If we weren’t growing, we’d be taking away work with our automation (instead of clearing the way for more, different work).
Exactly why you automate it on your own time, for your own enjoyment. Then you do your $DAYJOB with tools you created for yourself at a fraction of the energy it used to take.
This, to me, is one of the greatest joys of knowing how to program. It's like a super power.
Especially when it comes to support roles, there's just no way you can take the human out of that equation (as much as Google thinks you can), but you can do a hell of a lot to make the life of those employees much easier by addressing pain points and giving them the tools they need. This isn't just a case of fixing bugs to reduce support calls, but making sure your back-office/admin setup is solid and gives them everything they need.
This way, you're not automating away their jobs, you're enabling them to do it more effectively.
I'm not sure how this might work outside of a software firm, but I've led a couple of teams like this in the startup world and they've easily been my favourite positions.
It seems to hinge on the specifics of how point 4 would play out, which is largely a moral question.
Points 1 and 2 are negative in the eyes of management, and yet point 4 is so overwhelmingly favorable for management (or at least for the company...) that it would eclipse any negative implications of points 1 and 2.
Point 3 can be circumvented, or at least sufficiently mitigated. I imagine this is how well done software automation typically plays out (though I am only imagining here, really): a fallback is set up for customers who don't receive orders (e.g. a number they can call); initial error rate is unknown, but a mysterious timeout occurs after 100 customers; as soon as that happens the first time, the problem is dug into and solved; next error only occurs after 500 - 1000 customers—when it happens, the problem is dug into and solved; this process repeats, rapidly shrinking the error rate into something vanishingly small while only a handful of customers are affected (and not critically so).
Assuming no major flaws in the preceding, everything hinges on the consequences of point 4. If the moral implications are acceptable (e.g. company has other positions for these people), the main upshot of this is just that the company is now spending much less money, and the person responsible for the automation has hopefully been amply rewarded.
If the moral implications aren't acceptable (seems more likely...), then the whole thing is kinda stalemated—assuming the decision maker cares about that sort of thing ;)
A failure of capitalism when less work and more productivity is a bad thing.
You start doing the thing you were doing twice as fast earlier, thus your productivity doubles. Kind of, assuming that the price of your product does not change due to your increased productivity. If the price halves at the same time (e.g due to competitive pressure because you were not the only one to figure how to spend half the time doing same thing) your productivity measured in dollars did not change at all. Weird. You do twice the stuff at same time than before and now I claim your productivity did not change. Makes no sense whatsoever. So did your productivity increase or not? I have no clue.
Even further confusion. Your increased(?) productivity just caused that with same amount of money people can by more of your stuff, i.e deflation. Now, why the heck, given the massive increase in productivity(?) during the last century, we have seen inflation, not deflation? Makes no sense to me.
It looks to me like we would need to have more words for different kinds of productivity. Because at least I am confused as heck what that word actually means...
Also, if your market isn't already saturated, you can even sell more of your product without dropping the price. It really boils down to the fact that selling is what brings money, not producing.
For the employer, the productivity of their capital investment has increased.
You might be able to increase your productivity if you can leverage a salary increase, or figure out how to sell the automation to your employer for more than your salary, or sell it to others.
Because the money supply increased even faster than the goods & services supply.
Goods and services are traded in an economy, but finding a way to exchange A (ex: shoes) for B (ex: chicken nuggets) is such a chore that economic activity is limited. Money is a solution, like a hub city for air travel: the easiest way to guarantee a route between all pairs of nodes in the network. Trade shoes for money, then trade money for chicken nuggets. You're still trading shoes for nuggets, but now it's much easier, which helps everyone.
Everything gets priced in money (say, "dollars"), but if something is mispriced, arbitrage takes place. Buy an underpriced thing for a few dollars, trade it directly for an overpriced thing, then sell the overpriced thing for a lot of dollars. Money for nothin'. But once others catch on, they demand trade terms that give them the profit, changing prices until they can't be arbitraged.
So everything gets priced relative to everything else, and all prices can be expressed in "dollars".
If the maker of dollars decides to increase the supply by a factor of ten and no change in goods & services takes place, You have ten times as many dollars being offered for the SAME goods and services as before. Arbitrage will quickly push all prices to where the goods and services still have the same value relative to one another but their price relative to the dollar has changed by a factor of ten. Everything is "ten times as expensive" in dollars but not in terms of what people really need: other goods & services.
If you make the same number of generic shoes, twice as many generic electronic widgets, and ten times as many dollars, shoes will be traded for ten times as many dollars ("price" goes up 10x), and even widgets go up by 5x, because although productivity made 2x as many widgets, the number of dollars went up 10x.
This is quickly becoming an issue. As industrial output is rapidly becoming exclusively the product of automated systems, the 'worker' becomes irrelevant. The limit is, none of us do appreciable work for standard goods. And since we're not working, we're not getting paid, and we can't afford the goods.
We're gonna need a new system.
(Emphasizing to the business to avoid a tired argument about value really being what the market will pay. In technical econ terms by value I mean the private benefit of the consumer of the automation)
The value of the automated system is clear. The value of the engineer is the automated system. Which might be quite expensive, but nothing like the value of its output.
I called it a tired argument not because it definitely isn't true but because I'm tired of people shutting down unrelated conversations with it to look smart.
A simple scenario that shows these are separate concepts:
Suppose we have an extremely dumb firm that pays the engineer a trillion dollars to create an product that can make whoever owns it a billion dollars.
Suppose we have an extremely dumb engineer that charges a different firm $1 to produce the same product.
Suppose both firms are trying to sell the automation to a third firm. Their expenses are a sunk cost; this firm isn't going to pay the dumb firm that overspent any more. The value of the product is (generally) separate from your cost of making the product.
Of course, I'm sure there are people who did that and then lost their job when their boss discovered they didn't do much of anything any more.
On top of this, Capitalism is what continues to create new jobs, and ensures, for the post part, that you will be able to find another job if you lose your current one.
Moreover, it's not like Blockbuster was known for hiring skilled workers.
Do you believe buggy whip manufacturers should be entitled to their old job even today?
Hence the universal basic income.