Tie Your Ego to the Product, Not the Process
I was beginning to design my first big feature at Etsy a few months ago and had a kick-off meeting with Andrew, the engineer who would be building it out with me. We talked about design goals, problems to be solved, etc. and everything was feeling pretty good. As we were walking out of the meeting he said:
Send me the first version of your design when you have it so that I can start building. I don’t care if the entire approach changes at some point. I don’t mind throwing out code.
In my career, I’ve worked with a lot of engineers (both at startups and larger orgs like Amazon) and I’ve never had anyone say that to me. In fact, my general experience has been, with a couple exceptions, that I’d better be happy with whatever I pass off to get built, because I’m going to have to fight hard for any changes thereafter. There’s a sense I’ve been given that written code is sacred, changes herculean, and that I should have gotten the design right before allowing things to be built. At the same time, I know designers out there who refuse to let their designs be seen, much less get into real live production code before they feel 100% ready. It’s just not there yet is the common refrain when asked to share work or to begin baking the design into something real and tangible.
It’s an impasse built out of our own egos. Designers want their solution to be correct, while engineers want to write a feature once and ship it. Not only is this an impossibility for both sides, it creates tension and anxiety when trying to ship well-considered and impactful products.
Luckily, the solution is simple.
Tie your ego to the final product, not to the process of getting there. Consider nothing sacred. Wireframes, half-baked mockups, fully-baked mockups, and even live code should all be shareable, flexible and, if need be, expendable. Set a day each week to review work with your team, no matter what. Share everything. Share the dirty stuff. Share the I-just-started-this-an-hour-ago stuff. Share the small part of the UI that actually works in code right now. You’ll learn quickly what feels right, what needs work and what you’ve failed to consider. My particular project at Etsy has changed direction completely a few times as a direct result of sharing designs early, coding them quickly and realizing we could either simplify our solution or that we’d missed a critical point and needed to reconsider things. When there’s no fear of being wrong or throwing out work, you’re free to move more quickly and work together instead of in silos. And what you wind up shipping is more solid and thought-out than it otherwise would have been.