What’s so special about specialists?

A problem I am constantly asked to address is which are better Generalists, Specialists, or something in between? I have written about it, presented about it, and podcasted about it, but nothing as extensively as I plan for this post. Honestly, I don’t know how much additional value I will add to the community of thought on this topic, but at minimum, I will now have a URL to send people who want to know more details. So for me, this will be a big time saver. Much of the content comes from years of research and experience in coaching teams through an agile process.

The problem

Inevitably, the teams I am helping will face a period of rejecting agile because of some challenge a person or set of people are facing with the change. Usually, I get something like: “I am a specialist and this is doesn’t optimize for me”. This has always happened when I am coaching a team conversion from waterfall methods to agile. However, even the more successful teams face some challenge if they overdo the shift and swing the pendulum too far in the opposite direction. “I am a generalist now, just like everyone else. How do I differentiate for performance reviews?” If you facing similar questions on how your team should be staffed, then it is my hope that this post will help you answer what is right for you, why is that so, and some hints on considerations should you desire to implement changes in your environment. If you desire a simple one-size-fits all answer, then you want T-Shaped people. If you looking for a more nuanced answer, then I will encourage you to read on.


There multiple examples to draw from when comparing specialists and generalists. In the animal kingdom, a Koala is known as a specialist species. It can only live in one environment and has only one source of food. Compare it to a Raccoon, which has been known to be able to thrive just about anywhere. In the medical profession, you may have a general practitioner who will refer you to a heart specialist. Even jobs like Sign Spinners and Dog walkers are considered specialized jobs as they generally are only seen in specialized environments (heavily populated areas). Whereas, you can find a Handyman just about anywhere. It is interesting to note that Sign Spinners are becoming automated (crudely automated, sure, but automation always starts with basic beginnings). Lastly, there is the software world, where it is quite common to hear developers and testers to claim themselves to be specialists.


I am going to be exploring this topic as it relates to software development and the software development lifecycle. In addition, while almost every change requires shifts in people, processes, and technology, I am not going to spend a lot of time on tech. I am also going to assume (falsely) that delivered code is always perfect. This will help to keep the explanation simpler. As the patient reader will discover, this is a deep topic and I will only barely scratch the surface.


Some key terms used throughout this post.

Knowledge Worker – Thomas Davenport says: “Knowledge workers have high degrees of expertise, education, or experience, and the primary purpose of their jobs involves the creation, distribution or application of knowledge.” It is important to note that every human being is a bit different in terms of how they think and create, therefore it should not be a surprise that every knowledge worker has unique characteristics when it comes to producing results as well as the optimal environment needed to do so. However, this uniqueness is abstract to some degree. For example, I have knowledge for blogging, podcasting, agile practices, customer quality, data science/handling, testing, etc.

Generalist – someone with a wide array of knowledge; a person competent in several different fields or activities:

Specialist – a person who concentrates primarily on a particular subject or activity; a person highly skilled in a specific and restricted field.

Versatilist – someone who can be in a specialist role but at the same time switch to another role with ease; also known as a t-shaped person.

The Goals of Business

The goal of any business is to find a stable business plan that creates value and can grow the reach of the market to as many folks as possible. As part of this, optimizing the utilization of the resources used to produce new products is important to keep costs low and make more widgets. An important KPI when discussing Specialists and Generalists is Productivity. Productivity is defined as the number of outputs per unit of input. Since we are talking about software, let’s say the outputs are features that vary in their degree of value to the customer and the inputs are team members and time. However, while this is a necessary condition, unless you can easily replace those folks who leave your team, Employee Engagement is also going to be an important consideration. For the purposes of this post, I will define this to mean the degree in which your employees enthusiastically act to deliver business outcomes. Happy people are productive people.

Do NOT confuse productivity with efficiency. They are not synonyms. Efficiency is a measure of the ability to minimize waste while producing outputs.   It is common enough to misunderstand these terms.  Their differences can be subtle.  Here’s another reference comparing both.


