Six-Word Lessons to Think Like a Modern-Day CIO

by Jim DuBois

  58

  Rotate roles for balance and cleanup.

  We adopted a practice to not fully schedule two people per sprint per team. These two are on call for any production issues owned by that team, shielding the rest of the team to complete sprint priorities uninterrupted. When there are no issues, they knock off technical debt backlog items. This also helps people plan their personal lives for when they might be on call for a production issue.

  59

  Complex integrations slow down your progress.

  Simplify releases by using switches to turn on or off new capabilities. Often, this allowed us to decouple dependent releases. One team can release with their capability turned off, then turn it on when the rest releases. This also reduces release risk since capabilities can be turned off quickly if telemetry ever shows issues. Switches are later removed or consolidated to streamline code. Switches can provide for smaller more regular changes to simplify user adoption as well.

  60

  Decision-making: discuss, debate, decide, do.

  Simplifying your decision-making also supports going faster. Help teams understand where you are in the decision process. Don’t waste time debating options or trying to decide before the problem and options are clear. Problems well-defined are half-solved. Once decided, everyone should agree, or disagree and commit, and then move on. Don’t let debate continue after decisions, unless material new information is found. (Credit to Dave Gasiewicz for the alliteration of “Ds”.)

  Chapter Seven

  Transformation is Measured by Business Success

  Just after Satya was promoted to CEO and I became CIO officially, one product group leader came up with a plan to dramatically improve customer support for his online service. He approached me, asking that I move all our customer support systems (for all products) to him so he could iterate more quickly. I liked his goal, but had commitments to other product teams so couldn’t just move everything to him. I committed resources to work with his team to accomplish what he needed. He escalated to Satya, asking him to tell me to move everything.

  Satya’s response changed how I thought about my role. He and I agreed that IT needed to respond at the pace he needed for his transformation. Satya recognized that there was a lot of IT-like work happening across different teams throughout the company, outside the single IT organization that I now ran. He told me my job as CIO was to govern it all, whether it was in my team or not. He told me my accountability was to rationalize all “IT” investments, optimizing at the Microsoft level and “outsourcing” development to product teams if it would accelerate his transformation, without giving up accountability for ensuring we drove to the right outcomes.

  Taking the new charter to heart, we quickly mapped efforts across the company by business process, identifying similar or duplicate investments. A chart was born with business capabilities as the rows, and organizations across Microsoft as columns. We mapped north star visions to the rows, and started consolidating teams by row between columns to accelerate work and eliminate duplication. We knew the chart had limited fidelity in some areas outside my team, but it was directionally right so we didn’t slow down. As I evangelized the ambition, I drew out the chart on whiteboards for audiences across the company, always drawing a smaller green box around my team and a blue box around the whole chart, telling everyone that I now feel accountable for the blue box.

  Our lack of branding skills in IT showed as the name “Blue Box” stuck, symbolizing what we were working to make real. And I did end up moving part of the customer support systems to a product team, though a different one from the original request. We saw an opportunity to combine it with work from windows telemetry to create what is now an Artificial Intelligence (AI) based chat bot available online to help customers around the world. The bot learns from data, including how human customer support people are answering questions, and how customers are responding. It is taking over more and more of the call and chat volume, though customers can always ask for a human.

  The moral of the Blue Box story was that the transformation was measured by real business outcomes in each row of the chart, rather than focusing on the columns of who did what, or how it was done. Leveraging data to help customers get their questions answered, and answered correctly and quickly, or more importantly, eliminating the need to ask in the first place, was just one example of the business value we were driving. Think about what would make a huge impact to help your customers, to help your employees, to transform your products to disrupt your industry, in addition to optimizing your operations. All of this should add to your vision of what you are trying to accomplish.

  There are a few lessons I learned in how we got the rest of the company to change their thinking that allowed us to make progress toward the vision. In the model above, the finance organization was a great ally in looking at all investments across the company and eliminating duplication. Finance is always looking for ways to optimize investments, and they were critical in achieving the empowerment to drive change outside of my direct reporting IT organization.

  Another model was using data to motivate change by recognizing organizations that were quick to adopt. While publishing dashboards to highlight groups across the company that were doing well, we also showed the whole list, not just those doing the best, motivating those on the bottom to improve. For example, when we were trying to make data available for cross-company business intelligence (BI), we ran into some who didn’t want to share the data they had. There may have been a fear of giving up power by sharing their data, or fear that it would be misused, but when we started publishing who was sharing and who wasn’t yet, everyone quickly was motivated to participate, especially after Satya congratulated those who were first to participate.

  61

  Agility is wasted without appropriate results.

  A great culture that supports change, and teams that can work with speed and agility, are worthless if they are not delivering transformative, tangible results. I’m sharing lessons I’ve learned to modernize IT in this book, but it is all a waste without real business success. In this chapter I attempt to define and give examples of success . . . or not success.

  62

  Historical IT metrics aren’t success measures.

  Historically, IT measured success using compliance, uptime, and delivery: on time, on scope, on budget. These are still worth tracking, but should not define success. It’s the wrong incentive for IT to deliver only what is asked of them. Instead, define success based on bona fide business improvement, not IT delivery. And measure end-to-end processes working as expected, not uptime of IT services.

  63

  Engage business to define true success.

  Measuring business improvement is complicated. Some business partners will really understand their power metrics as part of overall company success. Others will optimize for individual team success, even at the expense of the whole company. Push for metrics that define true success, for the company and your customers. This allows everyone to innovate to drive real improvements at the right level.

  64

  Make sure you drive real transformation.

  Digital transformation does not mean going paperless, or building new mobile applications. It is rethinking what you do completely, dropping efforts that are no longer worthy, and prioritizing new and existing growth opportunities that can help you disrupt. It requires new levels of agility and innovation from everyone, and to get there faster, it requires simplifying legacy environments and API enabling everything for agility.

  65

  Expand vision to each company process.

  Build north star visions for each part of your company to connect to the overall vision. This provides focus, and a way for everyone to attach to the overall vision. These “parts” can be cut by major business processes, product lines or experiences, but do not just follow organizational boundaries. Think of all the apps or capabilities for each part as a product that you are improving iterativ
