Rob Sanders

Trainer | Coach | Systems Architect | Bridging system architecture and human behavior in high-tech teams

Systems Engineering the Soft Side: A Structural Approach to
Human Alignment in Engineering Teams

Bio.
Bio: Rob Sanders spent 30 years as a systems architect in
high-tech engineering before becoming a certified NLP
Master Trainer. He works with engineering teams on
communication and alignment problems that are at the heart
of most technical bottlenecks.

Abstract.

Most engineering teams have a problem they cannot find in
any technical document.

Decisions get made in meetings but never actually stick.
Two teams that build to the same spec often still end up
with parts that do not fit together. The best engineer in
the room stays quiet. The same discussion happens again
next week.

The technical work is fine. The people are capable. So
where is the problem?
It is in the space between people. Who owns this decision?
What did we actually agree upon? What is everyone assuming
but nobody saying out loud? These are engineering problems.
They just happen to be about people rather than about
systems.
This workshop treats them exactly that way.

Participants work through three structured steps, using
tools and logic that engineers already know.

Step 1 starts with two short exercises that show, in less
than ten minutes, why two people in the same meeting walk
out with a different picture of what was discussed. Not
because one of them was not paying attention. Because every
person filters information differently. Once you see how
that works, you can start asking better questions about
your own team: where are we assuming alignment that we have
never actually verified?

Step 2 uses a modified FMEA approach to find the real cause
of a recurring team problem. Not the surface cause, the one
that gets discussed in the meeting, but the cause
underneath it. Participants will work on one real problem
from their own work and trace it step by step. Examples
from engineering practice show how this works before
participants try it themselves.

Step 3 asks each participant to design one concrete change.
Not a complete plan to communicate better, but one simple
step they can implement the next week. Written in the same
format engineers use for any other change proposal: what
changes, from what to what, why, and how will you know it
worked.

Each participant leaves with three things: a clearer
picture of where they (or their team) are running on
unspoken agreements, a root cause analysis of one real
problem, and one change they can actually implement next
week.