Shipulski On Design

Archive for the ‘How To’ Category

Show them how the work is done.

Ask them what they saw.

Praise them for what they recognized and describe what they didn’t.

Repeat

Tell them how the work is done.

You do some and they watch you, and they do some and you watch them.

Ask them what they felt and what questions they have.

Praise them for their openness and answer their questions.

Repeat.

Ask them how the work should be done and listen.

Praise them for their insights and suggest alternative approaches for consideration.

Together, choose the approach and they do the work.  You check in as needed.

Ask them how they felt while doing the work and ask if they have questions.

Praise them for sharing; validate their feelings; and answer their questions.

Repeat.

Ask them to do the work.

They choose the approach and do the work.  You do something else but stay close.

If they ask questions, answer them.

Check in with them after the work is done, but they own the agenda.

Repeat

Ask them what work should be done next and listen.

Acknowledge their discomfort and tell them it’s supposed to feel like that.

They choose the work; they choose the approach; and you stay away.

If they ask questions, answer with more questions so they can work it out on their own.

Check in with them after the work is done, but make it a social visit because they’re pros now.

Image credit – skyseeker

When there are too many projects, all the projects move too slowly.

When there are too many projects, adding resources doesn’t help much and may make things worse.

To speed up the important projects, stop the less important projects. There’s no better way.

When there are too many projects, stopping comes before starting.

All projects are important, it’s just that some are more important than others.  Stop the lesser ones.

When someone says all projects are equally important, they don’t understand projects.

If all projects are equally important, then they are also equally unimportant and it does not matter which projects are stopped.  This twist of thinking can help people choose the right projects to stop.

When there are too many projects, stop two before starting another.

Finishing a project is the best way to stop a project, but that takes too long.  Stop projects in their tracks.

There is no partial credit for a project that is 80% complete and blocking other projects.  It’s okay to stop the project so others can finish.

Queueing theory says wait times increase dramatically when utilization of shared resources reaches 85%.  The math says projects should be stopped well before shared resources are fully booked.

If you want to go faster, stop the lesser projects.

Image credit – Rodrigo Olivera

When you notice someone having a difficult time, take the time to check in with them.  An in-person “Are you okay?” is probably the best way, but a phone call, text, or video chat will also do nicely.

When you’re having a difficult time, when someone notices and checks in you feel a little better.

When someone reacts in an outsized way, use that as a signal to check in with them.  Your check-in can help them realize their reaction was outsized, as they may not know.  It’s likely a deeper conversation will emerge naturally.  This is not a time to chastise or judge, rather it’s a time to show them you care.  An in-person “You got a minute?” followed by a kind “Are you doing okay?” work well in this situation.  But a phone call or text message can also be effective.  The most important thing, though, is you make the time to check in.

When you check in, you make a difference in people’s lives.  And they remember.

Is a simple check-in really that powerful?  Yes. Does it really make a difference?  Yes. But don’t take my word for it.  Run the experiment for yourself.  Here’s the experimental protocol.

1. Pay attention.
2. Look for people who are having a difficult time or people whose behavior is different than usual.
3. When you notice the behavior of (2), make a note to yourself and give yourself the action item to check in.
4. As soon as you can, check in with them. Do it in person, if possible.  If you cannot, call them on the phone or send them a text.  Email is too impersonal. Don’t use it.
   1. To initiate the check-in, use the “You got a minute?” and “Are you doing okay?” language. Keep it simple.
   2. After using the language of (4.1), listen to them. No need to fix anything.  Just listen.  They don’t want to be fixed; they want to be heard.
5. Enjoy the good feeling that comes from checking in.
6. Repeat 1-5, as needed.

After running the experiment, I think you’ll learn that checking in is powerful and helps both parties feel better.  And the more you run the experiment (demonstrate the behavior), the more likely it will spread.

And, just maybe, at some point down the road, someone may reach out to you and ask “You got a minute?” and “Are you doing okay?”.

Image credit — Funk Dooby

If you want your new product development projects to go faster, reduce the number of active projects.  Full stop.

