Leader: This would be a big change. Employees would need to learn many things to implement the change. Then, customers would need to learn how to perform tasks differently to use the product after the changes were made.

Once some systems were changed, others would need to be altered as well. When we mapped out the interdependencies, we realized that it was massive. We also realized that all the work would need to be completed in a short time frame, about six to eight months from start to finish.

Me: Was it going to be difficult to do everything within this timeline? Did that cause additional stress?

Leader: It might seem like a daunting task to some companies, but we’ve made changes in the past that were just as monumental. So we knew we could do it. It’s an example of how our culture shines. Once we make a decision, we operate more flexibly and effectively than other companies in which I’ve worked. I’m really proud of the way we can accomplish huge projects like this so successfully and with such agility.

Me: What about your culture allows that flexibility?

Leader: We pause and discuss the decision with the employees who need to help implement it. We set the context by sharing as much data and background as we can. We trust our employees and are transparent with what we share. We not only allow, but encourage staff to raise questions, debate the topic with us, and poke and prod. This helps us to check and make sure we are making the right decisions and considering all the details.

Other companies tend to have one-way discussions. They announce the change and shut the conversation down pretty quickly. We let discussions go on long enough to examine issues and get employee buy-in. Once the discussions are successful, then staff jump into action. They figure out what they need to do and start doing it.

Me: Does that mean you don’t have a project management framework that you put in place to help guide a change like this? That everyone just starts working on their part? It seems like that could result in chaos.

Leader: We do have a project management template. But we use it flexibly. We don’t adhere to it if it keeps us from doing the right things or creates unneeded bureaucracy. There are levels of project management that have to happen with a complex project like this one.

What I meant when I said employees just jump in, is that most of our staff are quite advanced in their field (we tend to hire senior folks). They are sophisticated and self-starting. They know what’s needed of them or know how to figure it out quickly. They jump into action and remain in action, doing their part.

That means we don’t have the high overhead that comes with having a lot of middle-managers walking around checking to make sure things are getting done. Folks don’t wait for status updates or permissions. It’s much easier to get things done at this company, both on a daily basis and when we’re in the middle of a big project like this.

Me: Do you have self-managed teams?

Leader: No, it would be going too far to say that. Our low ratio of management to individual employees keeps our overhead costs down. It also makes employees more satisfied because they’re empowered to make more decisions and work directly with others without going through management.

People help others when it makes sense. Folks would have to work harder if others weren’t seeing what needs to be done and pitching in, often when it isn’t even part of their job. That’s why things don’t need to be as top-down managed here.

Me: How well does that work? Do staff usually make the right decisions?

Leader: Usually, yes. That goes back to leaders setting the context. When we do our jobs well employees can make the right trade-offs.

Me: What did this project mean for other work those employees were doing? Were the employees assigned to this work in between projects? Or were folks reassigned from other work?

Leader: We look for the staff with the right expertise to do a job. The employees did have other work they were doing. Some of the things they were working on didn’t have strict deadlines. That work could be re-prioritized and temporarily put aside.

Other folks did have time-sensitive work. They had to work harder to accomplish everything. That’s also part of our culture, though. People are willing to put in the extra energy when needed. Part of the reason they’re willing to do this is because we don’t have a set number of vacation days. Staff know that when the project is done, they can take some time off if they are doing double-duty and working really hard.

Me: Do you find that any employees abuse that open vacation policy?

Leader: No, I haven’t found that in my groups or in other groups. People are passionate about working here. They like this culture and like that they’re treated as adults. They don’t take advantage of it. I’ve heard the opposite from people in other companies. In competitive cultures, people worry that it’s a way to get folks to forgo their vacation because they’re afraid they’ll lose ground if they take days off. That’s not the case here. People are encouraged to take vacation because we know that it refreshes them. Work-life balance is important here. (You will read more about incentives that encourage collaboration in Chapter 11.)

Me: From your perspective was this project a success?

Leader: It was a total success. It was completed within the six-to-eight-month deadline. There was structure to guide the project, but just enough to organize things without constraining staff or making them slaves of the structure. Staff quickly determined what they needed to do and worked together to accomplish it. They worked hard and were fine doing that because they knew they could take a break when the project was completed.

Manager: The different ways of operating this product on different devices was a problem. A lot of complaints made their way to us because our central group worked with all the groups that created the various versions of the product. But we hadn’t dedicated resources to fix it yet.

Me: Why hadn’t it previously arisen as a priority of your group or some other group to fix?

