THE AGILE CULTURE: LEADING THROUGH TRUST AND OWNERSHIP (2014)

Chapter 10. Case Study

Sometimes you just cannot quite fathom what you signed up for. The interviewing process had lasted a couple of months. This process was something of a joint “tire-kicking.” They did a lot of due diligence on me and I thought I had done a lot of due diligence on them. They had been very clear about the limited role they wanted me, their new CIO, to play.

This e-commerce company had already decided that all new customer-facing applications would be developed outside their existing IT organization. According to them, IT was slow, unreliable, and prone to chaos, could not keep a delivery commitment, and got everything wrong. All they wanted in a new CIO was someone who would get their IT operations and processes in good enough shape to support the new applications that were being developed by someone else. From my perspective, this seemed like a nice, simple job: no new projects to manage (someone from outside the IT organization was managing the outsourced product development projects), no large development staff to manage, no methodology to define and track. I would come in, assess IT’s process failings, implement operational and execution best practices, and let someone else handle the wave of new applications.

Exactly one week before my start date, Mitch, the company president, called me.

“Can you come in and meet with me?” he asked.

“Sure, when?”

“Right now. In fact, the sooner you can get here, the better.”

My soon-to-be-vacated office was a ten-minute drive away. “I am on my way.”

Mitch welcomed me into his office, sat me at his table, took a chair next to me, and placed a spreadsheet in front of me.

“As you know, we decided to outsource our new product development to a local software development company. They have been working on our projects for several months and are still months away from delivering anything. Today, I asked for a report on what we have spent so far.” Hepointed to the spreadsheet. “As you can see, we are spending lots of money and not getting anything for it.”

I looked at the numbers on the spreadsheet—these new projects were running at a burn rate of hundreds of thousands of dollars a month. I leaned back, faced the company president, and asked, “Do they have any projections on when something will be done?”

“No. The project manager is telling me that they keep running into problems.”

I thought for a moment. “Do you trust the project manager?”

“I used to but now I am not so sure. What I need right now is for you to dive into this and figure out what is going on. I know you are not yet our employee but we can’t keep spending money this way. If you have time in the next week, I would appreciate it if you can talk to whomever you can—the project manager, the company doing the work, anyone—just to get a sense of where we are.”

I told Mitch that I would immediately start my analysis and give him, on my official start date, a report of my suggested next steps. As the meeting was ending, I could not help but remind him. “I am happy to do this for you but this does change the terms of my employment?”

Mitch looked a little shocked. “How is that?”

“When you hired me you told me that I would have nothing to do with these development projects. I accepted that and figured that I would do one of two things. If the projects were successful, I would applaud. If the projects were challenged, I would offer my critiques. It seems I might end up doing more—and possibly quite a bit more—than that.”

Because I said this last bit with a smile on my face, Mitch, too, smiled and said, “Just let me know what we need to do. These projects are critical to our success and we need them to go well.”

As I drove back to my office, I thought about how my simple new job was about to change. Not only had I inherited an IT team with low credibility and low morale, I was on the verge of owning an entire portfolio of challenged projects. Where should I start? How was I going to pull this off?

For my next step, I met with Kevin, the manager of the troubled projects. Because I am a pretty matter-of-fact person, I asked, “Mitch thinks these projects are in serious trouble. Are they?”

Kevin replied, “Mitch does not have a lot of experience in large software projects. He doesn’t understand that there is a lot of preparation work we have to do before we can actually produce anything. We spent a lot of time and money writing up the requirements and then validating them.”

In the back of mind I started thinking, “Okay, they have decided to use traditional software development methods. We are going to create requirements documents, get them approved, and then start building software—which is fine as long as the requirements never change.”

I then asked, “Have the requirements changed very much since you started?”

Kevin answered, “Yes. We did our initial requirements documents and then used them in a series of internal focus groups. The focus groups changed quite a few things and so we updated the requirements. We then used the new requirements with a small group of customers. They gave us lots of really insightful feedback and so we updated our requirements again. That is where we are now.”

“So while all of this requirements gathering, creating the requirements documents, getting feedback, changing the requirements documents, getting more feedback, and then changing the requirements work was going on, what were the contract software developers doing? It seems from the monthly costs that they were doing something.”

“The developers were working on the product. We have really aggressive timelines on this project and so don’t have time to not be working.”

Now I was starting to get really depressed. We had wasted months of time and lots of money on “churn”—people working hard but not getting anything meaningful done.

My next stop was at the offices of the contract software development company that was doing the bulk of the work on the new products—business analysis, documentation, architecture, software development, and quality assurance. I met with the company president, his chief architect, their project manager, lead business analyst, and the vice president of sales.

I started by explaining the reason for my visit. I was trying to get a handle on the project’s scope and deliverables. The assembled masses gave me an overview of their company and what work had been done. I started to ask some of my deeply probing questions:

“What software development methodology do you use?”

Having done some research into my background, they proudly answered, “Agile.” This is an iterative methodology.

Hmm. Agile. Yet they are developing massive amounts of throw-away code and have delivered nothing. How could or should I ask my questions without offending the group? After all, I might need their resources to get some real work done.

“Agile? That is great. That will really help me understand the current status of the projects. Can you show me the current iteration plan for one of the projects?”

They all looked at each other. Finally the chief architect answered, “We are in the process up updating our iteration plans and so don’t really have anything to show you.”

I replied, “That makes sense. If you are updating your iteration plans, you must be doing so from your project backlogs. Can I see one of your project backlogs? That would really help me understand the scope of the projects.”

Again, silence. The business analyst eventually answered, “I can get you the requirements documents.”

“Thank you. That would be fantastic.”

The business analyst left the room and came back a few minutes later. “Sorry,” she said, “I had to wait for the printer to warm up.”

She handed me a short stack of paper. I took the first document, opened it, and started to read. It was very high level. All it described was the purpose of the application and intended audience. No pictures. No wireframes. No story maps. Just words about some nebulous product concepts and goals.

I tried not to look too stunned. “Is this what you are using to guide the architecture and development?”

She answered, “Well, not really. But it is our starting point.”

“Can I see something a little more developed than the starting point?”

She gave a somewhat disgusted sigh, “We are using Agile. We use these documents to get things started and then the development teams start coding.”

I thanked them for their time and drove back to my office. Now I was not only depressed but overwhelmed. A couple of days before I even started my new job, my list of issues now included:

The IT team has no credibility.

The IT team has no morale.

The company has a large portfolio of software projects that are critical to its success and has outsourced those projects to a company that thinks Agile is a license to produce nothing.

The new projects are heading toward complete failure.

I now own this mess.

I wonder if it is too late to get my old job back.

I was supposed to start my new job on Monday. I asked the company president, Mitch, if I could meet with him on Friday to give him my report. Given his anxiety about these projects, he carved out some time in his schedule.

I gave him a quick rundown on the issues. Most of the work that had been done was wasted. The best thing to do was to start over. He could keep his current project manager and the outsourced development company but he needed someone to rigorously guide their work—otherwise the chaos and waste would continue.

Mitch reflected for a minute and said, “That is what I thought was happening. I am glad you are here. I need you to provide that guidance.”

“But,” I said, “My role with these projects was to applaud their success or critique their failure. I have plenty to do just to get the IT team in shape. Don’t burden me with this.”

This time Mitch was the one who smiled, “If not you, who? If not now, when? We have to get these projects right and we have to have a functional IT team. I will see you on Monday. Please let me know if you need anything from me. I am glad you are here.”

Thus started what became one of the most challenging and gratifying roles in my career. As I now describe the actions we took, reflect on the Trust-Ownership Model, as it was our operating system for everything we did. For each issue we encountered, for every opportunity we identified, we handled it by asking ourselves how it would affect or how it would improve trust and ownership.

