CUTTER BUSINESS TECHNOLOGY JOURNAL VOL. 30, NO. 1
Lean is the term the Western world has come to use for the Toyota Production System (TPS). Created by Taiichi Ohno, TPS aims to reduce the time between a customer order and payment for the delivery of a vehicle by “reducing the non-value adding wastes.” While so much of Toyota’s success has been attributed to the mechanics of TPS, there is more to it than that. Jeffrey K. Liker, professor of industrial and operations engineering at the University of Michigan and author of The Toyota Way, states that “Toyota’s continued success … stems from a deeper business philosophy based on its understanding of people and human motivation.” While 21st-century technology leaders may not be in the business of manufacturing cars, I think we can all agree that they are in the business of leading people!
The Toyota Way is characterized by “management commitment to continuously invest in its people and promote a culture of continuous improvement.” Its two pillars are respect for people and continuous improvement (see Figure 1). The themes of people and continuous (or “relentless”) improvement also appear in the Scaled Agile Framework® (SAFe®)1 and the Lean System Society’s House of Lean for the 21st Century (see Figure 2).
In the House of Lean for the 21st Century, the roof represents the goal: delivery of value, in the sustainably shortest lead time with quality, high morale, safety, low cost, and most customer delight. This is supported by four pillars:
- Respect for people and culture
- Relentless improvement
Leadership is depicted as the foundation of the house.
4 Pillars, 12 Habits
The values contained in the House of Lean for the 21st Century give us guidance as to the mindset required to succeed, but it takes concrete practices to bring these values to life. Given that leadership is the foundation of Lean, the effective Lean leader needs to form habits that align to the pillars that support the goal.
Pillar 1: Respect for People
Habit 1: Invest in the People Who Do the Work
Effective 21st-century technology leaders invest in the people who do the work. In its simplest form, this means providing training when introducing new tools or processes. A common anti-pattern I encounter when working with technology leaders is a reluctance to invest in training — which frequently turns into adamant refusal if it means training for people who are not permanent employees of the company. I suspect the main reason for this attitude is that technology leaders often are not allocated sufficient budget for training. Getting the budget can be tough, but it’s a battle that 21st-century technology leaders know they need to fight.
Many times the need for training is linked to a change in process or technology that the organization believes will provide a competitive advantage, likely in support of some business case. This business case needs to include the cost of upskilling the people who will actually do the work. If a change is being imposed on your organization and the training cost has not been factored in, you will need to champion the cause. If you don’t look out for your team, who will?
As for training people who are not permanent employees of your company, I don’t think you have a choice. If you rely on these people to do the work, then they need to have the requisite skills. I understand the reluctance. You pay a premium for contractors and consultants, so you expect them to have the skills you need to get the job done. I can remember thinking that myself when I introduced Agile to a technology team I led. Then I got real.
I thought about replacing my current workforce with people who had Agile training, but then I remembered that the people currently on the team had been working in the domain a long time. Some of them had been there since the department was established. They had a lot of tacit knowledge that in many ways was irreplaceable. My next idea was to insist that the contractors and consultants arrange their own Agile training. Then I realized that this meant everyone would most likely get different training, and that seemed less than ideal.
In the end, I decided to pay for everyone to take part in the same training. In the scheme of things, it was a small investment, and more importantly it was the right thing to do. This was borne out by the results: the team became more open to new ideas and eager to learn, and practices that we had previously struggled to embed were readily adopted once the team had a shared understanding of the principles that underpinned the practices.
Habit 2: Eliminate Wasteful Work
There is nothing quite as demoralizing as doing work that is avoidable or not valued. Organizations are riddled with people toiling away on tasks that could be streamlined, automated, or stopped if a leader just took the time to review the work and take action. To be clear, I’m not advocating micromanagement. I am advocating a world in which we believe that the people we lead are intelligent and can recognize where there is waste present in the work that they do. As a leader, what vehicles do you provide to surface this waste and address it?
Recently, I was working with a leader, Marc, who came to recognize his team was overloaded with wasteful work. As part of introducing SAFe® to his organization, Marc’s team was holding their first PI Planning event.2 He asked team members to “bring out the dead” and make visible all the “business as usual” tasks that were consuming their time. He then set himself up in a booth at one end of the planning room and invited people to bring him the routine tasks that they perceived to be of low value so that he could support them in negotiating with stakeholders to cease the work (see Figure 3).
Habit 3: Foster a One-Team Culture
The 21st-century technology leader needs to calibrate their definition of team to encompass all the people who contribute to the delivery of technology products and services, regardless of whether they come from business or technology. This team — or more likely, team of teams — needs to understand that their fates are inextricably linked and that they succeed and fail as one team. How you lead this team of teams will have a significant impact on the level of “oneness” across the team.
In a team-of-teams scenario, it is important that there be a shared identity. There can be no “us” and “them” in a one-team culture. Things as simple as choosing a name for the teams of teams and creating a team t-shirt will start to provide a sense of shared identity. Establishing rituals to help the members of the team of teams build relationships is also key. My favorite is an event I like to call “Unity Hour.” This one-hour, all-hands gathering, held on a fortnightly or monthly cadence, creates a place for the team of teams to come together and interact on an informal basis. How you celebrate wins is another way you signal to the team of teams who is and is not part of the team. Do you celebrate individual team successes as a team of teams? You should.
Pillar 2: Flow
Habit 4: Visualize Your World
Visualization of a given team’s work has become prevalent in the technology world as Agile and Lean practices become more and more commonplace. The 21st-century technology leader uses a similar approach to visualization to assist in seeing the work across the entire department or program. There is no one-size-fits-all visualization template; however, Kanban-style physical walls are a good place to start. Constructing a good visualization requires understanding the path work takes when it flows through your department or program. The people who do the work are best placed to help you understand this flow. Even if you think you know how the process works, you will most likely be surprised when you hear about the reality.
Two visualization techniques that Lean technology leaders I have worked with find useful are:
- A view of the demand coming into their department or program
- A view of the work currently being delivered by their teams
Creating a card for each work item and displaying the cards on a physical wall can be extremely powerful. It allows the leader to see if their teams are overloaded or likely to run out of work. Once you can see, you can take action and live “respect for people” by smoothing out the demand to avoid either drowning your teams or having to stand people down due to lack of demand.
The second physical visualization of the work your teams have in flight replaces more traditional approaches to understanding progress, such as program status reports or Gantt charts. Unlike traditional approaches, this view can highlight bottlenecks in your process as cards pile up in specific columns. This style of visualization is generally maintained on a near-real-time basis by the people who do the work. Often leaders will introduce some sort of communication cadence by which teams share their progress and challenges with each other, using the wall to guide their discussions.
Habit 5: Limit Work in Process
The visualizations in Habit 4 also aid the 21st-century technology leader in limiting work in process (WIP). While it may feel counterintuitive, limiting the amount of work your team is actively working on will improve the flow of value to your customers. This can sometimes be tricky, as saying no — particularly to senior stakeholders — can be politically awkward at times. The existence of physical visualizations can help you manage it, though. Show your stakeholders your visualizations to provide context. Let them see what other demand your department or program is facing. Perhaps they can help you negotiate with other stakeholders to reduce demand, or they may even find, in context, that their request is not as valuable to the company as other requests being made of your team.
If all else fails, you might try a tactic one of my teams tried on me. I had a continuous improvement wall full of initiatives I was championing. In an effort to reduce WIP, my team told me I could only have 16 ideas on the board at any one time. I was most unhappy, as I was sure I had many more than 16 good ideas! Rather than fight with me, they created another column on the wall. They called it “The Pit of Fantastic Ideas” and told me I could put anything I liked in there, but they would not work on those ideas until they were prioritized into the top 16 ideas on the main board (see Figure 4).
Every few months, I would visit my Fantastic Ideas, and without fail I would find that many of them had become irrelevant as time had moved on. So it would appear my team had been onto something with this WIP-limiting idea. What I like most about that story is not that my team was right, but how they managed me. Instead of fighting me, they humored me, and that way I got to learn for myself how limiting WIP works.
Habit 6: Decentralize Decision Making
A significant impediment to flow in most organizations is the hierarchical nature of decision-making authority. Every time a decision has to be sent further up the management hierarchy, there are two potential negative side effects: (1) the decision is delayed, impeding flow, and (2) the person making the decision is likely less informed about the specifics of the situation than the person requesting the decision. Technology leaders are sometimes at the mercy of such dysfunction, and at other times they are the cause.
While you may not be able to change the limits on your own delegation of authority right away, you can and should work to empower the people on your team. If this is new territory for you, it is perfectly natural to be nervous. I am not suggesting you immediately abdicate responsibility for decision making.
In his autobiographical book Turn the Ship Around! retired US Navy Captain L. David Marquet wrote about his experience with giving control to the people who do the work. Marquet describes two pillars that enable “giving employees control over what they work on and how they work”: (1) the technical competence to make the decision, and (2) clarity regarding the organization purpose to which to align the decision. With these two supports in place, you can “move authority to the information,” enabling faster decision making and better flow.
Pillar 3: Innovation
Habit 7: Carve Out Time for Innovation
In this age of digital disruption, innovation is core to the survival of every organization. Carving out the time to invest in innovation, however, seems to be a universal struggle. You need to build time for innovation into the way your organization works. This means building innovation time into your cost models; somewhere between 10% and 20% of your team’s’ capacity is a good rule of thumb. With that in hand, your next job is to inspire creativity!
I have always taken a very broad view as to how innovation time should be invested. People can pursue anything from a cool new feature or product for customers, to a nifty automation that makes it easier for teams to do their work, to an investment in learning a new tool or technique. There are two goals here — to enhance the company’s ability to compete in the market and, perhaps more importantly, to create a workplace that people want to be a part of. While innovation helps an organization compete in the market, it can also unlock the intrinsic motivation of knowledge workers, which again brings “respect for people” to life.
When it comes to inspiring creativity, Atlassian’s ShipIt — formerly known as FedEx Day — continues to be an inspiration to many organizations. Once a quarter, teams are given 24 hours to work on whatever they want, but they must “ship it” at the end of 24 hours (hence the original name). The concept became widely known as a result of its inclusion in Daniel Pink’s bestselling Drive back in 2009. Atlassian credits ShipIt as the source of some of its “coolest stuff,” as well as for helping the company retain people. A similar approach I like to use is called the “Innovation Challenge.” In this model, teams invest their “spare” capacity in innovating, sharing their results with their peers at Unity Hour, where a vote is taken for the best innovation and the winner of the Innovation Cup.
Habit 8: Apply Validated Learning
When it comes to product innovation, great ideas are not enough. No matter how innovative your ideas are, if you can’t sell them, then you don’t have a business. This is a lesson that entrepreneur and author Eric Ries learned the hard way, more than once. From these earnings came his bestselling book The Lean Startup, in which he calls out validated learning as one of the five principles of the Lean startup method. If you work in a large corporation, you may be thinking that the Lean startup approach does not apply to you. Before you skip ahead to the next habit, though, let’s consider Ries’s definition of a startup: an organization dedicated to creating something new under conditions of extreme uncertainty. I will let you decide for yourself whether this applies to you.
Ries argues that everything a startup does should be “an experiment designed to achieve validated learning.” In The Lean Startup, Ries uses the beginnings of Zappos to illustrate the point. Zappos founder Nick Swinmurn started the company with the hypothesis that people wanted to buy shoes online. He then ran an experiment in which he listed shoes from local shoe stores on a website with the intent to buy them and ship them if they sold, which of course they did! This experiment allowed Swinmurn to validate his concept and learn about customer behavior before making a large investment in his new business idea.
Habit 9: Use Built-In Instability to Foster Creativity
In 1986, Harvard Business Review published the article that is credited with being the roots of Scrum, the world’s most widely used Agile framework. In the “New New Product Development Game,” Hirotaka Takeuchi and Ikujiro Nonaka identified six characteristics being used by teams that were delivering breakthrough new products to market quickly. One of these characteristics is “built-in instability,” a practice whereby management “offers a project team a wide measure of freedom and also establishes extremely challenging goals.” This unlocks intrinsic motivation, from which emerges creative new solutions.
Again, we can see that technical competence and organizational clarity create an environment where leaders can give control to the people who do the work and get great results. All that’s still needed is a clear and inspiring mission for the people who do the work. The teams you lead need to understand how the work they do is connected to the greater organization’s vision. This is what brings the organizational clarity.
Pillar 4: Relentless Improvement
Habit 10: Understand the System of Work by Spending Time at the Gemba
As a technology leader, it may have been some time since you were last “on the tools.” Or perhaps you are one of the rare breed of technology leaders who don’t come from a technical background. Either way, you are not apt to have a real appreciation of what it is like to work in the “system” that is your organization. To be an effective 21st-century technology leader, you need to address this blind spot, and the best way to do that is to spend time at the gemba.3
The concept of the gemba walk comes from Taiichi Ohno. As legend has it, he would indoctrinate new managers at Toyota by taking them down to the factory floor, drawing a chalk circle on the ground, and placing the manager in the circle. He would then leave the manager there for a shift to observe what was happening, checking in with them occasionally to see what they had learned or observed. If the student did not meet Ohno’s standards, they would be brought back to repeat the exercise the next day.
While Ohno’s approach would probably make the average knowledge worker uncomfortable, spending time at the gemba to observe and learn is invaluable for leaders. Rather than standing in a circle, go and talk to the people who do the work about how the work works. If you are feeling inspired, take a blank piece of paper and sketch out the value stream map for the technology products your team delivers. You can even take it a step further and engage your peers in a value stream workshop to understand how your team contributes to the whole value stream.4
Habit 11: Improve the System of Work
Given that the 21st-century technology leader is most likely not “on the tools,” they must add value to the organization in other ways. In my view, the role of the 21st-century technology leader is to improve the system of work for the people who do the work. First, the leader needs to gather the facts. Both spending time at gemba and value stream mapping will provide a multitude of improvement opportunities.
Another approach I use is to ask teams what impediments they are facing in doing their work. Some problems will be simple and rather tactical in nature. Others will be more complex and require significant investment of time and money. Your role as a leader is to take action. Sometimes that action will be a quick email or phone call; other times it will be developing a business case to acquire funding. Ideally, you will create a visualization that helps you track the demand and progress such as the one shown in Figure 4. This also provides transparency to the team regarding your progress — or lack thereof.
Habit 12: Read Books
Successful people read books. The effective 21st-century technology leader knows this and is a lifelong learner. If I were to prioritize the habits I’ve discussed here, reading books would be my pick for number 1. You may have noticed as you made your way through this list that a number of the habits make reference to learnings from books. When I first became a technology leader, I had no formal education in technology, but I was committed to learning. I read everything I could, then I took my learnings and discussed them with my team. We would debate the pros and cons of applying various ideas from books we had read. The ideas we agreed on we tried. Some worked and some didn’t, but we never stopped reading, and we never stopped experimenting. In the words of Verne Harnish, founder of the Entrepreneurs’ Organization: “Those who can read and don’t are only marginally better off than those who can’t.”
Now you are armed and dangerous. You have a dozen new practices to help you make this year your best year as a leader yet. Remember to apply the habits when implementing the habits — make your work visible, limit your work in process, apply validated learning, make space for innovation, and never forget that technology leadership is all about people!
1 The Scaled Agile Framework® (SAFe®) is a freely revealed knowledge base of integrated proven patterns for implementing Agile at scale (scaledagileframework.com). SAFe andScaled Agile Framework are registered trademarks of Scaled Agile, Inc.
2 PI Planning is a two-day, all-hands planning event in which teams visualize their planned work for the next 8- to 12-week program increment (PI).
3 ”Gemba” is a Japanese word for “the real place” where the work is done.
4 For an excellent approach to running an event like this, see Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation.