I can't hear your idea and the answer is NO!
If you are responsible for delivering a product that works and doing it on time, you have a monster inside. It starts as a small feeling in the pit of your stomach, but this menacing character can quickly take over and as deadlines approach, Dr. No is unleashed and this evil doctor cannot be controlled.
There is a tension between people who dream up product on paper and people who build product for reals for reals…I have had to work through this tension with every product team from sneakers to mix tapes to video games and iPhone apps…the creators keep asking for more and the builders say no louder and louder and if not managed effectively this split causes you to loose the valuable collaboration between disciplines and the creative solutions that come out of great engineering teams.
If your engineering lead has become Dr. No, you may have a culture that treats engineering as a resource to be consumed, as executors who can never work fast enough or hard enough to deliver for everyone else. Can you hear it in your product meetings? No…silent behind a blank look. No…wrapped in rolled eyes or a shrug. No…articulated with a frustrated shake of the head. No…slicing through a suggested change before it can be considered. NO…cutting off the thought before it is complete.
You are the CEO. It is your f’ing fault. It Sucks for everyone. You have to fix it.
At my game company, I was responsible for product and Dr. No was in the house as soon as we started writing code and it was my fault. I had spent 6 years managing design and development at a sneaker company. The process of game design was similar, but building a digital product was totally different than working with leather and molded rubber. I knew what I wanted built but I didn’t understand how our product was built and didn’t get why some “big” changes were easy and some “small” changes were impossible. I started to think it was a personnel issue and that I needed a more creative/open minded and hard working CTO/engineering team.
Turned out I just needed to learn some basic logic about our product architecture and incorporate these constraints into my thinking. Also, once I started trying to learn, started listening to the reasons why some of my requested features were crazy, the engineers started listening to me and identifying the goal that lay under the feature request — adn finding awesome ways to achieve the goal without derailing the entire product process.
It was a communication issue and I had to own it so the two sides of product creation could stop speaking past each other in different languages based on different assumed priorities and different work flows and processes.
I worked with my team and we adopted some simple rules that really helped.
- We started every product change or feature request with a statement of the goal. Before any work was done, we got to agreement on the goal.This put everyone on the same side, trying to find a solution leveraging their expertise/knowledge
- We moved from a culture of “no” (engineering saying no to requests and design saying no to new ideas for product coming out of engineering) to a culture of “why?” that focused the whole team on understanding an approach and collaborating to remove blocks in the process and to understand the trade offs that have to be made as resources are allocated and deadlines approach.
The head butting didn’t stop, but it got down to a healthy level. People learned from each other and made each other better. Designers worked within the constraints of what could be done and engineers found ways to deliver product that met the designers’ goals.
I don’t think designers and other product creators need to be able to code, but they need to understand the engineering process enough to consider it as they design. Engineers do not need to “get design” or be UI/UX experts, but they need to internalize a view of the end user as interpreted by the product/design team.
For some more on this with specific tactics for designers and engineers, see this piece on designstaff.org