Chapter Six. Empower the Team

Success is completely dependent on quality of people, culture, and learning. You cannot build a complex business system without building its development team simultaneously. Focus on both.

Michael K. Levine¹

1. Michael K. Levine, A Tale of Two Systems: Lean and Agile Software Development for Business Leaders (CRC Press, 2009), p. 294.

Please don’t skip this chapter. Every business book emphasizes the importance of people to the extent that it is hard to imagine something new being said. We all agree that empowered teams are important, but how do you develop them? We will do our best to say something fresh in the hope that our ideas, combined with your ideas and the thinking of so many others, will provide the spark and initiative needed to make your organization a great example of energized, inspired people innovating together.

Team empowerment brings the most out of all employees, motivating their best efforts in working together toward a shared vision. The full participation of all team members in working toward innovative ideas and continuous improvement is what makes the other Lean principles possible. Empowered teams realize their creativity from the bottom up; individual contributors on the teams are motivated to apply their best thinking to problem solving and continuous improvement.

People at Toyota say that if they had to choose the two most important principles, they would choose “respect for people” and “continuous improvement.” Dennis Kinlaw, in his book Developing Superior Work Teams, said, “Teamwork is the fundamental requisite for continuous improvement.”² All the other principles can logically grow from people working effectively together in an effort to continuously improve.

2. Dennis Kinlaw, Developing Superior Work Teams: Building Quality and the Competitive Edge (Lexington Books, 1991), p. xx.

All of the other Lean Integration principles can be achieved through the commonsense efforts of totally engaged and continuously improving teams, without reading this book or knowing anything about the other principles. However, without empowerment, it is unlikely that teams can achieve the advantages of the other Lean principles. Furthermore, sustaining those advantages over long periods is unlikely.

In this chapter we will examine the characteristics of successful teams and the power that can result from these characteristics, then we’ll tackle the challenge of setting up the environment in which empowered teams can thrive and grow.

We wrap up the chapter on team empowerment with a case study from Smith & Nephew, a multinational company in the health care industry. The study is based on a data governance program and illustrates a number of Lean principles, including effective use of metrics, visual controls, and value stream mapping, all in the interests of getting business executives and front-line staff engaged in the process of continuous improvement and sustainable data quality.

What Is a Team?

Rather than use sports analogies to describe effective teams, we have borrowed an analogy from the world of music. A jazz combo can be either a team or a group of talented individuals making music together. Even the untrained jazz listener can tell when a combo is a team. The music is tight, the musicians play off each other spontaneously, the music ebbs and flows between the rhythm section and the soloists in a way that stirs the emotions, and you can tell that the musicians are into the music and enjoy what they’re doing.

Certainly, the musicians themselves know when they are part of a team. When they are simply “phoning in the performance,” going through the chord changes, and finishing at the same time, the jazz combo is more like a work group, each member competently playing his or her role but not putting in the energy to understand what the others are doing and what could be done to enhance the team. Perhaps they’re tired, they feel disrespected or inferior to the others in the group, or perhaps they don’t enjoy the music they’re playing. For these or other reasons, magic is not created, and listeners can tell.

One of our favorite musical examples of an empowered team is the Bill Evans piano trio. He talked about the freedom he gave to the bass player and drummer, how they were free to stray beyond the traditional roles of bass and drummer if they felt the result would enhance the musical result. One of the seminal albums in jazz is Sunday at the Village Vanguard, which captures this magic in full flower with a bass player (Scott LaFaro) not laying down the traditional walking bass lines but effectively creating melodies that mesh beautifully with Bill Evans’s piano, and a drummer (Paul Motian) who didn’t lay down the traditional swing rhythms but literally created a percussive accompaniment that gels with the bass and piano. As a whole, by giving the freedom to everyone along with a shared vision of the objective, they created a style that changed the way that most piano trios play.

Work groups are not teams. If you think back on your experiences working on software projects, most “teams” might be best described as work groups—groups of highly competent individuals working on their separate responsibilities whose efforts were combined into the end result.

You know when you’re working on an empowered team and not just a work group because the synergy and synchrony among the people are exhilarating. You can feel the energy, the progress, the excitement, and the expectation. It’s fun to solve problems. Your combined efforts produce something beyond what was expected. You achieve something superb that you all are proud of. Think back through your own work experiences as we further break down the characteristics of successful, empowered teams, and think about ways that these characteristics can be fostered in your organization.

Characteristics of Empowered Teams

Whether discussing business, information technology, sports, or music, superior team experiences are described with remarkable similarity. Empowered teams differ from work groups in their consistency, intensity, and ceaseless striving.

For instance, when people describe their experiences on fantastic teams, they frequently use the extreme words always and never. “We always kept the feedback loop with our end users fresh—hearing what they had to say about how we were serving them.” Or “We never allowed our training to fall below par; we kept our skills up-to-date and deep.” People on these teams were consistent in their pursuit of excellence. They were driven by a vision of success that inspired them.

Intensity is strong in superior, empowered teams. The level of energy and commitment is high and can be described as a feeling of group impatience. And finally, there’s a feeling of restless dissatisfaction that creates a natural push for continuous improvement. “If it ain’t broke, improve it.”

Dennis Kinlaw describes these elements in his model for superior team development and performance, which we’ve adapted here in Figure 6.1. The top-level elements of this model are

1. Superior team results: This is best seen by building enthusiastically positive customers. The team achieves beyond expectations and is energized about the process.

2. Informal team processes: Day-to-day communication and responsiveness are consistent and quick, and there’s a feeling of safety and a lack of hierarchy in bringing up suggestions and issues.

3. Positive team feelings: This is best exemplified by feelings of inclusion, commitment, loyalty, pride, and trust.

4. Developing leadership: Team members are focused on development and performance.

Figure 6.1 Model for team development and performance³

3. Adapted from ibid, p. 42.

If you think about your own experiences with strong teams, you might be able to add some other ways of describing them. The point of this chapter is to get you thinking about what engaged people working toward common goals could accomplish in your organization, then about how to get them there. Most people have at some point been a part of a superior team. Think of the reasons why those teams worked well. Why were people excited and motivated? How did they get that way? Why did it end? How can you be a part of making that experience a reality again, and how can the team sustain this principle?

For example, our experiences show that teams that operate in an environment of open communication, with access to the information they need to get their work done, are both more effective and more creative. As Michael Levine wrote, “To make good decisions, team members need information and context.”⁴

4. Michael K. Levine, A Tale of Two Systems: Lean and Agile Software Development for Business Leaders (CRC Press, 2009), p. 294.

Examples of Empowered Teams in Software

The Open Source Community

The Open Source community starkly demonstrates a unique and interesting dynamic. Individuals, typically spread around the world, without any monetary compensation or managerial directive, successfully collaborate to create software “products” of substantial value, from Web browsers to operating systems to databases to thousands of other useful tools. When critical bugs surface, virtual teams collaborate around the clock to provide solutions, once again without managerial direction or monetary reward. New features are developed relatively quickly in most Open Source software, without work breakdown structures and executive guidance. High software quality is maintained, and software is continually refactored so that continual change and consistent progress are possible.

How is this possible, given that there is no top-down traditional command-and-control structure? The Open Source community benefits from the highly motivating power of respect, trust, and commitment. Participating in the creation and continual evolution of something that others will use, benefit from, and enjoy, fosters a deep feeling of being part of something important among people who will likely never meet. Creating code and features and improvements that engender the respect of peers is a powerful motivator.

In a way that is similar to the “invisible hand” behind the behavior of free markets, there seems to be an “invisible hand” behind the behavior of these virtual software teams.

While Open Source provides a good example of what’s possible through the power of respect, trust, and commitment, it would be simplistic to say that empowering an internal team in an IT department could achieve the same results easily. Often an internal team in an IT department has finite resources already stretched to the breaking point before a Lean Integration effort begins. How do we build a team and somehow establish the same kind of team-oriented “invisible hand” that energizes and motivates the people on Open Source teams?

