Engineers for Designers: Why Engineers always says No (and how to make them say yes)
It’s not an old wives tale that engineers will tell designers “no” when presented with ideas and mockups. It’s going to happen to you. Again. And again. And again. Don’t take it personally: it just happens.
In this post, I will talk about why engineers do this and how you can get them to say “yes” sometimes. Like previous posts, I’ll qualify this by saying that this is mostly targeted for software engineers and graphic designers in web application startups, though the advice may be valid in broader contexts as well.
Why Engineers Say No
Let’s say that we have nice photo of a forest. I’m not sure what a designer sees, but as an engineer, I’m thinking about how I would build it. How would I model the distribution of plants over the visible area? What are the variables that created this forest versus any other forest?
It’s just an engineer’s nature to always be coding. Engineers are always breaking things down into constituent parts to be built. It’s like I imagine clinical psychologists always reading people or musicians hearing out-of-tune notes. Ways of thinking are so deep that we just can’t turn them off.
This fact is relevant because engineers are trying to solve problems before they even have a full understanding. As designers begin talking to engineers, the latter are already thinking about how they would build it, and since most things are changes or additions to existing products, these imagined changes affect a much bigger system. In putting together a codebase, engineers create affordances for future changes, but most changes are hard to anticipate and don’t fit well in the codebase. This can make engineers unhappy.
A Codebase as a House
Let’s use another analogy to explain why this feels bad. Imagine that you are an architect and have created a nice single-family home. It is currently very stable and looks just as you wanted it to. It even has some affordances for anticipated changes. There are 4 bedrooms while you currently only have 1 child, and there’s extra space on the lawn to convert into garden space if you get around to that.
There’s some maintenance on it over time, but nothing too out of the ordinary. What really gets you is that things change. That 2 car garage isn’t good enough for when your teenager gets a car. You decide to get solar panels, but they looks ugly because the roof isn’t quite positioned right for the sun. It turns out the wiring in the house is bad, and you need to swap your dining room with your living room to get cable to your TV, but now the feng shui and flow from your kitchen is all off. In a few years, your house looks like Frankenstein’s monster in domestic form.
This process is what happens to a codebase. It starts out in pristine form, but as time goes on, more and more additions turn it into something very different and not nearly as elegant. And this is despite best attempts to anticipate the changes. What’s worse, this really is the toll of agile development. When things are iterating and changing rapidly, it’s hard to find time to make the insides beautiful while adapting the behavior.
So when a designer asks for something, the engineer has already started thinking about how to implement it without complete context or complete thinking, and because they don’t want to over-promise lest they be liable or compromise the stability of the codebase (especially if the change doesn’t fit with the affordances), the engineer is going to say
How to Make Engineers Say “Yes”
Hopefully, you at least understand the engineer’s plight even if you don’t think it entirely justifies the response. Fortunately, there are a few tactics that may help you get more positive responses from engineers.
1. Don’t let them respond immediately
If you have something new, don’t let them respond for at least, say, 10 minutes. If the engineer manage to get a “no” out sooner for the reasons above, then the conversation could spiral into an argument with opinions hardening quickly. In 10 minutes, however, a “no” can become a qualified “yes,” such as “yes, but…”, “yes if…”, or “yes, unless…” Even a few minutes is enough time for an engineer to digest and think about how they would actually implement it. Thoughts take time.
2. Warn them whenever possible
I mentioned above that codebases and houses can have affordances, and if you let engineers know about possibilities ahead of time, they can build those affordances into the system. In fact, it makes them feel good to figure out how to solve far away problems. There is, of course, a balancing act in that not all eventualities comes to fruition, but without guidance from design, engineers may harden a system in unfortunate ways.
Even if it’s past the initial foundation for a codebase, it’s helpful to get engineers involved anyways in thinking. Specific to the “no” problem, it helps to ease engineers into changes before they actually happen so they can process and figure out a “yes” when it comes to a decision. More generally, engineers can often predict hard blockers, which do exist.
Of course, don’t let them steal the show, either. Everyone in a business should think of themselves as a problem solver, and engineers may start to dominate a design process that is best left in a designers hands. Handle appropriately.
3. Show them an example
If someone else has already built something, show it to your engineer. An example has two potential benefits, one practical and one psychological.
First, engineers have an easier time copying than building. Not only can they play around with a working version, engineers can often extract the code that someone else has put together to get a layout or interaction working, especially in web development.
Second, it’s a challenge. Remember, engineers believe that they are Neo, so if another engineer can do it, then you can bet your engineer believes they are just as good – if not better.
…But the answer may still be “no”
There are tactics to convince engineers otherwise, but sometimes, the answer really is “no,” and that stinks. Engineers can give a lot of reasons, but here are the most common ones.
First, it may not be possible given the 3rd party libraries or frameworks being used in the codebase. Within an application’s codebase, just about everything is mutable: it may be ugly, but it can be dealt with. Sometimes, however, it’s just not the way that jQuery or the iOS SDK works, and there’s not much to be done around that. Often, there are workarounds to be found on stackoverflow or elsewhere on the internet, but this can be a blocker.
Second, a design may require contradictory code. Code largely needs to be deterministic, and you can’t have it both ways: given specific conditions, there can only 1 resulting behavior. If you can’t enumerate the behavior in a reasonably knowable way, then it might be impossible.
Finally, the implementation may be computationally impossible to do efficiently. I won’t get too much into this, but if your engineer starts throwing around things like Big-O, exponential, or NP-complete, then you should run for the hills.
I feel bad when I say “no.” I honestly do. But I still do it all the time. I wish I had an analogous situation to present, but it just happens. Feel lucky if your engineers are less stubborn with you. But if they are, try to understand their plight (as a house) and use the tactics above to get better responses out of them.
Coming up is the last segment of this series, and it’s going to be about the types of decisions and tradeoffs that engineers make on a daily basis. Most aren’t directly applicable to design, but I think you will see the consequences of it at the edge of your work, and your engineers will appreciate it when you appreciate the choices that they make.
Posted by: Kevin Leung, VP of Engineering