With a better understanding of the project portfolio nightmare I faced, I now needed to better understand the issues with the IT team. I inherited the typical IT organizational structure. There were directors of software engineering, quality assurance, service desk, release management, program management, and operations (system and network administration). I also inherited 17 open positions in the department that we could not fill (but more on that later). I spent my first several days doing nothing but talking with people. I did not say much. Instead, I asked open-ended questions like: What do you think the issues are? What do you enjoy about working here? And my personal favorite, if you could change one thing about life in IT, what would it be?

As a result of these conversations, I wrote down my thoughts as to the reasons for the low performance and morale:

The former CIO had been not just a micromanager but a tyrannical micromanager. He did not just insist that things be done his way. If anyone made a mistake, he threatened them with losing their jobs.

As a result of the tyrannical micromanagement, everyone was defensive and looked for ways to shift blame to someone else.

Some of the processes required by the tyrannical micromanager simply did not work. Most people knew these processes did not work but remained obedient lest they get fired.

No one in the department had any idea as to the goals and priorities of the company. Not one of the IT directors could tell me what mattered to the company. They came to work, did their jobs, and went home. There was no ownership and no passion.

On top of all that, I also owned a portfolio of failed projects. Where in the world should we start?

It was clear from my spending one-on-one time with people that trust and ownership were nonexistent. Individual initiative had been beaten out of everyone—at least those still in the department. But how could we improve trust and ownership while also fixing some of the process issues that were killing our credibility?

For example, we did two production releases of our staff- and customer- facing applications each week. Our process for testing and validating the software prior to release was so bad that at least one of these releases always failed. It was nice that we were releasing new features and enhancements twice a week but what would you think of an IT department that, when they gave you a new version of your mission-critical application, brought your system down? How much credibility would they have if this happened each and every week? How much would you trust them to work on your new projects? It was no wonder that the company had decided to outsource its new projects to someone else.

In prioritizing what had to change, I started with our production validation and release process.

On the Tuesday of my first week, there was a production release that failed. I let the team scramble around to fix the problems with the release but scheduled a meeting for Wednesday.

I started by doing something very important. I did not look for anyone to blame. I did not yell at anyone. I did not express any disappointment. Rather, I asked two questions:

Are you satisfied with our current production validation and release process?

If not, what would you change to make it better?

Now, over the years, I have learned to master production validation and release. I am really good at the best practices way to flawlessly get any change to any system into production. I could have told them exactly how to change the process so they would never again have a problem with production release. But I had two goals: to improve our process performance and build a high-performing IT team. I could achieve the first goal if I told them what to do but not the second. And if I told them how to implement a best-practice production release process, it would be my process and they would never feel any ownership for it or its results.

At first, it was hard to get them to answer either of these two questions. The tyrannical micromanager had never asked their opinion on anything. But I persisted and refused to give them the answers.

The director of quality assurance, Tom, who had been with the company for only three months, finally ventured an answer:

“I think we can do it better.”

I interjected, “If so, what could we do differently?”

Tom continued, “One of the problems is that our test and staging environments don’t match our production environment. When we do testing, we don’t test against the conditions of the production environment.”

The director of operations, who, in theory, owned the test, staging, and production environments, thought he was being blamed and shot back with, “The developers make changes to the test and staging environments and don’t tell me or my team what they did. Unless you give me complete control of those environments, I cannot be responsible for what happens.”

The legacy blame culture was emerging, so I jumped in, “None of you know me very well but let me tell you something that really matters to me. I honestly believe that it is impossible to learn and improve if we blame others. As soon as we feel blamed, we get defensive. As soon as we are defensive, we close ourselves to new ideas. I want you to do me a favor. If you ever see or hear me blaming anyone, call me on it. I work hard to not blame anyone but it sometimes slips through. As a recovering blame-oholic, you are my support team.

“Now, let’s get back to talking about how we can improve our production release process. It seems one of our opportunities is to get better at synchronizing our test, staging, and production environments. I suspect that is something we will have to get better at over time. Are there things we can do now?”

The director of release management, Sue, offered, “If the environments are not synchronized, we have to be more rigorous in our testing.”

“Do we require that all of the changes be tested before they are promoted into production?” I asked.

“We suggest it but don’t require it. When we talked about it before, we decided it would slow things down too much.”

The quality assurance manager now said, “Is it better to do things fast or to do things right? It seems our biggest problem is releases that break. Think of how much time we spent yesterday afternoon trying to fix the broken release. I would rather do it right and not go through the weekly panic we do now.”

I looked around the room and sensed general agreement. “Okay. Are we saying that one of rules is that we don’t push untested changes to production?” Everyone agreed and so I asked, “Is there anything we should require? What if the change was tested but still, for some reason, breaks?”

The group was starting to get the hang of thinking. Someone answered, “When something does break in production, it is a huge pain to figure out how to either fix or reverse the change. What if there had to be a way to roll back the change?”

“Is it reasonable to require a roll-back plan as part of the release planning? Or will people think we are just trying to discourage changes?” I asked.

The director of software engineering said, “Anyone can define how to reverse a change—this is not a big deal.”

And there we had it. The group came up with the plan for how to improve one of our most nagging process and performance issues. And they owned it because it was their plan. I offered my full support and asked them what I could do to help the new process succeed. All they wanted me to do was to turn down anyone who went around the process and came to me directly to beg for an exception. For me, that was an easy commitment to make.

Within one week, we no longer had any failed production releases. Our internal and external customers were shocked and delighted.

As an aside, about eight months later, one of our supposedly fully redundant network service providers suffered an outage that affected us. That was the first outage we had experienced since we changed our production release process. Our credibility had grown so much in those eight months that everyone assumed the outage was due to something beyond our control—we were the IT team whose production systems never failed. The organization was gaining confidence in us.

A few months before I started my new job, the company had conducted an employee satisfaction survey. The IT department had scored the lowest of any company department on this survey and so I knew there were plenty of internal issues we had to address. In addition, the survey asked everyone in the company their satisfaction with the various support departments—Human Resources, Accounting, Maintenance, and IT. Once again, IT had the lowest customer satisfaction score. Not only did the IT staff hate life, everyone in the company hated IT.

I knew I had to grow the ownership in the IT team to improve both our internal culture and our project results and customer service. Because I wanted to introduce myself to the entire team, I scheduled a meeting—lunch included—with the entire department. I gave everyone a short description of my background and then explained the things that mattered most to me:

Building a high-trust, high-ownership culture.

Delivering what mattered most to the company and doing meaningful work.

I told them that I wanted to do a potentially crazy exercise. If it was a complete failure, we would eat lunch and forget it ever happened. If it worked, we would develop an action plan for building our high-trust, high-ownership culture and then eat lunch.

We were in a large conference room filled with round tables. Naturally, people were sitting together, by department, at the tables. The operations team was in the far back of the room. The quality assurance team was at the front. The software developers were in the middle. I distributed pens and stacks of sticky notes to each table and described what would happen next.

“I want you to use your sticky notes to answer a question. Write one answer on one sticky note. Every idea you have deserves its own sticky note. Now, the question I want you to answer is:

‘If you could change one thing about life in our IT department, what would it be?’

Remember, one answer per sticky. Go!”

I let them work for a few minutes. Some people wrote down one or two answers. Others wrote down dozens. When everyone had at least one answer, I told them what came next.

“I want you, one person at a time, to come to the front of the room, read what is on your sticky notes and stick them to the wall. You don’t need to explain your answers; just read them out.”

With some prompting, the first few people walked up, read their answers, stuck their notes on the wall, and sat back down. Soon, there was a line of people waiting to read their answers. I begged people to move quickly, as this is usually the most time-consuming part of this collaboration exercise. The answers included things like:

Poor facilities.

Too many interruptions.

No priorities.

I want to work from home.

Get paid more.

Kill the outsourced projects.

The next step in their collaboration process was, in silence, to group all of these answers into common concerns and opportunities. I asked anyone with a passion to come to the wall—the wall that was now covered in sticky notes—and, without saying a word, group the answers. I reminded everyone that if they trusted the people doing the grouping, they could stay where they were, but if they wanted a voice in the grouping, they should come forward. Eight people stepped up quickly and completed the grouping. I only had to remind them a few times about the “group in silence” rule.

When they finished, we had four logical categories. These were

Working Conditions (office space, gym facilities, work from home, et cetera).

Prioritization (what matters most, stop the interruptions, project inception, project trade-offs, et cetera).

Internal Processes (agile or waterfall, project management, automated testing, et cetera).

Career Development (training, pay, promotions, cross-training, et cetera).

With the reminder that we would soon serve lunch, I put the resulting categories on each wall of the room. The Working Conditions sticky notes were on the wall behind me. The Prioritization category was on the wall to my right. And so on.

I described what would happen next. “If you have a passion for identifying ways to improve our working conditions, I want you to come to the wall behind me. If you have a passion for changing how we do prioritization, go to the wall to my right. If your passion is internal processes, back there. If it’s career development, over there. When you get to your category, I want you to once again use sticky notes to write down every idea you have for improving that category. And remember, one idea per sticky note. One last thing, because you are sitting by department, I would love for you to work with someone outside your department on this next part of the exercise.”

Chaos ensued as everyone moved to the category of their choice, but they were soon hard at work on generating ideas for improving their category. When everyone was done, I asked them to group their improvement ideas in silence. When that was done, I added a wrinkle.

“Now I want you to vote on which of your subgroups are the highest priorities in your category. To determine the number of votes you have, take the number of subgroups in your category, divide it by three, and round up to the nearest whole number. If you have seven subgroups, seven divided by three and rounded up to the nearest whole number is three. Thus, each person gets three votes. You can use all of those votes on one or spread them around. What you cannot do is sell your votes!”

Within a few minutes, each team had its category prioritized. I asked each team to nominate a spokesperson to review the top three improvement ideas in their category. I then led them through the final step.

“We have four categories and a total of twelve improvement ideas. I now want you to vote on which of these improvement ideas are the most important to you. Because there are twelve improvement ideas, how many votes do each of you get?”

Being the smart IT professionals that they were, they were quick with the answer, “Four.” I congratulated them for the answer and they voted. When the dust settled, we had a short list of high-priority improvement ideas:

Get good at agile software development.

Force the company to prioritize our work.

Give us more money.

Give us flexible work time.

Pay for training and certifications.

Now, I did not want to be the person who owned these improvement initiatives, so as lunch was being delivered to the back of the conference room, I announced, “Our last step is for anyone who has a passion for implementing these ideas to raise your hands. Who wants to implement getting good at agile software development?”

A few of the software engineers, quality assurance engineers, and project managers raised their hands.

“Okay, who is your team leader?”

They looked at each other and finally one person, Tim, timidly raised his hand.

“Tim, you get this team together and develop an action plan for how we will get good at agile software development. If you need help with the elements of an action plan let me know. If anyone else wants to participate on this team, please get with Tim.”

I then did the same with the others ideas and asked everyone to get their lunch.

After the meeting, I met with the team leaders to answer any questions they had about their role. I told them that we would meet as a combined group once a month to conduct various departmental business (and eat lunch together). During this meeting, I asked each team leader to give a report on the status of their projects to improve life in IT.

When I met with the leader of the “Give us more money” team, he asked how likely it was that we could ever convince the company to pay the people in IT more money. In other words, was his team living in a fantasy? I asked questions to probe why money was such a big issue. Were we paying that much less than market rates? Or was money a placeholder for other, poor working conditions? If so, what were they and what could we do about them? I tried not to give him any answers. Instead, I asked him to look beyond the symptoms to see if there was a different root cause.

Some of the people in the IT group thought that this entire exercise was a waste of time—nothing had ever changed and nothing would ever change. I accepted this attitude. Behavior and culture change is long, hard work. All I could do was what I could do. I should not expect that everyone would join me on this journey—I just needed enough to get a critical mass.

But I had laid down my markers. We were all accountable for changing the culture of IT. Everyone was an owner in this transition. And I was not the person with all the answers. I was turning over a lot of trust to the teams. One team was going to define how the company would prioritize IT projects. Another would define and implement a flexible-time policy—in a company that thought that the IT group was composed of a group of slackers and miscreants who wanted to do as little as possible.

With the plan for the collaborative changing of the culture in progress, I turned a portion of my attention to sorting through what to do with that portfolio of outsourced and troubled projects.

Clearly we had to improve our delivery of these projects. But did we first need to determine whether or not those projects would actually generate business value? Seven different teams were working on supposedly high-impact projects. But would each of these projects deliver value? If so, were there ways to increase the value?

To get answers to these questions, I arranged a series of meetings with my management team peers and the company president. I started each meeting by drawing a picture of and describing the Purpose-Based Alignment Model and asking, “For us, what belongs in the Differentiating quadrant? How do we create competitive advantage? What do we have to do better than anyone else?”

Their answers were all different but centered around one basic idea: We provide the highest levels of personalized service in the industry.

This was something I could work with, and I started to use, as a project portfolio decision filter, this question:

Will [this] help us be the best in the world at personalized service?

I met with Kevin, the person managing the outsource projects, and talked him through purpose alignment. “Kevin, before we go any further on these projects, I want to rationalize the portfolio with this decision filter. Just to humor me, let’s talk about one of your most challenging projects. Which is the project that troubles you the most?”

He answered, “Clearly our integration service. We need something to pass transactional information among the various application modules and components. We spent a lot of time looking at the options but were not really happy with the available technologies and so are developing a new messaging platform.”

“Are you using standard messaging technologies or will they not work?”

“According to our analysis, they won’t work—thus, the project. I have the best developers on the team working on this because everything hinges off it working.”

I tried to sort through how to ask my next question and decided to just plunge in. “Let’s use our decision filter on the project. Will an advanced, unique messaging platform help us be the best in the world at personalized customer service?”

Kevin answered, “It might.”

I asked back, “How?”

“We have to get it right or everything else fails.”

“Kevin, you know how difficult it is to write and test software. You have been doing this for a long time. And you think that using an unproven, to-be-developed technology is the best way to get a proven, must-be-right result? Again, let me ask, will developing our own messaging technology help us be better than anyone else at personalized service? To be honest, I cannot see any connection at all. The messaging is mission critical but hardly something we do to create competitive advantage. Given that, we should apply the parity rules and find the simplest, most standard, and best-practices-based option that exists. We are certainly not the only people who need to exchange mission-critical transactional data.”

Kevin pushed forward, “But we looked at other options and we don’t think they will work.”

“Remember the goal of parity—and this is clearly parity—is to find something that works well enough. For data exchange, such tools exist because they are an essential building block of any enterprise system. Who on the outsourced team did the search for existing tools?”

Kevin replied, “The chief architect.”

“Perfect. I will talk with him.”

I called the outsource provider’s architect. “Jason, do you remember me? We met at your office a couple of weeks ago.”

“Sure. What can I do for you?”

“Jason, I am looking at some of the project elements and have some questions about the messaging platform. I was wondering why you decided to build your own.”

Jason answered, “Oh, that. One of the guys on my team had a really great idea for a new messaging architecture. We think it will offer you a superior solution.”

“That sounds great. How is the development going?”

“Well, it works really well at low transaction volumes but suffers a bit when we apply more load. We think we will have the problems worked out pretty soon.”

“Jason, don’t worry about it. Let’s stop working on it right now.”

Jason was stunned, “Stop? But we’ve put a lot of effort into this project.”

