[jakewins]

One of my first tasks at Equipmentshare was automating invoice generation, and we did a lot of that basically pair programming with one of the back office specialists that did that work manually - it was super, super fun, we made really good friends, and now, ten years or something later, she’s a manager overseeing whatever systems replaced what we built.

But it was driven by both sides being made clear from the beginning: nobody is losing any jobs here, the goal is to 10x the number of accounts we could do per back office person; their new jobs will be overseeing the software and dealing with edge cases.

I’m not sure this would’ve been possible to do in such a way if the company wasn’t rapidly growing though.

Makes me wonder: what are things that are easier like this in orgs that aren’t in growth phases?

[ChuckMcM]

That is a great example. And yes, if you're in an org where things are "tight" it gets much harder because people will assume the worst outcome is most likely. I've always been a fan of being honest with people, not everyone I've worked for or with shared that point of view. But being consistently honest helps when you're explaining things because it is more likely someone trust you enough to try the change you're proposing. Sometimes that means having the conversation of "Once we're done with this change, the thing you're currently doing won't need to be done. But since we want everyone to have a place after this change, these are the areas that will need help once the change is in place, and we're hoping you would help in one of them ..."

I had an engineer tell me once that the reason they wrote really obtuse code was because "when the layoffs come I'll be the only one who understands it so I won't get laid off!" They were quite pleased with that strategy. I pointed out that they would also never get promoted if their manager couldn't get anyone else to learn their code. This was something they hadn't really considered.