One time I was asked to create a change management plan pertaining to an effort to offshore supply chain technology work.
This VP had no supply chain expertise, had never been a VP before, and lacked any qualifications for his role other than being bros with the SVP of digital and the CTO from a prior job selling travel on the internet. You’ll remember him from the previous pieces one reviewer called “Unfair, unprofessional, and about someone, a lot of us on LinkedIn know.”
Backstory
With the new VP/CTO came a mandate to offshore software development capacity for the supply chain technology organization.
Offshoring is a very popular approach for new leaders seeking to create performative cost-saving gains. You see, a programmer in Ukraine costs less per hour than a programmer in Seattle.
This is the full extent of the math. Due to many factors relating to distant offshoring, a programmer in Ukraine might produce dramatically less than the Seattle programmer, but we’re never to look at those numbers. Those numbers are the man behind the curtain in Oz. You must never speak of them.
At one point, he asked me to compile a spreadsheet supporting the decision. He reminded me that I should highlight the considerable cost savings.
I asked him how I should quantify the costs of getting their infosec setup and governing their access to important customer PII. How will we measure the return on their efforts? I may even have said, “Presently, we have great difficulty maintaining coherent specification from one side of the 8th floor to the other; how will we manage that when the product org is thousands of miles away and many timezones apart from the development org? “
These were apparently not the right questions.
”Just figure out the loaded cost of a Seattle developer and the loaded costs of a Ukraine developer and put them in the spreadsheet.”
Not sure why he couldn’t have managed that himself, to be honest.
Anyway, one day, he asked me to create a change management plan for the offshoring effort.
Realizing our respective definitions of things hadn’t yet lined up, I asked him what he’d like that plan to look like.
Me: Okay, sure, what do you mean by ‘change management plan’?
Him: You know a plan to manage change for the offshoring.
Me: In what way? What aspects of change management do you want to see reflected in this plan?
Him: Wow, you really don’t know anything about change management.
Me: I know a lot about change management, but I know enough and have worked enough places to realize there’s no one standard for change management, much less what a plan for such should consist of. Change management at Google is not identical to Amazon or Microsoft.
My definition of change management as it would pertain to offshoring would consist of being able to communicate the risks and benefits of this large investment effort in a manner that would help get people on board with the change and/or create a safe forum for people to express concerns that could inform our management of risks in that plan.
Him: No, not that, I worked in project management at Microsoft and I created a change management plan that spanned years and involved many artifacts.
Me: Oh good, because years of artifacts are not what I had in mind; since you did this before, maybe you can show me what that plan consisted of, or if you have the actual artifacts, I can take a look at them and ensure whatever I produce is what you want to see, I’d hate to waste your time by disappointing you.
Him: Never mind, I have a meeting.
<Storms off>
Another time, I was working with an executive who was traveling from California and had tried to stab me in the back a few times. I was putting direct effort into building rapport with her, if nothing else, to slow her hand the next time she was leaping to plunge a knife into my back.
I offered to drive her to the CSM class on the east side. It is a class I took, but I chose to forego the certificate as I’ve never been keen on certificates.
On the drive, she asked me to tell her about some of my past experiences. I mentioned that I’d done a lot of work with several major Fortune 10 retailers and investment bank technology organizations, and she just blurts out, “Wow, you really have no technology experience.”
I said, “I mean, every one of those clients was hiring me due to my extensive technology experience and seeking help with their technology organizations.”
She doubled down. “Well, sure, but that’s not like working in the Valley, not like real tech experience.”
I chose not to remind her that my experience working for nearly a decade at a market-leading startup web analytics company might be how I found myself in the position of being a successful independent technology consultant because, at that point, I realized doing anything but smiling and nodding was going to make her hate me more.
I’ve had so many executives condescend to me that I expect it now. I found it quite hilarious at the tail end of my consulting career. I am now firmly impervious to the slights of technology executives.
”Your boos mean nothing, I’ve seen what makes you cheer.”
Do you know many enterprise technology executives who can tie big-boy shoes or successfully bake a potato; one worthy of following into shallow water? So far it’s a single-digit percentage in my experience. I am also open to the concept that I’m just lucky, and the only ones foolish enough to hire me are avaricious fools.
None of them will read this, because none of them read, but if you hired me, and are reading yourself in my stories, reach out. Let me know how I got it wrong. You won’t though, because you’re not reading this.