The Gulf Between Design and Engineering

I couldn't agree more with Rune Madsen's article on the gulf between design and engineering in some organizations.

I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. These companies invest billions of dollars building teams, processes, and tools on top of an immature discipline and an outdated waterfall model that ends up being detrimental to productivity, team happiness, and ultimately, the resulting experiences we bring to life.

I work at a company which is a nestled set of orgs within orgs. A sibling design department to mine has recently finalized their waterfall process with a very detailed document. It's really well done, and a big achievement for our Design Ops. I'm reading it, though, and realizing that it could not possibly work for my department without introducing bottlenecks from design and slowing down the rate with which we ship. That documentation clearly solves an org problem, albeit one out of my view — I suspect a political one concerned with executive reporting. That's fair. There are many acceptable reasons for leadership to prioritize what they choose. In a big org like the one I'm in, accountability can take precedence over product. Again, fair.

My team — as opposed to the others — operates as Madsen describes: integrated with engineering. Every week, we're shipping new features across multiple Publishing tools. And at various levels. Sometimes the feature is a new button in the UI for a new function. Sometimes the feature is a systems-wide capability which cuts multiple steps out of a newsroom workflow. The high speed with which we work depends on the tight partnership between design and engineering. Because of this, possible ship-sinking icebergs in the engineering phase can be avoided by steering design in the right direction from the very beginning. We move smoothly and quickly from concept to launch.

It's very worth reading Madsen's entire article. I started to clip quotes from it and couldn't stop. What I'm going to continue thinking about is the various reasons an org may choose to operate differently. What are the orthogonal complications which prevent a team from working this way? What other company priorities may be worth sacrificing this efficiency for? (via Brad Frost)