“Yes. I know. I have seen the budget and the invoices. We don’t need a superior messaging platform. We need something that is proven. Even if your team works it out, we will be left with a custom messaging platform to support and enhance for the rest of our lives. That is something I don’t want to take on.”

Jason took a new approach, “But if we stop now, you will have wasted the thousands of developer hours we have already spent getting it to where it is.”

“Jason, I understand. How many hours do you estimate it will take to get it done?”

I had just raised Jason’s hopes. “My team estimates 800 to 1,000 more hours.”

“Jason, I cannot afford to waste another 800 to 1,000 developer hours on a product I don’t need. Let’s kill it now and apply those talented, smart resources to something we really need.”

I then talked to my director of software engineering and asked him to find a market-leading messaging platform we could use as our standard. He came back a day later with a purchase requisition in hand. For a cost that was much less than thousands of software developer hours and a simple download, we had our messaging platform.

I got the team to apply the purpose alignment and our decision filter to everything in the outsourced project portfolio.

One of the projects was to deliver a customer profile application. The assigned team had already spent thousands of hours creating a unique and innovative customer profile application. This project had a potential connection to how we created competitive advantage but did it require custom, unique development? While our customer profile application was important, there was no direct connection between it and being the best at personalized service. Why, then, were we creating a very innovative customer profile application? Because we did not know better. Wouldmaking a unique and interesting customer profile application generate value for us? No chance. Doing a better customer profile would not do a single thing to help us win in the marketplace. True, our customer profile application had to be good—its function was mission critical—but customers were not going to do business with us because we excelled at defining their profiles. After placing the project in the Parity category, I now had to align the project to that placement. In a kind and gentle way, I thanked the team for their work and effort and told them that I was killing the project and replacing it with a standard configuration of our customer relationship management system’s profile features.

This change in approach optimized value. The highest-value way for us to deliver a profile application was to use something that already existed and worked really well.

As a result, we stopped three of the seven outsourced projects and dramatically simplified the other four. Even better, we started to take ownership of our destiny. The company started to think that we knew what we were doing and just might do a better job of new product development than they had thought. Over the next few months, we shifted our developers into the lead positions on the remaining four outsourced projects, got them back on track, and delivered them.

With the goal of increasing trust and ownership to get to Energy and Innovation, the IT team had taken ownership (and I trusted them) to improve internal processes. We had also aligned the external project portfolio. There was still one major missing piece—we did not yet have ownership for the company’s results. We needed to align everything we did to the company’s goals. But what were those goals? In a perfect world, everyone in the IT group would be able to map what they were doing to one of the company’s goals.

I again hit the road and met with everyone on the leadership team. I explained that I wanted to make sure that IT was focused on helping each one of them achieve their goals. To do that, I needed to understand their goals—both in the short and the long term.

I synthesized their answers. I then gave the entire management team a report on my understanding of the goals so that we could all agree. We agreed to three high-level goals:

Increase customer retention.

Improve profit margins.

Become an employer of choice—attract and retain the best employees.

(Now, you might wonder why I had this meeting without members of my IT staff. At this point the IT group was still the gang that could not shoot straight.)

With these goals defined, I asked my entire IT team to map their work to these goals. I met with each group to inventory their current projects. We then identified which of the three goals, if any, the projects supported. We had plenty of orphan projects and so put those on temporary hold—at least until their project sponsors could map them to one of the company goals.

At our next all-staff meeting, I introduced and explained the company goals to everyone in the IT group and showed them which projects mapped to the goals and which did not. We then discussed any projects we should be doing that would help achieve the company goals. These went onto our project backlog. In my spare time, I created a visual display that showed each current IT project and which company goal it supported. We published this graphic to the entire company so that they could see not only what we were doing but why we were doing it. Finally, we revised our project inception process to consider how the proposed project mapped to the three goals. At each of our all-staff meetings, we updated the project visual with our progress and reminded each other of the company goals.

