Shipulski On Design

What do you say when someone in power over you asks you to do something that violates your ethics?  Do you say yes because you know it’s that’s what they want and avoid conflict? Or do you say no because it’s unethical from your perspective?  Seems like a no-brainer, right?  A hard no, 100%.  And maybe with a violation of your ethics, it is a 100% no.  But practically, I can imagine a situation where the consequences would be dire if you lost a steady paycheck, for example, you would not be able to care for your family. Is a no to power also a no to your family?  Can you say no to power and yes to your family?

What do you say when someone with power over you asks you to do something you think is bad for the business? This one is a little tougher.  What does a yes say yes to?  Does it say you are willing to do something you think is bad for business? Does it say the person with power has better judgment? What does a yes say no to?  Does it say no to your judgment?  Does it say no to your self-worth?  What would you say no to?

What do you say when someone with power over you wants to drastically expand your responsibility without a change in compensation, authority, or title?  Is this an offer you cannot refuse?  A yes can be a yes to a desire to climb the ladder, to learn and grow, or to work more for the same pay.  A no can be a no the demotion masquerading as a promotion, to increased stress, to decreased mental and physical health, and to career growth at the company.  What would you say no to?

These contrived scenarios were created to help me talk through this yes-no business.  Any company that used the “power over” approach would drive away its best people.  I created them to make three points. Firstly, a yes to one thing is also a no to other things.  Secondly, it can be difficult to know what you are saying yes to and no to.  Thirdly, saying no can be difficult.

If you want to understand someone, watch what they say no to.

Image credit — Kjetil Rimolsrønning

Tell me what you want done, but don’t tell me how. You’ve got to leave something for me.

Better yet, ask me to help you with a problem and let me solve it.  I prefer asking over telling.

Better still, explain the situation and ask me what I think.  We can then discuss why I see it the way I do and we can create an approach.

Even better, ask me to assess the situation and create a proposal.

Better still, ask me to assess the situation, create a project plan, and run the project.

If you come up with a solution but no definition of the problem, I will ask you to define the problem.

If you come up with a solution and a definition of the problem, I will ask you to explain why it’s the right solution.

If you come up with a problem, a solution, and an analysis that justifies the solution, I will ask why you need me.

If you know what you want to do, don’t withhold information and make me guess.

If you know what you want to do, ask me to help and I will help you with your plan.

If you know what you want to do and want to improve your plan, ask me how to make your plan better.

If you want your plan to become our plan, bring me in from the start and ask me what I think we should do.

Image credit — x1klima

Demoing something for the first time is difficult, but doing it for the second time is easy.  And when you demo a new solution the first time, it (and you) will be misunderstood.

What is the value of this new thing?  This is a good question because it makes clear they don’t understand it. After all, they’ve never seen it before.  And it’s even better when they don’t know what to call it. Keep going!

Why did you do this?  This is a good question because it makes clear they see the demo as a deviation from historically significant lines of success.  And since the lines of success are long in the tooth, it’s good they see it as a violation of what worked in the olden days.  Keep going!

Whose idea was this? This is code: “This crazy thing is a waste of time and we could have applied resources to that tired old recipe we’ve been flogging for a decade now.”  It means they recognize the prototype will be received differently by the customer.  They don’t think it will be received well, but they know the customer will think it’s different.  Keep going!

Who approved this work? This is code: “I want to make this go away and I hope my boss’s boss doesn’t know about it so I can scuttle the project.”  But not to worry because the demo is so good it cannot be dismissed, ignored, or scuttled. Keep going!

Can you do another demo for my boss?  This one’s easy.  They like it and want to increase the chances they’ll be able to work on it.  That’s a nice change!

Why didn’t you do this, that, or the other? They recognized the significance, they understood the limitations, and they asked a question about how to make it better. Things are looking up!

How much did the hardware cost? They see the new customer value and want to understand if the cost is low enough to commercialize with a good profit margin.  There’s no stopping this thing!

Can we take it to the next tradeshow and show it to customers?  Success!

Image credit — Bennilover

It’s fine if you’re asked to do too much occasionally.  Things come up and must be addressed.  Sometimes it’s your turn and sometimes it’s others’ turn.  No one can argue with that.  And sometimes the work demands your special skills and you go the extra because the work is important and urgent.  You know how to do it and there’s no time to bring someone else up to speed.  That makes sense to everyone.  We all know sometimes is our turn to take on too much.  That’s just how it is.  But it’s not sustainable (or fair) when doing too much once in a while becomes insufficient and you’re expected to do too much all the time.  But this creates a problem.

You want to grow in your career and you want to get ahead.  That’s good.  But when “too much every day” becomes the norm, your desire to climb the ladder makes it difficult to say no to “too much every day.”  Say yes to too much and you’ll earn your stripes.  Say no and your career plateaus. What to do?

