The Specialist-Generalist Balance

A couple of years ago I hit a crisis point. There was a distinct divide between disciplines at my company; I had been labeled a “backend developer,” and it was starting to feel restrictive. The label wasn’t wrong: I spent most of my working hours writing server-side code. I enjoyed it, and I was good at it—but it wasn’t all that I could do.

I’ve always considered myself to have a fairly generalist skill set, and slapping a label on me meant that I wasn’t allowed to work on anything other than that which fell under my remit as a backend developer. I felt typecast. And, unfortunately, it’s not a divide found solely at that company; it’s ubiquitous across the industry.

So what’s the problem?#section2

Consider the following project scenario: someone in marketing has an idea. They discuss it with a designer, who mocks it up in Photoshop. The designer hands it over to the front-end developer, who complains that the designer hasn’t considered how difficult X is to implement without major JavaScript hacking. She finishes her work and tosses it over to the backend developer, who flips out because the front-end developer hasn’t given a single thought to how Y is going to work with the company’s CMS.

Sound familiar?

Creating narrow groups of specialists divides teams and restricts the way we work together. In his article “Development is Design,” Brad Frost describes this divide as a fence over which specialists throw their respective pieces for other specialists to catch and run with. It’s not uncommon to see individual teams of “specialists” all sitting apart from each other. The larger the company grows, the more specialist stations are added, each with their own tasks to complete, and mostly working in isolation—isolation that fosters unhealthy environments, restricts collaboration, and creates silos.

The key is to find the right balance of specialists and generalists on your team—to use both to their advantage and to nurture healthy, productive environments. Ultimately, the question is: how can experts collaborate better together?

Balancing your team#section3

The appeal of generalists#section4

In my formative years, I worked as a developer at a small software agency. There was complete freedom—absolute trust and no red tape. If one of the live sites had a bug, I had free rein to jump on the live server and peruse the logs, or check the configuration file for errors. I was not only allowed, but often required to do anything and everything. It was such a small company that there simply were no specialists.

In this way, I picked up some rudimentary design skills; I learned to navigate my way around a server and a database; and I became fairly confident in developing on the client-side.

This type of generalist approach to developing websites clearly has advantages: generalists learn how each component works with the others. They develop an understanding and appreciation of the whole process. They’re also good at just getting things done; there’s no waiting around for a specialist to do the database work for you.

Generalists can apply their hands to most things, but they’re never going to master everything. Sometimes, having someone who roughly knows their way around something just isn’t enough.

If you have a rock band made up of members who can play “Smoke On The Water” on every instrument, but you don’t have individuals who can belt out a Slash solo, or drum like John Bonham, then you’re never going to play to a sold-out house.

Making the most of specialists#section5

Specialists are the experts in their field. They have spent their careers honing their skills on a given subject, and so it stands to reason that they’re going to be better at it than someone who doesn’t have their experience.

But misusing them will result in barriers to strong team collaboration. For example, once, at a large software company, I was tasked with investigating why our team’s build had broken. I identified that the problem was a missing dependency reference in the build definition. So, easy fix, right? Just pull up the build definition and fix the dependencies—until I realized I didn’t have access. I couldn’t edit the build definition directly, and was told I needed a “configuration specialist” to implement the fix.

What should have been a quick edit ended up taking hours while I waited for a specialist on another team to fix a problem that I knew how to solve. Unfortunately, this is a common scenario: rather than collaborating with the rest of the company, insular groups of specialists are given sole ownership over particular tasks.

Specialists are best placed in roles where they work alongside other team members, rather than separately. As Henrik Kniberg from Spotify says, “It’s like a jazz band—although each musician is autonomous and plays their own instrument, they listen to each other.”

Tear down the walls#section6

Collaboration is the ultimate goal when forming a team, since it allows ideas to flow freely and encourages innovation. Creating specialist groups with total ownership and little to no cross-team communication will erect unnecessary barriers to collaboration. So how do we identify and remove these barriers?

Open up bottlenecks#section7

I once worked with a company where the generalist development team outnumbered the specialists by fifteen to one. When developers required alterations to an automated build, they had to submit a ticket for a specialist to address. At one point, developers were submitting tickets faster than specialists could pick them up—resulting in a workflow bottleneck.

If the developers had been able to manage the automated builds themselves, the bottleneck could have been avoided. The knowledge held in the configuration team could have been shared among the developers, creating a more generalist approach and eliminating a silo.

To identify and open up your own bottlenecks, ask yourself:

• What part of the process is the slowest, and why?
• Are you relying on a single person to do all of your front-end development? Why?
• Are there any other people in the team who have similar skills, or show an aptitude for learning those skills?
• Do restrictive job titles prevent people from benefiting from each other’s skills and expertise?

Encourage communication#section8

