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
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?
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.
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.
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.
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!
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.
10 Reader Comments
Another (different) view on this subject:
This is a great post and you have a lot of wonderful suggestions for breaking down the walls between disciplines. I think “guilds” have been the most responsible for breaking down the walls in the nightmare scenario of specialists I used to work in. We call them “communities” and the Design community, by working together, has helped to spread the design standards and knowledge from Usability Engineer to Interaction Designer.
I’m curious to know whether there’s a lot of crossover between your Design community/guild and your Developer community/guild — it’s been the hardest wall to break down in my personal experience.
Hi Anne. Thanks for the feedback! We have had some success in crossing the developerdesigner divide.
We’ve also had the occasional group-hack, not a hack-day, just a bunch of us getting together to discuss and build something that we have a combined interest in over a non-fixed period. One recent group-hack was to build a puzzle game, which we’re still working on. It’s a nice way to get designers and developers (and other departments, of course) working together and communicating. If you find it difficult to arrange a formal hack-day involving the whole company, then a smaller group-hack is ideal, and you can rotate members to get more exposure.
Indeed, every company needs to have generalists and specialists, it’s the same as in a Hospital. I, for myself, I like to consider myself being a generalist.
Also, it’s hard to have a company composed only of specialists, you’ll need a very good management in order to go forward with such a team.
Breaking down the walls indeed, being labeled as UI specialist in my current position has restricted me to take part in some of the front-end developer meetings where I feel I could be of value.
Garin: one thing to ponder – regarding your example where you didn’t have access to change the config file – you are obviously a skilled developer, but imagine if all developers (regardless of their level of skill) had access to change the config. You would probably see a large increase in bugs, and time wasted on discussions about what is the best way to do certain things, often by people that don’t necessarily know the full details.
I’ve been in a similar boat to you, but I quite appreciate the silos, when they are implemented correctly, there is nothing worse than having to defend a design or architectural decision to someone that doesn’t understand the full picture, yet is adamant they should have full access to change everything, it can waste hours if not days.
Hi JSGuy. Thanks for your comment! In that specific example we did eventually allow access to developers. There was up-skilling involved, which is a good thing; the developers were trained in the nuances of the builds and the configuration team, being the specialists, played a huge part in that training. Ultimately, the configuration team remain the curators of the builds; they periodically review changes and help to fix builds if they break, even as a result of a developer-made change; but that happens so rarely that it has never been a problem. There will always be experts who understand their specialist area better than others, but there’s no reason they should insist on being the only people who contribute to that area. Sharing knowledge among colleagues and team members will alleviate the burden and help towards a more collaborative environment.
Hey Garin, great article.
I find myself in a similar scenario with a generalist skill set and do agree that it has it’s ups & downs.
Red tape can make development a hassle in terms of being reliant on specialists. I think you bring up a really important topic with developmental integration in terms of the hack days.
Thanks for the interesting read 🙂
Lot of food for thought. Having spent most of my time in a large enterprise with lot of specialists, keep wearing both hats as specialist and generalist, I used to have similar thoughts.
Finally it boils down to picking control over freedom of expression. Both have its advantages and disadvantages and will depend on the people involved! Typically, large organizations suffer from the bottlenecks created by specialists while smaller ones run the risk of anarchy and chaos resulting from the lack of specialists with generalist domination? This also gets manifests in the form of lack of processes on one end of the spectrum (small organizations) to too many impractical rules on the other end (large organizations). A balanced approach seems to be in order depending on the size of the organization.. Let the debate continue and time be the judge!
nice point of view…piastre per capelli
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions