Why this feels so hard
A few dynamics tend to show up together
By: Jim Homyak
I often times find it impossible to write crib notes (aka from a SysOp to a SysOp) here on my hobby time, because we have almost nobody who is anywhere close to what I know. Plus, I am not even close to what you know. I am also feeling too technical to be a suitable committee chairperson or some kind of leader. Why is that? I can't seem to stop talking over people's heads.
It makes sense that I feel stuck in that space between “I know too much to simplify it” and “I don’t have anyone to hand this off to.”
What I'm describing is a very real and very common experience among highly technical people: when our mental default is systems‑level thinking, it’s hard to switch into “committee‑friendly mode.” And when we’re the only ones who understand the infrastructure, we end up carrying everything by default.
I'm not broken, and I'm not unsuited for leadership. I'm just operating without the right translation layer.
Again, why this feels so hard . . .
A few dynamics tend to show up together everywhere in my life these days:
-
I think in abstractions and dependencies, while most committees think in tasks and outcomes. That mismatch makes my explanations feel “too high up” or “too deep down.”
-
I'm used to precision, so I catch myself explaining the whole system to avoid being misunderstood. Committees usually want only the 10% that affects their decision.
-
I'm seemingly the only domain expert, so I can’t rely on shared vocabulary. That forces me to either oversimplify (which feels wrong) or over-explain (which loses people).
-
I am used to solving problems directly, not narrating them. Committees operate by narration.
None of this means that I'm not capable of leading. It means I’ve been trying to lead in a context that doesn’t speak your language.
What actually works for technical people in non‑technical groups
These are approaches that preserve my accuracy without overwhelming people:
1. Start with the decision, not the system
Instead of explaining the architecture, begin with the one sentence the committee actually needs:
-
“We have two options, and here’s the tradeoff.”
-
“This is safe to approve.”
-
“This will break if we don’t fix X first.”
Once the people know the point, they can choose how much detail they want.
2. Use “layers” of explanation
Think of it like an expandable menu:
-
Layer 1: What they need to know
-
Layer 2: What they might want to know
-
Layer 3: What only you need to know
You only open deeper layers if someone asks.
3. Translate complexity into consequences
Instead of describing the system, describe the impact:
-
“If we don’t patch this, we risk downtime.”
-
“This change will save us 10 hours a month.”
-
“This is low risk, but it requires coordination.”
People understand consequences far better than mechanisms.
4. Document for a future me, not for a future SysOp
If I'm the only one who understands the system, I must write notes that help me pick up where I left off. If someone else eventually comes along, they’ll be grateful for anything.
5. Don’t try to “dumb it down”—try to “scope it down”
We don’t need to simplify my thinking. We just need to narrow the part I share.
Why I'm more suited for leadership than I might think
Highly technical people often underestimate how valuable their clarity, pattern recognition, and long‑term thinking are. Committees don’t need their tech coordinators to be less technical—they need us to be more selective about which part of our technical mind we bring into the room.
Leadership isn’t about talking at the right level. It’s about helping people make good decisions. We already know how to do that; I just need a communication style that fits the audience.
As I am open to it, I can find the help I need to build a simple “translation framework” that I can use in meetings so we don’t feel like I'm talking over people’s heads. Would you want something like that?
Drop me a line to