One of the projects we added to our backlog was advanced customer analytics. Because one of goals was increased customer retention, we decided we needed to better understand customer behaviors. Which customers stayed with us? Why? Which customer left? Why? Would it be possible for us to identify at-risk customers and then do an intervention to keep them? Was this worth doing? How did this project align with our decision filter? If we were to be better than anyone else at personalized service, shouldn’t part of that service be knowing when it was time to rescue a customer? Or make sure we provided services that meant no customer ever had to be rescued?

Because this project aligned with our Differentiating activities, we figured we should do something innovative. In our minds, that allowed us to be somewhat experimental. We brainstormed some of the things we could try and decided which ones to pursue. In some cases, we experimented with proven technologies. In other cases, we developed very low-cost pilots of our ideas. Some things worked but most failed. When we found something that might work, we started to communicate what we were doing (until then, the project was an IT “skunk works” project). Because we were dealing with so much uncertainty, we used iterative methods. We selected some pilot data from pilot customers and did more experiments. We gathered feedback and results and planned our next test. When we published our first working results, the company was ecstatic. They had insight into customer behavior that they never thought was possible.

On the increasing trust side of life, I used every tool we describe in this book. I never gave answers—even when I knew the answers. I trusted first. When I started the job, the company president asked me how many members of the IT group I would have to fire to improve the team’s performance. Not wanting to make a commitment when I knew the least, I gave a nebulous answer. My assumption was that everyone wanted to do a great job but was being stopped by leadership or process or something. I expressed thanks when people did well. I expressed thanks when people pretty much did anything. When someone made a mistake, I asked them what they had learned from the experience. I kept my commitments. If I was not sure I could commit to something, I told them so. I wanted to be completely trustworthy.

When it was time to do our annual budget, I discovered that my directors had never done budgeting. The tyrannical micromanager had done it all himself. I met with the person who owned the budgeting process and asked him to create a separate budget for each of my directors (under the regime of the tyrannical micromanager, there were not departmental budgets—just one big IT group budget). We allocated the current expenses as best we could to the various, new budgets. We then met with the IT directors and set them loose. I told them that it was nearly impossible to make a mistake, just to put in what we needed and we could adjust from there. When their budgets came in, they had been very conservative, so we had the joy of brainstorming ideas for what to do with the money they did not need (like fund our customer analytics and intervention experiments).

We replaced detailed, personal metrics with process metrics, such as: Did we keep our commitments? Did we provide outstanding customer service? Were we a great place to work?

Was it all so easy and happy? Hardly. Culture change never is. It made a huge, immediate difference just to ask people their opinions as to what we should do. We still had some fundamental process, trust, and credibility problems to solve but now we were in it together.

As I mentioned, on the day I started, there were 17 open positions in IT. The company had such a bad reputation that it was impossible to hire anyone—even at the height of the 2009 economic meltdown. Naturally, I was concerned about hiring anyone into what still might be a culture oflow trust and ownership. I met with our internal and external recruiters and explained what we were doing, how the culture was changing. I asked them to find me candidates that fit into the culture we were creating—not the culture we had. I met with each job candidate in person and described the future. This would be a culture of trust and ownership. I told them that their jobs would not only include job tasks but would also be to change the culture. We soon filled every open position.

Not everyone reacted well to the changes. One of my directors struggled mightily to take ownership and be trusted. Many times he told me, “Just tell me what to do!” Over time, he became more and more uncomfortable with the culture and found a new job. But almost everyone else embraced the changes and thrived. How do we know?

Six months later, we did a new employee survey; IT employee satisfaction and company satisfaction with IT had increased by nearly 25 percent. Project throughput (a measure of how many projects we completed per unit time) had doubled. Best of all, we had become the IT supplier of choice to the company. Before trust and ownership, everyone looked for ways to not use the IT group. Now, everyone wanted us to take on their projects. Even better, people were willing to delay their projects in order to wait for the IT teams to be available. We still had a long way to go but we were clearly on our way to Energy and Innovation.