Specializing Generalist

The ideal agile team is made up of specializing generalists – but what does that really mean? The goal isn’t to prevent functional silos of expertise, it is to allow people to cover for each other.

Great Conversation

Elena Yatzeck (@eyatzeck) posted a comment on an earlier article about agile maturity models.

In terms of refinement, I’m thinking a lot these days about “staffing the engineering team correctly.” I’m not sure I agree in practice that you can or should try to staff all teams with “specializing generalists,” or at least not as taken to an extreme. (If you’ll forgive the self-promotion, I talked more about this here: http://pagilista.blogspot.com/2012/01/no-blender-zone-cross-functional-doesnt.html.)

I’ll not only “forgive” the promotion, I’ll re-promote it. Good stuff.

When re-reading the maturity-model article, this snippet popped out at me:

People over process is the right emphasis. If you can’t find people that are “good enough” you might as well go home. Doesn’t matter how agile you are if you don’t have the horsepower. You also need people who are excited to “do agile” they like to communicate, they enjoy the project and team dynamics of an agile process. You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed. This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
Agile Maturity Model

Thirty months later, my experiences have increased my conviction that this is true – and have realized that the way I wrote the quote above fails to provide a key clarification.

Following that link to an (even earlier) article on specializing generalists, brings the following (emphasis added):

The idea of specializing generalists is easiest to grasp by first saying what it is not. It is not staffing a team with a database expert, a user interface coder, a SOA (service oriented architecture) guru and an architect. With four specialists, each development task has an obvious owner. Database changes and refactoring go to the database expert. Reworking the UI goes into the queue for the AJAX hotshot. The problem is that this approach is only efficient when each team member is equally loaded with work. Since an agile team is continuously reprioritizing their work based on repeated feedback cycles as part of each release, this doesn’t work. The team will never face a situation where the (for example) four most important things to do are one item for each specialist. You can very easily have a release where all of the most important tasks are focused on the user interface. So all of the non-interface-experts are either working on lower-priority tasks, or even worse – they are idle. And you delay the most important work until the specialist can get to it.

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

This is very effective for making the “development engine” a black-box. Feed it the highest priority stuff, and it all gets done. We can take that approach to the next level. Designers can implement, project managers can design test plans, and yes, product managers can specify design. Twitch. Back up a sentence and read it again.

Specifying design is not the job of the product manager. True. Very true. Emphatically true. But specifying design can be what a specializing generalist does, even when that person is also responsible for defining market needs.
Specializing Generalists 2008

Elena’s article identifies a common misconception – that “specializing generalist” is a fancy way of saying “a bunch of people who can all do everything:

It’s a seductively simple fallacy of division to interpret the concept of “cross functional” team to mean a “collection of cross-functional individuals.” New agilists are quick to apologize that “we still have functional silos here” as though it would be much better if everyone could do all the same things. Grab some equally skilled poly-functional people, have them all take turns doing all of the jobs as needed, and you’ll all laugh your way to on-time, high-quality, and valuable working software.

Not so fast!

The power of an effective agile team, like the power of any other effective team, doesn’t come from its homogeneity, but from its ability to harness its diversity.
No Blender Zone: Cross Functional Doesn’t Mean Homogenous

Elena goes on to say (emphasis mine)

Team members shouldn’t attempt to Harrison Bergeron themselves into a mish-mash of mediocre (but working!) software. Someone needs to facilitate the stakeholders into some sensible semblance of a business case. Someone needs to build functional test suites that mercilessly beat on the code to prevent it from breaking in production. Neither of these are exactly the same skills it takes to gradually evolve the design of a complex system in modules of 100 lines of code or less. If people want to try new things, that’s great, but it needs to be with the realization that other jobs on the team are actual professions with skills and the need for experience in order to excel.

I completely agree.

Specializing Generalist

Specializing Generalist.

  • Not a specialist.
  • Not a generalist.

You need best of breed team members who specialize in areas of expertise – “actual professions with skills,” as Elena puts it. Without people who excel in the needed areas, you end up with a mediocre product. How many times have you gone to the store and asked for the “middle of the pack” product?

That’s not even table stakes anymore. Just the ability to create “something” isn’t interesting in the market, and isn’t interesting to the members of the team. How many times have you heard someone brag “I love my job, I’m a cog in the machine?” You have to have people who specialize in all of the needed areas (interface design, market insight, coding, quality, etc) in order to create a viable product.

If you staff your team with (only) generalists you will fail.

Pure generalists cannot create a product that is “good enough” – because they aren’t good enough at the creating the parts, from which the product is the sum. You have to have people who specialize in creating great “parts” of the solution. That’s what you need to have a shot at creating a great product. But it isn’t really enough. The problem is in how you define “great.” Great means that customers buy it, users love it, and your competition is knocked back on their heels by it. Everyone agrees on this, but most people miss one thing.

Your market is changing – you also have to be fast. You can’t solve the right problems if you aren’t fast, because the problems that are “right” are constantly changing – your market is a moving target.

Specialists, as individuals, are capable of creating great “parts” in their silos, and those parts all add up to a “great” product, so what’s the problem? The problem is that collectively, by the time the specialists are done, they are no longer solving the right problem.

If you staff your team with (pure) specialists you will fail.

The most important tasks for the team, in any given sprint, will not balance into a perfectly allocated workload, where each “part” is worked on by each specialist, where no one is idle, and no one is a bottleneck. It just doesn’t happen. I haven’t seen it in 15 years in the software world, or in my prior decade as a mechanical engineer.

When one specialist is waiting for something important, she isn’t idle, she’s just working on something that is by definition not as important. OK, you’re minimizing the damage – but you’re still taking damage. When another specialist is the bottleneck, you lose. Nothing magical to do here.

If you staff your team with specializing generalists you may succeed.

The work that piles up in any one specialized silo is of varying degrees of complexity. The “UI specialist” may be backed up with a bunch of CSS tweaks, some straightforward AJAX calls to write, and a gnarly refactoring of the model-view-controller model to adapt to changing understanding of market needs. No one can solve the MVC problem without specialized skills – but with guidance from the UI expert, one of the other team members can handle the AJAX calls and CSS updates. Extend this same model across other aspects of the product. Your database expert may be needed to optimize query performance or resolve locking problems, but other members of the team could make straightforward schema changes.

It is the collective ability of the team to optimize what they collectively work on that accelerates the team’s delivery of the most important capabilities.

You have to have people who specialize, in order to optimize individual performance. But your team needs to be built with specializing generalists in order to optimize for team performance.

T-Shaped People

From an HR perspective, I was taught about “T-Shaped People” – people who have breadth and depth of skills.

  • Specialists are “I-Shaped People” – people who have depth of expertise, without breadth
  • Generalists are “Minus-Shaped People” – people who have a breadth of skills, but no depth of expertise.
  • Specializing Generalists are “T-Shaped People” – people who have depth of expertise in one area, combined with a breadth of skills across many areas.

These are the people you’re going for.

Thanks Elena for re-invigorating the discussion!

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

42 thoughts on “Specializing Generalist

  1. You have reframed the way I have always thought about this.

    The characteristics I have always looked for are people that are:
    – flexible
    – curious
    – passionate about end result

    Flexible people get along well with others – more team-focused and giving you breadth
    Curious people dig into why stuff works – and how it fits into the stuff around – establishing context for their work – giving you breadth and depth
    Passionate people get stuck in relentlessly for your depth

    End result is kind of T-shaped but maybe a fuzzy T-shape

    1. Hey, thanks Giles!

      Yes, I look for those things too – and I find that I always enjoy working with people who have those characteristics. I would also add “passionate about the doing of the work” and the “raw capability” to do it well.

      I do think that those are characteristics that describe people who are or will be T-shaped.

      It provides a good framework for thinking bottoms-up about how to improve your own (or coach someone to improve their own) skills. When you look top-down at the situation, across multiple members of a team, my argument is that for a team to realize the successes that are available to be realized, you have to build your team with people like this.

      Try a thought experiment – if your competitor has a team that is staffed this way, are they going to clean your clock?

  2. Pingback: asudell
  3. Pingback: Vasily Komarov
  4. Pingback: David Hobbs
  5. Pingback: Ronnie Taylor
  6. Pingback: Roger L. Cauvin
  7. Pingback: Karol M McCloskey
  8. Pingback: Giles Farrow
  9. Pingback: toorr
  10. Pingback: Paulo Marinho
  11. Pingback: Alltop Agile
  12. Pingback: Giulio De Luise
  13. Pingback: Buytes
  14. Pingback: Olivier
  15. Pingback: The Agile Planner
  16. Pingback: Steven Ford
  17. Pingback: Kevin Brennan
  18. Pingback: João Cerdeira
  19. This is a great compilation.

    However, I do want to say that the notion of Specializing Generalists is equally valid for non-engineering roles as well. I worked in Product Management for several years before taking on a P&L responsibility. It was then that I understood that not everything needs an engineering solution and early on, marketing solutions are more important. People who can help you experiment with several marketing channels help you grow correctly not just your team but your entire business.

    That’s what we are trying to do at Online Courses Marketplace at WizIQ. The early results seem to be great.

    1. Thanks, Vikrama, and welcome to Tyner Blain!

      Great point that this applies to “everything” – personally, I think people with a breadth of skills (in addition to a depth in one or more skills) can be more effective in any role – and I think that is particularly true in roles like product management, that are already multidisciplinary to start with. It’s also great to know when the right way to address a problem isn’t to just “build something.” :)

  20. Pingback: jon gatrell
  21. Pingback: Vikrama Dhiman
  22. Pingback: Simon Pamies
  23. Pingback: Satwik Hebbar
    1. Great, Elena, and thanks again for kicking off (re-invigorating?) discussion around this topic! When I approach convincing people of the value of this, I look at the value props to the people involved.

      The Scrum Master gets to do less juggling, and fewer higher-priority items get dusty at the top of the backlog waiting for someone who can do them to come available.

      I’ve yet to meet a great developer who, when asked to do the test-design for something they are about to build, who didn’t end up with a better design once they start building it.

      Great developers also tend to enjoy learning how to do “new to them” stuff. Crossing “domains” is a great way to infuse insights that come from experience in one domain into another domain. Take a story that might require two people (say the database siloist and the UI siloist) to execute the two main implementation tasks. Have them pair on both tasks. The db developer will inform how the UI developer designs her solution, and the UI developer will help inform the db implementation. They will both learn something, and (in my experience) both implementations will be more elegant. On the next story, do it again, but have each developer at the keyboard for the other developer’s area of expertise.

      The value prop for the developers is a combination of “right now” fun and learning, and “future benefit” breadth of skills.

  24. Pingback: Arnold Beekes
  25. Pingback: Gavin Allison
  26. Pingback: Carl Blomberg
  27. Pingback: Matt Badgley
  28. Pingback: Enzo Zuccolotto
  29. Pingback: Jeannine Fisher
  30. Pingback: Stuart Meagher
  31. Pingback: ProductCampRussia
  32. Pingback: John Oldfield
  33. Pingback: Andy Packard
  34. Pingback: German DZ

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.