The choice between being a specialist or a generalist is debated by many engineers. Nowadays, the industry may need something in between.

Generalist

As the saying goes, “A jack of all trades, but a master of none”. If you decide to go the path of the generalist your skills will grow horizontally. You will enjoy learning new concepts and will be able to satisfy your curiosity by working with different tools and languages.

However, mastering anything will be hard. In order to become proficient with a technology you need to dedicate massive amounts of time to it. A generalist focuses on multiple things at once, so their attention is split up.

In recent years, being called a jack of all trades has a slight negative connotation. Generalists cover a lot of area in their skills but many remain on the surface. Often, when challenging work needs to be done - engineers with deeper knowledge are needed.

Specialist

Specialists devote their time and work to a narrow set of technologies and tools. They sacrifice the joy of exploring multiple disciplines by dedicating their time and efforts towards one area. That way they may lack knowledge beyond the fundamentals in supporting areas but become masters at what they do.

Many developers are in this field because of the challenge. They like solving puzzles and untangling complex problems. It is often the specialists which are tasked with the most difficult but rewarding solutions.

Their mastery gives them insight that other developers lack.

Devoting all your time in one language, stack or technology can be limiting, though. If you decide to go the specialist route, you need to consider what investment will pay off the best in the long term.

Companies, Markets and Talent

The software industry is experimenting and looking for ways to build more effectively. In recent years we’ve come to the realisation that software engineers are not burdened with the challenges of other industries. We don’t have to develop products the same way physical ones are done.

We can ship faster, change frequently and most importantly - revert if we have to. Nowadays, projects rarely go as planned from start to finish. Modifications are made along the way. Sometimes whole features are abandoned and new ones are prioritised in their place.

Those specifics lead companies to look for smarter ways to work. But in order to do that, the industry needs different talent.

How We Used to Work

In the past, product work was prioritised based on what resources were available. If a feature required more back end engineers, but the Java developers were busy then development on it would be postponed.

This could cause hiring problems. When the company expects more back end or front end work, it would hire specialists in the corresponding area. But if priorities shift we’d end up with unutilized engineering power.

I’ve witnessed this more than once - product management trying to figure out how to keep the UI team busy. The next couple of months the back end team would focus on refactoring and improvements. So there is no one to implement the new required endpoints.

In this scenario, engineers may get asked to take up tasks that they wouldn’t normally do. This can be frustrating for people that have spent their time mastering a different stack.

While this could be a sign of bad planning, I don’t fully agree. People get hired because of their skill set but at some point direction shifts. Maybe a new competitor entered the market, maybe the users’s preferences changed, maybe it was something else.

Best of Both Worlds

The business needs engineers that can adapt to the dynamics of the modern world. Professionals that are self-sufficient and won’t go into paralysis when the DevOps is out on holiday. Ideally, any person in the team should fill any other role if needed - from small tweaks on the UI, to debugging the CI pipeline.

This is easier said than done, though. Acquiring the skills to be productive in multiple areas requires years. You also need to be exposed to different parts of the product. A company with strong silos between teams won’t give you that opportunity.

At the same time, when complex work needs to be done, a team of generalists may lack the experience to take proper decisions. When the database’s performance needs improvement or architectural decisions need to be made you need a person that’s deeply focused on that topic.

The T-Shaped Engineer

The evolution of software development methodologies required a new kind of engineers - specialised generalists.

Thus, the term “T-Shaped Specialist” was coined. It is used to describe a person whose knowledge distribution looks like the letter T. The horizontal line describes a broad working knowledge in multiple areas. The vertical one is for specialization in a topic.

A back end engineer who can put up their own interface, style it reasonably and deploy it may fall into that category. A UI engineer that can spin up an Express service when needed and can debug an API endpoint could also be considered T-Shaped.

Having a team of specialised generalists means that work can be prioritised without worrying about the available developers. This breaks the silos around teams and helps everyone to get more involved in the project.

Problems of T-Shaped Engineers

Having T-Shaped specialists is not a silver bullet. It doesn’t mean that anyone can do any job and do it well. While they have broad knowledge this doesn’t mean that they can perform exceptionally everywhere.

The business may sometimes falsely expect such engineers to be experts in everything. T-shaped engineers can adapt and get up to speed with different technologies. But they still have a main area of focus.

Expecting a specialized generalist to be an expert on cloud, microservice architecture and user interfaces is not realistic. Developers can wear many hats and support each other but knowing each team member’s strong sides is crucial.

Otherwise we are again in the situation in which we expect generalists to take decisions which require serious expertise.

Is It a Choice?

I recently started a couple of discussions on LinkedIn about specialists and generalists. Which option should a professional pick nowadays? Some of the answers came from non-technical people which shows that this is not just a problem in the software industry but as a whole.

The summary I can give from all the responses is that people are leaning more towards being a generalist or a T-Shaped specialist.

I don’t think this is a trend. It’s a real need that the business has and being a generalist may no longer be an option but a requirement.

Even if you devote your time to one topic it requires you to have knowledge in multiple supporting areas. Modern tooling has become so good that it allows us to be more involved in the full development process.

But with that comes the responsibility to learn more. When you’re building something you need to write tests for it. Then comes the question about how you will deploy it. To do that, you need to decide what infrastructure would do the best job.

Once the deployment process is done it opens the door to more challenges. You need to monitor and maintain the product you’ve shipped which is no easy task.

To do all this properly you need more than just working knowledge with a broad set of tools. As culture shifts to a “You build it, you run it” mindset - specialising in one area is no longer enough.

Summary

• Software developers need to make the choice between being a generalist or a specialist.
• Generalists have access to broader variety of work. Specialists are focused on a single area but problems they face are often more challenging
• Companies need to be flexible and adapt to market conditions. To do that they need talent that can easily shift priorities too.
• Specialists are too tightly focused. Generalists are flexible but they may lack the experience required for complicated tasks.
• A T-Shaped specialist is someone who has broad knowledge across multiple disciplines but focuses on one the most. Developers with this profile are highly valued across organizations. They are adaptable but can provide deep insight on the topics they have focused on.
• Chosing between being a generalist or a specialist may no longer be a choice. Modern tooling lowers the barrier of entry in other disciplines. Engineers are expected to do more beyond design and implementation.

Join the Newsletter

Every few weeks I send out my newsletter. Usually it contains my latest article, some useful coding resources and a quote about software engineering to ponder. Drop your email if that sounds interesting to you. No ads or spam. Unsubscribe any time.