The first known use of the term Specialist was in 1855 and it was coined to describe a medical practitioner who devoted their study to a particular branch of medicine. One year later the man would be born who would eventually create the system of management used most often today, Frederick Winslow Taylor. Taylor created the topic known as Management Science (aka Operations Research or Taylorism) back in the 1800’s deep within the industrial age. What started it was a study he did that recognized that deeply studying how workers performed their jobs and making small tweaks would greatly improve productivity. He used the term Generalists to describe workers that could be applied to most/any machine and specialists to describe those whose knowledge could only be applied to a very specific one. Taylor is accredited with noticing that the more repetitive the work could be made and the more inputs could be made consistent, then specialists would produce far more than generalists. He would prescribe folks to stay on a single machine and measure everything about it. Ultimately, he perfected the efficiency of the worker on that machine. But it came with a consequence, the resulting jobs required “less brains, less muscle, less independence”. In those days, this was fantastic. Getting new workers was relatively easy to come by and you could train them fairly readily on a new machine, and reap the rewards of high productivity, but it came at a cost. The workers became so specialized that they could not well function in a changing environment. Indeed, they could only take their inputs and turned them into the desired outputs. They were entirely unawares of the whole system in place. In order for the system to function, Taylor proposed a system of Managers to be constructed; it would be their job to 1) be the brains, 2) study productivity and 3) study and control the system. For the last 200 yrs, this was how the manager/employee relationship functioned, so when computer related jobs started to grow it was the business model most were used to.

The Pros and Cons of Specialists & Generalists

Specialists are optimized for “going deep” on repetitive tasks that require a minimum number of dependencies to succeed. In addition, they do not take a system view of problems, often requiring management to control their workloads in order to optimize productivity. In addition, as eluded to above, they are highly inflexible. Generally, they thrive in very specific environments with very specific workloads. Their inflexibility can be a bit of a problem and readily can cause workload starvation or bottlenecking of the process. For example, consider a UI development specialist whose UI is frozen (meaning no longer permitted to change for the release), what shall they do now? If it’s clear, the product will have a subsequent release, it may be fruitful to have them work on that now. This is more efficient, but if the product is stalled do to database changes then it would be more productive for the UI developer to apply their talents there. If they aren’t capable of doing so, I’ve seen teams go as far as add new UI features just so their developers aren’t idle. This creates a product that is optimized for the skills of your developers AND NOT for the needs of your customers. In the world where your customers can go to a competitor in a split second, this sadly is a really bad idea. However, there are really solid places where specialists make sense. In particular, those critical needs for a software release that are rarely called upon. Security and performance are examples. These require deep knowledge, generally valuable, and (unlike UI development) can be challenging for someone to pick up on a moment’s notice.

In contrast, Generalists are those folks optimized for flexibility. They are do take a system view, are very good at “filling in the cracks” and can be applied at just about any time to just about any problem. They are exceptional at solving 80% of any development problem (or 80% of all development problem… depending on how you want to look at it.. aside: both numbers totally made up), which leads them to be massively productive, since there is plenty of work them to pick up and move forward on. However, they tend to be inefficient with much of their time spent on ramping up on a new code base or learning a new skill. A frequent reader of this blog and/or listener to the AB Testing podcast will recall that I spent time as a manager of a dev team in the Unified Engineering model. There I encountered a phenomena: folks that had come from Test were out-producing those from Dev. I believe this was for 2 reasons: 1) Test development is a generalist skillset and 2) there was nothing particularly challenging about my product that required deep expertise in any particular area.

So what’s the silver bullet?

Ok, so specialists are more efficient than generalists, but generalists are more productive. But ideally, you’d want both: High Output and Low Waste. With a couple of caveats (see below), if you have a highly controllable business environment, then specialists are the way to go alongside a management team than controls how/when these folks are applied. Management will need to make sure all dependencies are cleared before the work gets handed off, of course. However, if you are operating in an chaotic business environment that needs to adapt to changing business requirements, you are better suited to hire a couple of key specialists and have the bulk of your team be generalists. Management may need to control costs directly, focusing the attention of the Generalists to only a few areas for each person. In both models, if the environment changes, you will need to be prepared to fire, then rehire your team if productivity/efficiency suffers as a result. This approach too may not be good enough though. It’s hard to quickly hire a team of any given size and time consuming. Once in my career, I completely hired a team of 30 people in just one month. It was a strong team, but it was grueling and required me to spend 3 weeks of interviewing 40 hrs a day, which was quite hard on my psyche (especially since I had other work to do as well). A better solution is hire versatilists. Think of them as specialists in 3 to 4 of the skills your team needs. As an example, I run a data science team today. I required every member of my team to be strong in at least 2 of the following: Data Science, Development, or Data Engineering. They need to also have a passion to learn the 3rd. As I hired, my emphasis for the remaining open positions focused on which area of my team showed the greatest weakness. This is strong and I am proud to claim they are known for being highly productive closers.


  • People have their own incentives. Above I mention a few caveats, much of these article is representing things from a pure emotionless business angle. However, until we’ve automated the development role, your employees will have emotions and care for more than just the business. Daniel Pink describes this human element as driving for Mastery (getting better at doing) something), Purpose (working towards something larger than ourselves), and Automony (self-direction). The value proposition of a product will, hopefully, drive their sense of Purpose. Specialists are going to be strong at pursuing Mastery and complain about being told what to do and when as will be required in order to keep your team productive. Likewise, Generalists are more easily granted autonomy (especially in an agile process such as Kanban), but they may not grow and may feel like they are constantly investing in and then abandoning skills. The Versatilist approach strikes a balance between these 2 extremes.
  • Software development is knowledge work. Very few things, in my mind, actually falls into the camp of “repetitive work” and low dependencies required to make specialists thrive. In fact, Steve Johnson’s work suggests that we would not want this even if we could construct it. Innovation comes from old ideas mixing together. A team of Versatilists, each required to switch areas every so often with 3-4 deep specialties are going to help knowledge sharing grow and help you innovate and adapt both productively and efficiency.

Send me your feedback and/or comment below. As I mentioned above, I’ve been meaning to write this for quite a while. I hope it’s helpful.


Book Review: Lean Analytics – great primer for moving to DDE world


So O’Reilly has this great program for bloggers, called the Reader Review Program. They will let me pick out a book of my choosing & read it for free, as long as I write up an honest review of the book here on my blog site. Because I know that I will eventually posting reviews here, I will be picking books that I think might have value to the audience that is following me. This is my first foray into this model. Right now, I think it’s an “everybody wins” thing, but I will pay heightened attention to how this affects the integrity & reputation of the site. Since I am generally reading 5-10 books at a time, I highly doubt that I will post blogs like this more than once or twice a year. Your feedback is welcome.


Lean Analytics by Alistair Croll & Benjamin Yoskovitz; O’ Reilly Media

    The title above will take you to OReilly’s site so you can delve further if you choose.



    As the title suggests, Lean Analytics is a solid combination of two powerful movements in the Software Engineering world, Lean Agile and Data/Business Analytics. While there are several books out there discussing the need for data science and growth in statistics, this book really covers the What, How, and Why for using data to drive decision making in your specific business. Without being too technicial or academic, it introduces readers to techniques, metrics, and visualizations needed for several common business start-up models in operation in today’s world.


    I am ***REALLY*** fond of the Head-First Series of books and that is just about the only thing that could make this book better. After The Lean Startup this is probably the most useful book for those trying to iterate fast in today’s software engineering world. I found the information to be very straightforward and easy to follow. While I think the authors really tried to cram everything they could into the book (at times, making it read awkwardly), they introduce you to practical examples of how to use the material and when.


Several sections of the book are quite good… looking at some lightweight case studies of startups and the analytics they used to navigate muddy waters. The book tries to make all types of software business accessible. Ranging from how to categorize the growth phase of your company, what things to use during your value phase, what analytics are appropriate for various types of companies (mobile apps versus SaaS e.g.), and even how to operate within enterprises. As a result, though, the depth at times can be lacking but if you are looking for a breadth book that covers all of the basics this one might be good for you. Reading it is one of the reason I have decided to start my Masters in Analytics. With more information in the case studies, and more examples of actual data to look at and suggestions on how to avoid false metrics and gives guidance on what to look for.


One of the struggles that I am seeing at my place of employ is that Test is shifting away from automation roles and into data pipeline roles. This means we are just changing the way in which we deliver information so that others can analyze it and make the “adult” decision. This, imho, is not good. But it falls within Test Wheelhouse, so it is safe. Please Please Please instead grab this book and take a leadership role. This book will help us start the disciple move into a direction setting role instead of just a measurement one.


This will likely be the topic of my next post. Thanks for reading…