The Messy Overlap

I stumbled into Design Engineering. I didn’t set out to become one, but in a way I suppose I have always been one… I just couldn’t help myself. Good software can be created in organizations siloed by discipline, but it’s in that messy overlap of design, engineering, and other disciplines truly collaborating where great software is made.

Early in my tech career—when I was living in Boulder—a friend introduced me to someone notable from the Bay Area. He introduced me as “one of those unicorns” who can write code and design. I’ve never enjoyed that term, but it was a very endearing introduction and my friend was obviously very proud of me. However, the person I was introduced to incredulously stated something along the lines of, “Why are you doing both? Focus on one.”

I didn’t. I kept pursuing both. I loved following the entire through-line from idea on a napkin to working software. It was fulfilling to know whatever I could dream up, I could bring in to existence.

I loved following the entire through-line from idea on a napkin to working software.

But I also did both, in no small part, because of the economics of my local market at that time—something the Bay Area notable was likely not aware of. Boulder had a burgeoning startup scene and was punching above its weight, but it was engineering-driven. Startups knew they needed design, but didn’t value it in a way that correlated to them paying much for it—beyond free beer and paper equity. I couldn’t pay my rent with unrealized gains.

I was embedded in the local design community. I knew so many amazing indie designers and small studios. They were bringing in clients who needed dev work and naturally began to turn to me to execute their designs. They knew my work was high quality, but more importantly, they knew I cared about the design. I cared about the outcome beyond the code under the hood.

I stopped introducing myself as a designer

Years later, by the time I arrived at LinkedIn on a short-term engineering contract (to build a Sketch plugin), I fully considered myself an engineer. After a long crisis of professional identity I had claimed the title. At subsequent tech events I stopped introducing myself as a designer or design/engineer hybrid. It’s not that I’d left design behind, but I certainly wasn’t advertising it. Maybe once a year I took a vanity project where I got to design or I’d put some cycles into a personal project—otherwise I focused on frontend and backend engineering skills.

But that’s the cleaned up version. In reality, I never fully stopped designing. A designer would hand me their designs and I’d fill in the gaps: motion, transitions, states that hadn’t been specced out (or even accounted for). Rather than asking what a designer wanted me to do, I’d add something in code—during the buildout—and propose it. I’d self-select: picking clients that met my design bar, avoiding messes and ensuring my design input would be considered and valued. With some designers, this balance was the explicit agreement. Those were the designers I was always most excited to collaborate with.

After a few initial projects at LinkedIn, I saw some space to do design again, and I took it. The work I was doing was under the umbrella of the design organization and it felt natural. Rather than wait for a busy product designer to free up cycles for a lower-priority, internal tool, I’d design the tool myself. Or, I’d get it started and then collaborate on the design. And I’d get to build it, completing that satisfying loop: idea > design > execution > refine the idea > repeat.

I was ultimately hired out of that contract into a full time role. We didn’t have a title for what I did, but I was expected to do both product design and engineering. Sure, the balance shifts—it’s never a 50/50 week, month, or even quarter, but it is really fulfilling to be able to put a critical eye to product design again and then also have the chance to build the idea—rare at any company; rarer still at a large company.

Engineers who understand the value of design and designers who want to understand—or even contribute—to the code behind their work have always been part of the process in creating software.

The titles our industry uses for the multidisciplinary work I do day-to-day continue to evolve: Design Engineer, Creative (or Design) Technologist, UX Engineer, or simply, “a designer who writes production code” are all thrown around. At LinkedIn we call ourselves Design Engineers internally, but still don’t officially have a title that reflects the work. I am curious how this hybrid discipline—and its multi-variant titles—continue to iterate in our industry, but my point is that the role has always existed. It has always been needed.

Engineers who understand the value of design and designers who want to understand—or even contribute to—the code behind their work have always been part of the software creation process. And often those skills are embodied by the same human, regardless of their role or title.

I try to describe my work history in the following way: I have experience in product design, backend and frontend engineering, and particularly enjoy roles that intersect some or all of these disciplines.

I’ll always enjoy that intersection because I do not believe you can build great software without it. That doesn’t mean a single person has to embody it completely, but it does mean a team has to embrace the messy overlap of disciplines required in building software people will actually want to use.