Shipulski On Design

996 is all the rage.  You work 9 am to 9 pm, 6 days a week.  Startups are doing it.  Might non-startups start doing it?

Productivity is important and competition is severe.  And I’m all for working hard, but I don’t think the 996 schedule is the most effective way to achieve productivity goals, at least not for all jobs.

My decision-making capabilities diminish when I am tired, and I would be tired if I worked a 996 schedule. My interpersonal and organizational effectiveness would suffer if I worked 996. My planning skills would degrade if I worked 996. My family life would suffer if I worked 996.  And my physical and mental health would degrade..

In my work, I make many decisions, I create conditions for teams and organizations to do new work, and I contemplate the future and figure out what to do next.  Maybe I should be able to do this work well with a 996 schedule.  But I know myself, and I know I would be far less effective working 996.  Maybe my work is uniquely unfit for 996? Maybe I am uniquely unfit for 996?

Some questions for you:

• How many hours can you concentrate in one day?
• How about the second day?
• If you worked a 996 schedule, would you get more done?
• How many weeks could you work 996 before the wheels fall off?

The startup pace is rapid.  Progress must be made before the money runs out.  At these early stages, when a company’s existence depends on hitting the super agressive timelines, I think 996 is especially attractive to startup companies  The potential financial upside is large which may make for a fair trade – more hours for the chance of outsized compensation.

But what if an established company sets extremely tight timelines and offers remarkable compensation if those timelines are met?  Does 996 become viable?  What if an established company sets startup-like timelines but without added compensation?  Would 996 be viable in that case?

Some countries and regions work a 996 schedule as a matter of course – no limited to  startups and (likely) no special compensation.  And it seems to work for them, at least from the outside.  And 996 may be an important supporting element of their impressively low costs, high quality, and speed.

If those countries amd regions can sustain their 996 culture, and I think they will, it will create pressure on other countries to adopt a similar approach to avoid falling further behind.

I’m unsure what broad adoption of 996 would mean for the world.

Image credit — Evan

To do new things, you’ve got to stop old things.

If you don’t stop old things, you can’t start new things.

Resources limit the work that can be done.

If you have more work than resources, you won’t be able to complete everything.

Spread your resources across fewer projects, and you’ll accomplish more.

If you run more projects, you’ll get fewer done.  Resource density matters.

For new behavior to start, old behavior must stop.

If you don’t stop old behavior, you can’t start new behavior.

When your standard work no longer works, it becomes non-standard work.

When it’s time for new work, non-standard work becomes standard work.

To get more done, improve efficiency.

To get the right work done, improve effectiveness.

New behavior requires a forcing function.

No forcing function, no change.

Things change at the speed of trust.

No trust, no change.

Transformational change isn’t a thing.

Evolutionary change is a thing.

Starting new projects is easy.

Finishing new projects requires stopping/finishing old ones, which is difficult.

Creating a start-doing list is common.

Creating a stop-doing list is unheard of.

Image credit — Demetri Dourambeis

No gets attention.

No creates a constraint that all can see.

No is a forcing function.

No preserves bandwidth.

No drives a workaround.

No forces a tack or jibe.

“No, and here’s why” is a good way to deliver a no.

No can secure a future yes.

No shifts strategy.

No requires courage.

No keeps your power dry.

No creates trust if your actions align.

No creates stress.

No is more powerful than yes.

No is not negative.

No is difficult to say.

Judge me by what I say “no” to.

Image credit — Kjetil Rimolsrønning

Good new product development projects deliver value to customers.  Bad ones create value for your company, not for customers.  Can you discern between custom value and company value?  What do you do when there’s an abundance of company value and a shortfall of customer value?  Do you run the project anyway or pull the emergency brake as soon as possible?

Customers decide if the new product has value.  That’s a rule. No one likes that rule, but it’s still a rule. The loudest voice doesn’t decide; it only drowns out the customer’s voice.

Having too many projects is worse than having too few.  With too few, you finish projects quickly because shared resources are not overutilized.  With too many, shared resources are overbooked, their service times blossom, and projects are late.   Would you rather start two projects and finish two or start seven and finish none? That’s how it goes with projects.

Three enemies of new product development: waiting, waiting, waiting.  Waiting that extends the critical path is the worst flavor of all.   Can you tell when the waiting is on the critical path?  If you calculate the cost of delay, it’s possible to spend money to eliminate waiting that’s on the critical path and make more money for your company.  H/T to Don Rienertsen.

For projects, effectiveness is more important than efficiency.  Yes, you read that correctly.  Would you rather efficiently run the wrong project (low effectiveness) or run the right project inefficiently?  Do you spend more mental energy on efficiency or effectiveness? (You don’t have to say your answer out loud.)

I think post-mortems of projects have no value.  The next project will be different, and the learning will not be applicable or forgotten altogether.  However, I think pre-mortems are powerful and can improve the effectiveness of a project BEFORE it is started.  I suggest you try it on your next project.

Strategy is realized through projects. Projects generate growth.  Cost savings come to life through projects.  I think building a deeper understanding of your projects is the most important thing you can do.

Image credit — Mike Keeling (one too many head on collisions)

Are you working on important problems?

Or are you seeking out important problems?

Or are you connecting with people who work on important problems?

I ask because I think working on important problems is important.

Are you working with people who build you up?

Do you separate from those who do the opposite?

Are you building up others?

Do you call out those who do the opposite?

Are you seeking out people who deserve rebuilding?

Do you suppress the unbuilding that creates the need for rebuilding?

I ask because I think building builds character.

Does your work matter?

What do you do when it doesn’t?

To whom does your work matter?

What do you do if you don’t know?

Do you seek out work that matters?

What do you do to block yourself from seeking out work that matters?

How do you decide if your work matters?

What do you do when you are unsure?

I ask because I think it matters.

Who is important to you?

How can you spend more time with them?

Who is not important to you?

How can you spend less time with them?

I ask because I think that’s important.

What do you think is most important?

What deserves more attention?

Who deserves to know?

When will you tell them?

I ask because I think this adds meaning to our lives.

Image credit – Dr. Matthias Ripp – Any Questions?

The CEO doesn’t decide if it’s good enough.  The VP of Marketing doesn’t decide if it’s good enough.  The VP of Engineering doesn’t decide if it’s good enough. The customer decides if it’s good enough.

If the product isn’t selling, the price may be okay, but the performance may not be good. In this case, it’s time to add some sizzle.  And who decides if the sizzle is sufficient?  You guessed it – the customer.  And if you add the sizzle and they buy more, the sizzle was the problem.  If they don’t buy more, it wasn’t the sizzle.

If the product isn’t selling, the performance may be okay, but the price may be too high.  In this case, it’s time to pull some cost out of the product and reduce the price.  Maybe a better way is to test a lower price with customers.  If they buy more, it’s worth doing the work to pull out the cost.  If they don’t buy at the lower price, the price isn’t the problem.  You still have some work to do.

If the product isn’t selling, both the performance and the price may be the problem.  It’s time to add some sizzle and lower the price.  But there’s no need to do the work until you test the hypothesis.  Make a one-page sales tool with the new sizzle and price.  If they like it, make it so.  If they don’t like it, make another sales tool with some different sizzle and a different price.  Repeat the process until the customer likes the new offering.  Then, make it so.

If the product isn’t selling, it’s possible the sales channel isn’t making enough money when they sell your product.  To test this, go on several sales calls with them.  If they are unwilling to bring you on the sales calls, it’s a good sign that there’s not enough money in it for them.  There are three ways to move forward.  Reduce the price to the channel partner.  If they sell more, you’re off to the races if, of course, there is enough margin in the product to support the reduced price.  Make it easier for them to sell your product so they spend less time and effort and make more profit.  Sell through a different channel.

When your product isn’t selling, figure out why it isn’t selling.  And because there are many possible reasons your product isn’t selling, it’s best to create a hypothesis and test it.  Your job is not to solve the problem; rather, your job is to figure out what the problem is and to decide whether it’s worth solving.

If you create a one-page sales tool with a lower price and customers still don’t want to buy it, don’t bother to design out the cost or reduce the price.  If you create a one-page sales tool with a new DVP and the customers still don’t want to buy it, don’t do the work to develop that new DVP.  If you test a reduced price to the channel and they sell a few more systems, don’t reduce the price because it’s not worth it.

Once you have objective evidence that you know what the problem is and it’s worth solving, do the work to solve it and implement the solution.  If you don’t have objective evidence that you know what the problem is, it’s not yet time to solve it.

There’s nothing worse than solving the wrong problem.  And the customer decides if the problem is worth solving.

Image credit — Geoff Henson

You know you know, but you don’t.

You think you know, but you don’t.

You’re pretty sure you don’t know.

You know you don’t know, you think it’s not a problem that you don’t, but it is a problem.

You know you don’t know, you think it’s a problem that you don’t, but it isn’t a problem.

You don’t know, you don’t know that you don’t need to know yet, and you try.

You don’t know, you know you don’t need to know yet, and you wait.

You don’t know, you can’t know, you don’t know you can’t, and you try.

You don’t know, you can’t know, you know you can’t, and you wait.

Some skills you may want to develop….

To know when you know and when you don’t, ask yourself if you know and listen to the response.

To know if it’s a problem that you don’t know or if it isn’t, ask yourself, “Is it a problem that I don’t know?”  If it isn’t, let it go.  If it is, get after it.

To know if it’s not time to know or if it is, ask yourself, “Do I have to know this right now?” If it’s not time, wait.  If it is time, let the learning begin.  Trying to know before you need to is a big waste of time.

To know if you can’t know or if you can, ask yourself, “Can I know this?” and listen for the answer. Trying to learn when you can’t is the biggest waste of time.

Image credit — Dennis Skley

Create something that isn’t.

Build something that turns ‘didn’t’ into ‘does’.

Work on your cants.

Help people.

Make a prototype.

Use all the pieces, but use them in different ways.

Make it worse and then do the opposite. (H/T to VF)

Finish one before starting another.

Turn a ‘must not’ into a ‘hey, watch this!’

Do less with far less (post 1, post 2).

Bundle the old and new items together, and vice versa.

See cannot as a call to arms.

Say no to good projects and yes to the amazing ones.

Use half the pieces.

See quitting as fast finishing.

Ask for help.

Repeat.

Image credit Victor Sassen (confusion)

Growing a company is challenging.  Here are some common difficulties and associated approaches to improve effectiveness.

No – The way we work is artisanal.

Yes – We know how to do the work innately.

It’s perfectly fine if the knowledge lives in the people.

Would you rather the knowledge resides in the people, or not know at all?

You know how to do the work.  Celebrate that.

No – We don’t know how to scale.

Yes – We know how to do the work, and that’s the most difficult part.

It doesn’t make sense to scale before you’ve done it for the first time.

Socks then shoes, not shoes then socks.

If you can’t do it once, you can’t scale it.  That’s a rule.

Give yourselves a break.  You can learn how to scale it up.

No – We don’t know how to create the right organizational structure.

Yes – We get the work done, despite our informal structure.

Your team grew up together, and they know how to work together.

Imagine how good you’ll be with a little organizational structure!

There is no “right” organizational structure.  Add what you need where you need it.

Don’t be so hard on yourselves.  Remember, you’re getting the work done.

No – We don’t have formal production lines.

Yes – Our volumes are such that it’s best to keep the machines in functional clusters.

It’s not time for you to have production lines.  You’re doing it right.

When production volume increases, it will be time for production lines.

Go get the business so you can justify the production lines.

No – We have too many projects.  It was easier when we had a couple of small projects.

Yes – We have a ton of projects that could take off!

Celebrate the upside.  This is what growth feels like.

When the projects hit big, you’ll have the cash for the people and resources you need.

Would you rather the projects take off or fall flat?

Be afraid, celebrate the upside, and go get the projects.

No – We need everything.

Yes – Our people, processes, and systems are young AND we’re getting it done!

Assess the work, define what you need, take the right first bite, and see how it goes.

Reassess the work, define the next right bite, put it in place, and see how it goes.

Repeat.

This is The Way.

Attitude matters.  Language matters.  Approach matters. People matter.

Image credit — Eric Huybrechts (Temple of Janus)

Give me fewer people than I need.  That will force me to come up with a better way.

Tell me what to do, but not how to do it.  If you know how to do it, I’m not your person.

Give me far less time than I need – months not years, weeks not months, days not weeks.  I will have no choice but to focus on the most important elements, and I will make decisions quickly because there is no time for indecision.  And I will have fun.

Tell me you don’t know.  That builds trust.

Give me bad tools, slow computers, and crappy infrastructure.  That will require me to make magic.

Tell me the truth.  That builds trust, too.

Give me a challenging task and tell me what I can’t do.  That will allow me to do anything else.

Tell me why you want the problem solved and get out of the way.  Everything will go better that way.

Give me a micro problem – move one atom, spin off one electron, make one photon, deliver one amp, limit me to one volt, give me a single gram.  I won’t be intimidated, and I will be able to see the physics.  Then, once solved, I will expand the solution to a size that fits our customers.

Tell me you need help, and I will help you.

Image credit — JD Hancock (Bizarro Superman)

I started writing because I had no mentor to help me.  I thought I could help myself grow.  I thought I could write to better understand my ideas.  I thought I could use writing to mentor myself.  I tried it.  It was difficult.  It was scary.  But I started.

You will see the title, but you won’t see my scrap paper scribblings that emerge as I struggle to converge on a topic.  Prismatic shapes, zig-zags, arrows pointing toward nothing, nested triangles, cross-hatched circles, words that don’t go together, random words.  And when a topic finds me, I move to the laptop, but you won’t see that either.

You will see the sentences and paragraphs that hang together.  You won’t see the clustered fragments of almost sentences, the disjointed paragraphs, the out-of-sequence logic, the inconsistency of tense, and the wrong words.  You won’t see my head pressed to the kitchen table as I struggle to unshuffle the deck.

You will see the density of my writing.  You won’t see the preening.

You will see a curated image and a shout out to the owner.  You won’t see me spend 30 minutes searching for an image that supports the blog post obliquely.

You will see the research underpinning the main points, but you won’t see me doing it.  Books on and off the shelf, books on the floor, technical papers in my backpack, old presentations in forgotten folders, YouTube, blogs, and podcasts.  Far too many podcasts.

You will see this week’s blog post on Wednesday night, Thursday morning, or Thursday afternoon, depending on your time zone.  You won’t see the 750+ blog posts from 15 years of Wednesdays.

When it was time to send out my first blog post, I was afraid.  I questioned whether the content was worthy, whether I was right, and whether it made sense. I struggled to push the button.  I hesitated, hesitated again, and pushed the button.  And nothing bad happened.

When it was time to send out this blog post, I was confident the content was worthy, confident I was right, and confident that it made sense.   I put myself out there, and when it was time to hit the button, I did not hesitate because I wrote it for me.

Image credit — Charlie Marshall