I’ve seen companies where software testers and developers were entirely independent teams. Testers were often only engaged at the end of the development process, when they received a test module based on the original requirements. But requirements can and do change during the development process—which, when teams operate completely independently, can lead to a lot of misunderstandings and lost productivity.

Including the testers throughout the development process would have improved communication and performance. Instead, project releases suffered as a consequence of the teams’ separation.

There are many ways to limit these kinds of divisions and foster communication on teams:

• Try to arrange the workspace so project teams can sit together. If they can’t sit together, then make sure that they have at least one conversation about the project every day.
• Remote working is a privilege, but it’s only possible if you make yourself available for discussions. A huge benefit of working in an office is being able to wander over to a colleague’s desk and just ask them something; remote working can make people seem unreachable. If you must work remotely, then make sure your colleagues feel comfortable contacting you.
• Scrum is a great tool for encouraging communication, especially the daily stand-up, during which each team member describes what they’re working on and any problems they need help with.

Fill in the skill gaps#section9

Does your team lack the skill necessary to complete a project or deliver it efficiently? Is the team unfamiliar with a particular approach or technology? Do they lack the confidence required to successfully overcome a problem? Use specialists as a means to train your staff:

• Bring in a specialist from elsewhere in the company or, if the skills don’t exist internally, hire a consultant.
• Don’t allow specialists to solve the problem in isolation. Give your team members the opportunity to work closely with them, to learn from their experience, and to begin building the skills they lack.
• Encourage your specialists to conduct workshops. Workshops are also a nice way to build an interactive relationship between specialists and generalists; they open communication and foster a knowledge-sharing environment.

Promote knowledge-sharing#section10

I once worked in a team that made a point of identifying silos. We were encouraged to work on the whole system and no single developer owned a specific area, though people had their preferences—I gravitated more towards client-side, while a colleague favored web services.

When I admitted that I was unfamiliar with how the company’s internal web services functioned because I hadn’t worked on them for so long, my colleague and I decided to alternate between client-side and web-service work during the next sprint, thus sharing our knowledge.

There are many ways to promote this kind of knowledge-sharing, which is fundamental to innovation and a collaborative culture.

Brown-bags#section11

At my current company, we hold regular brown-bag lunches—everyone brings their own lunch to eat while a colleague gives an informal talk on a topic that they’re interested in. Brown-bags often spawn interesting discussions among participants: I can recall a few occasions where a technical feature or procedure has made its way into our formal processes following a fervent brown-bag.

Scott Hanselman at Microsoft suggests that companies “host technical brown-bags at least twice a month and encourage everyone to present at least every year.” It’s a good opportunity to encourage a healthy debate among colleagues with whom you don’t necessarily collaborate on a regular basis.

Guilds#section12

In his article “Scaling Agile at Spotify with Tribes, Squads, Chapters and Guilds” (PDF), Henrik Kniberg defines a guild as “a group of people that want to share knowledge, tools, code, and practices.” Spotify uses guilds to bridge gaps between teams across the organization. For example, a developer is likely to encounter a problem that another developer in the organization has already solved. Where’s the sense in duplicating work?

Forming a guild allows common solutions to be communicated. It’s an opportunity to share experiences among teams.

At my current company, each team has at least one tester; the testers also belong to a separate QA guild, which allows them to pool their knowledge. It has been a big success: testing procedures have been standardized across the teams, and technologies like Selenium have been introduced into the test stack.

Internal open-source models#section13

Limit the perception of ownership by introducing internal open-source models. Give everyone the ability to contribute to your source code or designs by replacing ticket-based systems with a model similar to GitHub’s pull requests. If you’re competent and comfortable making a change to a codebase that sits within another team’s “area,” then why shouldn’t you? The other team can act as curators of the project by reviewing any code submissions and feedback—but guess what? Now you’re collaborating!

Hack days#section14

Are the projects you’re working on feeling a little stale? Try entering a competition as a company, or use a hack day to get ideas moving again:

• Arrange a company-wide Ludum Dare, where the best game at the end of the hack day wins.
• You don’t even need to restrict it to a day. Spotify holds regular hack weeks. You might even end up with something you can present to the business or a client.
• The National Health Service holds annual hack days in the UK, which local digital professionals are encouraged to attend. They work to solve the problem presented by NHS doctors and staff with whatever technology they have at hand. It’s incredibly empowering, and an amazing opportunity to give back to such an important organization.

Hack days don’t have to be IT-related; encourage people outside of the development team to take part by following the NHS model. Hack days allow people to work with colleagues they wouldn’t normally work with, in a situation where fresh ideas are encouraged and innovation is rewarded.

Go forth and collaborate#section15

Strong collaboration is crucial to building a successful team—and collaboration is fostered by breaking down barriers. Make good use of your specialists by integrating them with your generalists and positioning them to guide, teach, and instill passion in your teams.