Article summary
At software conferences, I often meet people who have titles. I’ve made connections with a bevy of “Information Architects,” “Usability Specialists,” “Visual Designers,” “Front-End Designers,” and even some “Project Managers.” They are able to quantify their role within one statement: “I write the HTML and CSS.” “I create the wireframes.” “I do usability testing.”
Whenever I have to give a quick summary of what I do, my one-line description is, “I make software.” It’s a wide description, and deliberately so, because on any given day I might be sketching interfaces, administering usability testing, writing code, doing visual design in photoshop, or tracking hours and budget using burn-up charts and other project management tools.
The Benefits of Generalists
Atomic Object makers are generalists in poly-skilled teams. Some of us have a deeper background in design while others have a deeper background in development, but everybody here is continuously growing their skills in both ends of the pool, and all of the disciplines they encompass. There are many reasons we work this way. Here are three:
1. Generalist Teams are Efficient
It’s hard to manage the workload of a specialist. Either they are busy, or they are idle. When specialists are busy, it creates bottlenecks in the software development process. (Jared Spool calls this the Binary Workload Problem.)
Generalist teams are much more flexible: when something needs to be done, anybody with a free hand can jump in and do it. When this happens, more-experienced team members can offer guidance, suggestions, and critique to less-experienced ones. This increases a team’s effectiveness overall and helps a project move forward more quickly than if it had to wait for a specialist’s time to become available.
2. Generalists are Profitable
Also in relation to the Binary Workload Problem, generalists can more easily be kept profitable than specialists. At Atomic Object, our company’s success depends on getting billable work done for our clients. If a maker has to sit idle because there is no work for him or her to do, that directly affects our bottom line. For our generalists, every piece of work is a chance to contribute value to our customers and practice our craft. Very seldom do we find ourselves looking to fill idle cycles.
3. Generalist Teams are Successful
The more people you have on your product team who are able to write good code, create a solid information architecture, pay attention to usability and user interface design, perform user research, catch a typo, write interface copy, and recognize business opportunities (along with many other skills that go into building great software), the better your software product is likely to be. When the whole team is paying attention to and caring about many different aspects of the software, your product’s chance at success is greatly increased.
So Why Unicorns?
Given the combination of efficiency+profitability+success that generalists bring, many organizations — startups and larger businesses alike — are on the hunt for a “ninja designer ux rockstar with kickass coding skillz.” Well-rounded software generalists are hard to find, which has led some people in the industry to start calling us “unicorns.”
The Unicorn Panel at SxSW
Many organizations are interested in what it takes to work as a team of software generalists. At the most recent Balanced Team event in Chicago, we had a lot of conversation about how teams work together to cover UX/Dev and visual design skills. Lane Halley, Jonathan Berger, Courtney Hemphill, and I put together a SxSW proposal to talk about our experiences. The panel is called “Unicorn Quest: How 3 Teams Blend UX & Dev Skills.”
Speaking at SxSW is a very competitive process (over 3,200 speaking proposals were submitted this year!). The programming committee takes popular vote as an important consideration when planning the tracks, so we’re calling on the support of our community.
If you like what you see, please help us out!
- Create an account and vote for us.
- Share to your friends with a personal recommendation (Twitter, Facebook, LinkedIn).
[…] makers” is visible from pretty much anywhere in our office. I’ve written before about how our poly-skilled teams function. In that post, I touched on how our teams manage their own projects instead of reporting to a […]
[…] we shared about how we roll at Atomic. We talked about what it’s like to work as part of a poly-skilled project team, including how we share design and development tasks and how teams manage their project’s […]