Understanding Engineers as a Designer
March 21, 2021
I’ve spent most of my career in pursuit of the love of Engineers. The reason is fairly simple to grok: you can build a product without a Designer, but you can’t without an Engineer. Solo startups are myopic in this revelation. Every time I’ve built something, I was working with a partner by necessity and no matter how much I thought I led the vision, my partner Engineer(s) always owned the output. In a sense that meant they were always my boss to be convinced. One of many contradictions you’ll find is that many Engineers don’t actually want to be a public boss, but very much do want to be the secret one. Accept this and lean into it. Like any good marriage, the Engineer-Designer bond is a fragile one built on trust and transparency.
Another trait you’ll learn quickly about great Engineers is that most of them have near-perfect memories. This makes sense and is likely a reason I’ve struggled when moving beyond the template layer as a Designer. I don’t have the logical processing power to keep nested functions, recursion and object oriented patterns in my head. The level of attention it requires is mountainous, and you’ll understand why most engineers eschew meetings and want to be left alone to their craft. Distractions are not minutes from conversation lost, but hours of their previous concentration dropped that must be rebuilt anew. If you wish to be loved by engineers remember this golden rule: value their time and stick to schedules if you can.
The core craft of Engineering is tool building, not tool usage, which is our domain. Engineers are concerned with removing repetition and optimize towards flexibility of a documented system. This is the reason they love Frameworks and rally around standards. The reason such standards are hot topics for them is these decisions dictate their day to day and future work. We don’t have anything like this in Design and instead talk in term of “trends”. Trends are temporary, standards are not.
A common stereotype that exists outside of Engineering is that Engineers focus too much on details. Usually I’ve found this only a half-truth. They enjoy the details near the trunk of the tree, but tend to dislike the details near its branches. The branches you can’t optimize, because the surface area is too large and unique. For most Engineers the detail work along that surface is not very exciting and tends to be filled with tedium. It’s why you’ll find large Engineering projects tend to slow down near the end — the busywork stage of applying those elegant patterns they created is near. Designers love this part, and it’s why we make good QA testers.
Designers also care about deep details, but ours tend to be more individual in scope: a small animation, a rogue but important deviation, and the oft-lionized pixel perfection. Engineers generally don’t care about pixel-perfection — it’s a perfunctory step that can be completed near the end. After all, the tool works regardless, and we might as well get feedback early. Both frames of reference are correct of course, but understanding the differing points of view hints at where you should spend your time with Engineers. Start early. Try to be explicit about the core experience during definition because you will very rarely have the buddy capital to change it later. Even then, if you can advocate for a late change, it’ll likely come in the form of a new version of the first attempt, rather than an adjustment of the original one. This is terribly expensive and why I tell designers to try to provide two designs when possible: the skateboard and the car. Engineers need to know about both even if they only deliver one.
In my experience Engineers love Designers who can code a little, but Designers don’t appreciate the reverse. This gets back to the tree metaphor. Designers will never code near the trunk (we only understand it vaguely), but Engineers will always need to design in the branches because that’s all Design has. Designers that can code usually don’t break things too much, their work is thought superfluous, and their contributions are a welcome way to finish parts of the job that Engineers don’t want to work on anyway. If it’s done in a PR, even better, and you’ve suddenly gained some empathy for Engineering work. In contrast, when Engineers fiddle with designs late in the game, they very much can mess up Design’s grand plans. Why grand? Design teams often work horizontally, while Engineers run vertically deep into a vein of expertise. These perpendicular aspirations force ideals that are often in combat with each other until you take a few steps back. Step back far enough and you’ll find your Product Manager… which well, produces its own art. They own the full scope.
The most effective way to be loved by Engineers though is to work hard at the beginning and the end of the project, leaving them alone in the middle. Provide a checklist of requirements for project completion and let them know what success looks like. This telegraphs when the project can end, which is their main ask. Respect that end and take any learned mistakes from your bad definitions into the next project, not the current one. You’ll just piss them off otherwise. Win the war so to speak, build trust.
Engineers greatest worry is feature-creep and project unknowns. This fear is so great that most engineering books are written around spec definition, and why a lot of their culture is focused on Request For Comment (RFC) theater and the naming of things. These documents and early decisions when done well are defensive against us (in a good way) and provide a reference for their rule of law. As a good partner provide a design document along with your actual design as a means of shaping these RFCs, since that’s where the project really is defined. Include your checklist of requirements and try to stick to it.
As a Designer the most fun part of the project is near the end. This is when things start to get tedious for Engineering, which is unfortunate timing, but sort of something you’ll need to navigate. Good designers are most busy in this period. You’ll find the design feels completely different when it’s on the page and a slight panic will creep in as you realize your mistakes. Past the early stages of definition, the skills you bring to the table as a Designer are most powerful here near the end. If your relationship with Engineering is healthy they will be happy to humor you with small changes at this critical time, but don’t overshoot it and ask for anything too big. They have their own loose ends to tie up, usually this is their time to rewrite code and make it maintainable before it’s too late. This comes back to the golden rule: respect their time.
It’s no surprise that the majority of my life-long friends are Engineers. They are fun to drink with and tend to be the most voracious hobbyists I know. They take their deep minds into their outside passions and become experts at novel things. I nodded my head learning that many of my wife’s Bluegrass friends were Engineers. It made sense. They like the complexity of the music and its focus on standards. My guess is that’s why so many of them enjoy Metal as well.
Most Engineers are skeptical optimists and carry their love of optimization towards that optimism. They always think BIG. Mostly I try to listen and learn from them, playing devil’s advocate to their theories with a slight impish goading. They seem to enjoy this revolving dance, and every fight is made with a wink. After all, good design acts in support of engineering, not in conflict with it.