The value of navigation

 Times change, and we must adapt to those changes.

• There was a time when software products were packaged, installing an upgrade was a big deal, and the market could only handle a new version every few years. Now products ship daily online.
• There was a time when intellectual property was king, you jealously protected your source code, you stored it in large central repositories, and you built it with enormous central builds. Now customer data is king, open source is shared between companies, and builds are fast and componentized.
• There was a time when program managers planned, developers coded, and testers tested separately for months before release, each discipline having clear handoffs and shared leadership. Now planning, development, testing, and release are continuous, experimentation and validation is done in production, and many testers have switched to become developers or data scientists.

There are two ways to adapt from the current state to the future state:

1. Declare the future state by leadership edict. I call this “bludgeoning.”
2. Lay out a roadmap that allows people, tools, rewards, and practices to reach the destination smoothly and predictably over time. I call this “navigating.”

Bludgeoning is rampant at Microsoft. It’s painful, error-prone, and wasteful. Although bludgeoning usually, eventually succeeds, it often takes multiple attempts. These attempts are not iterations, but failures followed by resets. Guess what? There’s a better way.

Eric Aside

There are also many examples of navigating at Microsoft. Probably the two most famous are Bill Gate’s 1995 Internet Tidal Wave memo, which laid out the steps different groups should take to ride the wave, and Bill’s 2002 Trustworthy Computing memo, which was followed by a paper from Craig Mundie mapping the details.

I’ll take you there

If you want to get from Redmond to Lake Tahoe, you could load up your 1985 Chevrolet Cavalier at dawn, head south without a map, and declare to the kids you’ll be in Lake Tahoe by sunset. Should you get lost in the mountains or run out of gas, you can always stop and ask strangers for help. They’ll provide what assistance they can and get you restarted in the right direction. That is, until you get lost and restart again, stay wherever you happen to be, or eventually arrive at the lake.

Fortunately, today’s cars come with navigation systems. You type your destination into the system, and it provides turn-by-turn navigation until you reach Lake Tahoe. (In 1985, you’d go to AAA and get a TripTik^®.) You can even plan your trip, stopping to see roadside attractions along the way, keeping the kids happy, and breaking up your trip into a manageable vacation. You arrive on time, with your family ready to enjoy all Lake Tahoe has to offer.

There’s no reason to bludgeon your family with a Chevrolet Cavalier. Likewise, there’s no reason to bludgeon your organization with a declaration that everything will be different by sunset, expecting things to turn out okay. Experienced leaders know things are not okay initially, but experienced leaders shouldn’t be bludgeoning in the first place.

Instead, leaders should get a map. Look at where you are as an organization: your staffing, tools, practices, and incentives. Look where you want to be. Then plan the trip from one to the other, involving your team as you go. In other words, navigate. You won’t make it there in a single day. There will be stops along the way. But navigating makes on-time arrival far more likely, with your organization ready to enjoy the benefits of the new world order.

Eric Aside

I talk about the mechanics of driving cultural change in Culture clash.

Men don’t ask for directions

Why do Microsoft leaders (men, women, executives, general managers, directors, and even group managers and architects) resort so often to bludgeoning, instead of navigating? I’m not really sure. Here are my top theories:

• Microsoft of old had a macho, hero culture that continues today. Macho people don’t ask for directions. They are people of action. They just go, and they figure things out along the way. Yes, this is foolish.
• Navigating is a lot of work. You need to study maps, make plans, judge timelines, and collaborate with different groups and interests. Bludgeoning only requires a large blunt object, like an executive edict. In other words, people are lazy.
• People may question your navigation, particularly if the travel time is long. Bludgeoning is much faster. It can usually be accomplished in a few days or a couple of months at most. And if people have never been there, you can arrive at Gravelly Lake near Tacoma and tell them it’s Lake Tahoe. In other words, people are impatient and don’t know the difference. Yes, that’s terribly wrong in so many ways.

Are we there yet?

If you’ve had enough bludgeoning and want to navigate instead, where do you start? You typically consider the longest stretch of the trip first, which most often is staffing or infrastructure.

• It’s staffing if the change involves hiring a different skill set or bringing people up to speed in a new skill area. A good example is switching staff from being testers to being developers or data scientists. You’ve got to map out training and hiring over three to 18 months, depending on the scale and need. This includes a chance for staff to practice on small projects, before raising the stakes on big ones.
• It’s infrastructure if the change requires significant new tools and services. A good example is switching from a packaged product to a web service. You’ve got to map out all the technologies you need (instrumentation, monitoring, experimentation, BI, automated deployment, componentization, data segmentation, global hosting, and certificate management, to name some key ones). Many of these technologies are built into Azure, but many need to be adapted to your team.

Your goal is a roadmap that leads to people being trained to use the practices they’ve learned with the tools required. If the tools aren’t ready yet, there’s no sense in training folks to use them. If the people aren’t trained or hired yet, there’s no sense in expecting the new practices to be followed. You should time out your trip so that everyone arrives at the destination together.

Not what you expected

Leadership direction is also a key part of navigation. There are three critical elements to align: expectations, feedback, and incentives.

• Leaders must make their expectations clear about using the new practices and tools.
• Leaders must provide feedback to the team about how well the change is proceeding and what improvements are still required. This includes establishing key success indicators that you publish as you go, so that everyone sees the progress.
• Leaders must reward those who embrace the change and reduce rewards for those who oppose it.

Incentives are particularly critical long term. If you expect quality work, provide feedback on quality, and then reward people who do shoddy work, you’ll soon get lots of shoddy work.

It’s a matter of physics

