Archive for the ‘Decisions’ Category

Leadership isn’t binary, and that’s why judgement is important.

100% of the people won’t like your new idea, even if it’s a really good one like the airplane, mayonnaise or air conditioning.

I don’t know the right amount of conflict, but I know it’s not 0% or 100%.

If 100% is good, 110% isn’t better. Percentages don’t work that way.

100% alignment is not the best thing. Great things aren’t built on the back of consensus.

100% of the problems shouldn’t be solved.  Sometimes it’s best to let the problem blossom into something that cannot be dismissed, denied or avoided.

Fitting in can be good, but not 100% of the time. Sometimes the people in power need to hear the truth, even if you know they’ll choke on it.

If the system is in the way, work the rule. Follow it 100%, follow it to the letter, follow it until it’s absurd. But, keep in mind the system isn’t in the way 100% of the time.

Following the process 100% eliminates intellectual diversity. And, as Darwin said, that leads to extinction.  I think he was onto something.

Trying to fix 100% of the problems leads to dilution. Solve one at a time until you’re done.

The best tool isn’t best 100% of the time. Here’s a rule: If the work’s new, try a new tool. You can’t cut a board with a hammer.

I don’t know how frequently to make mistakes, but I know it’s not 0% or 100% of the time.

As a sport, leadership isn’t binary. That’s why we’re paid to use our good judgement.

Image credit – Joe Dyer

The Duplicitous Relationship Between Time and Money

If you had a choice to make an extra year’s salary or live an extra year, which would you choose? If you had a choice to make an extra month’s salary or live an extra month, make the same choice? What about the trade between a week’s pay and a week of life? Does anything change when it’s a choice between ten years of salary and ten years of life? Does this thought experiment change anything for you? If not, no worries. It was a low-cost experiment.

If you decided you had enough money, how would you change your behavior? Would you spend more time with your kids? Would you take the time to decompress and enjoy what you have? Or would you spend more money so no longer had enough? What if next week you pretend you have enough money? Would things change? Is there a downside to spending more time with your family next week? Why not try it?

If every day you reminded yourself your lifespan was finite, would you live differently? If you reminded yourself every morning for the next week, would things change? It’s a low-cost experiment, and only the first two mornings are scary.  The experiment is free. Why not try?

What if you decided you didn’t want a promotion? Would you work differently? Would you use more judgment because the cost of failure is lower? Would you take more initiative? Would you say no more often? Or would you say yes more often? Would you choose to work on different projects? Why not try it for a week?  Who knows, you may get a promotion.

What if you decided you had enough stuff? What would you do with the extra money? Would give some to charity? Would you save up and buy more stuff? For the next week, why not remove one thing from your house and recycle it or give it away? You may teach yourself you have too much stuff; you may teach yourself your house looks better when it’s less cluttered, or you may feel good that your gift helped someone who didn’t have enough. There’s little downside to more pocket change, a decluttered house and helping others. Why not try it next week?

Every day we make trades between time and money, but we make them in a below-the-water-level way. And every day we choose between having enough or not, and, again, we make these choices in a less-than-fully-conscious way.  But these choices are far too important to make lightly.

Why not make some time every day to quiet yourself so you can be more aware of the day’s decisions?  It’s a low-cost experiment that could bring more clarity to your decision-making. Why not try it for a week?

image credit – Tax Credits

If you don’t know what to do, you may be on the right track.

What would you do if:

You had to push through your fear of being judged?

You had to break some rules to get an idea off the ground?

You had a concept that would displace your most successful product?

Your colleague tried to scuttle your best idea?

You knew it was time to stop judging yourself negatively?

Your colleague asked you to help with a hair-brained idea?

You were asked to facilitate a session to create new concepts, but no one could explain what would happen after the concepts were created?

You weren’t afraid your prototype would be a success?

You thought you knew what the customer wanted, but didn’t have the data to prove it?

You were asked to create patentable concepts you knew would never be commercialized?

Your prototype threatened the status quo?

You were asked to facilitate a session to create new concepts and told how to do it?

You were told “No.”

You saw a young employee struggling with a new concept?

You were blocking yourself from starting the right work?

You thought your idea had merit, but you needed help testing it in the market?

You were asked to follow a standard process but you knew there wasn’t one?

You were asked to come up with new concepts though there were five excellent concepts gathering dust?

You were told there was no market for your new-to-world prototype?

You had to bolster your self-confidence to believe wholeheartedly in your idea?

There is a name for what you would do. It’s called innovation.


image credit – UnknownNet Photography

Diabolically Simple Prototypes

Ideas are all talk and no action.  Ideas are untested concepts that have yet to rise to the level of practicality.  You can’t sell an idea and you can’t barter with them. Ideas aren’t worth much.

A prototype is a physical manifestation of an idea. Where ideas are ethereal, prototypes are practical. Where ideas are fuzzy and subject to interpretation, prototypes are a sledge hammer right between the eyes.  There is no arguing with a prototype. It does what it does and that’s the end of that. You don’t have to like what a prototype stands for, but you can’t dismiss it. Where ideas aren’t worth a damn, prototypes are wholly worth every ounce of effort to create them.

If Camp A says it will work and Camp B says it won’t, a prototype will settle the disagreement pretty quickly.  It will work or it won’t.  And if it works, the idea behind it is valid.  And if it doesn’t, the idea may be valid, but a workable solution is yet-to-be discovered.  Either way, a prototype brings clarity.

Prototypes are not elegant.  Prototypes are ugly. The best ones do one thing – demonstrate the novel idea that underpins them. The good ones are simple, and the best ones are diabolically simple. It is difficult to make diabolically simple prototypes (DSPs), but it’s a skill that can be learned.  And it’s worth learning because DSPs come to life in record time. The approach with DSPs is to take the time up front to distill the concept down to its essence and then its all-hands-on-deck until it’s up and running in the lab.

But the real power of the DSP is that it drives rapid learning.  When a new idea comes, it’s only a partially formed.  The process of trying to make a DSP demands the holes are filled and blurry parts are brought into focus.  The DSP process demands a half-baked idea matures into fully-baked physical embodiment.  And it’s full-body learning.  Your hands learn, your eyes learn and your torso learns.

If you find yourself in a disagreement of ideas, stop talking and start making a prototype. If the DSP works, the disagreement is over.

Diabolically simple prototypes end arguments. But, more importantly, they radically increase the pace of learning.

Image credit – snippets101

Learning at the expense of predicting.

john_william_waterhouse_-_the_crystal_ballWhen 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

Sort By Importance

ships-engine-order-telegraphUrgency is important, but it’s not everything. It creates focus, but washes out the radical fringe. It’s easy to measure, but easy to measure doesn’t mean it’s the best thing to work on.

In the heat of the moment urgency is king. Frantic project managers take shortcuts to meet a deadline defined fourteen months ago; Lean Startup-ers ready-fire-aim their way from pivot to pivot; And resources flow to projects that are scheduled to finish soonest.

Urgency is attractive because it’s so clear cut, so objective, so easy to measure.

Due Date – Today’s Date = Urgency.

There’s always consensus on today’s date, everyone knows the due date and subtraction come easily.  There you go. No debate, no discussion.  This project has more urgency than that one.  Just do the math. But where did the due date come from? Did the work content define the due date?  If so, projects with the least work content, with their immanent due date, are the most urgent and resources should flow to the shortest projects.  Did the annual trade show set the due date?  If so, projects with earliest trade shows should get priority.  Did the CEO define the due date for reasons unknown to mere mortals?  If so, projects that finish before the declared date should get priority and projects that finish after the due date should get put on the back burner.

Project scope defines work content and start date plus work content equals due date.  For two projects with equal work content, the project that starts first has more urgency. Should projects start sooner to increase urgency? Should project plans pile on resources to pull in the completion date to increase urgency? Should project managers strip the sizzle out of projects so they finish sooner?

Urgency isn’t important. Importance is important.

The problem with importance is its subjective nature. Because there is no objective measure of importance, judgement is required.  The cold scoring systems to rank projects don’t work.  There are no scoring rubrics, no algorithms, no customized weighting factors that can objectively quantify importance.  It’s either important or it isn’t.  It’s important in the chest, or it’s not. It’s all about judgement.

The context defines what’s important. Market share has dropped five years in a row, some projects are more important than others. Market share has increased five years in a row, a different set of projects is important. Can’t make payroll, urgency-based project selection is best. Technology is long in the tooth, it’s important to fund projects that buy or build new technology. Which projects are most important? It depends.

The best way to sort projects by importance is to ask “Is this project important?” and have a discussion. Some projects will have more upside and others will have more certainty.  Some could create new markets and other will proved two percent growth in a guaranteed way. Which are most important? It depends.

Importance is relative. Use the “Is this project important?” methodology to force rank your projects by importance.  Once complete, take a step back and ask if the ranked list makes sense.  Reshuffle if needed.  Starting from the top, fully staff the most important project. For the next most important project, allocate the remaining resources and repeat the process project-by-project until the resources are gone.  This process ensures the most important projects on the list get the resources. But there’s a hole in the methodology.

What if our innate urgency bias keeps the most important projects off the list?

Image credit – Stephen Depolo

When doing new work, you’ll be wrong.

OOPSWhen doing something from the first time you’re going to get it wrong.  There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough.  And more strongly, embrace the inherent wrongness as a guiding principle.

Take Small Bites. With new work, a small scope is better than a large one.  But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible.  And, without realizing it, the excitement can lead to a project bloated with novelty.  With the best intentions, the project team is underwater with too much work and too little time.  With new work, it’s better to take one bite and swallow than three and choke.

Ratchet Thinking. With new work comes passion and energy.  And though the twins can be helpful and fun to have around, they’re not always well-behaved.  Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction.  And that’s where ratchet thinking can help.

As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding.  Solve a problem and click forward one notch; solve a second problem and click forward another notch.  But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch.  It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster.  Ratchet thinking takes the right small bite, chews, swallows.

Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken.  In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale.  But as the cost of change increases the rate of changes slows.  So why not design the project to eliminate the cost of change?

To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come.  Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement.  And put in place a good revision control (and tracking) mechanism.

Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.

But doing new work you must.

image credit – leasqueaky

Diabolically Simple Questions

DiabolicalToday’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements.  There is a living layer of complexity growing on all branches of the organization right down to the leaf level.

Complexity is real, and it complicates things.  To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers.  But as a leader it’s more important to slash through the complexity and see things as they are.  And for that, it’s more important to know how ask diabolically simple questions (DSQ).

Project timelines are tight and project teams like to start as soon as they can.  Too often teams start without clarity on what they’re trying to achieve.  At these early stages the teams make record progress in the wrong direction.  The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?

There will likely be some consternation, arm waiving and hand wringing.  After the dust settles, help the team further tighten down the project with this follow-on DSQ:  How will you know you achieved it?

For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?

There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system.  Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works.  They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?

After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work.  The best DSQ for the job: How is it different from the existing system?  If the list is too long there’s too much newness and if it’s too short there’s not enough novelty.  If they don’t know what’s different, ask them to come back when they know.

After the “what’s different” line of questioning, the team must be able to dive deeper.  For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers.  Ask them to take some time and for each problem describe it on a single page using less than ten words.  Suggest a block diagram format and ask them to define where and when the problem occurs.  (Hint: a problem is always between two components/elements of the system.)  And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.

Though not an exhaustive list, here are some of my other favorite DSQs:

Who will buy it, how much will they pay, and how do you know?

Have we done this before?

Have you shown it to a real customer?

How much will it cost and how do you know?

Whose help do we need?

If the prototype works, will we actually do anything with it?

Diabolically simple questions have the power to heal the project teams and get them back on track.  And over time, DSQs help the project teams adopt a healthy lifestyle.  In that way, DSQs are like medicine – they taste bad but soon enough you feel better.

Image credit – Daniela Hartmann

How To Allocate Resources

shareHow a company allocates its resources defines its strategy.  But it’s tricky business to allocate resources in a way that makes the most of the existing products, services and business models yet accomplishes what’s needed to create the future.

To strike the right balance, and before any decisions on specific projects, allocate the desired spending into three buckets – short, medium and long.  Or, if you prefer, Horizon 1, 2 and 3.  Use the business objectives to set the weighting. Then, sit next to the CFO for a couple days and allocate last year’s actual spending to the three buckets and compare the actuals with how resources will be allocated going forward.  Define the number of people who will work on short, medium and long and how many will move from one bucket to another.

To get the balance right, short term projects are judged relative to short term projects, medium term projects are judged relative to medium term projects and the long term ones are judged against their long term peers.  Long term projects cannot be staffed at the expense of short term projects and medium term projects cannot take resources from long term projects.  To get the balance right, those are the rules.

To choose the best projects within each bucket, clarity and constraints are more important than ROI.   Here are some questions to improve clarity and define the constraints.

How will the customer benefit? It’s best to show the customer using the product or service or experiencing the new business model.  Use a hand sketch and few, if any, words.  Use one page.

How is it different?  In the hand sketch above, draw the novel (different) elements in red.

Who is the new customer? Define where they live, the language they speak and how they get the job done today.

Are there regional constraints?  Infrastructure gaps, such as electricity, water, transportation are deal breakers.  Language gaps can be big problems, so can regulatory, legal and cultural constraints. If a regional constraint cannot be overcome, do something else.

How will your company make money?  Use this formula: (price – cost) x volume.  But, be clear about the size of the market today and the size it could be in five years.

How will you make, sell and service it?  Include in the cost of the project the cost to overcome organizational capacity/capability constraints.  If cost (or time) to close the gaps is prohibitive, do something else.

How will the business model change?  If it won’t, strongly consider a different project.

If the investigations show the project is worthwhile, how would you staff the project and when?  This is an important one.  If the project would be a winner, but there is no one to work on it, do something else.  Or, consider stopping a bad project to start the good one.

There’s usually a general tendency to move medium term resources to short term projects and skimp on long term projects.  Be respectful of the newly-minted resource balance defined at the start and don’t choose a project from one bucket over a project from another.  And don’t get carried away with ROI measured to three significant figures, rather, hold onto the fact that an insurmountable constraint reduces ROI to zero.

And staff projects fully.  Partially-staffed projects set expectations that good things are happening, but they never come to be.

Image credit – john curley

Stop bad project and start good ones.

Ria Munk On Her DeathbedAt the most basic level, business is about allocating resources to the best projects and executing those projects well.  Said another way, business is about deciding what to work on and then working effectively.  But how to go about deciding what to work on?  Here is a cascade of questions to start you on your journey.

What are your company’s guiding principles?  Why does it exist? How does it want to go about its life?   These questions create context from which to answer the questions that follow.  Once defined, all your actions should align with your context.

How has the business environment changed? This is a big one.  Everything is impermanent.  Change is the status quo.  What worked last time won’t work this time.  Your success is your enemy because it stunts intentions to work on new things.  Define new lines of customer goodness your competitors have developed; define how their technologies have increased performance; search YouTube to see the nascent technologies that will displace you; put yourself two years in the future where your customers will pay half what they pay today.  These answers, too, define the context for the questions that follow.

What are you working on? Define your fully-staffed projects. Distill each to a single page. Do they provide new customer value?  Are the projects aligned with your company’s guiding principles? For those that don’t, stop them.  How do your fully-staffed projects compare to the trajectory of your competitors’ offerings?  For those that compare poorly, stop them.

For projects that remain, do they meet your business objectives?  If yes, put your head down and execute.  If no, do you have better projects?  If yes, move the freed up resources (from the stopped projects) onto the new projects.  Do it now.  If you don’t have better projects, find some.  Use lines of evolution for technological systems to figure out what’s next, define new projects and move the resources.  Do it now.

The best leading indicator of innovation is your portfolio of fully-staffed projects.  Where other companies argue and complain about organizational structure, move your best resources to your best projects and execute.  Where other companies use politics to trump logic, move your best resources to your best projects and execute.  Where other successful companies hold on to tired business models and do-what-we-did-last-time projects, move your best resources to your best projects and execute.

Be ruthless with your projects.  Stop the bad ones and start some good ones. Be clear about what your projects will deliver – define the novel customer value and the technical work to get there.  Use one page for each.  If you can’t define the novel customer value with a simple cartoon, it’s because there is none.  And if you can’t define how you’ll get there with a hand sketch, it’s because you don’t know how.

Define your company’s purpose and use that to decide what to work on.  If a project is misaligned, kill it. If a project is boring, don’t bother.  If it’s been done before, don’t do it.  And if you know how it will go, do something else.

If you’re not changing, you’re dying.

Image credit – David Flam

Is the new one better than the old one?

thumbs upSuccessful commercialization of products and services is fueled by one fundamental – making the new one better than the old one.  If the new one is better the customer experience is better, the marketing is better, the sales are better and the profits are better.

It’s not enough to know in your heart that the new one is better, there’s got to be objective evidence that demonstrates the improvement.  The only way to do that is with testing.  There are a number of types testing mechanisms, but whether it’s surveys, interviews or in-the-lab experiments, test results must be quantifiable and repeatable.

The best way I know to determine if the new one is better than the old one is to test both populations with the same test protocol done on the same test setup and measure the results (in a quantified way) using the same measurement system.  Sounds easy, but it’s not.  The biggest mistake is the confusion between the “same” test conditions and “almost the same” test conditions.  If the test protocol is slightly different there’s no way to tell if the difference between new and old is due to goodness of the new design or the badness of the test setup.  This type of uncertainty won’t cut it.

You can never be 100% sure that new one is better than the old one, but that’s were statistics come in handy.  Without getting deep into the statistics, here’s how it goes.  For both population’s test results the mean and standard deviation (spread) are calculated, and taking into consideration the sample size of the test results, the statistical test will tell you if they’re different and confidence of it’s discernment.

The statistical calculations (Student’s t-test) aren’t all that important, what’s important is to understand the implications of the calculations.  When there’s a small difference between new and old, the sample size must be large for the statistics to recognize a difference.  When the difference between populations is huge, a sample size of one will do nicely.  When the spread of the data within a population is large, the statistics need a large sample size or it can’t tell new from old. But when the data is tight, they can see more clearly and need fewer samples to see a difference.

If marketing claims are based on large sample sizes, the difference between new and old is small.  (No one uses large sample sizes unless they have to because they’re expensive.) But if in a design review for the new product the sample size is three and the statistical confidence is 95%, new is far better than old.  If the average of new is much larger than the average of old and the sample size is large yet the confidence is low, the statistics know the there’s a lot of variability within the populations. (A visual check should show the distributions to more wide than tall.)

The measurement systems used in the experiments can give a good indication of the difference between new and old.  If the measurement system is expensive and complicated, likely the difference between new and old is small.  Like with large sample sizes, the only time to use an expensive measurement system is when it is needed.  And when the difference between new and old is small, the expensive measurement system’s ability accurately and repeatably measure small differences (micrometers vs. meters).

If you need large sample sizes, expensive measurement systems and complicated statistical analyses, the new one isn’t all that different from the old one.  And when that’s the case, your new profits will be much like your old ones.  But if your naked eye can see the difference with a back-to-back comparison using a sample size of one, you’re on to something.

Image credit – amanda tipton

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner