Today, let's go a little deeper, into what makes a Generalist or a Specialist and how they mix together in a software engineering team.
There is a place - there is a need, even - on a software team for both the Generalist and the Specialist. Whether you are wired to go ever-deeper in your expertise and specialization or to go intermediate-deep on any given topic but apply that same depth across a wider breadth, you have a role to play.
And we need each other; there are both strengths and weaknesses, pro's and cons, advantages and disadvantages in each approach. A need to balance each other,
The Specialist's Deep Expertise
I used to work with a fellow who was a lifelong fan of the Toronto Maple Leafs hockey team. Not just a fan, a fanatic. But his fanaticism expressed itself in his love of the lore and the history, not in the outward expressions of the super-fan. You were unlikely to see him go any further than a jersey or a hat - no face-painting or street-dancing for him. But you were also unlikely to ever win an argument with him about the facts, figures and trivia of the team. He knew who was their main goalie in 1958 (Johnnie Bower) and could think through and answer questions about how many times they lost the Stanley Cup final (9 times).
The depth of his expertise on the history of the Toronto Maple Leafs always astounded me. (Of course, as a much less-knowledgeable fan of the Montreal Canadiens, I could not figure out WHY he had that expertise!)
A Specialist in the tech world likewise develops an amazing depth of skill, expertise and experience in one or a small number of technologies or domains. They might know the finer points of tuning a database; or be expert in cyber-security or have extensive and deep experience with AWS services and architectures.
Like my Maple Leafs fan friend, some of their knowledge will be at their fingertips: the benefits and subtle differences of each type of load balancer, for example. Other times, their expert, specialist knowledge will give them the ability to quickly think through a problem from different angles and pull the most critical facts together.
That makes them most valuable when facing the knottiest, most difficult, most technically complex challenges. Call this their greatest strength.
Some of the strengths of the Specialist are
- Deep expertise and ability to solve the hardest problems
- Quick recognition of patterns and solutions
- Authoritative presence with trusted guidance and mentorship
- Attuned to subtle or nuanced scenarios, failures and optimizations
Of course, it is not all honey and roses for the Specialist. The cliched critique is that they miss the forest for the trees, so focused on the finer details that they miss the wider picture.
Some disadvantages of a Specialist include
- Narrow focus, overlooking implications beyond their domain
- Bus-factor of one, when the team becomes too reliant on the specialist
- Boxing in - specialists can struggle to shift between different types of work or different tech stacks
The specialist's advantage isn't merely knowing more facts. It is having developed an intuition about the problem space through repeated exposure.
The Generalist's Broad View
A generalist, like me, will not have the exceptional depth in a particular technology or domain that the specialist does. Instead, they will bring a working knowledge of a wider range of technologies, disciplines, domains, components.
Think of the solutions architect, able to draw on a knowledge of networking, storage, compute, security, optimization, cost and other factors in designing a robust and resilient solution. Full disclosure, I am a certified AWS Solutions Architect (Associate-level).
A Full-stack developer also tends in the generalist direction, moving easily between front, middle and back tiers of a system. Although they can become very specialized in the particular stack through which they move.
Some strengths of us generalists include:
- Ability to adapt to and move between different technologies or roles
- See and actively connect work and concepts across boundaries, be they system, technical, architectural or organizational
- Versatile in playing many different roles, wearing many different hats when needed
- Bring ideas and solutions from one domain into another
But as with the specialist, these advantages come with trade-offs, like:
- Solutions will be more shallow and may miss important complexities or edge cases
- Broader responsibilities lead to increased context-switching and reduced concentration
- Challenges maintaining even intermediate depth across ever-growing fields
We generalists show our value in problems across components, tiers, organizational or other boundaries. Where a specialist can fine-tune the database query or back-end algorithms to address a performance problem, when it is caused by a larger end-to-end inefficiency, the generalist will be better placed to solve it.
Or in the face of ambiguity or not-fully-defined problems, which the specialist might send back as needing more work on the Product side, the generalist is well-placed to work with Product to define and decompose the problem.
Team Management Challenges
Given the reality of people with different interests, experiences, expertise and career goals, two challenges of managing real-world software engineering teams occur to me.
First is finding the right balance.
A team filled with only specialists will have phenomenal abilities to solve very complex technical challenges within the bounds of their expertise, but struggle once they must reach beyond those edges. A team of only generalists may excel at delivering routine features and fixes but struggle when the deeper and more vexing problems arise.
Some blend of the two seems, on the surface, the right answer to team construction. In my experience, the specifics of exactly what that blend and balance looks like varies, depending on the context of the organization, problem domain and nature of the challenges ahead.
A startup might benefit from having more generalists, maximizing flexibility and ability to adapt rapidly to changing inputs to deliver end-to-end solutions.
An infrastructure or platform team would need more specialists with strong understandings of their systems.
An R&D team might demand even higher levels of specialization, to push the envelope of what is possible in the domain.
A product-driven team, especially an environment with sometimes-fluid requirements, would be more successful with a more generalist-heavy balance.
These are obviously sweeping statements; your mileage may differ in your specific context. A startup in the field of cryptography or cyber-security would need much deeper specialization than my generic statement earlier.
The second team management challenge is how to avoid accidental specialization.
You know the tendency of both managers and teams: the Dev who built feature X is the one who gets assigned the next hundred tweaks and fixes to that feature. After all, they know it best, they will finish the task faster and better than someone else.
Basically:
- The Engineer gains expertise in a feature
- More related work is assigned to that engineer
- Others have fewer opportunities to learn
- The engineer becomes the local specialist
A series of perfectly rational manager decisions made sense in the short term. But ultimately lead to a more fragile team, dependent on the expert.
The challenge is how to foster a healthy team with local expertise alongside adequate knowledge-sharing and generalized knowledge. It will require the manager to deliberately accept some short-term inefficiency, whether through pairing, rotation, or cross-training.
TL-DR
Specialists bring depth, understanding difficult problems and their subtle consequences.
Generalists bring breadth, connecting disciplines, navigating ambiguity, and crossing boundaries.
A specialist's initiative may identify an opportunity nobody else understands.
A generalist's initiative may recognize a problem spanning multiple systems.
A specialist's diligence may catch a subtle technical flaw.
A generalist's diligence may uncover a failure at an integration boundary.
To create and foster an effective software engineering team, we cannot choose one model exclusively, but must find the right mix for our specific context.