Atomic grew from a rich computer science culture that focused on coding and project management practices. Before we hired and integrated designers directly into our agile teams, we used to work with outside design partners.
Although we liked our partners and respected their professional talents, working with outside organizations often resulted in several types of scenarios where time and money were wasted:
1) Inexperienced clients trying to manage both the design and development teams independently with a focus on localized efficiencies.
2) Design and development teams managing themselves for localized efficiencies.
3) Upfront design efforts that produced unused designs, granted future design control to developers and decreased responsiveness for specialized design capacity.
Most of the issues related to working with outside partners stemmed from divided design and development teams being locally optimized for throughput instead of team effectiveness. Atomic decided to hire designers so our teams could have control of design and development capacity and create better software products more effectively.
We made the assumption that development would likely be the bottleneck on any given team. We assumed that a full time designer on a project with 2-4 developers would result in too much unutilized design capacity. We decided to schedule our designers on multiple projects and add slack to their schedules to accommodate emergent needs. A flaw with our initial approach was that, in practice, design can be the bottleneck and the need for design capacity can frequently spike on projects. Overlapping spikes from multiple projects results in contention for a scarce resource and one or more teams get bottlenecked by design.
We are now reducing the number of projects a designer can work on during any given period. Even with a better generalized balance of design and development capacity, we still experience design lead or lag during projects. To handle shifting bottlenecks, we are expanding upon our definition of being talented generalists. Our definition of being a generalist now includes learning and practicing interdisciplinary skills as well as being effective in multiple industry and technology domains. A developer can help with with user research, IA or IxD tasks. A designer can contribute HTML and CSS directly into a project. A poly-skilled team that is effectively estimating, tracking and managing their work can make the best judgement of when to apply what skills from any given team member.
[…] our continued development of poly-skilled team practices, we have programmers and designers collaborate on early IA and IxD concepts. After […]
[…] previously written about Atomic’s poly-skilled team approach and mentioned some of the related challenges from integrating design and […]
[…] the devs. It’s a good arrangement that increases our flexibility as a group and enhances the poly-skilledness of our teams.Do I ever miss hanging out with my designer buddies? Yup. Sometimes I wish I could just lean over to […]
[…] and translate their excellence into business value. Atomic’s strategy of deploying poly-skilled, co-located teams of generalists puts us in a position of delivering quality to every customer […]
Comments are closed.