The Role of the Generalist
I am not a specialist. This was a hard lesson for me to grasp for many years, and I would be lying if I said that I have fully learned it yet. For whatever reason, my instinct has always been to select role models who specialize in a particular area of their craft, rather than those who pursue a slightly wider range of skills. In an effort to rectify this, I am going to share some lessons I have learned over the past few years as I have made my way in the world of technology as a generalist.
What is a generalist mindset?
To start with, I think it is helpful to define what I mean by “generalist” in this context. To me, a generalist mindset means placing a priority on learning the first eighty-percent or so of several interrelated skills, such that one can complete larger tasks from start to finish, often using skills from several domains or subdomains on a single project. The difference between a “specialist” mindset and a “generalist” mindset, then, is that while a generalist might specialize in a specific field of work, a “specialist” is interested in picking an even narrower subset of those skills to drill down into so that they can know as much as possible about one particular domain.
The generalist engineer
So what does this look like in my day-to-day job as a software engineer? Well, as a generalist, I often need to ask questions so that I can start with an understanding of the bigger picture. I want to know who is going to be using the thing we are building, what problems they will be solving with it, how we are going to maintain it, and how it fits into the future direction of the other products we are creating. By allowing my curiosity to push me to gather this type of information, I have found I am able to help better lead new work and answer questions about existing work for internal customers and teammates later. As an example, I have not spent as much time working in Java as I have Ruby and I cannot yet fine tune the JVM much beyond the basics. As a generalist though, I have done professional work in a couple different JVM languages and I’ve been able to build multiple, easy-to-maintain web applications that solved the problem at hand when that was the tool that we needed to use.
Continuing from this example, if you really need to fine tune a JVM in a high-throughput application, obviously my skill set is not going to be immediately useful. Here comes the fun part though, if we have a few moments it is entirely possible that I could go read about the specific JVM-related issue at hand and come up with a solution for us to try. This is because being a generalist means that I need to be able to learn enough on the fly to fill in as a kind of pseudo-specialist in a wide range of environments throughout my work day. One moment I might be configuring a Puma web server for a Ruby on Rails app, and the next I might be writing a new feature for a Kotlin API. I am not an absolute wizard in either of these domains, but do I know enough to figure out how to solve the problem at hand more often than not. As fun as it is to call in a specialist with the bat signal, usually all we really need is just someone who can fix the thing, write the feature, or turn the power off and on again.
We need everyone
We cannot all be specialists, and I am here to say that is both okay, and amazing! After all, a strong team is made up of a wide range of people, some who are natural generalists and some who are driven to specialize in a smaller range of domains. I am learning to embrace my inner generalist and I continue to uncover more ways every week that I am able to use this mindset to contribute in unique ways to the products my team delivers.
