My Company Botched Its Own Outsourcing Plan
If you have fired the entire engineering team you need to be across the details. You need to be sure about what you are doing, the benefits and disadvantages of the actions you are taking.
If you’ve been following this blog, you’ll know that I’ve been laid off along with the whole of engineering to be replaced with outsourced offshore counterparts.
So, when a product manager asked leadership if their new colleagues would be working our local hours or in Indian hours I was actually shocked at the response, even though this would not affect me at all.
“It depends on the contract we signed”
You’d think that would be a basic thing to know before firing half the engineering team, but apparently not.
Bitter? Moi?
Look, outsourcing my job isn’t shocking, and isn’t even surprising.
Every tech worker knows companies will cut costs wherever they can and that we are just technical resources to be deployed where necessary. What is shocking is how completely unready they were for what they just did. No transition plan, no operational oversight, and not even the barest hint of strategic thinking.
If you’re going to fire an entire engineering team and replace them with offshore contractors, you might want to figure out how any of that is actually going to work first. At least that is how I might plan such a change.
It’s not just that I’m a bitter ex-employee, I promise.
Fire People, Hope for the Best
Here’s the thing, my company didn’t just replace us with offshore contractors. They replaced us mid-sprint, in the middle of active work, and with no apparent thought given to what that would do to ongoing projects. They went from:
Our team leading the work
to
Contractors leading the work
…overnight.
Did they sync this change with sprint planning?
No.
Keep Everyone Guessing
At this point, you might be wondering: If they didn’t align the transition with the sprints, how did they plan to hand over work?
Good question. They thought it was a great idea to get the fired staff to train their replacements. They did ask us to act “professionally” in doing so (ha). I think that they didn’t think about how to manage the fallout of the change and just went full on into the change.
When pressed on what the plan was, leadership’s answer was basically:
“We’ll figure it out”
That’s the level of planning we’re dealing with here.
Ensure Maximum Chaos
If you were trying to make this transition more chaotic, I don’t think you could have done a better job than my company did.
They seemed to be gaslighting employees as they went. Management on some level seemed to know that they were taking a risk in replacing staff, but still seemed dedicated in pressing on despite the risks they would bear.
They were (of course) going to lay us off right before Christmas. That meant that you might expect some reduced candace of work and tickets to be completed. Unfortunately, leadership removed any contingency from project plans as “we need to keep going to make sure that the business keeps running”, because new features are the most important thing during such a transition.
Spoiler: I wasn’t there for the fallout. But seeing their level of planning I can imagine that they had the following questions (but I can’t say for sure!).
“Why is there a backlog of unresolved tickets?”
“Why are customers complaining about increased bugs?”
Why are the contractors asking so many questions?”
I think that axing the people who built the system without ensuring the migration plan to those who would replace them were capable was a big mistake. You wouldn’t fire a hospital’s entire surgical team mid-operation and then wondering why the patient isn’t doing well.
I think you’d plan such a thing and make sure you absolutely knew what needed to be done before laying anyone off. Or maybe that’s just me?
Conclusion
If You’re Going to Be This Bad at It, Maybe Don’t Do It at All
I get it. Outsourcing is a business decision. But if you’re going to do it, at least pretend you’ve thought it through.
If you have no migration plan, no knowledge transfer, no structure, and no clue what time your new team is even working… maybe, just maybe, you’re not ready to do this yet.
Instead, my former employer decided to free-fall into outsourcing with the confidence of someone who’s never done a pull request review but is sure they can fix production.
I still think how they handled my departure is much more interesting. So, I’ll save that for another post, but you can bet that it will be going into this in a way you’re going to love.