Shipulski On Design

Archive for April, 2026

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

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