Expectations result from mental models and wants. When you have a mental model of a system and you want the system to behave in a way that fits your mental model, that’s an expectation. And when you want the system to behave differently than your mental model, that’s also an expectation. When the system matches your wants, the world is good. And when your wants are out of line with the system, the world is not so good.
Speculation is not expectation. Speculation happens when you propose, based on your mental model, how the system will behave. With speculation, there’s no attachment to the result, no wanting it to be one way or another. There’s just watching and learning. If the system confirms your mental model, the applicability of the model is reinforced (within this narrow context.) And when the system tramples your mental model, you change your mental model. No attachment, no stress, no whining, no self-judgement.
When doing work that’s new, system response is unknown. Whether the system will be exercised in a new way or it’s an altogether new system, metal models are young and untested. When it’s the first time, speculation is the way to go. Come up with your best mental model, run the experiment and record the results. After sitting in data, refine your mental model and repeat. If your mental model doesn’t fit the system, don’t judge yourself negatively, don’t hold yourself back, don’t shy away. Refine your mental model and build-test-learn as fast as you can. And if your mental model fits the system, don’t judge yourself in a positive way. This was your first test and you don’t understand the system fully. Refine your model and test for a deeper understanding. [Note – systems have been known to temporarily conform to mental models to obfuscate their true character.]
When doing work that’s new, expectation gets in the way. If you expect your models to be right and they’re not, you learning rate is slower than your expectations. That’s not such a big deal on its own, but the rippling self-judgement can be crippling. Your emotional state becomes fragile and it’s difficult to keep pushing through the work. You doubt yourself and your abilities; you won’t put yourself out there; and you won’t propose radical mental models for fear of looking like you don’t know what you’re doing. You won’t run the right experiments and you never the understand the fundamental character of the system. You block your own learning. If you expect your models won’t to fit the system, you block your learning from the start. Sometimes your lack of confidence blocks you from even trying. [Note – not trying is the only way to guarantee you won’t learn.]
Within the domain of experiments, mental models and generic systems, it’s relatively easy to see the wisdom of speculations and the perils of expectations, where wanting leads to judging and judging leads to self-blocking. But it’s not so easy to see in the domain of life where experiments are replaced with personal interactions and generic systems are replaced with everyday situations and mental models are ever-present. But in both domains the rules and consequences are the same.
Just as in the lab, in day-to-day life expectations are dangerous.
Image credit – Dermot O’Halloran
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
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
If an expert says it will work, it will work. If they say it won’t work, it might. Experts can tell you will work, but can’t tell you what won’t.
If your boss tells you it won’t work, it might. Give it a try. It will be fun if it works.
If you can’t make it work, make it worse and then do the opposite.
If you can’t explain the problem to your young kids, you don’t understand the situation and you won’t make it work.
If something didn’t work ten years ago, it may work now. Technology is better and we’re smarter. More likely it would have worked ten years ago if they ran more than one crude experiment before they gave up.
If you can’t draw a one page sketch of the problem, it may never work.
If you can’t make it work, put it down for three days. Your brain may make it work while you’re sleeping.
If you don’t know the problem, you can’t make it work. Be sure you’re trying to solve the right problem.
If your boss tells you it will work, it might. If they tell you how to make it work, let them do it.
If none of your attempts have been fruitful and you’re out of tricks, purposely make one performance attribute worse to free up design space. That may work.
If you don’t know when the problem occurs, you don’t know much. Your solutions won’t work.
If you tried everything and nothing worked, ask someone for help whose specialty in an unrelated area. They may have made it work in a different domain.
If you think everyone in the group understands the problem the same way, they don’t. There’s no way they’ll agree on the best way to make it work. Don’t wait for consensus.
If you don’t try, that’s the only way to guarantee it won’t work.
Image credit – Simon Greig
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
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
The past has past, never to come again. But if you tell yourself old stories the past is still with you. If you hold onto your past it colors what you see, shapes what you think and silently governs what you do. Not skillful, not helpful. Old stories are old because things have changed. The old plays won’t work. The rules are different, the players are different, the situation is different. And you are different, unless you hold onto the past.
As a tactic we hold onto the past because of aversion to what’s going on around us. Like an ostrich we bury our head in the sands of the past to protect ourselves from unpleasant weather buffeting us in the now. But there’s no protection. Grasping tightly to the past does nothing more than stop us in our tracks.
If you grasp too tightly to tired technology it’s game over. And it’s the same with your tired business model – grasp too tightly and get run through by an upstart. But for someone who wants to make a meaningful difference, what are the two things that are sacred? The successful technology and successful business model.
It’s difficult for an organization to decide if the successful technology should be reused or replaced. The easy decision is to reuse it. New products come faster, fewer resources are needed because the hard engineering work has been done and the technical and execution risks are lower. The difficult decision is to scrap the old and develop the new. The smart decision is to do both. Launch products with the old technology while working feverishly to obsolete it. These days the half-life of technology is short. It’s always the right time to develop new technology.
The business model is even more difficult to scrap. It cuts across every team and every function. It’s how the company did its work. It’s how the company made its name. It’s how the company made its money. It’s how families paid their mortgages. It’s grasping to the past success of the business model that makes it almost impossible to obsolete.
People grasp onto the past for protection and companies are nothing more than a loosely connected network of people systems. And these people systems have a shared past and a good memory. It’s no wonder why old technologies and business models stick around longer than they should.
To let go of the past people must see things as they are. That’s a slow process that starts with a clear-eyed assessment today’s landscapes. Make maps of the worldwide competitive landscape, intellectual property, worldwide regulatory legislation, emergent technologies (search YouTube) and the sea of crazy business models enabled by the cloud.
The best time to start the landscape analyses was two years ago, but the next best time to start is right now. Don’t wait.
Image credit – John Fife
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.
If you believe the work is meaningful, best effort flows from every pore.
If you believe in yourself, positivity carries the day.
If you believe the work will take twelve weeks, you won’t get it done in a day-and-a-half.
If you believe in yourself, when big problems find you, you run them to ground.
If you believe people have good intensions, there are no arguments, there is only progress.
If you believe in yourself, you are immune to criticism and negative self-talk.
If you believe people care about you, you’re never lonesome.
If you believe in your team, there’s always a way.
If you believe in yourself, people believe in you. And like compound interest, the cycle builds on itself.
Image credit – Joe Shlabotnik
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
There always far more tasks than there is time. Same for vacations and laundry. And that’s why it’s important to learn when-and how-to say no. No isn’t a cop-out. No is ownership of the reality we can’t do everything. The opposite of no isn’t maybe; the opposite of no is yes while knowing full well it won’t get done. Where the no-in-the-now is skillful, the slow no is unskillful.
When you know the work won’t get done and when you know the trip to the Grand Canyon won’t happen, say no. Where yes is the instigator of dilution, no is the keystone of effectiveness.
And once it’s yes, Parkinson’s law kicks you in the shins. It’s not Parkinson’s good idea or Parkinson’s conjecture – it’s Parkinson’s law. And it’s a law is because the work does, in fact, always fill the time available for its completion. If the work fills the time available, it makes sense to me to define the time you’ll spend on a task before starting the task. More important tasks are allocated more time, less important tasks get less and the least important get a no-in-the-now. To beat Parkinson at his own game, use a timer.
Decide how much time you want to spend on a task. Then, to improve efficiency, divide by two. Set a countdown timer (I like E.gg Timer) and display it in the upper right corner of your computer screen. (As I write this post, my timer has 1:29 remaining.) As the timer counts down you’ll converge on completeness.
80% right, 100% done is a good mantra.
I guess I’m done now.
Image credit — bruno kvot