I'm a big Boston sports nut. And, as cliched as the sports metaphor may be for discussions on teamwork, there are lessons to be learned from the collapse of the Red Sox, which was the worst in baseball history and has ongoing and transformative consequences for the organization. There were, of course, many reasons for the losing streak that took the Red Sox from a healthy lead of nine games in the AL wild card race to the low point of their 2011 season, where they dropped out of playoff contention entirely.
In one of the more infamous stories to come out of the collapse, apparently three of the Red Sox starting pitchers decided to eat fried chicken and drink beer in the clubhouse during games, when they should have been sitting in the dugout supporting their team mates. Rather than showing leadership, Lackey, Beckett, and Lester were self-involved and selfish, fine examples of people you would never want on your team. And the Red Sox paid the price.
We can't draw a direct line from the antics of professional athletes to the attitudes of knowledge workers, and it would be a mistake to try. But as software designers and engineers we are part of a well-paid, in demand profession that is shaping the future of American business. With that in mind, one of the least appreciated factors in assessing software design projects, the talent required for them, and the structure needed for them to function smoothly and ultimately succeed, is how much or how little the individuals on the project are team players.
Genius Over All
In the digital technology industry, we're currently experiencing a dearth of qualified engineers and UX designers. In this war for talent, we're too often searching for the rock star candidates, focusing solely on the hard skill set. The soft skills that make a person a great team player may not be much of a priority. The stereotype here is that of the genius engineer or designer who can solve problems all on their own. And it is within this genius framework that assessors of technical ability debate whether one great engineer is worth 5 or even 50 average engineers.
Team orientation, then, is a key ingredient that's often overlooked by technology project managers and leaders. Why is this? For starters, while it sounds like an obvious personal attribute, it can be extremely difficult to assess. Team orientation is actually an amalgam of many different soft traits. For software UI designers, this can be any combination of flexibility, tenacity, dedication, communication, and self-awareness. During a job interview, we can guess at a person's ability to integrate well into a existing culture or their willingness to go the extra mile to meet a deadline, but we can't know for sure until we work with them. If we're looking for the rock star applicant we might very well miss the person who's not quite as flashy, but makes everyone around them better.
Free Agent Nation
Of course, the hiring path is a two way street. And, if tech companies are looking for rock stars, workers are trying just as hard to be that unique talent. For knowledge workers, then, the ability to switch jobs easily, and work wherever we want, whenever we want is freeing, but also destabilizing. We increasingly orient our careers around ourselves alone, and a cynical observer would say that we're a generation of natural mercenaries. Why shouldn't we be? In an economy where corporations are seemingly loyal to no one, why shouldn't a creative class worker operate as a company of one? So, is this the best we can do? Is the team dead?
Innovation and the Swarm
Here's just one example of how teamwork helps improve design. At Involution we run a studio model, which means that every designer has access to critiques and advice from every other designer in the shop. For projects requiring a lot of good ideas rapidly, we may overload the job with a swarm of designers, who will work together intensively for a few days or even a whole week, sketching, iterating, and generally feeding off of each others' ideas.
To iterate and eventually innovate in a studio atmosphere requires a certain amount of selflessness. You learn to let go of personal attachments and focus solely on the quality of the ideas. It's hard for designers to separate themselves from their work. It's only natural to be attached to your creation … after all you thought of it, didn't you? Ultimately, however, it's this willingness to serve the project or product team that not only improves the quality of work, but enables the collaborative process to happen, whether we're working with colleagues, stakeholders, users, or clients.
Leadership is Serving
If we believe that teamwork is critical to good software design, then we can ask ourselves: Did I pull my weight today? How can I improve and support my team better? How can we all work together more productively and effectively? On the flip side, if we act like those Red Sox starting pitchers, we'll never create, innovate, and push this economy forward. As software professionals it is our responsibility is to produce great work, and remember that leadership and teamwork is indeed about serving.