Shipulski On Design

Posts Tagged ‘Lessons Learned’

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

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

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

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.

image credit — johnwayne2006

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

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

Whether it’s strategic planning or personal planning, work always outstrips capacity.  And whether it’s corporate growth or personal improvement, there’s always a desire to do more.  But the more-with-less and it’s-never-good-enough paradigms have overfilled everyone’s plates, and there’s no room for more. There is no more time to double-book and there are no more resources to double-dip.  Though the growth-on-all-fronts will not stop, more is not the answer.

Growth objectives and BHAGs are everywhere and there are more than too many good ideas to try.  And with salary increases and incentive compensation tied to performance and the accountability movement liberally slathered over the organization, there’s immense pressure to do more. There’s so much pressure to do more and so little tolerance for a resource-constrained “No, we can’t do that.” the people that do the work no longer no longer respond truthfully to the growth edict.  They are tired of fighting for timelines driven by work content and project pipelines based on resources.  Instead, they say yes to more, knowing full well that no will come later in the form of slipped timelines, missed specifications and disgruntled teams.

Starting is easy, but starting requires resources.  And with all resources over-booked for the next three years, starting must start with stopping.  Here’s a rule for our environment of fixed resources: no new projects without stopping an existing one. Finishing is the best form of stopping, but mid-project cancellation is next best.  Stopping is much more difficult than starting because stopping breaks commitments, changes compensation and changes who has power and control.  But in the age of growth and accountability, stopping before starting is the only way.

Stopping doesn’t come easy, so it’s best to start small.  The best place to start stopping is your calendar.  Look out three weeks and add up the hours of your standing meetings.  Write that number down and divide by two.  That’s your stopping target.

For meetings you own, cancel all the status meetings.  Instead of the status meeting write short status updates.  For your non-status meetings, reduce their duration by half.  Write down the hours of meetings you stopped. For meetings you attend, stop attending all status meetings. (If there’s no decision to be made at the meeting, it’s a status meeting.)  Read the status updates sent out by the meeting owner.  Write down the hours of meetings you stopped attending and add it to the previous number.

If you run meetings 3 hours a week and attend others meetings 5 hours per week, that’s 8 hours of meetings, leaving 32 for work. If you hit your stopping target you free up 4 hours per week.  It doesn’t sound meaningful, but it is.  It’s actually a 12% increase in work time. [(4÷32) x 100% = 12.5%]

The next step is counter intuitive – for every hour you free up set up an hour of recurring meetings with yourself. (4 hours stopped, 4 hours started.)  And because these new meetings with yourself must be used for new work, 12% of your time must be spent doing new work

The stopping mindset doesn’t stop at meetings.  Allocate 30 minutes a week in one of your new meetings (you set the agenda for them) to figure how to stop more work.  Continue this process until you’ve freed up 20% of your time for new work.

More isn’t the answer.  Stopping is.

Image credit – Craig Sefton

As vacation approaches the work days drag. Sure you’re excited about the future, but when compared to the upcoming pleasantness, the daily grind feels more like a prison.  Anticipating a good time in the future rips you from the present moment and puts you in a place you’d rather be.  And when you don’t want to be where you are, wherever you are becomes your jail cell.

Mid-way through vacation, as the work days approach, you push yourself into the future and anticipate the stress and anxiety of the work day.  Though vacation should be fun, the stress around the workday and the impending loss of vacation prevent your full engagement in the perfect now.  I’m not sure why, but for some reason your brain doesn’t want to be on vacation with you.  It’s difficult to think of your perfect vacation as your jail cell, but while your brain is disembodied, I think it is.

And when vacation is over and you return to work, it’s pretty clear you’re back in jail.  You put yourself back in the past of your wonderful vacation; compare your cubicle your previous poshness; and make it clear to yourself that you’d rather be somewhere else. And the better your vacation, the longer your jail time.

But it’s easier to see how we use unpleasant situations to build our jail cells.  Our aversion to uncomfortable situations pushes us into the past to beat ourselves up over uncontrollable factors we think we should have recognized and controlled.  We turn a simple unpleasant situation into a jail cell of self-judging.  Or, we push ourselves into the future and generate anxiety around a sea of catastrophic consequences, none of which will happen.  Instead of building jails, it’s far more effective to let ourselves feel the unpleasantness for what it is (the result of thoughts of our own making) and let it dissipate on its own.

