Posts Tagged ‘Lessons Learned’
Rule 1: Allocate resources for effectiveness.
We live in a resource constrained world where there’s always more work than time. Resources are always tighter than tight and tough choices must be made. The first choice is to figure out what change you want to make in the world. How do you want put a dent in the universe? What injustice do you want to put to rest? Which paradigm do you want to turn on its head?
In business and in life, the question is the same – How do you want to spend your time?
Before you can move in the right direction, you need a direction. At this stage, the best way to allocate your resources is to define the system as it is. What’s going on right now? What are the fundamentals? What are the incentives? Who has power? Who benefits when things move left and who loses when things go right? What are the main elements of the system? How do they interact? What information passes between them? You know you’ve arrived when you have a functional model of the system with all the elements, all the interactions and all the information flows.
With an understanding of how things are, how do you want to spend your time? Do you want to validate your functional model? If yes, allocate your resources to test your model. Run small experiments to validate (or invalidate) your worldview. If you have sufficient confidence in your model, allocate your resources to define how things could be. How do you want the fundamentals to change? What are the new incentives? Who do you want to have the power? And what are the new system elements, their new interactions and new information flows?
When working in the domain of ‘what could be’ the only thing to worry about is what’s next. What’s after the next step? Not sure. How many resources will be required to reach the finish line? Don’t know. What do we do after the next step? It depends on how it goes with this step. For those that are used to working within an efficiency framework this phase is a challenge, as there can be no grand plan, no way to predict when more resources will be needed and no way to guarantee resources will work efficiently. For the ‘what could be’ phase, it’s better to use a framework of effectiveness.
In a one-foot-in-front-of-the-other way, the only thing that matters in the ‘what could be’ domain is effectively achieving the next learning objective. It’s not important that the learning is done most efficiently, it matters that the learning is done well and done quickly. Efficiently learning the wrong thing is not effective. Running experiments efficiently without learning what you need to is not effective. And learning slowly but efficiently is not effective.
Allocate resources to learn what needs to be learned. Allocate resources to learn effectively, not efficiently. Allocate your best people and give them the time they need. And don’t expect an efficient path. There will be unplanned lefts and rights. There will be U-turns. There will times when there’s lots of thinking and little activity, but at this stage activity isn’t progress, thinking is. It may look like a drunkard’s walk, but that’s how it goes with this work.
When the objective of the work isn’t to solve the problem but to come up with the right question, allocate resources in a way that prioritizes effectiveness over efficiency. When working in the domain of ‘what could be’ allocate resources on the learning objective at hand. Don’t worry too much about the follow-on learning objectives because you may never earn the right to take them on.
In the domain of uncertainty, the best way to allocate the resources is to learn what you need to learn and then figure out what to learn next.
Image credit – John Flannery
The WHY and HOW of Innovation
Innovation is difficult because it demands new work. But, at a more basic level, it’s difficult because it requires an admission that the way you’ve done things is no longer viable. And, without public admission the old way won’t carry the day, innovation cannot move forward. After the admission there’s no innovation, but it’s one step closer.
After a public admission things must change, a cultural shift must happen for innovation to take hold. And for that, new governance processes are put in place, new processes are created to set new directions and new mechanisms are established to make sure the new work gets done. Those high-level processes are good, but at a more basic level, the objectives of those process areto choose new projects, manage new projects and allocate resources differently. That’s all that’s needed to start innovation work.
But how to choose projects to move the company toward innovation? What are the decision criteria? What is the system to collect the data needed for the decisions? All these questions must be answered and the answers are unique to each company. But for every company, everything starts with a top line growth objective, which narrows to an approach based on an industry, geography or product line, which then further necks down to a new set of projects. Still no innovation, but there are new projects to work on.
The objective of the new projects is to deliver new usefulness to the customer, which requires new technologies, new products and, possibly, new business models. And with all this newness comes increased uncertainty, and that’s the rub. The new uncertainty requires a different approach to project management, where the main focus moves from execution of standard tasks to fast learning loops. Still no innovation, but there’s recognition the projects must be run differently.
Resources must be allocated to new projects. To free up resources for the innovation work, traditional projects must be stopped so their resources can flow to the innovation work. (Innovation work cannot wait to hire a new set of innovation resources.) Stopping existing projects, especially pet projects, is a major organizational stumbling block, but can be overcome with a good process. And once resources are allocated to new projects, to make sure the resources remain allocated, a separate budget is created for the innovation work. (There’s no other way.) Still no innovation, but there are people to do the innovation work.
The only thing left to do is the hardest part – to start the innovation work itself. And to start, I recommend the IBE (Innovation Burst Event). The IBE starts with a customer need that is translated into a set of design challenges which are solved by a cross-functional team. In a two-day IBE, several novel concepts are created, each with a one page plan that defines next steps. At the report-out at the end of the second day, the leaders responsible for allocating the commercialization resources review the concepts and plans and decide on next steps. After the first IBE, innovation has started.
There’s a lot of work to help the organization understand why innovation must be done. And there’s a lot of work to get the organization ready to do innovation. Old habits must be changed and old recipes must be abandoned. And once the battle for hearts and minds is won, there’s an equal amount of work to teach the organization how to do the new innovation work.
It’s important for the organization to understand why innovation is needed, but no customer value is delivered and no increased sales are booked until the organization delivers a commercialized solution.
Some companies start innovation work without doing the work to help the organization understand why innovation work is needed. And some companies do a great job of communicating the need for innovation and putting in place the governance processes, but fail to train the organization on how to do the innovation work.
Truth is, you’ve got to do both. If you spend time to convince the organization why innovation is important, why not get some return from your investment and teach them how to do the work? And if you train the organization how to do innovation work, why not develop the up-front why so everyone rallies behind the work?
Why isn’t enough and how isn’t enough. Don’t do one without the other.
Image credit — Sam Ryan
See differently to solve differently.
There are many definitions for creativity and innovation, but none add meaningfully to how the work is done. Though it’s clear why the work is important – creativity and innovation underpin corporate prosperity and longevity – it’s especially helpful to know how to do it.
At the most basic level, creativity and innovation are about problem solving. But it’s a special flavor of problem solving. Creativity and innovation are about problems solving new problems in new ways. The glamorous part is ‘solving in new ways’ and the important part is solving new problems.
With continuous improvement the same problems are solved over and over. Change this to eliminate waste, tweak that to reduce variation, adjust the same old thing to make it work a little better. Sure, the problems change a bit, but they’re close cousins to the problems to the same old problems from last decade. With discontinuous improvement (which requires high levels of creativity and innovation) new problems are solved. But how to tell if the problem is new?
Solving new problems starts with seeing problems differently.
Systems are large and complicated, and problems know how to hide in the nooks and crannies. In a Where’s Waldo way, the nugget of the problem buries itself in complication and misuses all the moving parts as distraction. Problems use complication as a cloaking mechanism so they are not seen as problems, but as symptoms.
Telescope to microscope. To see problems differently, zoom in. Create a hand sketch of the problem at the microscopic level. Start at the system level if you want, but zoom in until all you see is the problem. Three rules: 1. Zoom in until there are only two elements on the page. 2. The two elements must touch. 3. The problem must reside between the two elements.
Noun-verb-noun. Think hammer hits nail and hammer hits thumb. Hitting the nail is the reason people buy hammers and hitting the thumb is the problem.
A problem between two things. The hand sketch of the problem would show the face of the hammer head in contact with the surface of the thumb, and that’s all. The problem is at the interface between the face of the hammer head and the surface of the thumb. It’s now clear where the problem must be solved. Not where the hand holds the shaft of the hammer, not at the claw, but where the face of the hammer smashes the thumb.
Before-during-after. The problem can be solved before the hammer smashes the thumb, while the hammer smashes the thumb, or after the thumb is smashed. Which is the best way to solve it? It depends, that’s why it must be solved at the three times.
Advil and ice. Solving the problem after the fact is like repair or cleanup. The thumb has been smashed and repercussions are handled in the most expedient way.
Put something between. Solving the problem while it happens requires a blocking or protecting action. The hammer still hits the thumb, but the protective element takes the beating so the thumb doesn’t.
Hand in pocket. Solving the problem before it happens requires separation in time and space. Before the hammer can smash the thumb it is moved to a safe place – far away from where the hammer hits the nail.
Nail gun. If there’s no way for the thumb to get near the hammer mechanism, there is no problem.
Cordless drill. If there are no nails, there are no hammers and no problem.
Concrete walls. If there’s no need for wood, there’s no need for nails or a hammer. No hammer, no nails, no problem.
Discerning between symptoms and problems can help solve new problems. Seeing problems at the micro level can result in new solutions. Looking closely at problems to separate them time and space can help see problems differently.
Eliminating the tool responsible for the problem can get rid of the problem of a smashed thumb, but it creates another – how to provide the useful action of the driven nail. But if you’ve been trying to protect thumbs for the last decade, you now have a chance to design a new way to fasten one piece of wood to another, create new walls that don’t use wood, or design structures that self-assemble.
Image credit – Rodger Evans
Put Yourself Out There
If you put yourself out there and it doesn’t go as you expect, don’t get down. All you are responsible for is your effort and your intentions. You’re not responsible for the outcome. Intentions don’t drive outcomes. In fact, be prepared for your work to bring out the opposite of your intentions.
If you put yourself out there and it goes poorly, don’t judge yourself negatively. Sometimes, things go that way. It’s not a problem, unless you make it one. So, don’t make it one. Just put yourself out there.
The clothes don’t get clean without an agitator. Hold onto that, and put yourself out there.
How do you know you’ve put yourself out there? The status quo is angry with you. The people in power want you to stop. The organization tries to scuttle your work. And the people that know the truth take you out to lunch.
If you put yourself out there and your message is met with 100% agreement, you didn’t put yourself out there. You may have stepped outside the lines, but you didn’t put your whole self on the line. You didn’t splash everyone with a full belly flop. There wasn’t enough sting and your belly isn’t red enough.
You won’t get it right, but put yourself out there anyway. You can’t predict the outcome, but take a run at the status quo. You don’t know how it will turn out, but that’s not a reason to hold back, it’s objective evidence it’s time to take a run at it.
Don’t put yourself out there because it’s the right thing to do, put yourself out there because you have an emotional connection. Put yourself out there because it’s time to put yourself out there. Put yourself out there because you don’t know what else to do.
Be prepared to be misunderstood, but put yourself out there. Expect to be laughed at and talked about behind your back, but put yourself out there. And expect there will be one or two people who will have your back. You know who they are.
No sense holding back. Get over the fear and put yourself out there.
The only one holding you back is you.
Image credit – Mark Bonica
Learning at the expense of predicting.
When doing new things there is no predictability. There’s speculation, extrapolation and frustration, but no prediction. And the labels don’t matter. Whether it’s called creativity, innovation, discontinuous improvement or disruption there’s no prediction.
The trick in the domain complexity is to make progress without prediction.
The first step is to try to define the learning objective. The learning objective is what you want to learn. And its format is – We want to learn that [fill in the learning objective here]. It’s fastest to tackle one learning objective at a time because small learning objectives are achieved quickly with small experiments. But, it will be a struggle to figure out what to learn. There will be too many learning objectives and none will be defined narrowly. At this stage the fastest thing to do is stop and take a step back.
There’s nothing worse than learning about the wrong thing. And it’s slow. (The fastest learning experiments are the ones that don’t have to be run.) Before learning for the sake of learning, take the necessary time to figure out what to learn. Ask some questions: If it worked could it reinvent your industry? Could it obsolete your best product? Could it cause competitors to throw in the towel? If the answer is no, stop the project and choose one where the answer is yes. Choose a meaningful project, or don’t bother.
First learning objective – We want to learn that, when customers love the new concept, the company will assign appropriate resources to commercialize it. If there’s no committment up front, stop. If you get committment, keep going. (Without upfront buy-in the project relies on speculation, the wicked couple of prediction and wishful thinking.)
Second learning objective – We want to learn that customers love the new concept. This is not “I think customers will love it.” or “Customers may love it.” In the standard learning objective format – We want to learn that [customers love the new concept]. Next comes the learning plan.
What will you build for customers to help them understand the useful novelty of the revolutionary concept? For speed’s sake, build a non-functional prototype that stands for the concept. It’s a thin skin wrapped around an empty box that conveys the essence of the novelty. No skeleton, just skin. And for speed’s sake, show it to fewer customers than you think reasonable. And define the criteria to decide they love it. There’s no trick here. Ask “Do they love it?” and use your best judgement. At this early stage, the answer will be no. But they’ll tell you why they don’t love it, and that’s just the learning you’re looking for.
Use customer input to reformulate the learning objective and build a new prototype and repeat. The key here is to build fast, test fast, learn fast and repeat fast. The art becomes defining the simplest learning objectives, building the simplest prototypes and making decisions with data from the fewest customers.
With complexity and newness prediction isn’t possible. But learning is.
And learning doesn’t have to take a lot of time.
Image credit — John William Waterhouse
Sometimes things need to get worse before they can get better.
All the scary words are grounded in change. Innovation, by definition, is about change. When something is innovative it’s novel, useful and successful. Novel is another word for different and different means change. That’s why innovation is scary. And that’s why radical innovation is scarier.
Continuous improvement, where everything old is buffed and polished into something new, is about change. When people have followed the same process for fifteen years and then it’s improved, people get scared. In their minds improved isn’t improved, improved is different. And different means change. Continuous improvement is especially scary because it makes processes more productive and frees up people to do other things, unless, of course, there are no other things to do. And when that happens their jobs go away. Every continuous improvement expert knows when the first person loses their job due to process improvement the program is dead in the saddle, yet it happens. And that’s scary on a number of fronts.
And then there’s disruption. While there’s disagreement on what it actually is, there is vicious agreement that after a disruption the campus will be unrecognizable. And unrecognizable things are unrecognizable because they are different from previous experience. And different means change. With mortal innovation there are some limits, but with disruption everything is fair game. With disruption everything can change, including the venerable, yet decrepit, business model. With self-disruption, the very thing responsible for success is made to go away by the people that that built it. And that’s scary. And when a company is disrupted from the outside it can die. And, thankfully, that’s scary.
But change isn’t scary. Thinking about change is scary.
There’s one condition where change is guaranteed – when the pain of the current situation is stronger than the fear of changing it. One source of pain could be from a realization the ship will run aground if a new course isn’t taken. When pain of the immanent shipwreck (caused by fear) overpowers the fear of uncharted waters, the captain readily pulls hard to starboard. And when the crew realizes it’s sink or swim, they swim.
Change doesn’t happen before it’s time. And before things get bad enough, it’s not time.
When the cruise ship is chugging along in fair seas, change won’t happen. Right before the fuel runs out and the generators quit, it’s all you can eat and margaritas for everyone. And right after, when the air conditioning kicks out and the ice cream melts, it’s bedlam. But bedlam is not the best way to go. No sense waiting until the fuel’s gone to make change. Maybe someone should keep an eye the fuel gauge and let the captain know when there’s only a quarter tank. That way there’s some time to point the ship toward the closest port.
There’s no reason to wait for a mutiny to turn the ship, but sometimes an almost mutiny is just the thing.
As a captain, it’s difficult to let things get worse so they can get better. But if there’s insufficient emotional energy to power change, things must get worse. The best captains run close to the reef and scrape the hull. The buffet tables shimmy, the smoked salmon fouls the deck and the liquor bottles rattle. And when done well, there’s a deep groan from the bowels of the ship that makes it clear this is no drill. And if there’s a loud call for all hands on deck and a cry for bilge pumps at the ready, all the better.
To pull hard in a new direction, sometimes the crew needs help to see things as they are, not as they were.
Image credit – Francis Bijl
Celebrating Seven Years of Blog Posts – what I’ve learned about writing.
Today marks seven years of weekly blog posts. Here’s what I’ve learned so far:
When you can write about anything, what you choose tells everyone what you’re about.
Sometimes you’ve got to start writing to figure out what you have to say.
Some people think semicolons are okay; others don’t like to show off.
When you don’t want to write and you write anyway, you feel good when you’re done.
Use short sentences. Use fewer words.
Writing is the best way to learn you don’t know what you’re talking about.
Writing is a good way to have a deep conversation with yourself.
Worrying about what people will think is the surest way to write like crap.
Writing improves by writing.
When the topic comes slowly, start writing. And when the words don’t come at all, repeat.
If you don’t know what you are talking about before you start writing, no worries. You’ll know when you’re done.
When you have nothing to say it’s because what you have to say is too personal share.
For me, writing is learning.
Image credit David Kutschke
What if it works?
When money is tight, it’s still important to do new work, but it’s doubly important not to waste it.
There are a number of models to increase the probability of success of new work. One well known approach is the VC model where multiple projects are run in parallel. The trick is to start projects with the potential to deliver ultra-high returns. The idea isn’t to minimize the investment but to place multiple bets. When money’s tight, the VC model is not your friend.
Another method to increase the probability of success is to increase the learning rate. The best known method is the Lean Startup method. Come up with an idea, build a rough prototype, show it to potential customers and refine or pivot. The process is repeated until a winning concept finds a previously unknown market segment and the money falls from the sky. In a way, it’s like the VC Model, but it’s not a collection of projects run in parallel, it’s a sequential series of high return adventures punctuated by pivots. The Lean Startup is also quite good when money’s tight. A shoe string budget fosters radical learning strategies and creates focus which are both good ideas when coffers are low.
And then there’s the VC/Lean Startup combo. A set of high potential projects run in parallel, each using Lean’s build, show, refine method to learn at light speed. This is not the approach for empty pockets, but it’s a nice way to test game changing ideas quickly and efficiently.
Things are different when you try to do an innovation project within a successful company. Because the company is successful, all resources are highly utilized, if not triple-booked. On the balance sheet there’s plenty of money, but practically the well is dry. The organization is full up with ROI-based projects that will deliver marginal (but predictable) top line growth, and resources are tightly shackled to their projects. Though there’s money in the bank, it feels like the account is over drawn. And with this situation there’s a unique and expensive failure mode lurking in the shallows.
The front end of innovation work is resource light. New prototypes are created quickly and inexpensively and learning is fast and cheap. Though the people doing the work are usually highly skilled and highly valuable, it doesn’t take a lot of people to create a functional prototype and test it with new customers. And then, when the customers love it and it’s time to commercialize, there’s no one home. No one to do the work. And, unlike the relatively resource light front end work, commercialization work is resource heavy and expensive. The failure mode – the successful front end work is nothing but pure waste. All the expense of creativity with none of innovation’s return. And more painful, if the front end was successful the potential failure mode was destined to happen. There was no one to pick it up from the start.
The least expensive projects are the ones that never start. Before starting a project, ask “What if it works?”
image credit – jumping lab
The Cycle of Success
There’s a huge amount of energy required to help an organization do new work.
At every turn the antibodies of the organization reject new ideas. And it’s no surprise. The organization was created to do more of what it did last time. Once there’s success the organization forms structures to make sure it happens again. Resources migrate to the successful work and walls form around them to prevent doing yet-to-be-successful work. This all makes sense while the top line is growing faster than the artificially set growth goal. More resources applied to the successful leads to a steeper growth rate. Plenty of work and plenty of profit. No need for new ideas. Everyone’s happy.
When growth rate of the successful company slows below arbitrary goal, the organization is slow to recognize it and slower to acknowledge it and even slower to assign true root cause. Instead, the organization doubles down on what it knows. More resources are applied, efficiency improvements are put in place, and clearer metrics are put in place to improve accountability. Everyone works harder and works more hours and the growth rate increases a bit. Success. Except the success was too costly. Though total success increased (growth), success per dollar actually decreased. Still no need for new ideas. Everyone’s happy, but more tired.
And then growth turns to contraction. With no more resources move to the successful work, accountability measures increase to unreasonable levels and people work beyond their level of effectiveness. But this time growth doesn’t come. And because people are too focused on doing more of what used to work, new ideas are rejected. When a new idea is proposed, it goes something like this “We don’t need new ideas, we need growth. Now, get out of my way. I’m too busy for your heretical ideas.” There’s no growth and no tolerance for new ideas. No one is happy.
And then a new idea that had been flying under the radar generates a little growth. Not a lot, but enough to get noticed. And when the old antibodies recognize the new ideas and try to reject it, they cannot. It’s too late. The new idea has developed a protective layer of growth and has become a resistant strain. One new idea has been tolerated. Most are unhappy because there’s only one small pocket of growth and a few are happy because there’s one small pocket of growth.
It’s difficult to get the first new idea to become successful, but it’s worth the effort. Successful new ideas help each other and multiply. The first one breaks trail for the second one and the second one bolsters the third. And as these new ideas become more successful something special happens. Where they were resistant to the antibodies they become stronger than the antibodies and eat them.
Growth starts to grow and success builds on success. And the cycle begins again.
Image credit – johnmccombs
Moving Away from Best Practices
If the work is new, there is no best practice.
When you read the best books you’ll understand what worked in situations that are different than yours. When you read the case studies you’ll understand how one company succeeded in a way that won’t work in yours. The best practices in the literature worked in a different situation, in a different time and a under different cultural framework. They won’t work best for you.
Just because a practice worked last time doesn’t mean it’s a best practice this time. More strongly, just because it worked last time doesn’t mean it was best last time. There may have been a better way.
When a problem has high urgency it should be solved in a fast way, but if urgency is low, the problem should be solved in an efficient way. Which way is best? If the consequences of getting it wrong are severe, analyses and parallel solutions are skillful, but if it’s not terribly important to get it right, a lower cost way is better. But is either the best way?
The best practices found in books are usually described a high level of abstraction using action words, block diagrams and arrows. And when described at such a high level, they’re not actionable. You may know all the major steps, but you won’t know how each step should be done. And if the detail is provided, the context of your situation is different and the prescriptive steps don’t apply.
Instead of best practices, think effective practices. Effective because the people doing the work can do it effectively. Effective because it fits with the capability and capacity of the people doing the work. Effective because it meshes with existing processes and projects. Effective because it fits with your budget, timeline and risk profile. Effective because it fits with your company values.
Because all our systems are people systems, there are no best practices.
Rule 1: Don’t start a project until you finish one.
One of the biggest mistakes I know is to get too little done by trying to do too much.
In high school we got too comfortable with partial credit. Start the problem the right way, make a few little mistakes and don’t actually finish the problem – 50% credit. With product development, and other real life projects, there’s no partial credit. A project that’s 90% done is worth nothing. All the expense with none of the benefit. Don’t launch, don’t sell. No finish, no credit.
But our ill-informed focus on productivity has hobbled us. Because we think running projects in parallel is highly efficient, we start too many projects. This glut does nothing more than slow down all the other projects in the pipeline. It’s like we think queuing theory isn’t real because we don’t understand it. But to be fair to queuing and our stockholders, queuing theory is real.
Queues are nothing more than a collection of wayward travelers waiting in line for a shared resource. Wait in line for fast food, you’re part of a queue. Wait in line for a bank teller (a resource,) you’re queued up. Wait in line to board a plane, you’re waiting in a queue. But the name isn’t important. Line or queue, what matters is how long you wait.
Lines are queues and queues are lines, but the math behind them is funky. From firsthand experience we know longer queues mean longer wait times. And if the cashier isn’t all that busy (in queuing language – the utilization of the resource is low) the wait time isn’t all that bad and it increases linearly with the number of people (or jobs) in the queue. When the shared resource (cashier) isn’t highly utilized (not all that busy), add a few more shoppers per hour and wait times increase proportionately. But, and this is a big but, if the resource busy more than 80% of the time, increasing the number of shoppers increases the wait time astronomically (or exponentially.) When shoppers arrive in front of the cashier just a bit more often, wait times can double or triple or more.
For wait times, the math of queueing theory says one plus one equals two and one plus one plus one equals seven. Wait times increase linearly right up until they explode. And when wait times explode, projects screech to a halt. And because there’s no partial credit, it’s a parking lot of projects without any of the profit. And what’s the worst thing to do when projects aren’t finishing quickly enough? Start more projects. And what do we do when projects aren’t launching quickly enough? Start more projects.
When there’s no partial credit, instead of efficiency it’s better to focus on effectiveness. Instead of counting the number of projects running in parallel (efficiency,) count the number of projects that have finished (effectiveness.) To keep wait times reasonable, fiercely limit the amount of projects in the system. And there’s a simple way to do that. Figure out the sweet spot for your system, say, three projects in parallel, and create three project “tickets.” Give one ticket to the three active projects and when the project finishes, the project ticket gets assigned to the next project so it can start. No project can start without a ticket. No ticket, no project.
This simple ticket system caps the projects, or work in process (WIP,) so shared resources are utilized below 80% and wait times are low. Projects will sprint through their milestones and finish faster than ever.
By starting fewer projects you’ll finish more. Stop starting and start finishing.
Image credit – Fred Moore