Shipulski On Design

There is a dearth of engineering leadership capability, and it negatively impacts the company’s bottom line every day.  And it’s prevalent in all levels of the engineering organization.

Entry-level engineers feel the lack of engineering leadership capability as soon as they arrive.  They want to know how to get things done, how to address a lack of information, how to address a conflict, and how to develop themselves and their career. And yes, they want to know how to approach the work, use the tools, and follow the protocols.  But first-level engineering leaders don’t know how to help the young engineers in these ways because no one taught them.  And they don’t even know they’re supposed to give that type of guidance because no one ever gave them that type of guidance and support.

The result is a confused, disgruntled, and frustrated entry-level engineering crew who are unhappy and ineffective.  And the two things you don’t want in your entry-level engineers are unhappiness and ineffectiveness.  This directly impacts the bottom line.

Step up one level in the engineering organization, and though the needs are somewhat different, the problem is the same.  The mid-level engineering leaders don’t teach how to work across teams, how to assign work that will help engineers grow, how to create development plans, how to execute the work defined in those plans, and how to build confidence in their team members.

The result is more ineffectiveness and more frustration, but on a larger scale.  Talent retention becomes a problem, and engagement in the work wanes.  Both are bad for the bottom line.

Step up another level and, though the problems are different, the situation is the same.  The top-level engineering leaders can’t develop the mid-level leaders, the first-line leaders, and the entry-level engineers.  They were raised in the broken system and don’t know how to grow talent.  And the problem is so widespread that the engineering organization thinks it’s normal that no one gets guidance, mentorship, and support.  It’s such a big problem and so widespread that no one recognizes that there’s a problem.

But there is a problem.  A big problem.  And there’s a root cause that can be remedied.

The engineering organization is judged on completing projects as fast as possible and with the fewest resources.  And this forcing function blocks leadership development altogether.  And because of how they’re measured, the engineering organization believes there is no time to improve leadership capability and grow world-class engineering leaders.  But this thinking is wrong.

In a karma yoga way, the projects are the mechanism to develop engineering leadership.  Teaching engineers and leaders how to collaborate across teams IS leadership development.  Guiding young engineering leaders through a process to balance schedule risk and technical risk IS leadership development.  Working skillfully through resource conflicts CREATES engineering leadership capability.  Growing engineering leaders does not require extra work.  And it does not slow down the projects.  It makes projects go faster because skillful engineering leaders spot problems early (because someone taught them how) and fix problems immediately (because someone showed them how to do it on the previous project).

Engineers were not taught how to be an engineering leader in engineering school.  And we aren’t taught how to be engineering leaders in our day-to-day work.  And engineers are starved for engineering leadership, and engineering leaders are equally starved for mentoring and guidance.

Systematically developing engineering leadership talent is not a cost; it’s an investment.  What would happen to your bottom line if your engineering teams collaborated more effectively, if your engineers were engaged in the work, if engineering resources flowed naturally to the most important projects, and if your engineers and engineering leaders stayed with your company twice as long as they do now?

To improve your bottom line, invest in improving your engineering leadership capability.  This is The Way.

Image credit — Rob Roy

To help your team members communicate more effectively, teach them to put their argument on one page.  Teach them what to leave off the page and explain why those things should be omitted. Teach them what’s at the top of the page and explain why.  Help them identify the central element and show them how to make it fill the center of the page.

Teach them that the professionals distill.

They will have difficulty stripping away the clutter.  They will have difficulty shedding the details. They will have difficulty raising the level of abstraction.  Their fear is typically that people (the leadership team) will think they don’t know what they’re doing because their one-pager doesn’t contain all the details.  It’s your job to help them think otherwise.  You have to help them understand that capable people know how to distill their argument to its essence and answer questions about the details when asked.

To help your team members get the tone right, teach them about snarl words and no purr words.  Snarling and purring create a manipulative tone that devalues the argument.  Teach them to use the fewest, clearest, non-judgmental words.  And no blaming words.  Explain that “they” and “them” signal that there are competing factions that aren’t working well together.