The best way to become a jail breaker is to start with awareness – awareness your mind has left the present moment.  When you’re on vacation, be on vacation.  And when you’re in the middle of an unpleasant situation, sit right there in the middle of the unpleasant situation.  (No one has ever died from an unpleasant situation.)  And, as a skillful jail breaker, when you realize your mind is in the past or future, don’t judge yourself, praise yourself for recognizing your mind’s unintended time travel and get back to your vacation.

But this is more than a recipe for better vacations. It’s a recipe for better relationships and better work.  You can be all-in with the people you care about and you can be singularly focused on the most challenging work.  When someone is standing in front of you and you give them 100% of your attention, your relationship with them improves.  And when you give a problem 100% of your attention, it gets solved.

Think about the triggers that pull and push you out of the present moment (the dings of texts, the beeps of emails, or the buzzes of push notifications) and get rid of them.  At least while you’re on vacation.

When 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

When the work is new, it all comes down to learning.  And with learning it all comes down to three questions:

• What do you want to learn?
• What actions will take to learn what you want to learn?
• How will you decide if you learned what you wanted to learn?

There are many definitions of learning.  To me, when your beliefs change, that’s learning.  If your hunch moves to a validated idea, that’s learning.  If your understanding of a system moves from “I don’t know” to “I know a little bit.”, that’s learning.  If you believed your customers buy your product for Feature A and now you know they really buy it because of Feature B, that’s learning.

What do you want to learn? The best place to start is to clearly define what you want to learn.  Sounds easy, but it’s not. Some of the leading thinking recommends you define a formal hypothesis.  I don’t like that word.  It’s scary, intimidating and distracting.  It’s just not helpful.  Instead, I suggest you define a Learning Objective.  To do that, complete this sentence:

I want to learn if the customer ____________________.

It may take several iterations/meetings to agree on a Learning Objective, but that’s time well spent.  It’s faster to take the time to define what you want to learn than to quickly learn something that doesn’t matter.  And define the Learning Objective as narrowly as possible.  The tighter the Learning Objective, the faster you can learn it.

What actions will you take to learn what you want to learn? In other words, for every Learning Objective create a Learning Plan.  Use the Who, What, When format.  Define Who will do What and When they’ll be done.  To increase the learning rate, define the minimum work to fulfill the narrowly-defined Learning Objective.  Just as you defined the Learning Objective narrowly, define the Learning Plan narrowly.  And to further speed the learning, set constraints like – no one can travel to see customers; no more than five customers can be contacted; and the Learning Plan must be completed in two days.  You’re not looking for large sample sizes and statistical significance; you’re looking to use your best judgement supported by the minimum learning to create reasonable certainty.

How will you decide if you learned what you wanted to learn? Learning requires decisions, decisions require judgement and judgement requires supporting information.  As part of the Learning Plan, define the Learning Information you’ll collect/capture/record to support your decisions.  Audio recordings are good and video is better.  For fast learning, you can record a phone call with a customer or ask them to share their webcam (and record the feed) as you talk with them.  Or you can ask them to shoot some video with their smart phone to provide the information needed to achieve you Learning Objective.

To analyze the data, it’s best to review the audio/video as a group and talk about what you see.  You should watch for body language as well as listen to the words.  Don’t expect complete agreement among your team and expect to create follow-on Learning Objectives and Learning Plans to answer the open questions.  Repeat the process until there’s enough agreement to move forward, but don’t wait for 100% consensus.

When you present your learning to company leadership, show the raw video data that supports your learning.  Practically, you’ll connect company leaders to customers and let the customers dispel long-held biases and challenge old thinking.

There’s nothing more powerful than a customer telling your company leaders how things really are.

Image credit – Thomas Hawk

People ask why.

People buy products from people.

The right people turn activity into progress.

People want to make a difference, and they do.

People have biases which bring a richer understanding.

People use judgement – that’s why robots don’t run projects.

People recognize when the rules don’t apply and act accordingly.

Business models are an interconnected collection of people processes.

The simplest processes require judgement, that’s why they’re run by people.

People don’t like good service, they like effective interaction with other people.

People are the power behind the tools.  (I never met a hammer that swung itself.)

Progress is powered by people.

Image credit – las – intially