When I realized my biggest gap wasn't technical — what an outside review showed me

Before you ask “what should I learn next?”

If you’ve been working as an engineer for a few years, this question probably shows up at some point.

“What should I study next? Which certification will get me to the next level?”

I was sitting with exactly this question, getting ready for a job change and doing an honest career inventory. Cloud, AI, security, project management — the moment I started listing the things I “should” be learning, the list became infinite.

Around that time, I had a chance to get a gap analysis done by an outside party. They read my CV, my personality notes, my homepage, all of it — and gave me back an objective picture of “what’s the biggest gap between where you are and the future you say you want?”

The answer they came back with was nothing like what I’d expected.

”Your gap isn’t technical”

The opening line of the report has stayed with me:

What you most need right now is not “adding new skills.” It is turning the experience and intuition you already have into formal knowledge, and building a habit of structurally understanding and correcting your own thinking patterns.

I’ll be honest — at first I was a little confused. Part of me had been hoping for a clear instruction like “go get AZ-104” or “go deeper on security.” Concrete, checkable, actionable.

But as I re-read the line, it landed harder each time.

I had the experience — just not the formal version of it

Over the past few years I’ve led teams of 1 to 4 people. I’ve gone end-to-end from requirements to operations. I’ve done my share of task distribution, progress tracking, and 1-on-1s.

But in the language of the report, all of that was just situational experience.

  • Could I explain, to someone else, why I made the calls I made?
  • Could I reproduce the same outcome with a different team?
  • Could I write down my 1-on-1 style as a “template” that survives me leaving?

For each of those, the honest answer was no. I had a mountain of experience, but none of it was in a shape I could hand off. That, I realized, is a far bigger problem than “I don’t know enough about cloud.”

The other wall, on the inside — “interpretation first”

If the outer wall was formal knowledge, the inner wall the report pointed at was a habit it called “interpretation first.”

The pattern they described in me went like this:

  • I build a “tentative structure” out of fragments even when information is missing
  • Once I put something into words, it starts to feel like confirmed reality
  • I quietly accumulate dissatisfaction, and one day it surfaces as a big decision

These aren’t separate tics. They all come from one underlying drive: the difficulty of staying in an “I don’t know yet” state. The need to close the loop and get to an answer, fast.

And the unsettling part: this is my strengths — structural thinking, fast verbalization — flipped into liabilities. Just doubling down on strengths doesn’t fix this. The fix is learning when to switch the strength on, not how to push it harder.

I’ll dig into that part more tomorrow, when I write about the psychological concept behind this — the need for cognitive closure — and what I’m doing about it.

The real gap for mid-career engineers is usually inside, not outside

Sitting with this longer, I started to think this isn’t just my story.

Mid-career engineers who have reached a certain technical level usually get stuck on the next stage for one of two reasons:

  1. The experience they already have hasn’t been turned into formal knowledge.
  2. Their own thinking habits aren’t understood as a structure.

Memorizing one more technology gives a smaller long-term return than writing up one past project as a “reproducible template.” Getting one more certification grows you less than naming three patterns of “this is how I tend to get it wrong.”

It sounds obvious once you say it out loud. But somehow, it’s the hardest thing to notice from the inside.

Three questions for doing your own gap analysis

You don’t need to hire someone to do this. These are the three questions I now ask myself on a regular cadence.

1. What percentage of my experience exists in a form someone else could pick up tomorrow?

Docs, templates, retrospective notes — anything counts. If “I could walk out today and the next person could keep this project running” is 100%, where am I really?

2. Can I name three recent judgment calls I got wrong?

If you can’t, it’s not that you haven’t made mistakes. It’s that you don’t have a habit of looking back. Even one concrete miss, named clearly, is great material for spotting your own thinking habits.

3. When does my strength flip into a weakness?

“Quick to decide” sliding into “decided too early.” “Logically clear” sliding into “talked over someone’s feelings.” Strengths and weaknesses are rarely separate things. Most of the time they’re the same trait used at the wrong moment.

Closing — own the map, not just the mountain

The biggest thing this gap analysis taught me was this: the thing to fix isn’t the size of your skill mountain. It’s the resolution of your own map.

  • A lot of mid-career engineers are already past the point where pure technical level differentiates them
  • What separates the next stage is the ability to formalize experience and see your own thinking accurately
  • Growth, at this point, is less about pushing strengths harder and more about catching the moment strengths turn into weaknesses

If you were about to open a tab and search “what should engineers learn next” — pause for a second first. Grab paper. Write down five judgments you made in the past year. The way your own words sound, written back at you, will probably tell you where your real next gap is more honestly than any roadmap will.

Tomorrow, I’ll go deeper on the concept behind that “interpretation first” habit — the need for cognitive closure — and the small daily habits I’m using to defuse it.

Contact

Feel free to reach out with any questions or feedback.

Get in touch