Manager: There were several reasons. Probably the biggest was this company’s culture. Each group had a lot of autonomy to be creative and do their own work. Creating one central way that all versions of this product would work would impose constraints on those groups. That was a bit counter to our culture.

Me: How did you initiate this project? What were your first steps?

Manager: I decided to focus on this issue when I had time that wasn’t consumed with high-priority work and deadlines. First, I collected available data to see if it confirmed that this was indeed a problem; that customers found it unpleasant to use our product on different devices.

Me: Was the data definitive?

Manager: Yes. It showed that customers were frustrated. They wanted the operating systems to be the same across the various devices. It didn’t prove whether we were losing customers—whether they were frustrated enough to move to a competitor’s product because of this glitch. While the data didn’t answer all of my questions, I felt it was strong enough to make a business case for working on this project.

Me: What did you do next?

Manager: I engaged in some mini-experiments pretending I was the customer. I tried to get into their minds and determine which of the various ways of performing a certain function was likely to be easiest.

Me: How far did you go with your research? Did you redesign the product in detail before taking your idea to anyone else?

Manager: My intent wasn’t to come up with the solution by myself. I was just trying to determine how difficult the task seemed.

Then I wrote a proposal that made the business case and outlined how the changes could be made. I shared it with peers to get their ideas and buy-in. Then, I took the proposal to vice president–level leaders and asked if they’d consider letting us work on it.

Me: I assume you got that approval since this did turn into an actual project, right?

Manager: The VPs liked it enough to let me bring together a group to study the issue further. A small number of staff from design, engineering, research, marketing, and a few other groups came together for a week to flesh out the idea.

The work went well. There was consensus that this was doable and important enough to pursue. We made a strategy presentation to that VP group, including some detail about how we’d go about this work, still at a pretty high level. Once again, that VP group approved it to go to the next step.

Me: Did you start working on the project at this point?

Manager: We weren’t quite ready to jump in and start working yet. It was a pretty complex task. Over a several month period, mid-level leaders in the groups that own the versions of this product got together and worked out the process. We also started building stronger alliances between those groups.

Me: Then did work begin once you mapped out the process and strengthened those alliances?

Manager: Not quite yet. One of the unique aspects about this company is that work groups have the authority (to a large extent) to decide what they want to work on. If a new idea arises, like this one, you cannot foist it onto the work groups. You have to convince them to take it on as a project, persuading them of its importance relative to other things they could be working on.

Me: That’s quite different than how work is assigned in most companies. How did you persuade those work groups to take it on?

Manager: We took the basic proposal that we used to sell the idea to VPs and added details that would inspire employees in these work groups to want to take it on. We anticipated questions they’d have about this project, and about product features, time estimates, and opportunities for them to learn new things while performing the work. Fortunately, the project was appealing enough and the consumer pain great enough that we were able to interest enough work groups that the project could proceed.

Me: Then you began work?

Manager: Not until we completed one last step. We created a project plan to manage the work. We determined who would do what, how people would work together and communicate. Then we began work.

Me: Was it all smooth sailing from that point until the project was completed? Or did you encounter issues that had to be resolved?

Manager: There were challenges along the way. The way those challenges were faced said a lot about the company culture and why I and so many others loved working there.

Two groups that needed to work closely had different tools and ways of performing the work. Some of those tools conflicted with each other. It hadn’t been a problem in the past. But it was now, because the parts they were working on had to fit together. They had to come to an agreement on whose tools and process they would use.

One of the groups was under-staffed and also working on another project. The second group knew what kind of pressure the first group was under. Rather than trying to convince the first group to change their tools, which would have added yet more work to their plates, the second group decided to just adapt to the first group’s way of doing things.

Me: That’s impressive. Is that rare, or did that sort of thing happen regularly?

Manager: It really did happen regularly. That was one of the things I appreciated about the culture. People wanted to help others. It was in the “genes” of the culture.

Me: When issues arose did groups usually work them out between themselves or did management have to get involved?

Manager: Sometimes management got involved. We had to intervene in this project when there was a kerfuffle about one of the features that operated differently in the different versions. The groups couldn’t agree on the best way of doing the task. After a certain amount of going back and forth, they realized they needed management to break the stalemate. I and a few other managers got involved and helped them sort out the details and decide which way to go.

Me: Was there any negativity associated with bringing you in to resolve things?