Respect, Trust, and Commitment

Monetary compensation is not the driver behind successful Open Source teams. Nor are management directives driving the teams, handing down schedules, and monitoring progress. In a similar way that there is an invisible hand that drives market behavior in free markets, there is also an invisible hand that motivates individuals to work in these teams. It can be described in many ways, but we’ll take one approach here.

The motivation for people to participate actively in these communities is somewhat similar to what drives people to contribute to Wikipedia. People seek to be part of something important, useful, and successful. They are looking for the respect of their peers and to work in an environment where they have the support they require and the freedom to grow and achieve.

People’s motivations are no different today from what they were before the Internet. They have always existed, but modern examples like Open Source, Wikipedia, and any number of different social networking phenomena show them in exceptional relief.

Software Start-up Companies

Not everyone participates in Open Source, so here is another example that highlights the “invisible hand” behind exceptional empowered teams. You frequently find effective teams within start-up software companies. Typically, the level of passion and alignment is extremely high (commitment). Employees feel they are involved in the creation of something new and important. Because of funding issues, market situations, and a huge variety of other issues, many start-ups don’t succeed, but frequently their innovative techniques live beyond the company’s life span. From the people who participated in these endeavors, you will hear wistful recollections of the team they were a part of.

The challenge, and objective, is to create a similar feeling in the midst of much larger, traditional IT organizations.

How do we achieve this vision of being part of something important, especially when our topic, integration, has a history of being “underappreciated”? How do we create the environment for teams to grow using the “invisible hand” of respect, trust, and commitment? The most successful answer that we’ve seen is to treat the Integration Competency Center as a business, as if it were a software start-up company within a larger IT organization providing products and services to the internal market. This is not only beneficial to the customer (the business) but is equally important for fertilizing the soil to create effective, empowered teams.

Creating an Empowered Lean Integration Team

Launch “ICC, Inc.” Like a Software Start-up Company

We ask people to think of the ICC as a business from several different perspectives in different chapters throughout this book. The ICC is an internal services business that provides software products and services to customers, the business community. You are creating “ICC, Inc.” within your enterprise, and your objective is “customer delight” for your business customers. You do this by trying to create the best product of exactly the right specification supplied in the least time at the least cost for your customers.

The conventional wisdom is “Better, cheaper, and faster; pick any two.” With Lean Integration and “ICC, Inc.,” we’re going to work toward delivering all three. Improving the ICC processes, people, and technology takes time, but setting this vision provides a foundation for developing the feeling of team empowerment necessary to make this happen.

We talk all the time about the pace of change in business, and particularly in the world of technology. But to be realistic, it usually takes three to five years to establish a top-notch “ICC, Inc.,” which is also about how long it takes most start-ups to mature to a level where they are gaining market share and becoming entrenched in their markets.

Thinking in terms of a software start-up company has tremendous power in instilling a vision and synchronizing everyone’s view of the customer. You are trying to create integration (or business intelligence) services and capabilities that will be highly sought after by the business. You will be able to meet their goals better, cheaper, and faster than any alternative.

Thinking of the ICC as a business has numerous benefits to the people working on the team:

1. It clarifies the view of who the customer is.

2. The view of what is valuable to the customer can therefore be clearer.

3. The objective of delighting the customer by providing integration solutions better, cheaper, and faster becomes the driver for the company.

4. Thinking in terms of “ICC, Inc.” provides an identity and a group in which to be included. All aspects of what a start-up provides should be considered:

a. Marketing the products, services, and successes of “ICC, Inc.” to management and each other. Celebrate the successes of the team.

b. Know the competition of “ICC, Inc.” What other ways are projects being done that compete with the ICC? Are you happy to give away that business, or would you like to win it for yourselves?

c. Measure and chart the growth and success of “ICC, Inc.” (See the next chapter for ideas about how to do this.)