A rule to live by: If the new product development project is 90% complete, the company gets 0% of the value.  When it comes to new product development projects, there’s no partial credit.

Improving the capabilities of your project managers can help you go faster, but not if you have too many active projects.

If you want to improve the speed of decision-making around the projects, reduce the number of required decisions by reducing the number of active projects.

Resource conflicts increase radically as the number of active projects increases.  To fix this, you guessed it, reduce the number of active projects.

A project that is run under the radar is the worst type of active project. It sucks resources from the official projects and prevents truth telling because no one can admit the dark project exists.

With fewer active projects, resource intensity increases, the work is done faster, and the projects launch sooner.

Shared resources serve the projects better and faster when there are fewer active projects.

If you want to go faster, there’s no question about what you should do.  You should stop the lesser projects to accelerate the most important ones.  Full stop.

And if you want to stop some projects, I suggest you try to answer this question: Why does your company think it’s a good idea to have far too many active new product development projects?

Image credit — JOHN K THORNE

When there’s a disagreement, listen before you talk.  And if that doesn’t work, listen more. With this approach, disagreement cannot blossom into a problem.

When there’s a decision to be made, make it.  There are problems with any decision you make, and you might as well learn them as soon as you can.

When there’s a change coming, get people together and talk about what’s coming. One thing to remember – the talking you do before the change is much more meaningful than the talking after the change causes problems.

When an important project is behind schedule, pause the project.  Nothing causes dialog, problem-solving, and movement of resources like pausing an important project.

When person A says one thing to person B and another to person C, call a meeting with A, B, and C and within fifteen minutes the source of the problem will be apparent to all.

When someone doesn’t do what they said they’d do, send them an email asking when they’ll do it.  Then, at the same time every week, “reply all” to your email and ask them when they’ll do it.  That way, they get to see the ever-growing, time-stamped record of their problematic non-performance.

When there’s no owner of the problem, there can be no solution.  And that’s a big problem.

When it’s your problem, solve it.

When someone tries to give you their problem, don’t take it.  Like any gift, if you don’t accept it, the would-be giver still owns it.

When there are no problems, there can be no learning.

Image credit — Rob Oo

There are natural limits to the amount of work that any one person or group can do.  And once that limit is reached, saying yes to more work does not increase the amount of work that gets done.  Sure, you kick the can down the road when you say yes to work that you know you can’t get done, but that’s not helpful.  Expectations are set inappropriately which secures future disappointment and more importantly binds or blocks other resources. When preparatory work is done for something that was never going to happen, that prep work is pure waste.  And when resources are allocated to a future project that was never going to happen, the results are misalignment, mistiming, and replanning, and opportunity cost carries the day.

But how to know if you the team has what it takes to get the work done?  The answer is a capacity model.  There are many types of capacity models, but they all require a list of the available resources (people, tools, machines), the list of work to be done (projects), and the amount of time (in hours, weeks, months) each project requires for each resource.  The best place to start is to create a simple spreadsheet where the leftmost column lists the names of the people and the resources (e.g., labs, machines, computers, tools).  Across the top row of the spreadsheet enter the names of the projects.  For the first project, go down the list of people and resources,  and for each person/resource required for the project, type an X in the column.  Repeat the process for the remainder of the projects.

While this spreadsheet is not a formal capacity model, as it does not capture the number of hours each project requires from the resources, it’s plenty good enough to help you understand if you have a problem.  If a person has only one X in their row, only one project requires their time and they can work full-time on that project for the whole year.  If another person has sixteen Xs in their row, that’s a big problem. If a machine has no Xs in its row, no projects require that machine, and its capacity can be allocated to other projects across the company. And if a machine has twenty Xs in its row, that’s a big problem.

This simple spreadsheet gives a one-page, visual description of the team’s capacity.  Held at arm’s length, the patterns made by the Xs tell the whole story.

To take this spreadsheet to the next level, the Xs can be replaced with numbers that represent the number of weeks each project requires from the people and resources.  Sit down with each person and for each X in their row, ask them how many weeks each project will consume.  For example, if they are supposed to support three projects, X1 is replaced with 15 (weeks), X2 is replaced with 5, and X3 is replaced with 5 for a total of 25 weeks (15 + 5 + 5).  This means the person’s capacity is about 50% consumed (25 weeks / 50 weeks per year) by the three projects.  For each resource, ask the resource owner how much time each project requires from the resource.  For a machine that is needed for ten projects where each project requires twenty weeks, the machine does not have enough capacity to support the projects.  The calculation says the project load requires 200 machine-weeks (10*20 = 200 weeks) and four machines (200 machine-weeks / 50 weeks per year = 4 machines) are required.

Creating a spreadsheet that lists all the projects is helpful in its own right.  And you’ll probably learn that there are far more projects than anyone realizes.  (Helpful hint: make sure you ask three times if all the projects are listed on the spreadsheet.)  And asking people how much time is required for each project is respectful of their knowledge and skillful because they know best how long the work will take. They’ll feel good about all that.  And quantifying the number of weeks (or hours) each project requires elevates the discussion from argument to analysis.

With this simple capacity model, the team can communicate clearly which projects can be supported and which cannot.  And, where there’s a shortfall, the team can make a list of the additional resources that would be needed to support the full project load.

Fight the natural urge to overcomplicate the first version of the capacity model.  Start with a simple project-people/resource spreadsheet and use the Xs.  And use the conversations to figure out how to improve it for next time.

It’s difficult to describe what an innovative company looks like, and there’s no singular recipe or direction that is right for all companies.  Here are some From: To: pairings that I hope will help you in your migration toward innovation.  You’re heading in the right direction as your company generates Tos and fewer Froms.

From:  No one is asking for that technology.

To:       What does this new technology stand for?

From:  How will the company benefit?

To:       How will the customer benefit?

From:  What’s the smallest improvement that will make a difference?

To:       How can we make the most significant difference?

From:  When will you be done?

To:       What will you learn?

From:  This might not work.

To:       How might this work?

From:  Start, Start, Continue.

To:       Stop, Start, Continue.

From: We’ve tried that before and it didn’t work.

To:      What’s changed since last time?

From:  What does perfect look like?

To:       How is the work done today and which elements can we improve?

From:  Defend and Defend the core.

To:       Extend and Defend the core.

From:  Define the idealized future state.

To:       Start with the work.

From:  That won’t work!

To:       Hey, watch this!

If you want to help someone grow, use the work.  Put them on mission-critical work that gives them the opportunity to demonstrate next-level skills.  And the work must fit the person – it can’t be too difficult or too easy.  It must be just right.   And don’t create new work. Instead, for the company’s most important projects, identify the critical path work that is vital to the projects’ success and assign them to the work.

Rule 1: A personal development plan must be made from real work.

People don’t develop skills when they talk about the work, they develop skills when they do the work.  But if the work isn’t new, they don’t develop new skills.  And if the work is too difficult, they don’t develop new skills.  The role of the leader is to define work that stretches the individual without pulling them apart.  To do this, the leader must select the work appropriately and pay attention as the work proceeds.  When the going gets rough, the leader shows them how it’s done and then lets them do the work in a supervised way.  The leader does it right when it can be done independently after the work is done with supervision.

Rule 2: A personal development plan is only as good as the leader’s involvement.

There’s great pressure to create personal development plans for everyone.  It’s a good idea in principle, but in practice, it’s not effective.  Good personal development plans are resource intensive.  Even before the work starts, the planning and coordination require significant resources.  And once the plan is up and running, the company’s best talent is applied to the best (and most important) work and the best leaders must stay close to the work for the duration.  The level of commitment is significant to design and manage a good personal development plan and this limits the number of development plans that can be done well.

Rule 3: Fewer personal development plans create more personal development.

X: We need to decrease the time to market for our new products.

Me: So, you want to decrease the time it takes to go from an idea to a commercialized product?

X: Yes.

Me: Okay.  That’s pretty easy.  Here’s my idea.  Put some new stickers on the old product and relaunch it.  If we change the stickers every month, we can relaunch the product every month.  That will reduce the time to market to one month.  The metrics will go through the roof and you’ll get promoted.