Part of directing properly is setting reasonable goals. As a leader, you want to challenge your staff to excel, but not to the point of absurdity. Everyone loves a big hairy audacious goal (BHAG), but strange things happens when that goal is beyond audacious. People lose confidence, motivation, and purpose.

For example, a BHAG would be a Windows device for every child in India. However, if you add the words, “by the end of the year,” it’s no longer a BHAG. It now defies the laws of physics. As a leader, you must know the difference. While some of your organization won’t think through the physics, the ones that do will have interesting reactions.

• Some people will think the leader doesn’t know the physics and will lose all confidence in the leader.
• Some people will think the project is doomed and will lose all motivation to achieve the goal.
• Some people will think the project has already failed, will lose all purpose in their work, and will just mess around with arbitrary side projects instead.

The moral of the story is: As a leader, you should know the physics, or at least have forthright, knowledgeable people advising you.

Taking the scenic route

Sometimes the physics will tell you that you can’t achieve your goal in the timeframe you have. Instead of ignoring the physics and bludgeoning your team, you could navigate to your desired outcome by making stops at a few interesting intermediate goals along the way.

For example, say your organization currently updates your client product and its associated service once a year. The product is installed using an old-school msi, and the service runs on a custom server configuration in a single datacenter. Your BHAG is to convert your product into a universal app that ships monthly, host your service on Azure in datacenters across the globe with daily updates, and experiment extensively on improvements. You’d like to achieve your goal within a year, but trusted members of your staff and experienced friends of yours across the company assure you that a year is an absurd timeframe—you’d be lucky to make the change in two years.

You could ignore the physics and declare, “We’ll do it in six months!” The idea being that your organization will work so hard that maybe it will finish in a year. (Yes, this is a real example, with details changed to avoid making it personal.) The outcome of this bludgeoning is not success within a year—that’s not physically possible. The outcome is a dysfunctional team that’s lost confidence, motivation, and purpose; a dysfunctional product and service that have been victimized by a barrage of sloppy changes rushed to hit deadlines; and employees who have no idea how to update an app monthly or service daily in a sustainable way, many of whom have fled to different teams that have achievable goals. Oh, and you’ve also fallen a year behind in the market.

Instead, you could navigate through a few achievable goals that move you toward your desired destination.

• First year: Host your service on Azure, while making incremental improvements to your client product. Your team will learn important lessons about automated deployment, segmenting of data, componentization of work, and modern data and web services. You’ll see immediate benefits to your existing product, since it will be talking to a more reliable, scalable, and agile service. Your customers will appreciate that improvement, while also enjoying new client features.
• Second year: Update your service monthly, then weekly, and then daily. Incorporate experimentation and more comprehensive instrumentation and monitoring. At the same time, port your product to a universal app. The port will be easier at this point because the app will be talking to a stable and easily updated service. By the time your app ships, your team will have learned all the right habits and built all the right tools to update the app monthly.

This is a reasonable, achievable plan you can share with your team. It’s challenging, but motivating, with a clear path to a better future that everyone can reach together.

Eric Aside

I detail how to roll out changes in Things have got to change: Change management.

An oldie but a goodie

A critical element of scenic stops along the way to your desired destination is making use of what you currently have, both people and technology. You’re not trying to change everything at once. Instead, you enhance bits and pieces at a time, taking advantage of the natural boundaries already in your product and organization.

In the previous example, if you had multiple complicated services, you could stretch out that first year, converting a few services at a time. If you had a suite of client products, you could stretch out the second year, porting individual clients to universal apps as you go. Bludgeoning is all or nothing. Navigating gives you choices, with clear progress along the way to your ultimate destination.

Eric Aside

I juxtapose the allure of starting fresh with the advantages of reusing what you have in NIHilism and other innovation poison.

Posting them to my wall

If there’s a problem with navigation, it’s not that it takes too long (you choose the best route available). Rather, it’s that bludgeoning makes a far bigger impression. Everyone notices the leader with the big bludgeoning announcement. Few notice the leader whose team members quietly modernized their entire infrastructure and reduced their cycle time from months to days.

How do you draw more attention to your successful journey? Post pictures from your trip and share them with your world. Those pictures can be actual photos along the way, but usually they are time-series charts that measure the improvements you’ve made. Share charts that track things like median bug age, time between releases, build speed, customer satisfaction, or whatever your key indicators of success happen to be.

It’s important to determine your key success indicators before you begin your journey. Otherwise, you can’t share your progress along the way and how far you’ve come when you arrive.

Eric Aside

I describe effective measures in How do you measure yourself?

Arrive in style

Change doesn’t have to be all or nothing. Change doesn’t have to be bludgeoned into an organization. Navigating your way to a brighter future together achieves better sustainable results, while making the most of your current people and assets.

Examine where your people, tools, practices, and incentives are today. Consider where you want them to be. Time your journey based on the shifts that will take the longest. Describe your ultimate destination to your team, and determine how you’ll measure your success along the way. Lay out achievable steps that take advantage of natural boundaries and existing assets. Then set off on your journey together with clear expectations, regular feedback, and rewards for those who embrace your direction.

When you arrive, show off the pictures from your trip. Celebrate your achievements, as well as the wonderful experiences you’ve had together along the way. Your team will be stronger, better adjusted to our changing industry and market, and more competitive—ready to take on the next challenge.

Eric Aside

If you’re an individual contributor (IC) or a lead, you can encourage your leadership to navigate by asking basic navigation questions: where are we headed, what are the mileposts along the way, how will we recognize them, and should we expect changes in staffing, training, practices, or tooling?

These questions will help your leaders recognize gaps in their navigation, and prompt them to fill those gaps.