It feels like organizational change is the only constant in Corporate America. Sometimes I actually view this as a good thing: we should always have a flow of change, and trying to hold on to some form of stasis is a bad thing.
At other times it happens due to a change at the top and follows the path of the Three Envelope Joke:
A fellow had just been hired as the new CEO of a large high tech corporation. The CEO who was stepping down met with him privately and presented him with three numbered envelopes. “Open these if you run up against a problem you don’t think you can solve,” he said.
Well, things went along pretty smoothly, but six months later, sales took a downturn and he was really catching a lot of heat. About at his wit’s end, he remembered the envelopes. He went to his drawer and took out the first envelope. The message read, “Blame your predecessor.”
The new CEO called a press conference and tactfully laid the blame at the feet of the previous CEO. Satisfied with his comments, the press — and Wall Street — responded positively, sales began to pick up and the problem was soon behind him.
About a year later, the company was again experiencing a slight dip in sales, combined with serious product problems. Having learned from his previous experience, the CEO quickly opened the second envelope. The message read, “Reorganize.” This he did, and the company quickly rebounded.
After several consecutive profitable quarters, the company once again fell on difficult times. The CEO went to his office, closed the door and opened the third envelope.
The message said, “Prepare three envelopes.”
Whenever there is a big shift, you often see the vision vs. the reality. While showering last night (where my brain does its best work ;) I related this to rock climbing. When you are in a given hold on the mountain you have the vision of where you want to get too. The great views at the top of that mountain will be phenomenal!
But how do you get there? One hold at a time. One choice and a reach to the next hold. If you try to go too far, then you can fall.
Consider a change that so many organizations are going through right now…. the change to customer first. First, the mobile revolution happened and a lot of companies had to innovate with small mobile teams. Then some went for mobile first, but wherever we are now everyone pretty much has to think of mobile. Many of us are pivoting the organizations to not be able platforms, but to be about the customer. The verticals need to give the best possible user experience across all of their screens. Depending on the use cases, different form factors will require various resources (e.g. some products will be 90% of their resource into mobile, others will still do more on desktop, etc). It is all about how the customer best interacts with the product.
You can easily see the vision of vertical teams making the right trade offs on resources and getting experiences to their customers however they want to interface with us.
The reality on the ground right now though may be different. You may have a small number of people who have the mobile skills, and the appetite for mobile is larger than you can offer. You can try to spread out the talent in the verticals, or you can have a core group that is helping the various teams get up to speed in very real terms.
You may have a large application that you want to open up as a platform for the vertical teams to place their customer interactions into.
You may find that there are duplicate efforts where X was done “for mobile” and Y was done “for desktop” and really you want Z which understands all of the needs.
In that case, how you get from X + Y => Z? This is where the rock climbing comes in. Can you envision the intermediate steps to get there? Those steps need to be as stable as possible, and ideally not be huge stretches, but get you in the right direction.
This relates directly to dealing with a code base and systems of code bases. You are constantly “re-org”-ing a code base. Ideally you are a great gardener who can deal with the tech debt often so there isn’t too much of a gap that requires radical change. Ideally your architecture is built to be as available to change as possible. Flexibility is important.
This is also where abstractions are really helpful. Are you able to change out the implementations while keeping “legacy” interfaces? That can buy you time and give you more stable holds that keep moving you up the mountain.
Micro-services can be great for this as you can change out small pieces, and you can even experiment with new technology in small experiments. If you need to aggregate for performance or another need, you can have orchestration layers that help hide all of that.
Sometimes you need to change your tools. You can upgrade your climbing gear, but first you want to try out the new stuff to see if it really does help you, or is it just a new shiny toy that looks fun. Do you want to be someone who is a gear-head to be cool, or do you want to be experimenting with new things all the time but only changing out your gear when you see it providing real value. Your trusty old pick ax that feels so right in the hand may still be the right choice (cough Emacs).
We need to create cultures and teams that take ownership of the climbing process. Someone needs to hold the belay, but how do we share the load and all be excited about the vision so we are happy to do all the work that we need too, to get to the top of the mountain.
Building a 1.0 of a product is the first simple mountain. When you are a large company you become a mountain range. It can enable you to have a huge impact if you play it right, or it can scare the hell out of your climbers.
I am looking forward to some hard climbing, and some great views in 2015.
p.s. I literally got some great views over the holiday in Colorado! Happy new year and may your views be fantastic.