The Ownership Problem
When I was starting out as a designer, I had a pretty big chip on my shoulder about how my job was perceived. At that point in time, the design community was, seemingly as a whole, pushing back on the idea that designers just make things look good. Every other day there’d be a blog post or a podcast about explaining to clients or coworkers that we have more to contribute, and that we should own the user experience as well as the visual design, and as a young designer I of course bought into that in the extreme. I took that chip on my shoulder through my first few jobs. I’d find myself constantly referring to myself as the “design owner” to combat terms like “product owner” or to push back against engineers simply building whatever they thought was right.
There are few things I regret more in my career than how strongly and how long I held onto that idea. Inevitably, me holding onto the idea that I should own the design meant disenfranchising my non-design coworkers. It meant having ridiculous arguments that weren’t about the product or substance, but rather who was responsible for which decisions. Instead of grasping onto opportunities for collaboration and embracing the strengths of other disciplines, I created a silo, a wall, a territory. Even today, we create these silos all the time in our organizations. How many companies out there have teams that look like this…
Instead of like this?
Trying to create singular owners within our processes and responsibilities is not only a source of friction, it’s completely impractical. Engineers make decisions all the time that impact the product roadmap and user experience. Designers will create artifacts that impact the way products are implemented or iterated upon. Product managers will always weigh in on both design and implementation, and their ability to advocate for their team’s ideas will shape the product and its future.
Hanging onto ownership, at the end of the day, hurts your ability to ship amazing work. It turns out that the way great products get built isn’t by owners or groups of owners. Great work is done by people who accept that everyone on their team co-owns the product, the design, the code. People on highly successful teams understand and embrace the inherent fuzziness of their roles and responsibilities. They share knowledge and decision-making, which winds up elevating the products they work on.
Share knowledge and decision-making. It sounds pretty straightforward, but in reality it can be a pretty difficult adjustment for folks who aren’t accustomed to working that way. For designers, you have to not only start treating your teammates’ concerns, questions and ideas as valid, you have to also reach out actively for their opinion. You have to bring folks into the process with you from the very beginning. Whether that’s whiteboarding and brainstorming together, doing regular design reviews with your team, whatever. People won’t be used to giving that feedback, so you’ll have to actively tease it out of them and give them many opportunities to contribute.
For engineers, you have to learn to explain software engineering to designers and product folks in a way that allows them to participate (which can be difficult when the topic is complex or nuanced). There’s been nothing more valuable to me than having engineers explain how the code is working and fielding my questions patiently. Because of them, I’m able to talk a bit more confidently and helpfully about the implementation details of the products I work on. At times it required an engineer to try explaining something multiple ways, even drawing it out, before I latched onto the concept.
And for product managers, it means making the roadmap and product a team sport. Instead of coming to the team with a plan or even a list of ideas for them to pick from, engage them in the roadmapping process. Explain your craft to the team — what makes something important usually, what are strategies for deciding what order to do things in or how to scope a project? If you can empower the engineers and designers on your team and get them to think like a product person, your team can, in many ways, run itself. That doesn’t mean you aren’t necessary, it means you’re really good at your job. It means you can focus on bigger things, more long-term things.
Thinking about it as I write all this down, it’s really more about embracing our roles as experts and teachers instead of owners. As information sources instead of silos. As collaborators instead of hoarders. It’s about loosening our grip and inviting others to help us carry our work forward. By doing so, we not only free ourselves up to improve our products, but also to expand our own realms of knowledge and expertise as we learn from the people we work with every single day.
Don’t like visiting web sites? Sign up for the newsletter to get blog content and links I’ve found each week.
