I used to think being a good engineer meant knowing a little about everything. I'd bounce from networking to databases to cloud infrastructure, picking up just enough to be dangerous. It made me feel versatile, like I could solve any problem thrown at me. And for the first few years, it kind of worked. I could patch together solutions from different domains, and my managers liked that I was flexible.
But there came a point where I hit a wall. Every time a complex issue surfaced something that required real expertise, I'd freeze. I could tell you the basics of how a load balancer worked, but when the traffic patterns broke in a weird way, I had no idea why. I could set up a database, but tuning a query that was bringing production to its knees was beyond me. I was a mile wide and an inch deep, and the cracks were starting to show.
That changed when I spent two years focused entirely on performance optimization for a legacy ERP system. It was brutal. I learned the internals of that platform better than I knew my own apartment. I could read execution plans like a novel, predict cache misses, and argue with developers about index design. It was tedious, frustrating work. But somewhere in that grind, something clicked. I stopped being the person who could talk about performance and became the person who could actually fix it.
What surprised me was how that depth unlocked breadth in unexpected ways. Once I truly understood one system from the metal up, I started seeing patterns everywhere. The way memory management worked in that ERP turned out to be similar to how a caching layer behaved. The locking mechanisms in the database mirrored concurrency issues in the application code. I wasn't just learning new things anymore. I was recognizing old friends in different clothes.
There's a trap in our industry where we celebrate the jack-of-all-trades. Job descriptions ask for five years of experience in three different stacks, and we all nod along like that's reasonable. But I've seen too many teams where everyone knows a bit of everything and nobody knows enough to fix the thing that's on fire. The T-shaped model works because the vertical bar gives you credibility and a home base. You can always retreat into your depth when the noise gets too loud.
These days when I mentor junior engineers, I tell them to pick one area and own it for at least a year. Not forever, just long enough to feel the weight of real expertise. Learn what it means to understand a system so well that you can predict its failures before they happen. Then take that confidence and branch out. You'll find the horizontal part of the T comes much easier when you're not constantly second-guessing your footing.
I still learn new things constantly. But I no longer pretend to be an expert in everything. I know my vertical bar is performance and systems thinking, and everything else is a horizontal exploration. There's a freedom in admitting what you don't know, and a power in knowing exactly what you do.