ely. Plan based on the products, not projects. Align visions for these products ignoring org lines, allowing you to understand and eliminate duplication.

  66

  Find new value in existing data.

  Can you combine data you already have to create new value? Is there a business model hidden in what you discard? For example, we had years of enterprise sales opportunity data. We were about to purge it since all the opportunities were long past. Then we discovered the data was useful to train a machine-learning model that accurately predicted success of any new sales opportunities. This opened up many new ideas.

  67

  Predict success and then improve it.

  Big data can make the future more predictable and less uncertain. Spending time on real value here is a reason we want to go faster elsewhere. Once we determined how to reasonably predict success of sales opportunities, we attacked related, but more complicated, AI problems. What actions can you recommend to people to improve the forecasted success? Can you completely automate the whole sales forecasting process to free up sellers to have more direct time with customers?

  68

  Find insights connecting data across processes.

  Marketing pioneered A/B testing, using experiments to determine value. Any analysis of user behavior can create new insight, especially when connecting across processes. Using AI to look at behaviors and actions, we improved our marketing model by connecting marketing-qualified leads all the way through sales to orders. Connecting the end results of a lead all the way through allowed us to improve our model for rating marketing leads, increasing their value.

  69

  Clean up your data for decision-making.

  In driving transformation, ensure you have mechanisms to keep your data clean, improving its usefulness in decision-making. Incent people to share data to speed learning and remove redundancy. Especially share the data that hurts, identifying previously known truths that are actually false. Transformed processes should identify data issues quickly and prioritize fixes in sprint backlogs. Clarify data ownership accountabilities to help drive consistency. Remove process variability first, then set goals to improve the right metrics.

  70

  Optimize the appropriate manual operations tasks.

  In a digital transformation, prioritize what you automate based on what adds the most value, rather than just digitizing all manual tasks. If optimizing one process doesn’t improve the end-to-end process, it should become a relatively low priority unless it is keeping you from scaling your business. Eliminating steps altogether is better than automating them, but improving the end-to-end process is better than eliminating or just automating the steps.

  Chapter Eight

  Accelerate Without Sacrificing Security and Compliance

  In 2000, The Wall Street Journal reported that Microsoft had been hacked. While Microsoft disagreed with the facts of the article, seeing the impact of what could have happened was a wake-up call. Security jumped in priority immediately and stayed there because we started finding more vulnerabilities and needed to change how we thought about security. This priority highlighted new practices, skills and tools to improve security in our products, and our ability to protect ourselves and our customers. Some product teams skipped whole release cycles, dedicating capacity to addressing better security.

  But by 2006, I was frustrated by our slower overall pace, feeling we were not getting the balance right. Security was getting in the way of delivery. When our Chief Information Security Officer left the company, I was asked to take the position. In hindsight, I know I was not qualified. I did not get the job because I was a security expert. I believe I was given the job because I complained the most about security keeping us from going faster. I could hear the unspoken congratulations, “OK Jim, you fix it.”

  I embraced the new team, curious about how I could make a difference. My eyes were opened. I had no idea how easy it was to compromise a company’s defenses, even if they were careful. My new team was looking to me to sponsor what they needed from the rest of the company. I understood how important it was for the future of Microsoft to get this right. I also remembered how frustrated I’d been with security before my eyes were opened. I determined that I needed a mission where appropriate security and great productive experiences could co-exist, where it would be an AND, not an OR. It took a long time to articulate this well to all stakeholders and make progress. The best choice I eventually made was to hire a real security leader, Bret Arsenault, for the team as I took on more responsibilities in addition to the security organization. Bret hired and developed one of the best security teams in the world, even if they do all keep tape over their laptop cameras.

  I was constantly amazed by the team as the world evolved. Microsoft was on the list of most attacked entities on the planet. We played chess with very real adversaries trying to disrupt us, or steal secrets, always needing to keep a few moves ahead. We collected and ingested over 20 billion events a day into our AI based engine to look for anomalies. Modern practices and the cloud were game changers for us to stay ahead. Bret’s team helped design AI based products like Windows Defender ATP for huge steps forward. Like the cloud migration, we learned a lot on the journey, including where we needed to help all our teams better understand security, and build it in from the start. Sophisticated red team/blue team exercises helped us identify new threat vectors, but we continued to prioritize basic hygiene first, and then prepare for more advance persistent threats (ATPs).

  Sometimes the ATP preparation was surreal, like when Satya asked us to release Sony’s movie The Interview on Xbox Live on Christmas day in support of free speech. We prepared to counter a possible attack in response. We knew from forensics of the Sony hack what we might expect. Authorities identified ranges where we should look for an attack to come from. We collaborated on strategy with Google’s security team as they prepared to launch at the same time on YouTube. All of it felt like I was in a movie myself, and all of it was important example to take security very seriously.

  71

  Everyone is accountable for faster security.

  With the sophistication of bad adversaries today, everyone must understand and feel accountable for security. Otherwise one incident can derail all your other efforts. Security teams should help everyone learn to stay secure, not try to do it alone. All teams should work with security teams as advisors. Security is not the enemy of fast when we work together. Only together can we succeed.

  72

  Fast and secure can be complementary.

  Design security in from the start, so it improves speed. Help teams understand how to be secure, so security never slows them down. Empowering teams to use security tools themselves limits the risk of finding security issues too late in a release. Tools such as code review tools can be automated into every test pass during sprint team iterations. Leverage templates and scripts to ensure security controls are active and operating as expected.

  73

  Prioritize security hygiene to minimize risk.

  Ninety percent of security incidents are prevented with focus on good security hygiene. Almost every hack you’ve read about in the news was not some sophisticated attack, but rather was enabled by someone not taking security hygiene seriously. Stay current. Stay patched. Manage strong identities. Encrypt your data. Establish good monitoring, incident management and recovery processes. Leverage templates and scripts to ensure there is no configuration drift.

  74

  Secure important data wherever it goes.

  Network boundaries no longer provide the same protection. Critical data goes every-where on mobile devices and through APIs with partners. Assume your network is compromised. Prioritize protecting data instead. Classify the data. Make sure your controls are designed to protect the data wherever it goes. Isolate as appropriate. Detect when anything is trying to compromise your protections. Practice how you respond and recover quickly.

  75

  Identity is the new secur
ity boundary.

  Network used to be the boundary and I would still consider software-defined networks, but the future focus is strong identity. Include user, device, app and data identities. Implement multi-factor authentication, and plan to eliminate the use of passwords completely. There should be no persistent elevated access for any user. Instead have a simple process to grant temporary access to approved people when they need it. Ensure devices are healthy to enforce strong user identities. Apps and data should understand access restrictions.

  76

  Log everything. Capture all relevant information.

  Security is unique in that you may consider duplication of roughly equivalent security products because they each give you overlapping but not complete views of what is happening in your environments. Log and consolidate every action by users, devices and applications, and every access attempt to data. Timely ingestion of huge amounts of data is solvable today to consolidate all these events. Plan for time to tune out all the false positives.