by Jim DuBois
11
Fast in the wrong direction fails.
Going fast is only useful when there is a clear, compelling vision of where you are going. Not a vision statement, but a rich description that gives meaning to the future, answers the “why” questions, shows how the business will operate differently, how new value is realized, and how teams will operate better together to deliver these outcomes. This clarity on the direction to run allows for more team autonomy and empowerment.
12
Make sure the vision can evolve.
In our dynamic world, this vision cannot be static. It should evolve as you learn. Don’t change it dramatically all the time or you will frustrate people; but when you learn something material, or someone has a great idea to improve the vision, do update it and communicate the change. Ensure there is a process for regularly updating all stake-holders to better manage expectations.
13
Remind everyone of the vision regularly.
Once the vision is clear, even when it doesn’t change, don’t assume that everyone gets it. It needs continual reinforcement for it to sink in. Something stable in a sea of constant change can bring comfort and build confidence. As you build on your vision, and when you update everyone on progress, always start by repeating where you are going.
14
Define what is inhibiting progress today.
One of the best ways to help everyone understand the vision is to encourage a discussion around where you are not like the vision yet. Explain not only gaps between today and the vision, but a list of what is keeping you from getting there faster. Be curious. Get everyone involved, contributing to, and owning the list to ensure understanding.
15
Define how to measure vision progress.
Another critical way to help people understand the vision is to clearly define the business metric(s) that will be used to measure success--not a list of metrics, but the one or two that really define the progress. These should not be IT metrics related to IT delivery, but the business metrics that will measure the outcomes and the company success.
16
Go after the important problems first.
What changes will make the biggest difference in getting you to the vision? Prioritize the big rocks first. Prioritize new capabilities and simplifications. You understand all this, but make sure you factor in some quick wins, and identify experiments to accelerate. Don’t underestimate the value of progress to build momentum and attract more believers to the vision.
17
Clarify the roadmap to the vision.
With a clear vision and view of the priorities, define a roadmap to help people understand milestones along the way. This isn’t a locked plan, and no one should expect to follow it exactly. It includes expected milestones for both adding new capabilities, and when legacy will be retired. Update the roadmap as you learn. Create the detail around features and changes needed next to create a healthy, groomed backlog. Communicate the roadmap along with the vision.
18
Identify, clarify and resolve all dependencies.
Beyond clarity for teams, a primary purpose in building roadmaps is dependency management. Understand every dependency, internal or external, especially where they become a critical path for one of the teams. When vision and high-level roadmaps are clear, most of the time spent managing progress becomes resolving dependencies. Make sure details around next dependencies are clear when grooming the backlog.
19
Make issues visible to all teams.
When there is an issue, the natural tendency is to try to resolve it before anyone finds out. Unfortunately, this doesn’t allow everyone else to react faster, to help each other, or adjust plans. Broad visibility to issues follows the principle that bad news should travel fast. Make sharing the stuff that hurts a healthy part of your culture. The culture should feel negatively about withholding information.
20
Empower everyone to improve the plan.
Everyone can innovate to improve the solution once you have a shared sense of purpose, and clarity on vision, roadmap, and issues. All can find ways to accelerate the plan, including solving issues faster. It’s amazing to see ideas from users that help them achieve results faster, and innovations from developers who now understand why, rather than just coding to requirements.
Chapter Three
Empower Teams to Deliver the Vision
In early 1998, John Connors was CIO of Microsoft. When we told him we were struggling to get the Windows team to recognize gaps in the enterprise version of Windows NT, he arranged a session with Bill Gates so we could give him IT practitioner feedback directly. We explained to Bill where we needed better manageability, where we had to improve security, and why it was impractical to require a person to sign in at the console rather than remotely.
With every point we raised, Bill told us we must be incompetent if we needed the product to be simpler and more foolproof. I was feeling like this meeting was a waste of everyone’s time. That is until the end when Bill turned to the head of Windows and said, “I don’t know why these guys think this is so hard, but we need to make this work for our customers as I bet a lot of them will say the same thing. You need to get your team to fix all the items on their list!”
We left the room on a high. Maybe we were incompetent, but Bill got our points, and the products were going to be better for our customers.
Over the years that followed, Steve Ballmer and then Satya Nadella made a practice of coming to IT for feedback, kicked off by this one meeting. And knowing that the CEO cared about our opinion, appropriate product teams engaged with us regularly to better understand enterprise needs.
Like John did in this example, we should always do whatever is needed to help our teams make a difference. Don’t be afraid to look silly. Find ways to get around blockers. Do what is right to achieve the vision.
21
Remove all governance barriers and complexities.
Once everyone agrees on what needs to happen, make it easier for teams to deliver. Identify everything that is getting in the way and determine what you can remove quickly. Historically, with good intentions, rules were implemented to improve quality and control spending. Often these rules evolved into bureaucracy that doubles and triples what it takes for IT to deliver. Attack the bureaucracy and systematically reduce technical debt to free up more positive delivery.
22
Clarify who gets to decide what.
Decision-making is a great place to start simplifying. Peter Weill, professor at the MIT Sloan School of Management, taught me to simplify governance by clarifying who gets to decide what. When teams understand their boundaries, they don’t waste time reinventing what is already decided. They know where they are empowered to innovate, and where they can leverage and build on contributions from other teams. Good boundaries help people feel safe, avoid waste, and move faster.
23
Help teams adopt everything already decided.
Don’t waste time trying to decide what is already decided. For example, you should have a modern engineering process, but don’t have each team design their own. There is a whole chapter coming up on modern practices. To truly empower teams to go faster, make sure they understand how and why common practices help them. Make them easy to adopt. Don’t just teach the new practices. Like defining the vision, explain why they need to work differently and how it will simplify and improve their experience.
24
Remove layers between IT and business.
Many IT organizations structure account management-type layers between business decision-makers and IT delivery teams. These layers are meant to help translate requirements, but at the speed we need to work, especially to adopt Agile practices, this structure will slow you down. Reallocate these people to more delivery capacity, and engage business subject matter experts directly with teams prioritizing and grooming items in your development team backlog. Trust increases with direc
t engagement and common goals.
25
Remove management layers to improve clarity.
Like in the previous lesson, more layers in management can slow teams down and muddle communication clarity. Again, reallocating middle management to more delivery capacity helps you improve speed and clarity, without increasing costs. The appropriate manager-to-employee ratios vary by role, but fewer layers is critical. Side benefit: middle management is usually the most resistant to adopting culture change.
26
Empower teams to change their plans.
Don’t require teams to get permission to make appropriate changes. Unless it impacts a dependency with another team, allow everyone to update and recommunicate plans as they learn. Include business subject matter experts in the decisions. Regularly help teams resolve dependency conflicts, making sure everyone understands proposed changes, and focusing on what is best for the company and customers.
27
Evolve to future organizational roles thoughtfully.
Modern teams need a different balance of roles compared to historic IT teams. Over time we reduced the number of analysts, generic PMs, infrastructure specialists, testers and relationship managers, while adding people with skills in development, data science and security. And our network expertise changed to focus on internet edge and wireless networks. To reduce anxiety, explain early the future balance. Help employees develop new skills. When people move or there is attrition, outsource to backfill roles that will go away.
28
Govern ALL IT investment including shadow.
Embrace the innovation happening outside of IT. Don’t call it shadow IT. Consider it all part of your scope. Identify duplication. Help with dependencies. Share. Don’t try to move it to IT. Show your CEO and CFO the value of them engaging in, or delegating to you, the prioritization across ALL IT investments. Use Technology Business Management (TBM) to understand where all the investments are. Using a product like Apptio greatly simplifies this process.
29
Ensure activity isn’t confused with progress.
Measure progress toward the vision, not the activities required to get there. Don’t celebrate a release. Celebrate the impact of the release as it achieves the desired impact. Don’t focus on how many experiments failed. Celebrate the learnings from them that are accelerating progress. Don’t reward people for working long hours or for just completing tasks. To better incent behavior, recognize and reward outcomes and learnings that accelerate progress. Do not reward activity alone.
30
Avoid the attraction of shiny objects.
It is natural for techies to be fascinated by new technology. The latest tech can be useful in solving real problems. But not always. Help teams focus. Technology shouldn’t be applied for technology’s sake. As author and Harvard professor Clayton Christensen would say, make sure you are providing a job a customer wants done. Likewise, people may attach importance to highly visible activities within your company. Help teams understand real versus perceived importance by connecting how progress helps the vision.
Chapter Four
Debunk the Myths Holding You Back
In early 2013, I was just returning to my office at the Microsoft Redmond campus when I got a call. It was Kevin Turner’s administrative assistant. At the time, about half the employees at Microsoft reported up to Kevin, and it was not normal to get time with him.
I heard, “Jim, can you come to Kevin’s office right now?”
I answered, “Of course,” like I had any other choice, but then I added, “Can you tell me why?”
A pause inspired a thrill of panic in me.
“He will tell you when you get here.”
I won’t try to explain all that went through my mind on the way over to Kevin’s office.
I soon discovered that our CIO, Tony Scott, had decided to leave the company to take care of a family situation. Kevin told me that he wanted me to play the interim CIO while they conducted a search for the best person for the job.
Suddenly, my peers worked for me. Kind of. Temporarily. It was uncomfortable. Fortunately, I didn’t want the job. My next career goal was to go back into the product groups. So, I pulled my peers together and asked their permission to play the role. I pointed out that we couldn’t afford to lose the momentum we’d started. The company couldn’t afford for us to pause while they found us a new leader. We determined to accelerate our progress, so we could better set up our new leader when that someone was found. We drove a new mantra, “Create tomorrow, deliver today,” recognizing it had to be both at once. I got to evangelize a new narrative to the organization, starting with many beliefs that had to change.
Seven months later, after exhausting other options and seeing all of our material progress, I was asked to take on the official CIO title without the word “interim.” By then I was too invested to say no, and could now start making bigger changes, giving the team permission to break some more old norms.
31
Myth: accelerate what we’ve been doing.
Just doing the same things faster will never gain the momentum you need. For culture and pace to change, you must directly address the problems with how work has always been done. Understand the practices people hold onto as sacred, so you can proactively debunk them. This isn’t easy. People will fight material change. Get key influencers to adopt modern ways of working. Engage the willing. Recognize and reward that behavior so others want to follow.
32
Myth: Going fast will sacrifice uptime.
Fast and uptime aren’t necessarily mutually exclusive. Fast can add risk so you do need to manage the risks better, and ensure you can always recover quickly. Automate provision-ing and release to eliminate manual errors while improving speed. Measure real uptime, not IT service availability. Is the business capability completing successfully? Other than as a method to transition everyone, I don’t recommend bimodal IT (where some go fast while others focus on uptime). Focus everyone on speed AND uptime.
33
Myth: internal businesses are IT’s customers.
There are no customers or suppliers inside a company. Real customers buy or use your company’s products. Trying to create the role of customer internally just creates confusion around the setting of appropriate metrics. Instead, IT must work collaboratively with the rest of the company to deliver for real customers. IT needs to feel as much owner-ship for the business outcomes as their business partners, measuring success with the same business metrics.
34
Myth: the cloud makes IT unnecessary.
Why make all these changes if IT is just going away? Actually, the only people who believe this myth don’t understand the scope of IT and all the new demands on IT today. Sure, many things go away with cloud services. That is good as it gives IT the chance to meet all of the new demands and opportunities. Democratize BI and focus instead on curating data for power users. Adopt SaaS, avoiding customizations except where you really must be unique. Move to the cloud and retire data centers. Leverage AI to improve productivity.
35
Myth: ITIL isn’t necessary with Agile.
As you accelerate, don’t ignore the good principles from historic practices. Do challenge and eliminate bureaucracy, but don’t eliminate ITIL processes completely. You still need change management, incident management, problem management, etc., but simplify and streamline the processes so they add value for fast teams. For example, automation and new cloud capabilities will simplify capacity management while helping to reduce overall risk.
36
Myth: multitasking helps you go faster.
We’ve learned personally that we can’t be our best when multitasking, such as driving and texting. Likewise, when teams attack too many priorities at once, productivity drops and errors increase. Go faster with less risk of error by focusing on the vital few. Pick the most important efforts to do first, taking on new items as they finish. Always make progress. A well
-managed backlog keeps you from ever stalling.
37
Myth: don’t fix what isn’t broken.
Change your definition of broken. Even if something is working well, if it is slowing you down, assume it is broken. You may even need to break some things to make progress, to build momentum, or sometimes just to get appropriate attention. This is especially true for rules that are entrenched in your old culture. Agitate for the right change. Fix everything that slows you down.
38
Myth: control is necessary for security.
This is a common belief, especially around physical controls. Our new reality recognizes that these controls still need to exist, but they don’t need to be in your data centers or only controlled by your people. Ensure controls are still in place, and simplify your security management by outsourcing appropriate controls to cloud providers who have more sensors and controls than you can do yourself. Extend your monitoring, but give up some control to get better security.