The objective is to paint a clear vision, get people excited about achieving it, and then discuss the roadblocks that can and should be removed to enable teams to innovate and continuously improve toward this vision. Even when this vision has been painted and people are excited, the next goal is equally critical to enabling empowered teams.

Ensure Sufficient Capacity for Continuous Improvement

The hardest nut to crack in making ICCs successful is getting enough spare bandwidth to make some of the changes that the team desires. Many use the analogy of trying to change the tires on a car while it is moving at 60 miles per hour. If teams are totally consumed year-round with just meeting day-today operational needs, progress toward the vision will be hampered and the feeling of empowerment toward the ultimate goals of Lean Integration will be distrusted as nothing more than verbiage. People need time and space to breathe and think. Time and again, it is during these moments of breathing that most true innovation takes place.

Google is famous for allowing 20 percent of its software developers’ time to be set aside for thinking and innovation. Other organizations taking agile approaches leave a week between two- to four-week iterations for downtime, allowing developers to develop ideas without guidance or direction. Frequently, it is during these periods of “free” time that the most innovative ideas emerge. And more often than not, innovation breeds efficiency and further opportunity for more innovation.

We realize that there is a chicken-and-egg problem here. You need excess capacity to make the changes to improve processes that make you more efficient, but you don’t have excess capacity because your current processes consume all resources. This is a difficult cycle to get out of, but truly, finding a small win in this area can do more to get the ball rolling with “ICC, Inc.” than just about anything else. Excess capacity, when it exists within an empowered team that shares a Lean vision of the future, is the most powerful weapon available to make Lean Integration successful. Excess capacity and an empowered team lead to innovation and therefore more excess capacity and more innovation, and along the way customers are getting what they need, better, cheaper, and faster.

Excess capacity is so important to team empowerment that perhaps the two are almost equivalent. If a team never gets time or space to change or innovate, how can the team be truly empowered? Not addressing this important issue leads to ICC maturity stagnation at many organizations.

Leadership and Vision

In our first ICC book, we discussed the importance of people and change agents, but we didn’t specifically address the role of leadership. Empowerment does not mean that leadership is either neglected or deemphasized. Leadership simply plays a different role.

Create a Sense of Safety

Change and flexibility are hallmarks of continuous improvement and Lean principles. One additional requirement that falls out from a continual quest to eliminate waste is to institutionalize the principle that staff won’t eliminate their own jobs as a result of productivity improvements.

The leadership of “ICC, Inc.” needs to create an environment where it’s fun to solve problems and where significant improvements in productivity aren’t going to end up costing people their jobs. This feeling of safety is foundational to making Lean thinking work. Lean does not mean layoffs. Lean means getting people involved and engaged in the process of creating additional customer value. A higher percentage of people’s time is spent automating the common patterns, creating and maintaining the “assembly lines,” rather than working as craftspeople on individual integration works of art.

Roles for Leaders

Besides helping to set the vision and promote “ICC, Inc.” wherever that promotion is beneficial to the success of the ICC business, leaders need to understand their role as that of initiator, model, and coach.

Initiator

Leaders within Lean Integration teams initiate various actions and processes for building the teams’ capabilities. They accomplish this by first initiating team development exercises for setting goals, and subsequently instituting exercises around working toward achieving those goals. All goals are team goals, not individual goals. Having a leader who is a change agent to make this happen is critical.

Model

Leaders must also model the behavior they expect other members of the team to follow. This is exemplified not only by the way they perform when they interact with the team and perform work within the team, but also when they interact with people outside the team (customers and other stakeholders) to accomplish the goals of the team. This means modeling the characteristics outlined in Figure 6.1: results, informal processes, and feelings.

Coach

Finally, leadership means providing coaching wherever it can be helpful to the team. This includes counseling, mentoring, tutoring, and improving performance. Just as important is to encourage people to take responsibility for driving bottom-up improvements. “The people with ideas, working with their teams, should be the implementers of their ideas. They should not be asked to drop their ideas into a suggestion system to be implemented by others.”⁵

5. Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash (Addison-Wesley, 2006), p. 236.

Empowering individual contributors does not mean abandoning management structures. Leadership plays a crucial role in Lean Integration that is different from its role in the traditional hierarchical, command-and-control world. Leadership is about creating the environment where team members are truly empowered to think and innovate, make decisions and mistakes, and question authority for the good of the vision. They have the resources they need, the time they need, the freedom they need, and the trust and respect they need to continuously work toward making the vision a reality.

Change Agent Leadership

One of the dangers of success is that it can breed complacency. One of the hardest things to do is to challenge the things that drove the current measure of success—but not to do so can lead to stagnation. It is for this reason that a sustainable integration strategy must drive change constantly.

Change is difficult and brings risks, so we must be careful to manage the tug-of-war between driving change rapidly and slowing it down. To facilitate this apparent paradox, a range of change leaders is required, including change agents, early adopters, late adopters, and change resisters. An empowered team needs all types. Change resisters ask the tough questions and put up roadblocks to ensure that change doesn’t happen too fast; late adopters are the pragmatists who ensure that all the details of a new initiative are thoroughly worked out; early adopters are the experimenters who fine-tune new ideas to fit the organizational dynamics; and change agents are the explorers with innovative ideas.

The appropriate diversity of change leaders is critical. In order to achieve a Lean Integration practice, particularly in light of continuous improvement, more change agents are needed than change resisters. Womack and Jones encourage us to look for change agents inside the organization: “. . . in the fifty firms we’ve looked at it was possible to find the right change agent, and generally after only a short search.”⁶

6. James P. Womack and Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation (Simon & Schuster, 1996), p. 248.

But what exactly is a “change agent”? A change agent

• Is a voracious learner

• Does not wait for orders to take action on new ideas

• Expresses excitement freely concerning new ideas and change

• Demonstrates a sense of urgency to capitalize on innovations and opportunities

• Challenges the status quo

• Transcends silos to achieve enterprise results

• Skillfully influences peers and colleagues to promote and sell ideas

• Displays personal courage by taking a stand on controversial and challenging changes

A successful Lean Integration team is also a successful change management team. It would be a mistake to underestimate the difficulty in leading change in a large enterprise. Womack and Jones make this point in Lean Thinking: “The most difficult step is simply to get started by overcoming the inertia present in any brownfield organization. You’ll need a change agent plus the core of lean knowledge, some type of crisis to serve as a lever for change, a map of your value streams, and a determination to kaikaku quickly to your value-creating activities in order to produce rapid results which your organization can’t ignore.”⁷ (Note: In Lean terms there are two kinds of improvement. Kaizen refers to steady incremental improvement, and kaikaku means revolution, or radical improvement.)

7. Ibid., p. 247.

Some of the more difficult challenges facing the Lean team include

• The “not invented here” syndrome and other similar behaviors

• Project funding by fine-grained silos that don’t have the money for and aren’t motivated to solve the “big picture”

• Emphasis on tactical short-term investment that doesn’t appear to leave any room for strategic infrastructure investments

• Short-term, tactical time pressures that prevent solving the problems “the right way”

• Autonomous operating groups in distributed geographies that will not accept guidance from a central team

• Fear of change and a vested interest in the status quo, resulting in the belief that there is no compelling reason to change

The word challenges may be too moderate when referring to this list; these seem a lot more like immovable barriers. As insurmountable as these hurdles may appear to be, they are not unique to an integration team and have been conquered in the past. Joe Stenzel provides some encouragement: “It is generally accepted that people are afraid of change. In reality, people are afraid of the unknown. People are not afraid of change if they understand and believe that the change will benefit them. When this happens, they adopt change so fast that it can make one’s head spin.”⁸

8. Joe Stenzel, Lean Accounting: Best Practices for Sustainable Integration (John Wiley & Sons, 2007), Kindle loc. 1691–93.

While there is no simple “silver bullet” solution, there are a number of key concepts that have been proven over and over to be effective in driving changes. Here are seven of the best:

1. Think strategically—act tactically: Have a clear vision of the future, but be prepared to get there one step at a time. It is good to keep in mind that there is no end state. In other words, something is always changing, so if you miss a window of opportunity to establish, say, a new architectural standard on the latest project, don’t worry. Another project will come along. If you are in it for the long run, individual projects, even big ones, are just blips on the radar screen.

2. Credibility through delivery: In order to be perceived as a leader by others in the enterprise, you need their trust and respect. It’s not just about being open, honest, and trustworthy; do people trust that you will actually get the job done? In the final analysis it comes down to your ability to execute. To organize your work, you should set appropriate priorities, assign the appropriate resources to the task, and maintain good communication with your customers. Above all, keep your promises.

3. Sidestep resource issues: In this global economy of outsourcing, off-shoring, and contracting, there should never be a reason not to find the resources to get a particular job done. If you want to create a reputation as a “can do” customer-service-oriented team, there should never be a time when you need to say no to a service request because of lack of resources (but there may be other reasons to say no).

4. Choose your battles: Whenever you have the choice between a carrot and a stick approach, always use the carrot. You can, and should, carry a stick in terms of having the support of senior executives for any mandated processes or standards, but you should use the power as infrequently as possible. Sometimes this might even mean deviating from enterprise standards. One way to help you choose your battles is this exercise: Write down your integration standards on a piece of paper and stroke out one at a time, starting with the ones on which you would be willing to compromise if pushed into a corner, until you have only one left. That is the standard for which you should use your stick.

5. Take out the garbage: Accept responsibility for work that no one else wants. An interesting lesson learned is that many of the jobs that others don’t want are those that don’t serve a specific function but end up being ideal integration initiatives. Sometimes these also end up being difficult challenges, but generally management recognizes them as such, which opens the door to your asking for top-level support when needed.

6. Leverage knowledge: There is a well-known truism that states that “knowledge is power.” In an integration team you are ideally positioned to talk with just about anyone in the organization. By asking a lot of questions and being a good listener, you can gain a lot of knowledge about the organization that narrowly focused project teams or groups don’t have. This knowledge can come in very handy in terms of which projects get approved and where you shouldn’t spend your time, where next year’s budget will land, which groups are hiring and which aren’t, and so on.

7. Take it outside: Another aspect of leadership is active participation in the broader community, specifically, participation in standards bodies or professional organizations. The external activities can be useful both for getting new ideas and insights and for polishing your own ideas though discussion and debate with others. In the end, these activities can make you stronger individually, which can only help you play a leadership role inside your enterprise.

Important Practices That Help Enable Empowered Teams

Rotate Team Members into the Customer’s Shoes

One of the more difficult challenges for developers is to understand the business perspective. In other Lean business initiatives, people usually have an intuitive grasp of the customer and the products and services that customers need. Whether we’re talking about cars, health care, homes, or other tangible, everyday items, understanding the customer is not much different from understanding ourselves. For instance, in the automobile industry, everyone on the assembly line has driven a car before. Everyone has gone through the process of opening a new bank account. For so many different “products,” people have some sort of intuitive, commonsense grasp of what the customer might want, although this must never be completely substituted for constant interaction with and feedback from real customers.

In the IT world, however, “ICC, Inc.” serves the business community. What the business community requires to do its job is frequently more abstract and difficult for a software developer to understand. What business professionals do in the different organizational departments is often completely foreign to people in the IT department. This makes it seem as if the business and IT speak different languages.

People in the IT department who have a firm grasp of the business as well as a strong technical competence are usually some of the most valuable people on integration or quality projects. In some cases, these people came from a business function, or they came from system integrators where they had much more interaction with the business community. In any case, working toward a goal where people have the opportunity to walk in the shoes of customers has a tremendous benefit in developing and clarifying the vision of what will create customer delight. Additionally, this can be a good motivator and can help to build bridges and improve communication between the IT community and the business community.

Conversely, making some business analysts honorary members of “ICC, Inc.” has many of the same benefits. People pontificate about the importance of “business/IT alignment” to the point where nobody’s listening anymore, but rotating business and IT team members in this way can help facilitate this alignment.

Grow the Skills of Team Members

Many ICCs already understand the importance of growing integration skills to make team members more effective. But to make Lean Integration more effective, growth in other skills is important as well. The Poppendiecks state this succinctly: “Deskilling workers creates interchangeable people while upskilling workers creates thinking people.”⁹

9. Poppendieck, Implementing Lean Software Development, p. 228.

Continuous improvement and problem-solving skills are the hallmarks of success with Lean thinking. Chapter 5 discussed kaizen methods for continuous improvement, but there are also other problem-solving methods that are important for teams to use.

Lean thinking and continuous improvement require the ability to get to the root cause of problems. Often, attempts are made to solve issues by treating the symptom rather than the root cause. In many cases, the symptom was mistaken for the root cause.

One useful method for ensuring that you arrive at the root cause is the “5 Whys” method, which we should learn from our children. Young children drive us crazy sometimes, asking us why the world is the way it is. After each answer we give, they continue to ask “why?” Time and again, why, why, why? Finally, despite our best efforts at patience, we answer, “Because I said so.”

Lean thinking adopts this childlike approach to getting to the root of process problems. By continually asking “why?” to determine why a process works the way it does, at some point you reach the “because I said so” stage. At this point, back up one “why?” and you will find that the last answer is the root of the problem. With this root cause on the table, the team can begin to discuss alternatives for remedying it.

Incentives, Compensation, and Rewards

One of the most important practices to ensure empowered teams is appreciating that metrics, rewards, and objectives should emphasize team objectives. Personal performance should be judged in reference to performance within the team and the team’s success. Individual metrics around how many software objects someone created or how many bugs someone fixed should be avoided entirely. Group metrics are fine. Individual metrics are not.

The Poppendiecks add some advice to this discussion: “Eliminate annual performance ratings for salaried workers; do not undermine team cooperation by rewarding individual performance” and “If you have a [employee] ranking system in your company, a lean initiative will be hollow at best. The behaviors that ranking systems encourage are competition, hiding information so as to look good, and hiding problems so as not to look bad.”¹⁰ Stenzel reinforces this line of thinking: “Instead of motivating higher performance, extrinsic rewards actually put limits on what employees want to do and what they judge to be fair.”¹¹

10. Ibid., pp. 141, 143.

11. Stenzel, Lean Accounting: Best Practices for Sustainable Integration, Kindle loc. 2300–2301.

Judge quality based on the bigger picture, and improve the process to make the creation of quality problems less likely, because quality issues are a result of the process, not of someone’s personal performance. Individuals should be incented to help other members of the team, to coach and mentor others, and to participate in ways that benefit the bigger picture to support improving the value chain from the perspective of the customer. Individually oriented metrics and incentives can drive behavior that degrades positive team behavior.

We would do well to follow Stenzel’s advice: “It has been known for a long time that people are not motivated by financial rewards or stretch goals and targets beyond fulfillment of the basic necessities of life. They are motivated by work that uses their inherent creative capacity. In his classic Harvard Business Review article ‘One More Time, How Do You Motivate Employees?’ Frederick Herzberg makes the point that people are not motivated by targets, rewards, or negative reinforcement. The article states, ‘Forget praise. Forget punishment. Forget cash. You need to make their jobs more interesting.’”¹²

12. Ibid., Kindle loc. 1863–67.

Global Teams

Some of the most effective teams we’ve seen are global teams. Whether these are Open Source teams, IT teams that use offshore partners, or simply extremely large IT teams that span numerous time zones, the best global teams sometimes operate better than teams operating within the same building.

How does this happen? This happens through practicing constant communication and continual checkpointing and synchronization, and ensuring that no team members are treated as second-class citizens.