X: That won’t work.  The customers will see right through that and we won’t sell more products and we won’t make more money.

Me: You never said anything about making more money.  You said you wanted to reduce the time to market.

X: We want to make more money by reducing time to market.

Me: Hmm.  So, you think reducing time to market is the best way to make more money?

X: Yes. Everyone knows that.

Me: Everyone?  That’s a lot of people.

X: Are you going to help us make more money by reducing time to market?

Me: I won’t help you with both.  If you had to choose between making more money and reducing time to market, which would you choose?

X: Making money, of course.

Me: Well, then why did you start this whole thing by asking me for help improving time to market?

X: I thought it was the best way to make more money.

Me: Can we agree that if we focus on making more money, we have a good chance of making more money?

X: Yes.

Me:  Okay.  Good.  Do you agree we make more money when more customers buy more products from us?

X: Everyone knows that.

Me:  Maybe not everyone, but let’s not split hairs because we’re on a roll here.  Do you agree we make more money when customers pay more for our products?

X: Of course.

Me: There you have it.  All we have to do is get more customers to buy more products and pay a higher price.

X: And you think that will work better than reducing time to market?

Me: Yes.

X: And you know how to do it?

Me: Sure do.  We create new products that solve our customers’ most important problems.

X: That’s totally different than reducing time to market.

Me: Thankfully, yes.  And far more profitable.

X: Will that also reduce the time to market?

Me: I thought you said you’d choose to make more money over reducing time to market. Why do you ask?

X: Well, my bonus is contingent on reducing time to market.

Me: Listen, if the previous new product development projects took two years, and you reduce the time to market to one and half years, there’s no way for you to decrease time to market by the end of the year to meet your year-end metrics and get your bonus.

X: So, the metrics for my bonus are wrong?

Me: Right.

X: What should I do?

Me: Let’s work together to launch products that solve important customer problems.

X:  And what about my bonus?

Me: Let’s not worry about the bonus.  Let’s worry about solving important customer problems, and the bonuses will take care of themselves.

Image credit — Quinn Dombrowski

X: Me: format stolen from @swardley.  Thank you, Simon.

Show customers what’s possible. Then listen.

The best projects are small until they’re not.

Today’s location before tomorrow’s destination.

The best idea requires the least effort.

Ready, fire, aim is better than ready, aim, aim, aim.

Be certain about the uncertainty.

Do so you can discuss.

Put it on one page.

Fail often, but call it learning.

Current state before future state.

Say no now to say yes later.

Effectiveness over efficiency.

Finish one to start one.

Demonstrate before asking.

Sometimes slower is faster.

Build trust before you need it.

“Yin & Yang martini” by AMagill is licensed under CC BY 2.0.

Choose the right project. When you say yes to a new project, all the focus is on the incremental revenue the project will generate and none of the focus is on unrealized incremental revenue from the projects you said no to. Next time there’s a proposal to start a new project, ask the team to describe the two or three most compelling projects that they are asking the company to say no to.  Grounding the go/no-go decision within the context of the most compelling projects will help you avoid the real backbreaker where you consume all your product development resources on something that scratches the wrong itch while you prevent those resources from creating something magical.

Choose what to improve. Give your customers more of what you gave them last time unless what you gave them last time is good enough. Once goodness is good enough, giving customers more is bad business because your costs increase but their willingness to pay does not.  Once your offering meets the customers’ needs in one area, lock it down and improve a different area.

Choose how to staff the projects.  There is a strong temptation to run many projects in parallel.  It’s almost like our objective is to maximize the number of active projects at the expense of completing them.  Here’s the thing about projects – there is no partial credit for partially completed projects.  Eight active projects that are eight (or eighty) percent complete generate zero revenue and have zero commercial value.  For your most important project, staff it fully.  Add resources until adding more resources would slow the project.  Then, for your next most important project, repeat the process with your remaining resources.  And once a project is completed, add those resources to the pool and start another project.  This approach is especially powerful because it prioritizes finishing projects over starting them.

“Three Cows” by Sunfox is licensed under CC BY-SA 2.0.