Early on in my career, I was happily building out new features and diving into whatever different tech stack presented itself. I prided myself in the ability to jump in and get shit done. I was like someone who never learns a foreign language to any level of basic fluency, but can visit any country and ask where the bathroom is. Everyone liked working with me (as far as I could tell), so I was this super versatile engineer who could help out on any team.
I identified very strongly as a generalist. I liked that I could figure out just enough pretty easily to get something done. When I thought of building technical depth, I imagined being a specialist like a super hardcore database engineer who had worked on various database technologies for 20–30 years. I couldn’t commit to something like that. I’d rather be building and shipping features.
A few years in, I realized that the advice to stay a generalist for as long as possible wasn’t serving me that well. When teams were assembled, I was never the person that a team was built around — those were the specialists. The specialists were the givens (because their unique skillset and the project matched up), and the rest of the team was filled in. I was filler. Suddenly, being called a “versatile engineer” didn’t feel like a compliment anymore.
I worked with my new manager to build depth in a few areas and systems, and I soon saw that building technical depth didn’t at all mean committing to something for the next 20 years. Once I became the most knowledgeable person in an area (in my specific instance, it was the notifications system and internal API design), people started consulting me on technical design decisions. I started to have more opinions about our infrastructure. I developed a deeper level of critical thinking and problem solving. And when something didn’t make sense to me, I didn’t assume that it was that way because some all-knowing engineer had set it up just so — I tried to understand how it had become that way, and suggested and made improvements.
It was the process of building depth and expertise that was invaluable — working on something beyond the superficial level of just getting something to work is very different from understanding it fully. When you learn one foreign language and all its conjugations and sentence formations, it becomes way easier to learn another one — similarly, once you fully understand one complex engineering system, the next one becomes much easier to grasp. My T-shaped skillset was finally starting to grow a trunk rather than a stump, but not only that, building that depth made it easier to build depth elsewhere (hence the banyan tree).
I once interviewed someone who had participated in and won several hackathons. When I asked him what areas he thought he would have to learn more about to support a web application in production (beyond a weekend) with millions of users, he looked at me curiously, and replied, “well, maybe some backend infrastructure, but actually, now there’s AWS so you don’t even really need to know that much.” Building technical depth also increases your understanding of what you don’t know in other areas, and helps you develop empathy and become less insufferable to work with.
When I moved over to management, I started to give the new grads I was managing pretty different advice than I had received and followed early on. Yes, work on a lot of different things. But even if you identify as a generalist, also find something to go deep in. It doesn’t really matter what it is.