I think the only way to beat this double bind is to be happy with your current role, be satisfied with your strong efforts to make meaningful (and reasonable) contributions, and continually grow and develop. I think this recipe will lead to great work and I think doing great work is the best way to battle the double bind.

And when it comes to great work, you are responsible for doing great work and your company is responsible for how they respond.  If you hold onto that, your next steps will be clear.

When you do great work and your company doesn’t notice, their response sends a strong message.  And your next step – do more great work.  Their response will change or you will change companies.

When you do great work, your work gets noticed, and all your company gives you is more work, their response sends a strong message.  And your next step – do more great work but constrain your output to a reasonable level.  Their response will change or you will change companies.

If you do great work, your work gets noticed, and you get a raise, a promotion, a bigger team, responsibility for the most important projects, and the authority to get it all done, your company’s response makes it easy for you to do more great work for them.  And that’s just what you should do.

Keep it simple – when in doubt, do great work.

Image credit — _Veit_

Startups are good at making something work in the lab for the first time. However, startups are not good at moving their one-in-a-row prototypes to the manufacturing floor.  But if startups are to scale, that’s exactly what they must do.  For startups to be successful, they must continually change the design to enable the next level of production volume.

To do that, I propose a 10, 100, 1000 approach.

After the one-in-a-row prototypes, how will you make 10?  Can the crude assembly process produce 10 prototypes?  If so, use the same crude assembly process.  The cost of the prototypes is not a problem at this stage, so there’s no need to change the manufacturing processes to reduce the cost of the components.  And at these low volumes, it’s unlikely the existing assembly process is too labor intensive (you’re only making 10) so there’s likely no need to change the process from a “time to build” perspective. But if the variation generated by the assembly process leads to prototypes that don’t function properly, the variation of the assembly process must be controlled with poke-yoke measures.  Add only the controls you need because that work takes money and time which you don’t have as a startup.  Otherwise, build the next 10 like you built the first one.

After the first 10, how will you make the next 100?  Building 100 units doesn’t sound like a big deal, but 100 is a lot more than 10.  Do you have suppliers who will sell you 100 of each part?  Do you have the factory space to store the raw materials?  Do you have the capability and capacity to inspect the incoming material? Do you have the money to buy all the parts?  If the answer to all these questions is yes, it’s time to ask the difficult questions.

The cost of the units is likely still not a problem because the volumes are still small.  There’s likely no need to change the manufacturing process (e.g., moving from machining to casting) to reduce the cost of the units.  And it’s unlikely the time to build the units is becoming a problem because a super long build time isn’t all that problematic when building 100 units.  So it’s not time to reduce the number of parts in the product (product simplification through part count reduction – aka, Design for Assembly).  But it’s likely time to reduce the variation of the assembly process and eliminate the rework-inspect-test loop that comes when each unit that emerges from the production process is different.  It’s time for assembly instructions, assembly fixtures, dedicated tools at each workstation, measurement tools to inspect the final product, and a group of quality professionals to verify the product is built correctly.

After the first 100, how will you make the next 1000? If you can, avoid changing the design, the manufacturing processes, or the assembly process.  Keep everything the same and build 1000 units just as you built the first 100.  But that’s unlikely because the cost will be too high and the assembly time will be too long. For the most expensive parts, consider changing the manufacturing process to one that can support higher volumes at a lower cost.  You likely will have to buy the parts from another supplier who specializes in the new process and for that, you’ll need a purchasing professional with a quality background.  To reduce build time, do Design for Assembly (DFA) to eliminate parts (fasteners and connectors).  And for the processes that generate the highest rework times and scrap, add the necessary process controls to reduce variation and eliminate defects.  Do the minimum (lowest investment dollars and design time) to achieve the appropriate cost and quality levels and declare success.

After 1000 units, it’s time to automate and move to new manufacturing processes.  For the longest assembly processes, change the design (the parts themselves) to enable automated assembly processes. For the highest cost parts, change the parts (the design itself) to enable the move to manufacturing processes with lower cost signatures.  The important idea is that the design and its parts must change to automate and enable lower-cost manufacturing processes.  You’ll need new suppliers and purchasing professionals to bring them on board.  You’ll need quality professionals to verify the quality of the incoming parts and the output of the assembly process.  You’ll need manufacturing and automation engineers to simplify and automate the manufacturing processes.

The 10, 100, 1000 process is rather straightforward but it’s difficult because it requires judgement.  At what production volume do you move to higher volume manufacturing processes to reduce costs?  At what production volumes do you change the design to automate the assembly process to reduce assembly time?  At what point do you add assembly fixtures to reduce variation?  Which assembly processes do you improve and which do you leave as-is?  When do you spend money on improvements and when do you buckle down and grind it out without making improvements?

The answer to all these questions is the same – hire a pro who has done it before.  Hire a pro who knows when (and how) to do Design for Manufacturing and when to keep the design as it is.  Hire a pro who knows when (and how) to add poke-yoke solutions and when to keep the assembly process as it is and rework the defects because that’s the lowest cost and fastest way to go. Hire a pro who knows when to change the design to reduce assembly time (Design for Assembly) and when to change the design and invest in automated assembly.  Hire a pro who knows how (and when) to implement a full-blown quality system.

