Design Engineering #3 — Break walls
In 2021, I took over managing a Design Engineer named Dylan. His manager, Cady, gave me a dossier folder emphasizing how talented he is. Dylan was always ready to jump into any map project with new ideas and a willingness to do anything for it. However, Cady worried that he might run into walls because not many ideas live to see the days, especially if resources don’t align or the engineering huddle is too high.
He and I bonded quickly over the love for maps and how much fun we could play with it. At my previous company, I created a pixel world map where my team could customize their own towns to showcase their latest projects. In turn, he showed explorations of novel visualizations using his own travel data.
Dylan told me the problems he was facing at work. Just as Cady feared, he had been running into endless loops of engineering communication. When his proposed design required multiple codebase changes, he could not convince any engineer team to execute and own the work end-to-end. For example, the backend team responsible for the data aggregation don’t want to be responsible for how it looks like. The frontend team responsible for illustration library wouldn’t want to maintain a illustration mapping specific to any project, and so on. As someone interfacing both designers and engineers, Design Engineers are often the first one to identify the gap where teams were often limited by the surface or code they own. I showed Dylan how he could break the code boundary by writing the mapping code in the search service himself. The code worked, and as a result it became a bridge between teams. Later on, it was also a catalyst for a team to realize its systematic benefits and own it.
After learning to break walls, he continued to create bigger impacts. This time, a big reimagine project got blocked. No matter how many times we polished design mocks or replied to comments, stakeholders hesitated to commit to it. Even if the future of map navigation looks good on screen, drivers would still be confused on the actual road. As a Senior Design Engineer, he utilized the craft to prototype with real-world constraints. Dylan rewrote existing code prototypes with dynamic map, used design system components library, and connected them to a functional navigation APIs. Together with other Design Engineers, they would rent a car to test and perfect this prototype down to lowest zooming level. Subsequently, he would rally stakeholders to be behind the wheel. One by one, questions about network latency, fickle GPS, exit signal, sun flare, and other engineering concerns were resolved. He succeeded in exciting the entire organization to invest in the vision.
Cady wasn’t the only one worried about Dylan. Over a lunch, his mother also expressed understandable concerns about him picking up a flying license. What if he is being careless and flies too close to the sun? I agreed with her that Dylan is a risk taker but I believe he would follow through and land.
L5 Senior Design Engineer - Craft
• Prototypes and presents difficult-to-visualize concepts to justify design and technical decisions
• Contributes readable code and collaborates with engineers
• Delivers works using component libraries
• Capable of production-level engineering in an area of technical focus
• Uses data to form and validate inefficiencies in both design and engineering processes
L5 Senior Design Engineer - Expertise
• Uses a web or mobile technology stack to explore engineering feasibility
• Has at least one developed design proficiency, such as interaction, motion, visual or UX design
• Uses engineering build tools and IDE to reproduce and debug UI janksThis is the third article in my series on Design Engineering. If you have questions about this best job on earth, leave a comment or reach me on LinkedIn.