Manager: Not at all. In general, managers let the teams try to work things out themselves. In this case, we noticed the arguing. But we wanted to give them a chance to resolve it. When they weren’t able to do that and called us in, that was fine. They had grappled among themselves long enough to know they weren’t going to resolve it easily. It was right that they called us in. There was no resentment on their part and certainly no negative feelings on our part. That’s one of management’s chief roles in this company.

Me: Are there any other aspects of this project that you would like to share?

Manager: We built in some friendly contests to make things more interesting for the teams while they were working hard to solve tough problems. The team that was first to figure out a great solution to some snarly problem got some kudos. The reward was “bragging rights.” It wasn’t like the first prize was a new car, second prize was $100, and third prize was that you got fired.

We had tried awarding tangible prizes previously at this company (neither the car nor firing them; more like the $100 gift). But we found that these sorts of prizes caused unhealthy competition and kept groups from collaborating fully. We learned to keep the prize at the level of bragging rights.

Me: Was the project successful?

Manager: Yes. The various versions of the product were successfully combined so the operating systems were the same for users. It was a great idea whose time had come. It enhanced customer satisfaction.

Me: What was the goal of this project? And what was your role?

Leader: The goal was to select the technology that all development groups would use moving forward. That meant consolidating to one tool that would be used by over 1,000 different employees. I was the overall project leader.

Me: How did you come to that role? Were you asked to take it on?

Leader: I volunteered because I felt strongly about the need for it. I knew it wouldn’t be an easy project, and also knew that if it was to succeed, whoever led the project would need to roll up their sleeves, become quite involved, and do the right thing every step of the way.

Me: Were you working on it by yourself or with others?

Leader: Because of the number of individuals and teams who would be affected by this change and the criticality of their buy-in, our Chief Information Officer partnered with me to pull together architects and technical leaders from the business units. There was representation of technologists from every business unit. This was to ensure that we examined the potential technologies from their perspectives to meet critical needs. We worked collaboratively to select the singular technology that all the groups would use moving forward.

Me: Was this team empowered to make the final decision and implement it? How did that work?

Leader: We worked together and tested a number of technologies. Fortunately, we reached agreement pretty easily about the one we felt was best for our company. We presented our results and recommendations to the CIO and the executive team and they agreed with our conclusions.

Me: Was it easy from there?

Leader: Not by far. The hardest parts were still ahead of us.

We had to figure out how to convince staff that it was right to move to one unified technology. And we had to convince them that the one we selected was the right one. Then, we had to figure out how to implement this change that would significantly affect how 1,000 employees performed their work.

Me: How did you persuade employees that this was the right thing to do?

Leader: We started with top leadership, just below the CIO and other executives who had approved our recommendations. We met with those leaders and had an open dialogue about the need for the unified technology, the benefits that would result, and the specific technology that we had selected. Then, as project leader, I attended staff meetings of each manager who worked for these leaders and then staff meetings of the levels below that, until I had spoken with the 1,000 employees in their respective groups.

I explained the problems it was causing the company to use all these different technologies. That was not a difficult case to make since many of those employees had gotten caught up in problems caused by the conflicting technologies. I reinforced the need to stop wasting time re-inventing the same solutions just because these different technologies did not “talk to each other.” I heard their concerns and answered them as candidly as I could.

Me: Were there any parts of those conversations that were particularly difficult?

Leader: One of the hardest parts was that employees felt this might signify a move to overall centralization, which might decrease their autonomy in other areas. Through our dialogues, employees saw they were still going to be partners. Their concerns were heard and they were assured that this was not the beginning of a negative sea-change in the culture.

Me: Once you had persuaded staff, how did you implement the change?

Leader: We decided that current projects could be completed using their current technology. We didn’t want to disrupt projects that were already under way. New projects would start with the new technology.

We set up a services team to train employees and assist them through the transition to the new technology. We made it fun by bringing in thought leaders from outside of our company to deliver brown-bag lunchtime talks. We created user groups for programmers to share what they were learning. We recruited programmers who had strong expertise in this new technology to form a tiger team that could be called on by any project in the organization that ran into challenges. We set up an internal information portal that included a directory of every team working in the technology and what they were doing. Every time a new group delivered its first project using the new technology, we held a lunch-and-learn with the whole team on stage, sharing the challenges they’d faced and how they had succeeded.

Me: Was the project successful?

Leader: Yes, It was successfully implemented and all 1,000 software development staff were moved to the singular technology. Over time, the initiative had an unintended and very pleasant effect of spawning a massive social network of employees with advanced skills, reaching out to help others as needed.