A CEO’s reflections on the joys of working with technical people
e (CEO, non-engineer, professional wrangler of chaos, enthusiastic about a new project):
“So, it looks like we’ve got a new automotive project coming in. It’s the one which requires you to start ASAP. Yes, the G120/D drives.”
My husband (engineer, speaks fluent ladder logic):
“Nice. Which TIA Portal version are we going to use? Are we going to configure SINAMICS G120/D with STARTER or with StartDrive, which is integrated in the TIA Portal?”
Me:
“I’ll have to ask about that. What I know is that I found the coolest place AND it is 5 minutes walking from the factory! ”
And just like that, we’re off. He’s talking about the systems, processes and God knows what else. I’m thinking about logistics, budgets, client expectations, and whether this should go in a blog post.
Engineers vs. Non-Engineers: The Most Functional Dysfunctional Couple
I’ve spent my entire career working with tech people—developers, sysadmins, book printers, mobile app designers, software engineers, and now: PLC programmers. I’ve learned a few things:
- Engineers think in systems.
- Non-engineers think in impact.
- And great projects happen when both speak just enough of each other’s language to get into trouble together.
Exhibit A: The Kickoff Call
Engineer husband:
“We’re following VASS 6.0.2, but I need to check if the safety PLC uses a separate Profisafe channel.”
Me:
“Right. While you do that, I’ll confirm if the client’s team they actually sent us the updated machine layout or just thinks they did.”
Because here’s the deal: someone needs to understand both what a G120 is and how to write a proper client email with bullet points. That’s me. I don’t pretend to know everything that’s happening in the PLC code — but I do know how to keep a project from derailing at week three when nobody’s booked flights, someone forgot to order patch cables, and the HMI is still in Italian.
Exhibit B: Communication Styles
Me:
“How are we doing?”
Engineer husband:
“Depends. The code compiles, but the robot controller is throwing errors unless I simulate the gripper. Might be a signal inversion, might be a timing issue.”
Me (translation):
“Okay, we’re not in flames. I’ll push the Monday meeting and get you time to test.”
I don’t have to write code. I have to understand what’s blocking the people who do and remove that obstacle. Sometimes that means client diplomacy. Sometimes that means explaining why “almost working” isn’t good enough when you’re launching a line that’s going to stamp 40 parts per minute for the next decade.
What I’ve Learned as a Non-Engineer Leading Engineers
Ask the right questions — even if they sound “dumb.”
My “will it work?” is half-joke, half-risk assessment. It gets engineers thinking about safety, assumptions, and client fears. That’s valuable.
Give technical people space to do what they do best.
I don’t micromanage the code. I manage everything around the code.
Never underestimate the power of context.
Engineers build elegant solutions. I give them the real-world parameters they have to work within — deadlines, client politics, code to get into the hotel room.
Be the bridge.
Someone has to connect procurement, commissioning, electrical, programming, and the client’s vision. That someone is often me. Or you, if you’re the non-engineer in your team.
Final Thought
Working with engineers is like co-piloting a spaceship. One of you is handling the fuel flow, ignition logic, and trajectory math. The other is making sure you land on the right planet, with food in the hold and a smiling mission sponsor. It’s not about who’s smarter — it’s about respecting each other’s expertise.
And yes, occasionally I still ask:
“Will it work?”
Not because I don’t know — but because I need to hear the engineer say, confidently:
“Yes. We tested it.”
That’s when I know we are ready to go home.