designers and engineers need a deeper understanding of each other’s craft to create truly great products. i’m convinced that engineers need to understand the experiences designers aim to create, even as designers need to understand just know how engineers will make those experience come to life. when the two groups interact for the greater good: they build phenomenal products, with minimal time resources.

it’s all a matter of empathy — loosely defined as understanding the feelings and thinking of others. during my time leading engineering and design on webOS, and later at Twitter, i’ve learned that empathy is core to a product team’s ability to move quickly from designers’ “what” to engineers’ “how.” said differently, a designer knows what to make, and an engineer knows how to make it. when they overcome the communication barrier that separates the what and the how, good things are certain to come.

at palm, for example, we had to deliver a complete reset of webOS, moving the entire platform to a web-centric model. to do that, we put together a unified group of four teams: one team on the kernel, another on the apps, a third on infrastructure and the fourth on design. by working as a unified group, the engineers could empathize with what designers wanted the experience to be, while the designers understood the constraints of the OS.  and because of that empathy, we delivered an entirely new webOS in less than a year. we had achieved a virtuous cycle of product design, the goal of every product company.

the notion of deep, cross-discipline understanding isn’t limited to software development. it can be just as effective when developing hardware, hardware/software systems, and even for manufacturing. it’s not even new. design for manufacturability and assembly methodologies – where designers actually consider whether their designs can be easily assembled and built – have been around for decades.

but without empathy — where the different roles innately understand each other’s goals, assumptions and constraints — those cross-discipline development teams are still prone to misunderstandings and delays. recognizing that there is craft in the what and the how is key – and for the leader to help their design and engineering teams seamlessly understand each other is key.

which brings up the question: how can people with different mindsets and goals understand each other’s thinking? my colleague john maeda, who also happens to live at the intersection of design and technology, suggests early stage companies let designers code and engineers design. while not everyone can make this crossover, those who do will bridge the groups and help accelerate development.  i’ve lived in the valley long enough to see these kind of hybrid design/engineers make a huge difference in companies and now in the startups that they are founding.

for even slightly more mature companies, i believe it’s the leaders who have to crossover  and interact with other teams. they become the bridges who make sure everyone’s on the same page, with the same understanding of goals and constraints. and they also make sure design comes at the beginning of the process. without it, empathy becomes a one-sided proposition, and that just won’t work. so it’s not enough for a leader to keep the “why” in focus for everyone anymore – they’re going to have to get their hands dirty in the what and how, or at least serve as a solid communication bridge.