Teach them that words matter.

To help your team communicate a complicated process, system, or approach, teach them to create a hand sketch that represents the complicated idea.  The hand sketch method is like the verbal decluttering described above, but teaching them to create a hand sketch takes the distillation to the next level. The hand sketch is not the process itself; it represents the process.  The sketch doesn’t describe the system in full; it focuses on the main pillars. And it doesn’t describe the approach in a flow chart way; it elevates the novel elements.  And to further raise the bar, limit the number of words to an unreasonable number like six or twelve.

Teach them that a sketch demonstrates understanding.

This one-page approach can also be used for problems, planning, and prioritization, but that’s for another time.

Image credit — Tambaco The Jaguar

Coach? Mentor? Consultant? What’s the right word?

Subject matter expertise.  However they categorize themselves, they must have subject matter expertise.  If you work in the hardware space, they should have experience in hardware.  If you work in the software space, they must have software experience. Ask if they have solved a similar problem in a similar space.

People and Teams.  Whatever they call themselves, they must know how to create the conditions for effective team performance to emerge.  Yes, there is a need to help individual leaders elevate their game.  That’s the minimum entry criterion.  But it’s not enough to guide one person.  Big growth objectives require engaged teams that work together and pull in the same direction.  Have they pushed a team in a skillful way to elevate the work and have the team stand taller because of it?  Ask them for objective evidence.  Have they helped an engineering team obsolete their best work?  This is a high bar because the team must see their best work as something that can be made irrelevant, see themselves as a team that can elevate their work, and be fully engaged in the go-forward challenge.

Systems, not point solutions. Regardless of how they identify, it’s not enough to create a solution for today’s problem.  Anyone can create a narrow solution for today’s specific problem. Have they created the systems, processes, tools, and built out the roles/responsibilities to prevent a broader, more global class of problems?

In the trenches.  Bottom line, no matter their label, they must have done similar work in a hands-on way.  Not in an advisory way, not in an oblique way, not in a thought-leader way, but in an in-the-trenches way.  In a I-did-it-myself way.  Ask them what their role was.  Ask them what they did.  And if they can’t be specific with you, don’t hire them.

It doesn’t matter what they call themselves.  But they must have subject matter expertise, they must have helped teams elevate their game and stand tall, put preventive systems in place, and worked in a hands-on way.

Image credit — Paul VanDerWerf

There is no such thing as losing time.  Time doesn’t reverse itself, at least outside the theoretical physics textbooks. We can spend time on things that will never go anywhere, but that’s wasted time, not lost time. The trick with this type of project is to learn that there’s a fundamental constraint BEFORE running the full project.  Here’s a rule:

If there is a fundamental constraint that blocks the project, work on a different project.

We can work on projects that generate zero customer value, but, again, that’s wasted time, not lost time. The trick with projects that deliver zero customer value is to verify there IS customer value BEFORE running the full project.  Here’s a rule:

If the project will not deliver customer value, work on a different project.

But, to be clear, it is insufficient to demonstrate that the project might deliver customer value.  You must demonstrate that the project delivered customer value.  You should now ask me, “Mike, how can we demonstrate the project delivered (past tense) customer value before we run the project in full?”  The answer is to demonstrate traction.  Traction is objective evidence that the customer spent time and energy in ways that are surrogates for “buying” the offering.

If you create a one-page sales tool, show it to a customer, and they want to buy five, that’s traction.  If, after you show them the one-pager and ask for a $200 deposit, and they give it to you, that’s traction. If you make a non-functional prototype, show it to a customer and describe how it helps them make progress, and they want to buy the prototype, that’s traction.

While, as I said, there is no such thing as losing time, there is another way to think about things that is, I think, closer to losing time.  When you use all your resources to do project A, you lose the opportunity to spend your time on project B. When you do a project that will never launch, you lose the opportunity to spend your time on a project that will.  And when you do a project that delivers zero customer value, you lose the opportunity to spend your time on a project that delivers massive customer value.  This perspective, I think, is preferred because it forces a value comparison among all candidate projects instead of simply evaluating the value of a single project.

And timing matters.  There is a viable time window for each project.  You can be too early and smash your head on a viability window that has not yet opened, or you can start a project too late, and the viability window slams shut on your fingers before you can launch.  And in that way, you can lose out on a project’s viable time window.  This isn’t losing time in the strict sense, but I think talking through time windows is helpful.

Before running a full project, learn that there’s no fundamental constraint.

Before allocating significant project resources, demonstrate enormous customer value.

Before starting a project, assess the relative value of all the viable projects. Think opportunity cost.

Before going all in on a project, make sure the timing is right.  Think viable time window.

Image credit — Tsutomu Taksu

Things move at the speed of trust.  And when they don’t move, it’s because there’s no trust.

Talking about trust won’t make a difference.  Making trust makes the difference.

In fact, if you have to talk about trust, you probably don’t have it.

Building trust must happen before it’s needed.  And since you don’t know when you’ll need it, you might as well start building it today.

Sometimes it takes a lot of trust to tell someone what you know they don’t want to hear.

Ignoring people’s negative behavior can indicate that you don’t trust them enough to call them out.

Giving trust is a good way to accelerate its receipt.

Don’t tell people to trust you.  Tell them to watch you.

Trust is behavior-based.

Trust doesn’t require consensus, but it does require truth.

Relying on trust is risky, but it’s not lonely.

Image credit — Tom Lee

Slow down to go fast.

Progress over activity.

Effectiveness before efficiency.

Finish at the expense of starting.

Location is more important than destination.

See the system as it could be, not how it should be.

Brown field designs are real; green field designs are not.

What could go right is more important than what could go wrong.

Uncertainty is flexible, certainty is dangerous.

Learning before scaling.

People first.

Image credit — mhobl

Sometimes it’s difficult to believe in yourself.  Here is a three-step process to elevate your self-belief.

1. Find someone who believes in you.
2. Ask them why they believe in you.
3. Whatever they say, believe them.

What they tell you will be different than what you think of yourself.  They see you differently than you see yourself, and they have an eyeball-based justification for believing in you.  And you are not qualified to dismiss their justification. Their justification is grounded in your behavior. They watched what you did.  They watched you persevere through trying times. They watched you treat people with kindness and respect.  They watched you call out unacceptable behavior.  They watched you say the unpalatable when everyone else was thinking it but was afraid to say.

It may be difficult for you to believe them, but you must.  Their truth, their belief in you, is grounded in your behavior.  They believe in you because they watched you.  They have real examples.  They have personal experience.  Believe them.

And if you still don’t believe in yourself, repeat the process until you do.

Image credit — Wayne S. Grazio

Take a position.  People will have to reconcile their thinking with yours and, together, the crew will deepen the collective understanding.

Take an opposite position.  Announce you are running a thought experiment and take a position that is opposite of the prevailing theory.  Make it good.  Make it deep.  Do it for real.  The prevailing theory will be strengthened, adapted, or discarded, and everything will be better for it.

Take an opposite position to your own prevailing wisdom.  If there’s no one to play with, repeat the previous exercise with yourself.  Give yourself the business.  I bet you’ll teach yourself something and you’ll have better clarity on what you know and what you don’t.

Challenge someone’s best thinking.  Announce you want to help them sharpen their thinking.  Ask them why they think as they do.  When they answer, ask them “why?” again.  Repeat this process until you’ve asked “why?” five times.  This process is aptly named The Five Whys.  If they don’t feel uncomfortable, you’re doing it wrong.

Draw a picture. Announce that you want to help solve the problem. Ask “What’s the problem?”  Then, draw a picture of the problem and show it to the crew.  It won’t be right, but that’s okay.  Ask them to fix the drawing so it captures the problem.  Repeat the process until the picture looks like the problem.  From there, the solving will come easily.  Here’s an old blog post from 2013 with a simple “problem defining” template — How Engineers Create New Markets  and another from 2017 that describes how to sketch a problem — See Differently To Solve Differently.

Make a Map. Check out these two blog posts — To Make Progress, Make a Map (2023) and The Half-Life of Our Maps (2014).

I think it’s better to be clear than correct.  Clarity brings contrast; contrast creates conversation; and conversation begets understanding.

Clarity is king.

Image credit – Natashi Jay

The marathon is a two-to-three-hour race.  The training plan is specialized and designed to get the athletes ready to run twenty-six miles.  And the marathon runners are lean and light because the physics of their event demands it.

The 100-meter sprint is a sub-ten-second race.  The training plan develops explosive power to accelerate quickly and strength to hold on for the last twenty meters.  Sprinters are muscled all over – shoulders, chest, glutes, quads, and calves – because that’s what’s required to win their event.

The decathlon is a multi-day event.  The training plan includes jumping, vaulting, throwing, sprinting, and distance running. Decathletes are strong, nimble, fast, robust, and multi-skilled because they compete in a wide range of events.  They do it all, and they do it on their own.  They are often called the best track athletes because they are highly capable in ten diverse events.  But they cannot outlast a marathon runner or out-accelerate a sprinter.

The 4 X 400-meter relay is a three-plus-minute race in which each of the four teammates runs 400 meters carrying a baton and passes it to their teammate.  They train as a team for their specific distance and build the right amount of strength.  They are muscled all over, but a little less so than the sprinters.  And they must work together with their teammates to time and coordinate a high-speed baton pass within the pass zone.  If they drop the baton, they all lose, so teamwork is a must.

Some questions for you.

What are you built for?

Does your sport fit you?

Do you have a good training plan?

How much time will you spend on your training?

Do you want to work on one thing or ten?

Do you want to run solo or with a relay team?

Image credit – Steve Austin

When you have more projects than people, you have far more activity but far less progress.

Pro Tip: Activity doesn’t pay the bills. Progress does.

Would you rather make lightning progress on two projects or tortoise progress on four?  I prefer lightning.

But isn’t four projects better than two?  It is, if you get compensated for the number of active projects. But it’s not, if you get compensated for finishing projects.

Pro tip: There’s no partial credit for a project that’s less than 100% done.

But how to protect your resources from four projects when you have the resources to deliver on two? This is not a complicated answer: block the extra project from entering the pipeline until you finish one.

Pro Tip: Finish one before you start one, not the other way around.

But what about the efficiency that comes from shared resources that can be spread over four projects?  Don Reintertsen would say “Shared resources create waiting and waiting is the enemy.”  I agree with Don, but I think his language is too reserved.  I say “If you’re focused on the efficiency that comes from shared resources, you don’t know what you’re doing.”

Pro Tip:  Waiting kills progress.  Don’t do it.

Here’s a process to consider.

1. Define the resources you have on hand to work on projects.
2. Choose the most important project and fully staff the project. If the project is fully staffed, start the project.
3. Define the remaining unallocated resources.
4. Choose the next most important project and fully staff the project. If the project is fully staffed, start the project.  If the project is not fully staffed, don’t start a project until you finish one, or you can hire the incremental resources to fully staff a project.
5. Repeat.

Image credit – KIUKO (Elephant Tortoise)

Reduce the energy cost of virtue so it’s less than the energy cost of sin. (Dave Snowden)

Said another way – make it easy to do the right thing.

Don’t push through.  Move obstacles out of the way.

Don’t tell people about their problem. Ask people about their problem.

Try small experiments and do more of what works and less of what doesn’t.

Don’t tell people they have a problem.  Volunteer to help them.

Instead of Ready, Fire, Aim, try Ready, Aim, Fire.

Before trying to improve things, define the system as it is.

When two competing theories cause disagreement, agree to try both.

Slow down to go faster.

Say no so you can say yes.

Give praise in public and give criticism in private.

Say nothing negative unless you’ve exhausted all other possibilities.

Build trust BEFORE you need it.

These are good ways to create the conditions for good things to happen.

Image credit — Peter Addor – The monkey that makes a monkey of us.