Shipulski On Design

Archive for the ‘Leadership’ Category

Customers buy products.  Manufacturing makes the products. Design engineering designs the products.  Engineering leaders guide and grow the engineers.  In a “start with the customer” way, engineering leaders are important to growing revenue and profitability.

Engineering leadership requires both technical leadership and people leadership.  You need to understand the technology, or you can’t use good professional judgement.  And you need to understand people, or you can’t create the conditions for them to do work they thought was impossible. (I call this the almost impossible.)

Is it 90% technical and 10% people? Or is it 90% people and 10% technical? Or is it split down the middle at 50-50? The answer is yes.  Sometimes it’s a 90/10 meeting followed by a 50/50 conversation in the hall.  Sometimes it’s 10/90 for a whole week.  Sometimes it’s 90/10 in the morning and 10/90 in the afternoon.  Once in a while it’s 100/0 for a hot minute or 0/100 on rare occasions.  (Most of the time, though, it feels like 75/75.)  A great engineering leader must know technology and people and must know how to set their balance based on the context.

I think the curriculum for an engineering leadership development program must be context-specific.  And because each company’s context is different, I think an engineering leadership development program should be company-specific.  The new product development process is unique. The products are unique. The analytical tools and how they’re used are unique.  The ins and outs of the design reviews are different.  So, when in doubt, I suggest you make your engineering leadership development process more company-specific and use context-specific artifacts and examples.

More specifically, I think the curriculum to teach new product development is the new product development projects themselves.  Junior engineering leaders work alongside senior engineering leaders during the actual projects in an apprenticeship way.  The senior leader demonstrates an activity, and the junior leader watches.  Next time, the senior leader demonstrates less, and the junior leader does more. This responsibility balance shifts over time until the junior leader demonstrates and the senior leader doesn’t have to watch anymore.  The junior leader is certified activity by activity under the guidance of a senior leader.  And when the junior leader has demonstrated all the necessary activities, they become a senior leader.  And the cycle continues.

Companies win when their customers buy their products.  And I think one of the best ways to do that is a formal (company-specific) program to develop engineering leaders.

Image credit – Willy Verhulst.

We do our best, and it’s either good enough or it isn’t.  But it IS our best.  Some questions: How was the good/not good bar set?  Who set it? Was the bar set unreasonably? Were the measurement criteria clear? Was there agreement on the good/not good delineation? Does there need to be agreement?  If there’s a disagreement, how is it arbitrated? Can there be disagreement?

Truth is, all goals, including the goals used to decide if you did a good job last year, are arbitrary.

20% improvement over last year. Arbitrary.  Why not 21%?

15% faster than last time.  Arbitrary.  Why not 85%?  Or 300%?

80% more “things” than last year.  Arbitrary.  Why not 9%?

If you do a sh*tty job last year, wouldn’t that set next year’s bar arbitrarily low?

Unless, of course, last year’s bar was set arbitrarily high and you actually did a great job.

If your leader likes what you did last year, you’ll get a good rating.  And how do they decide if they like what you did last year?  Kinda arbitrary.

If you made your leader look good last year, you’ll get a good review.  But someone else arbitrarily set your leader’s good/bad threshold.  One step removed from you, but still arbitrary.

If you do what you say you’ll do, that’s not arbitrary.

If you keep your promises, that’s not arbitrary.

If you help people, that’s not arbitrary.  (And they will remember you helped them.)

If you tell the truth, that’s not arbitrary.

If you treat people with respect, that’s not arbitrary.

If you see something then say something, that’s not arbitrary.

If you listen to people, that’s not arbitrary.

If you treat people with kindness, that’s not arbitrary.

If you advocate for people, that’s not arbitrary.

If you say what everyone else is afraid to say, that’s not arbitrary.

When you take responsibility, that’s not arbitrary.

When you maintain someone’s confidence, that’s not arbitrary.

When you take action, that’s not arbitrary.

When you care, that’s not arbitrary.

When you help the team laugh, that’s not arbitrary.

When you give guidance, that’s not arbitrary.

When you tell people they did a good job, that’s not arbitrary.

When you ask people what they’re working on, that’s not arbitrary.

When you demonstrate trust, that’s not arbitrary.

Improvement goals are arbitrary.

Demonstrating that you care is not.

Image credit — Marcin Wichary

When you see others get promoted, what do you do?  Do you beat yourself up because you didn’t get promoted?  Are you happy for them?  A little of both?

When someone you worked with for a long time gets a wonderful new role outside the company, what do you do? Do you hold onto the fact that things will be harder for you because they won’t be there for you?  Do you worry about the organizational gap that you’ll be asked to fill? Do you actively celebrate their good fortune and praise them to the sky?

When you work with someone for a long time, you build trust.  And trust allows you to have difficult conversations.  You can talk about the real deal.  You can discuss situations that have strong emotional energy. You can get to the real root cause, however inconvenient.  You can share your fears and struggles.  You can support each other in bad times and celebrate success in good times.  When you have trust, it’s less lonely for both of you.

When the person you work with for a long time is a pro, they teach you because you are willing to learn from them.  And you teach them because they’re willing to learn from you.  They elevate their pro-ness, and so do you.  Sure, it feels good to both of you, but it also feels good to the broader organization.

When you work with someone for a long time, you invest in each other.  You don’t keep score; you simply invest.  They need some investment, and you give it freely.  And when they need some investment, you don’t hesitate.  You grow from the giving as much as the receiving.  This respectful give-and-take ratchets up performance on both sides of the interaction.

I think working with someone for a long time creates immense value.  However, I think it’s difficult to measure and takes time to develop and yield fruit.  I don’t think companies can effectively calculate the return on investment of its people working together for a long time, but that’s okay.  There is great personal value that comes from working with someone for a long time. And I think that’s reason enough to find someone to invest in for the long haul.

Image credit — Veit (Can I trust you?)

I’ve built engineering teams that developed the world’s most successful products in their space.

At the start of the team’s migration to greatness, they don’t believe in themselves. And that’s why you, as their leader, have to believe in them.  Every day, you must tell them why you believe in them.  Every day, you must give them examples of their behaviors that justify your belief in them.  At the start of the journey, they don’t know how to do their work differently.  And that’s why you, as their leader, must show them how.  You can’t simply tell them how to do the new work because they won’t believe you.  And that’s why you must show them.  There are no half measures here.  You’ve got to be all in.

As their leader, you must set exceptionally challenging goals.  They cannot be impossible goals, but they can be almost impossible.  And when the team pushes back on your almost impossible request, you must explain HOW you will help them do the almost impossible.

None of this is free.  You must create the tools, training, and time for the exceptional performance to emerge.  You must give them the new tools, the training, and you must give them the time to learn the tools and use them appropriately.

Pro Tip: If you don’t give the team the tools, training, and time to use them, you’ll get what you got last time.

At the earliest sign of the new behaviors, you must praise them publicly.  “This is what I’m talking about!  This is great!  I like how you used the new tools.  Thank you.”  Tell everyone what they did.  Tell their spouse or partner.  Tell their kids.  Be proud.

And as the new behaviors build on each other (and they will), continue to show them your happiness.  Turn up your excitement for their remarkable work.  Tell them what they did because they won’t know.  Tell them why it was so good.  And push them for more.  Tell them you know they can do more.  And now they’ll believe you because they’ve seen what’s possible.  And they’ll believe in themselves. And once they believe in themselves, it’s off to the races.

The products will work better, will sell more, will cost less, and won’t break.  They will be easy to build, easy to test, and easy to troubleshoot.  And they will be profitable as hell.  But that’s not the real value.  The real value is that you helped build a team that believes they can do it better next time.

I have helped engineering teams do work they could not imagine.  I have helped technicians elevate their performance and outperform engineers. I have helped Ph.Ds. learn from customers.  And I have helped engineers grow into Principal Engineers, Engineering Directors, GMs, and CEOs.

This has been the most rewarding work of my life.

Image credit — Mikhail Esteves – Piggy Back

AI may be wonderful in some contexts, but AI makes it more difficult to be an effective engineering leader.  Using AI in engineering elevates the training, development, and mentorship requirements that companies must address to make their engineering leaders successful.

When asked questions, AI gives answers.  The answers may be correct or not.  In day-to-day life, that’s not such a big deal.  But in engineering, that’s not good enough.  In engineering, the answers must be right.  Not almost right.  Not maybe right. Not kinda right. The answers must be right. When engineering leaders design products, those products must work, function as advertised, satisfy customers’ needs, meet the cost target, and not hurt people.  If an engineering leader follows AI blindly, there’s no guarantee the product will be successful, profitable, or safe.

When asked the wrong question, AI gives an incorrect answer to the question that should have been asked.  If an engineering leader misunderstands the context, there’s a good chance they’ll ask the wrong question.  And they won’t know it. At best, this will create rework and project delays. And in the worst case, the company could launch a product that hurts people.

And there’s an even more troubling situation: when the engineering team presents solutions to the engineering leader without informing the leader that AI was used to generate the solutions.  To protect against this failure mode, the engineering leader must recognize when AI has been used and dig into the questions/prompts the AI was given.  From there, the engineering leader must use their knowledge of the design context to decide whether the prompts were valid and whether the answer is useful or viable.  This is a heavy lift and requires highly capable engineering leaders who have been trained to recognize AI use and verify the validity of its solutions.

Can your engineering leaders use their knowledge of the design context to provide the right prompts to an AI?

Can your engineering leaders challenge the applicability of an AI’s answer even when they think they’ve provided good prompts to the AI?

Can your engineering leaders detect when their teams have used AI to generate solutions?

Can your engineering leaders challenge the engineering teams when they suspect AI has misled the engineering team?

I hope the answer to those four questions is yes.

Image credit — Richard

Go faster. Do it better. Do more with less.  Meet the growth objective.  All good ideas, but how? In two words: Engineering Leadership.

Going forward, competition will be fiercer. Engineering organizations will be asked to do better engineering work, even though they did that on the previous project.  And to do that, engineering leaders will have to up their game.  They will have to improve the engineers’ performance on the job and their own performance.

I think engineering leadership development is a singular challenge for companies that want to thrive and grow. And for mature companies, I think it will become more difficult as these companies reduce headcount.  The burden on engineering leaders will grow as there are fewer leaders, more projects to complete, more work to elevate, and each leader will have more direct reports.   It’s already difficult for engineering leaders to make time to grow engineers and to do it without guidance and support, but I think it will become more difficult.

And developing engineering leaders is difficult for younger companies that want to grow.  These companies have engineering leaders with less experience and are new to the company and the industry.  The organizational design is still forming and fluid, the work processes are still under development, and there are far more projects to deliver.  Engineering leaders must create the organizational structure, identify engineering talent to develop, fill organizational holes, and increase design productivity to meet the company’s growth targets.  These are big challenges for new-to-role engineering leaders who must get it done without mentorship and guidance.

Often, companies try to use standard leadership development programs to grow engineering leaders, but in my experience, these generic leadership programs don’t cut it.  Every aspect of engineering leadership work has a technical bias that shapes the work, the processes, and the approaches.  Generic leadership development programs are not built on a technical backplane and don’t provide the specialized guidance and support for the work.

Engineering leadership development is different.

Engineering leadership development comes with unique challenges.  And to further complicate things, those challenges differ between mature companies and younger companies.

Your products and technologies are different.

Your processes are different.

Your business models are different.

And your engineering leadership development program should be different.

Image credit — Bennilover

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