In today’s connected environments, the ability to share desktops and virtual whiteboard concepts is quite mature. Successful global teams don’t happen by accident or naturally; it takes effort and good habits on the part of the team members to make them work. But we’ve seen many cases where time zone differences can result in great productivity as long as synchronization points take place either daily or several times a week. Tossing specifications over the wall and working at arm’s length demonstrates the batch-and-queue mentality. With Lean Integration, remember our mantra is pull and flow. Using the 24-hour clock, some teams are seeing great advantages to working this way on bug fixes and other development initiatives.

Of all the Lean Integration principles, empowering the team may be the most important and the most difficult. Change takes time. While people may be motivated by the Lean Integration vision at first, sustaining and building toward true team empowerment and a learning organization takes years, not months. But getting started toward this objective can create a self-sustaining, self-improving trajectory, assuming it is nurtured and consistently emphasized along the way.

Organizing the Team: Thoughts on Organizational Structures

An organization’s structure must support enough hierarchy to facilitate accountability and responsibility, but not so much structure that the bureaucracy introduces waste by serving itself rather than the customer. Being Lean means not “overorganizing”: Division of work by specialization can lead to waste and a tendency to focus on maximizing individual resource utilization rather than minimizing customer lead times.

Typically, ICCs begin focusing on a particular class of integration, such as process integration, and grow the maturity of that capability before adding another class of integration, such as data integration. This is because the technologies and skill sets are a bit different. For an area such as application integration, ICCs frequently start by focusing on administration and operations of the integration environment, because these are the easiest places to start. In other words, for a fairly large organization, the ICC will install, upgrade, administer, and operate the integration environment while other project teams use the technology for their integration projects. This is a valuable improvement over the integration anarchy approach, where every project team chooses and administers its own technology (which is what makes the hairball grow so fast).

While providing administration and operations services for the integration environment does deliver significant value to large organizations, providing integration development and maintenance services with a Lean mind-set has a much higher payoff. The political barriers are higher, but the returns are higher as well. In some ways, this book is about applying Lean thinking to development and maintenance responsibilities in order to break out of the admin/operations rut where many ICCs find themselves stuck.

Once an organization has focused on improving its services for application integration, there are significant economies through skill and process sharing by taking on data integration as well.

Factors driving the organizational structure include the ICC model you select (shared services versus centralized services, for instance), the scope of responsibilities, geographic distribution of the team, strengths of the various team members, and corporate culture. If the team consists of fewer than a dozen people or so, you may not need any structure at all and simply have all the staff report directly to the ICC director. Figure 6.2 shows a typical structure for a medium-sized shared-services or central-services ICC, where the dotted lines around “Data Integration” and “Application Integration” suggest that the ICC may start with one or the other, rather than both, in the beginning.

Figure 6.2 ICC organizational structure

One of the critical factors in making Lean Integration initiatives successful is to establish the role of the chief engineer. Sometimes, particularly in smaller organizations, this role may be owned by the person who is the ICC director, but the key is that this person has responsibility for delivery of solutions. Put another way, the chief engineer is the hands-on “chief integration architect”; people in this position roll up their sleeves and get their hands dirty in the trenches. This person has a deep understanding of the vendor integration tools in play and looks for the existence of patterns throughout the integration projects. Above all, the chief engineer is accountable for the success of the ICC’s output from the customer’s perspective.

Governance committees can be the bane of Lean Integration. The objective of any governance committee is important, but being Lean means finding ways where the process of achieving that objective doesn’t interfere with the satisfaction of the customer. Having a chief engineer helps to ensure that governance committees are not used as an excuse for delays and waste because of distributed accountability.

In a larger ICC, the data/metadata management team is responsible for the development of shareable objects and services, as well as growing the capabilities of the metadata management system that in turn enables visual management capabilities. Administration/operations is responsible for the integration infrastructure components, and the one or more integration teams work on the development and maintenance of the different styles of integration projects.

Everyone on the different teams is involved in the constant, continuous improvement of the value streams associated with customer delivery. Organizational structures need to support and not hinder that primary imperative.