Too often do we fall under the impression that building something, especially in the world of software, entails being handed a specification by the product and design team and then fleshing out the code for it. It’s sometimes treated as two step process, more or less.
From what I gather, this is an especially common pattern present at large companies where creative momentum is more restricted and thus structurally defined. In many cases, this practice dictates the roles of everyone involved in the building process: managers are responsible for communicating workflows and product features from designers to engineers and shuttling the questions and concerns that arise between multiple parties. And, for the most part, this gets the job done — product managers spec out a feature, designers mock it up, and then engineers go off and build it. If everyone understands and performs their respective jobs, the traditional conveyor belt of building software works and the product ships. Everyone is happy.
But, this process doesn’t work for everybody. And nor should one enforce this style simply out of tradition.
I am undoubtedly lucky to be working with a team that understands and respects the importance of iteration. The constant bouncing back and forth of ideas between product and engineering until a refined version surfaces from the depths is no easy task, though; it requires 100% participation from everybody involved and forcefully waives your personal feelings. This style of creation lends weight to the school of thought that design and engineering are inexplicably connected — that, the sum of them is ultimately greater than their individual selves. It is with this understanding that product creation should — with some degree of flexibility, of course!— be more than just a two step process.
With that being said, it is then without a doubt that the constant iteration and discussion of ideas between design and engineering inevitably yields a more thoughtful, polished, and delightful product than had they not worked in close collaboration. As Steve Jobs mentioned in The Parable of the Stones:
That’s always been in my mind my metaphor for a team working really hard on something they’re passionate about. It’s that through the team, through that group of incredibly talented people bumping up against each other, having arguments, having fights sometimes, making some noise, and working together they polish each other and they polish the ideas, and what comes out are these really beautiful stones.
While not everyone may subscribe to this process, it is essential to note that a team should be adaptable and open to change if a process does not work. Resistance to process adjustments in the face of obvious failure is an ingredient for creative disaster.
The road to shipping great products is not an easy one. But, with enough concerted effort, we can all smooth out the bumpy ride by not blindly adhering to die-hard processes. There is no win-all way to building delightful things but there should be a place where engineers and designers should feel free to express their views. I’d like to call this place the magical room.
The magical room is free of bureaucracy. It tolerates failure and encourages iteration. It welcomes many ideas but lets only the best ones stay. It bears witness to constant creation and destruction. It is a workshop, playground, and safe haven. It is free of thirty page product specs and sales forecasts. It discourages rigid rules and encourages improvisation.
It protects the creative process.
Unfortunately, this room does not exist in many organizations. And if it ever did and no longer does, it got torn down by the Hands of Process.
As a strong advocate of ensuring that this magical room continues to exist at not just where I work but at other organizations as well, I cannot help but champion building this room more than enough.
It is where great products are ultimately built.