10 Signs You Are Ready For A New Challenge

Liz Wiseman's new book, Rookie Smarts, jumped onto the Best-Selling Books Hardcover Business List  at No. 7 (week ended October 19), as reported in The Wall Street Journal.

Her book is all about living and working perpetually on a learning curve.  She contends that we do our best work when we are new to something.  And, she teaches us how to reclaim and cultivate the curious, flexible and youthful mindset called "rookie smarts."

"Something magical happens when a skilled veteran successfully re-learns his rookie smarts and is still able to retain his veteran acumen," explains Wiseman.

Wondering if you are ready for a new challenge?  Take a look at this list from Wiseman of the 10 signs that indicate you are ready for a new challenge:

1. Things are running smoothly.
2. You are consistently getting positive feedback.
3. Your brain doesn't have to work hard to be successful.
4. You don't prepare for meetings because you already know the answers.
5. You've stopped learning something new every day.
6. You are busy but bored.
7. You're taking longer showers in the morning and you take your time getting to work.
8. It makes you tired to think you could be doing the same job a year from now.
9. You've become increasingly negative and can't identify why.
10. You're spending a lot of time trying to fix other people's problems.

Wizeman is a researcher, executive advisor, and speaker who teaches leaders around the world.  One of her earlier books is, Multipliers:  How the Best Leaders Make Everyone Smarter.

Thanks for the book publisher for sending me a review copy of the book.

The 27 Challenges Managers Face

Take a look at the list below.  How many of these 27 management challenges are you facing right now? And, how many do you believe you'll face during the next year?

1. Going from peer to leader
2. Coming from the outside to take over leadership of an existing team
3. Bringing together an entirely new team
4. Welcoming a new member to your existing team
5. Helping an employee who has a hard time managing time
6. Assisting an employee who needs help with interpersonal communication
7. Getting an employee more organized
8. Helping an employee who needs to get better at problem solving
9. Working with an employee who needs to increase productivity
10. Helping an employee who needs to improve quality
11. Managing an employee who knows more about the work than you do
12. Showing an employee how to start "going the extra mile"
13. Working with an employee who does "creative work"
14. Helping an employee make an attitude adjustment
15. Managing conflict between and among individuals on your team
16. Dealing with an employee who has personal issues at home
17. Keeping a superstar engaged
18. Retaining a superstar
19. Losing a superstar in the best way possible
20. Developing a superstar into a new leader role
21. Managing in an environment of constant change and uncertainty
22. Managing under resource constraints
23. Working through interdependency
24. Working around logistical hurdles
25. Managing across differences in language and culture
26. Renewing your management relationship with a disengaged employee
27. Renewing your own commitment to being a strong, highly engaged manager

If you selected one or more of these challenges, then Bruce Tulgan's new book, The 27 Challenges Managers Face, is the book to add to your "to read" list.

Because, Tulgan provides step-by-step solutions and practical advice for handling all 27 challenges listed above -- the 27 most common challenges identified by Tulgan during 20 years of workplace research.

Tulgan is also the founder and CEO of RainmakerThinking, Inc., a management research and training firm.

Tulgan is the author of, It's Okay to Be the Boss and Managing Generation X.

Thanks to Jossey-Bass for sending me a review copy of Tulgan's latest book.

Nine Times To Thank A Customer

In your leadership role, it's vital that your team members know how to deliver excellent customer service. "Knock Your Socks Off" type service as book editor Ann Thomas and Jill Applegate would say.

Part of delivering excellent customer service is saying "Thank You" to your customers and knowing when to say "Thank You".

Thomas and Applegate recommend telling your customers "Thank You" during at least these nine situations:

1. When they do business with you...every time.
2. When they compliment you (or your company)
3. When they offer you comments or suggestions
4. When they try one of your new products or services
5. When they recommend you to a friend
6. When they are patient...and even when they are not so patient
7. When they help you to serve them better
8. When they complain to you
9. When they make you smile

You and your team members can say "Thank You":

• Verbally
• In writing (and don't underestimate the power of personal notes via snail mail)
• With a small, tasteful, appropriate gift

What is a CIO?

I needed to develop a clear definition of my job as CIO to a new boss recently. Initially my plan was to do a quick check of the internet, look for a good definition and pass it on. Wow - was I disappointed! 

After having been a CIO for over a decade, I could not find a decent description of the job. I realized I had to put the effort into writing what I thought was a realistic description of role. So here it is:

The role of a CIO is to create, implement, and sustain an information systems vision for the organization. Implementation of the vision requires integration of the people, processes, data, and technologies from across the organization needed to deliver information systems. Success is measured by realizing the benefits and controlling the risks of information systems throughout the organization by managing value, volume, and quality.

To accomplish this role, the CIO needs to be allocated certain non-negotiable responsibilities including:

• Strategy and planning for the future of information systems in the organization,
• Stewardship (governance) of information systems decision-making processes,
• Investment portfolio management of information systems projects, 
• Organization structure required to support information systems,
• Ethics and principles needed to create acceptable information systems standards,
• Leadership of ICT directly, and other IT units indirectly,
• Information systems policies, principles, and procedures,
• Quality of operational systems, and
• Adapting the organization to the inevitability of process and technology induced change.

No discussion of the CIO's role is complete without outlining the scope of the role. In any organization the CIO mandate includes all information systems at the organization, not just the central information systems department. The CIO creates the information systems context needed to deliver the clients’ content, which encompasses all aspects of all information systems used in any dimension of the organization.

To deliver on the role and scope that I have defined, a CIO's mandate must include certain core functions:

• Develop and sustain all information systems supporting the organization's core mission,
• Implement any new system software, continuously improve production application systems, and provide organization-wide data stewardship to enable the business needs of the university,
• Design and manage an enterprise architecture mapping all the technologies, applications, and data for present and future systems at the organization,
• Create, enhance, and support the technical infrastructure of the organization,
• Ensure the privacy, security, and legislative compliance of information assets are diligently and proactively protected,
• Implement project management tools and skills to ensure consistent delivery of information systems investments (projects) on time, in scope, and within budget, and
• Continuously improve operational processes needed to support and run information systems.

Hopefully this short description helps anyone else trying to do the same search I attempted. 

~

The Scaling Dilemma

“One of the most scalable organizations in human history was the Roman army. Its defining unit: The squad – eight guys. The number of guys that could fit in a tent,” says Chris Fry, who knows a bit about scaling. He led software development at Salesforce.com during its years of hyper growth, and is now SVP of Engineering at Twitter. Fry found that the way to build a scalable organization is to focus on the basic building blocks – small, stable, multidisciplinary teams that are expected to independently tackle problems, make decisions, and get things done. Fry advises, “When it comes to building a deeply efficient engineering organization, there are several things you can do to move the needle:

• Build strong teams first. Assign them problems later.
• Keep teams together.
• Go modular. Remove dependencies.
• Establish a short, regular ship cycle.”[1]

Amazon.com works on the same principle. Its basic unit is the two-pizza team – a team small enough to be fed with two pizzas. When Amazon needed to scale, two-pizza teams were chartered to build Amazon Web Services, one service per team. A team includes everyone needed to design, deliver, and support the service – from specifications to operations. If a service is too large for a two-pizza team, Amazon prefers split the service into smaller pieces rather than to combine teams to deal with the larger service, because this preserves the dynamic interactions of small teams.

What Could Go Wrong?

If it works for Salesforce, Amazon and Twitter, surely it will work for you… So you form a lot of small, independent, multidisciplinary teams and you are careful to give them all clear goals. What could go wrong with that?

August 27, Scene 1

“Hi Owen, how’s it going?”

“Just great! We’re going to make our target. We got the last piece done overnight. We’re working on integration testing right now. We’ll have it ready to release tomorrow. Lucky for me, because this month I really need that bonus.”

August 27, Scene 2

“Hey George, I hear you had a shutdown last night.”

“Yeah, we got things up fast, but it still counts against our shutdown limit. It’s the last one we can afford this month, if we want our bonuses. So there won’t be any more.”

“Do you know what caused it?”

“The usual. A new release from development. A naive piece of code, the kind of thing you can’t test for. Anyway, it’s fixed.”

“And you’ve made sure they won’t make that mistake again?”

“Nah, they don’t want to listen to us. We’re just not going to put up any more releases until September. We’re not going to miss our target.”

“But I hear they have another release almost ready to go.”

“Over my dead body.”

The Dilemma

It is a beautiful thing when the building block squads of an organization gel into high performance teams and can be counted on to meet challenging goals. But tricky part is, once you create these strong independent teams, how do you get them to work together? How do teams maintain their autonomous character while working in concert with an increasingly large network of other teams? How do you make sure that each team has a clear goal, but none of the goals are in conflict?

In a lean environment, the leader’s role is to set up strong teams, to be sure, but it is also to devise a system – let’s call it a goal system – which assigns goals to teams. This is no easy task. Teams need clear, meaningful goals; they have to be the right goals; teams must have the capacity, capability and autonomy to achieve their goals; and most important, the goals of various teams cannot conflict with each other.

One thing we know for certain is that local goals create local optimization. So it’s clear that the start of a goal system is a system-level, unifying goal. Something that conveys the purpose of the work, the why. Some way to confirm that progress is being made – at the team level – toward achieving the overall purpose. Of course, this is a lot easier said than done.

The Goal System

Many companies use projects to set up a goal system. A project manager lets the team know what the project goal is and what everyone needs to do to reach the goal. If there are several competing projects, a Project Management Office (PMO) is added to manage the project portfolio and distribute corporate goals among projects. However, there are problems with the project approach. You don’t often see stable teams in a project company, because people are usually assigned at project start and reassigned at the end. Worse, people are often assigned to multiple projects with competing demands on team members’ time. Finally, since most projects are conceived of as a relatively large batch of work, project teams tend to be quite a bit larger than a squad of eight to fourteen people. So the basic building blocks of scale – small, intact, multidisciplinary teams – are rarely found in a project environment.

One of the things Scrum has contributed to the practice of software development is the idea that small autonomous teams perform much better than large project teams or single-discipline teams that work in sequence. So Scrum provides the building blocks of scale, but unfortunately, it does not contain a scalable system for choosing team goals, making sure they contribute to organizational goals and are in sync with the goals of other teams. So we need to look elsewhere for ways to set up a goal system.

The Theory of Constraints

People with a lean mindset might look to the Theory of Constraints (TOC) for guidance on choosing and communicating team goals because it has a good track record for directing the efforts of multiple teams toward a single goal, at least in manufacturing.[2] TOC starts with the assumption that in any system there will always be a constraint that gets in the way of achieving the system goal, and the way to keep teams working toward the overall system goal is to be sure that everyone is focused on getting more work through the system constraint. Let’s see how TOC might be applied to developing a software system.

When the Constraint is Technical

The first step – after clarifying the overall system purpose and goal – is to find the biggest constraint to achieving that goal. For purpose of discussion, let’s choose one of the most typical technical constraints encountered in delivering a software system: the integration of various components of the system without the introduction of defects or unintended consequences. In fact, project organizations typically allocate a third or more of the project time to release overhead – including integration, testing, fixing defects, and deployment – with the largest portion going to finding and fixing problems discovered during integration. When integration is the system constraint, TOC tells us that the most important focus for development teams should be removing this constraint.

Agile approaches to software development recommend the frequent delivery of working software to customers. When this recommendation is followed literally (software is released to end customers frequently), the integration constraint is regularly exposed and has to be confronted. One of the earliest agile approaches, Extreme Programming (XP), includes technical practices such as Test Driven Development and Continuous Integration that help make frequent releases practical. Continuous Delivery[3], which expands on these practices, has gained widespread favor as the agile approach which explicitly focuses on the integration constraint. In Continuous Delivery we find actionable advice on how to tackle the integration problem with techniques that scale across large networks of teams.

The objective of Continuous Delivery is to dramatically increase the number of times integration occurs while decreasing the amount of time it takes to negligible levels. This has the same effect that just-in-time flow does in manufacturing: the impact of defects is reduced to near zero because they are discovered immediately before they can propagate or hide. The problem is, a much wider swath of an organization needs to get involved in Continuous Delivery than is typically found on a development team. The system architecture has to be devisable, the marketing department has to figure out how to deal with frequent deliveries, the development and operations departments have to work closely together.

The Theory of Constraints can help here. If the constraint is integration, TOC recommends that we measure the rate at which work moves through the constraint – in this case the rate at which completely integrated and tested software is released to production – and make improvement of this rate the goal of every team involved in the system. It turns out that a throughput measurement on the system constraint is a great metric for team goals because it is easy to measure, provides immediate feedback, and is structured to result in improved system-wide performance. If everyone working on a system is trying to stabilize and improve the rate at which tested, integrated software is successfully released to end customers, then teams across the system will naturally have to work together and will find that their goals are compatible.

When the Constraint is Knowledge

More often than not, however, technical issues are not the biggest constraint in system development and the fundamental problem is not an integration problem, it is a design problem or a fitness-for-use problem. Far too often we end up with a system that doesn’t work well or is difficult to use. In this case, the biggest constraint in developing software systems is the way in which we decide what to build and parse that decision amongst the teams doing the work.

Project organizations spend a good deal of time deciding what to do and turning these decisions into goals or requirements. However, this activity is front-loaded into the beginning of the project, while verification that the project requirements are correct waits until the project is complete – too late to make changes. Most project organizations consider deciding what to build to be an execution problem rather than a constraint. They would say: It’s unfortunate that project goals and requirements are sometimes wrong, but the way to fix this is to work harder on getting them right before the next project.

Organizations with a lean mindset would frame the problem differently. They are likely to identify the biggest barrier to making good decisions as incomplete knowledge, and thus the biggest constraint of the system would be the rate at which knowledge is generated. So a lean organization would focus on the feedback loop between customers and development teams. They would decrease the length of the feedback loop, increase the speed of the feedback loop, and remove barriers to the free flow of information inside the feedback loop. These organizations would say: If we can test our assumptions and designs more quickly we will learn faster and make better decisions.[4]

No More Politics

One of the signs that teams have conflicting goals is negative politics. A good way to eliminate political wrangling is to get teams to work together toward a unifying goal and to show team members the impact of their actions on that goal – in real time.

August 27, Alternate Scene

“Hi George, I noticed a little glitch in the last night’s graph so I thought I’d check to see if anything went wrong.”

“Oh hi, Owen. Glad you stopped by. As a matter of fact, we did have a shutdown last night, but we were lucky and caught it right away and got things back up fast enough we didn’t lose any customers.”

“So what caused it, do you think?”

“It was a database lockout. It seems to happen a lot about six to eight hours after a new release. When we find it we do a workaround that lasts until the next release.”

“Whoa! That means it’s something in the code that isn’t getting caught in testing.”

“Well, yeah! There’re a lot of problems in code that only come out during production.”

“Um, well, we worked late last night to get that feature ready that Chris asked for. Do you think we can do another release tomorrow?”

“Well Owen, let’s take a look at the graph. You see last night there was a downward spike here, where we closed down the site and no one could use the app. But we got it up so fast that almost everyone was still around and we could just reconnect them. It was the middle of the night here, so we mostly had browsers in Europe and Asia. We don’t have many customers there – yet. But what if we hadn’t caught it so fast? In five minutes we would have lost maybe half of the people using the app. What if it had happened during the daytime here? That spike would have been an order of magnitude bigger, and we would have lost a lot more people. It’s one of our busiest seasons, right before school starts. Do you really think we should take such a risk?”

“But George, we have to do it sometime. Sooner is better than later.”

“Not the way I see it, Owen. The fewer releases we put out, the fewer customers we’re likely to disrupt.”

“Okay, I see your point, but we’ve got to fix that problem so we can release frequently, because new features are what drives that graph up higher.”

“Not if the system crashes, they aren’t.”

“Whatever. We still have to fix the problem.”

“Yeah, so how do you propose we do that?”

“How about a side-by-side release with a trigger that knocks out the new system if it gets flaky?”

“Easy for you to say, Owen. You don’t have to make it happen.”

“But if I could make it happen, would you let me?”

“Sure, why not? But it won’t be easy.”

“How about I get with the team and tell them that in order to have a release, we have to write some failure detection and recovery code, and babysit the next release around the clock to be sure it works.”

“Can’t hurt to give it a try.”

The Unifying Goal

A network of strong teams is the first step to scale. The second step is to set up a system that distributes goals to teams in a way that avoids goal conflict. One good way to do this is to find a goal that is the final arbitrator of ‘good,’ make it visible to all teams in real time, and hold teams responsible for it.

The purpose of throughput accounting in the Theory of Constraints is to create just such a unifying goal. Simply stated, throughput accounting provides a measurement of the rate at which an organization achieves its purpose. This rate is effectively the same as the rate of throughput at the system constraint, so teams working to improve throughput at the constraint or to improve overall system impact are working toward the same goal. Either way, a single unifying goal allows individual teams to act autonomously, confident that they are not working at cross purposes with other teams.

What if you cannot find a unifying goal that represents the system constraint, or if a team’s work has no apparent impact on that goal? Over time it would be better to move to a decoupled architecture so that individual teams can have an impact on the overall system goal. But in the meantime, each team should monitor the impact of its work on its immediate customers. The question is not: Did the team complete its work? The proper question is: Did the team give its immediate customers what was needed, when it was needed, in a state that allowed the downstream teams to perform their work well?

Finally, remember that scaling is a two way street. If you think that scaling gives you problems as a leader, imagine the problems it brings to other people in the organization. It’s fun to work at a small company where everyone knows what’s important and works together to make the company successful. But as the company grows, people at all levels are in danger of losing their line of sight from what they are doing to the company’s success. This limits their ability to act with initiative to bring about that success, and thus undermines their engagement. You can’t scale unless you keep all of the bright minds in the company engaged and working together to help the company grow.
______________________________

Footnotes

[1] From First Round Review: Unlocking the Power of Stable Teams with Twitter's SVP of Engineering.

[2] I was reminded of this as I read Tame the Flow by Steve Tendon and Wolfram Müller, which provides a nice summary of how the Theory of Constraints in general, and throughput accounting in particular, can generate much better team goals than either the work-bin WIP limits of Kanban or the cost/profit focus of traditional cost accounting.

[3] See Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and Dave Farley (2010), and Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale by Jez Humble , Barry O’Reilly, and Joanne Molesky (2014).

[4] It’s interesting to note that Continuous Delivery is an excellent way to address the knowledge constraint as well as the technical constraint of software development.

11 Ground Rules For Meeting Behaviors

While recently reading C. Elliott Haverlack's new book, Unbundle It, I found his 11 ground rules for meeting behaviors to be particularly helpful:

1. Arrive on time.
2. Be respectful of other attendees.
3. No phones or computers if at all possible.
4. No leaving the meeting or getting up to walk around until scheduled breaks.
5. No eating unless during working meal meetings (consuming beverages as appropriate is acceptable).
6. No side conversations.
7. Good posture.
8. Listen intently (even if you don't want to).
9. Ask questions at the appropriate time.
10. No filibustering.
11. Take notes.

Artist Island

Once there was an island called Artist Island. The people on this island made a very good living by gathering stones from Stone Island, forming them into stunning jewels and selling the jewelry to people in the Land of Festivals. At first, people from Artist Island visited the Land of Festivals to see what kind of jewelry would be popular and then scouted out the right kinds of stones on Stone Island. But that was not a very efficient use of the time of these excellent artisans, so after a while the people from Stone Island were asked to bring their stones to Artist Island. Later, to further improve efficiency, the Stone People were asked to deliver the finished jewelry to the Land of Festivals. Since the Stone People were now the ones in contact with the Festival People, they became responsible for ordering the jewelry as well.

The people of Artist Island continued their search for efficiency. It took a long time to shape a pile of stones into a pile of jewels, and by the time a pile was done, the Stone People complained that the designs were out of date. So the artisans learned about Lean and decided to reduce work-in-progress. They worked on stone piles for no longer than two weeks, and brought smaller piles of jewels to the boat dock for shipment to the Land of Festivals.  However, the transport boats were still quite large and took some time to fill up, so it still took a long time for jewelry to get to the Festival People, and the designs were still out of date.

Then the Stone People came up with an idea. If they invested in smaller boats, they could deliver jewelry to the Land of Festivals in much smaller batches, shortly after it was made. Gradually they switched from large boats to small boats, and as they did, they started using the same small boats to deliver stones to Artist Island. Now a stone could be dug out of a mine, taken to Artist Island, formed into a jewel and delivered to the Land of Festivals in about a month. The jewelry designs were much more up-to-date, and sales improved.

But there was still a lot of unsold jewelry in warehouses in the Land of Festivals, because sometimes the jewels had flaws and sometimes the artisans didn't understand what the Stone People were asking them to make. Quite often the jewelry was boring because the Stone People weren't aware of the many marvelous kinds of jewels that were possible, so they didn't order many interesting designs.

The Earthquake
About this time an earthquake shifted the rocks holding water in the lake, and the water level receded.  Artist Island became a peninsula connected to the mainland. Some enterprising artisans decided to walk to the mainland and talk to the Festival People. They discovered that the Festival People didn't really like their jewelry designs very much, and so the artisans went back home and produced some new designs. After a few trips, they learned more and more about the festivals, their timing, their themes, and the kind of jewels that would be best for each one. They began to produce jewelry specially designed for each festival, and sales soared.

Of course, the artisans weren't using their time quite so efficiently anymore, because some of the best craftspeople spent part of their valuable time walking over to the mainland and talking to the Festival People. But then again, contact with customers energized the artisans, and they brought their enthusiasm back to Artist Island. The new designs were wildly popular, so none of them ended up stored in a warehouse. Thus the people of Artist Island were able to sell more jewelry and charge higher prices than before.

The artisans found that the Festival People were looking for unique jewels, so they asked the Stone People to look for new kinds of stones. But the new stones that the Stone People brought were not suitable for forming into jewels, and the artisans began to wish they had kept a few of their old boats so they could go and look for new stones themselves. One day some of the artisans went exploring their new peninsula and discovered a shallow sandbar connecting Artist Island to Stone Island. So they were able to wade over to Stone Island to help the Stone People look for better stones.

Because they knew what they were looking for, the artisans soon discovered new types of stones that could be easily formed into jewels. Actually, the new stones were much bigger than the previous ones -- they barely fit in the small boats -- so the Stone People had ignored them. The large stones gave the Artist Island people a novel idea: perhaps they could make cups and bowls from the new stones. Several different kinds of stones were brought to Artist Island and artisans eagerly tried their hand at making household items. This turned out to be easier than the intricate work of making jewelry, so even apprentice artisans were able to shape the new stones. The Festival People loved the new dishes and bought many pieces in addition to the jewels they always enjoyed.

Of course, the artisans weren't using their time quite so efficiently now that some of the best craftspeople were working with the Stone People as well as the Festival People. But then again, dishes involved less intricate work so more items could be produced and it was much easier to avoid flaws. Furthermore, the Festival People were eager to buy every single item the artisans could produce. No longer was finished work gathering dust in warehouses. Thus the artisans were able to make and sell many more products than before. Finally, since the household items were considered a necessity, business remained good even during tough economic times.

The New Landscape
Let’s take a tour of Artist Island a few years after the waters receded and turned it into a peninsula. The former island has three different kinds of artisans. First of all there are the enterprising artisans who learned to empathize with customers and look for new stones to shape in novel ways to solve customer problems. They are deeply engaged in their work and have created tight feedback loops so they can continue to develop products that customers love and bring innovative new stones to the market.

This group of artisans has revised the definition of efficiency.[1] They don’t worry too much about resource efficiency -- that is, keeping every artisan busy. They focus on flow efficiency -- that is, keeping each stone moving from Stone Island all the way to customers in the Land of Festivals with as little delay as possible. They have found that with greater flow efficiency, they get higher quality, more rapid customer feedback, and thus they are more likely to make products that delight customers. The enterprising artisans are doing very well.

But not everyone on Artist Island noticed that the waters receded, or if they noticed, they were not eager to abandon their comfortable routines. The traditional artisans believe in resource efficiency -- that is, making the most efficient use of their valuable time. So they continue to receive boatloads of stones from the Stone People, form them into the kind of jewels they are asked to make, and send the jewelry to be sold in the Land of Festivals. It’s not their problem if the Stone People order the wrong jewels, or if the boats are so large that their work is out of date by the time it reaches the Land of Festivals, or if half of their jewelry ends up in warehouses, unused by the Festival People. Their job is to deliver what they are asked for in a timely manner, and to continually reduce their costs.

Of course, the work is not very challenging and it’s difficult to get enthusiastic about making piles of jewelry that no one is likely to use. Because of this, many traditional artisans are leaving to join the enterprising artisans, attracted by the opportunity to think for themselves, the challenge of improving their artistic skills, and the satisfaction of seeing their work appreciated by the Festival People.

There is a third area of Artist Island -- one that wasn't mentioned earlier -- an area that has been around ever since stones began to be used for practical items. Here we find the parts-makers, artisans who form stones into parts for automobiles and airplanes and medical devices and control systems and things like that. They make up almost half of the population of Artist Island. The parts-makers work with vehicle and device designers to make sure their parts fit and operate properly. Recently they have learned a few things from the enterprising artisans, such as focusing on flow efficiency (moving stones through their work area without delay), understanding the needs of their customers (both the device designers as well as device customers), and constantly looking for new stones that can better meet these needs.

The Future
As the years go by, the enterprising artisans will move to the mainland to work side-by-side with the Festival People. The parts-makers will also migrate to the mainland and join forces with the device designers. All that will be left on the former island are the cost centers housing traditional artisans, but even these will gradually shrink and eventually disappear. Because in the end, while the talent of the artisans will remain essential, Artist Island will not matter anymore.

Navigating the New Landscape
We have spent a lot of time over the past decade working to make life better on Artist Island (a.k.a. Software Development Land). We promoted Lean principles such as small batches and steady flow and quality at the source. But over the past few years we have watched the waters recede and marveled as the island turned into a peninsula. The best and brightest of the artisans have abandoned the boat system and learned to talk directly with customers, work as partners with other disciplines, and seek out new approaches to solving problems.

We have written three books about Artist Island, but we couldn't write a fourth, because the island has largely disappeared. In its place is a new landscape, one in which integrated product teams are expected to ask the right questions, solve the right problems, and deliver solutions that customers love. So we wrote our fourth book -- The Lean Mindset: Ask the Right Questions -- about thriving in the new landscape, a land without islands, a land that doesn't have quite enough artisans, a land that’s full of endless possibilities.
_____________________________
Footnote:
[1] Thanks to Niklas Modig and Pär Åhlström, for introducing us to these two viewpoints on efficiency. See their excellent book -- This Is Lean: Resolving the Efficiency Paradox.