When it’s time to move from the lab to the factory floor, it’s time to hire a pro.

Image credit — Jim Roberts Gallery

Be successful, but be yourself.

Accept people for who they are and everything else gets better.

Tell the truth, even if it causes stress.  In the short term, it is emotionally challenging but in the long term, it builds trust.

Disagree, yes.  Disappoint, yes.  Disavow, no.

Be effective, but be yourself.

If your actions cause pain, apologize. It’s that simple.

It’s easier to accept others as they are when you can do the same for yourself.

Judging yourself is the opposite of accepting yourself as you are.

When someone needs help, help them.

Be skillful, but be yourself.

If there’s an upside to judging yourself, I don’t know it.

When you’re true to yourself, people can disagree with your position but not your truthfulness.

When you help someone, it’s like helping yourself twice.

There are plenty of people who will judge you.  There’s no need to join that club.

When you stand firmly on emotional bedrock, your perspective is unassailable.

When you’re true to yourself, it’s easier for others to do the same.

Be yourself especially when it’s difficult.  Your courage will empower others.

If there’s no upside to judging yourself, why do it?

Some questions for you:

How would things be different if you stopped judging yourself? Why not give it a try tomorrow?

Wouldn’t you like to be unassailable? Why not stand on your emotional bedrock tomorrow?

Over the next week, how many people will you help?

Over the next week, how many times will you demonstrate courage?

Over the next week, how many times will you be true to yourself, even when it’s difficult?

Image credit – _Veit_

If you don’t believe in the project, the team will sense it; energy will drain from the project; and no one will want to work the project.

If you don’t believe in the project, you can’t make yourself believe in the project.

If you don’t believe in the project, you can’t fool people and make them believe you believe in the project.  Your disbelief will flow from your pores like a bad smell.

If you don’t believe in the project, your disbelief will weaken an already weak project.

If you don’t believe in the project, your disbelief can twist a good project into a bad one.

If you don’t believe in the project, it may not be the right project, but you are not the right person to run it.

If you don’t believe in the project, but the company still wants you to run it, the worst thing for the project is for you to run it; the worst thing for the company is for you to run it; and the worst thing for your career is to refuse to run it.

If from the start you think the project will fail, tell the right people why you think it will fail. If after telling them why you think the project will fail, they then ask you to run the project, you have a problem and a choice.  Your problem is you’re the wrong person to run the project.  Your choice is to run the project into the ground or take the lumps for not running it into the ground.

My choice is to give someone else an opportunity to run the project.  I think life is too short to run a project you don’t believe in.

Image credit — Bennilover

We wait because we don’t have enough information to make a decision.

We wait until the decision makes itself because no one wants to be wrong.

We wait for permission because of the negative consequences of being wrong.

We wait to use our judgment until we have evidence our judgment is right.

We wait for support resources because they are spread over too many projects.

We wait for a decision to be made because no one is sure who makes it.

We wait to reduce risk.

We wait to reduce costs.

We wait to move at the speed of trust.

We wait because too many people must agree.

We wait because disagreement comes too slowly.

We wait for disagreement because we don’t subscribe to “clear is kind.”

We wait when decisions are unmade.

We wait because there is insufficient courage to stop the bad projects.

We wait to stop things slowly.

We use waiting as a slow no.

We wait to reallocate resources because even bad projects have momentum.

We wait when we dislike the impending outcome.

We wait for the critical path.

We wait out of fear.

Image credit — Sylvia Sassen

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

If you try to change what you cannot, your trying will not bring about change. But it will bring about 100% frustration, 100% dissatisfaction, 100% missed expectations, 0% progress, and, maybe, 0% employment.

Here’s a rule: If success demands you must change what you cannot, you will be unsuccessful.

If you try to change something you cannot change but someone else can, you will be unsuccessful unless you ask them for help.  That part is clear.  But here’s the tricky part – unless you know you cannot change it and they can, you won’t know to ask them.

If you know enough to ask the higher power for help and they say no but you try to change it anyway, you will be unsuccessful.  I don’t think that needed to be said, but I thought it important to overcommunicate to keep you safe.

Here’s the money question – How do you know if you can change it?

Here’s another rule: If you want to know if you can change something, ask.

If the knowledgeable people on the project say they cannot change it, believe them.  Make a record of the assessment for future escalation, define the consequences, and rescope the project accordingly.  Next, search the organization (hint – look north) for someone with more authority and ask them if they can grant the authority to change it.  If they say no, document their decision and stick with the rescoped project plan.  If they say yes, document their decision and revert to the original project plan.

If you do one thing tomorrow, ask your project team if success demands they change something they cannot.  I surely hope their answer is no.

Image credit — zczillinger