Teach, Don't Lead¶

Design happens at all levels of the product development process. Great designers realize they make a bigger impact when they teach the entire organization good design methodology.

Our experience is that developer team uptake for design methodology is uneven. Often the resistant teams don't understand the design process value because it seems simplistic or superfluous to coding and construction. Teams like this typically feel more comfortable banging out user stories or specifications. While true they can make the code match these stores well, perhaps in pleasing ways, the resulting work may not address need, or misses that "a-ha" experience where you understand at an entirely different level. These teams are almost never hostile about this, so you can get them to begrudgingly change their methodology "this one time." They might complain about it before and during, but often they'll look back and think, "Wow, we would never have gotten here in the traditional methodology." That doesn't mean you won't have to drag them kicking and scratching into more design sprints, but they will come to respect and appreciate the results.

Another concern is that some teams may have legitimate, long spells between design sessions. The designer will need to step in and refresh the team, but it should be a gentle shadow during the sprint. The team really needs to own the sprint.

A designer who gets the entire organization to adopt sound design methodology is now free to orchestrate a larger, cohesive vision.