Design Engineering - a State of Mind
Finding my dream role blending code, design, and product thinking
👋 Welcome to the Design Engineer Newsletter Series — a collection of essays, internal material from the archives, and new think pieces about the evolving role of design engineering.
We’re excited to kick off this edition highlighting Andy’s story of discovering design engineering. We hope it can be inspiring to someone else also looking to get into design engineering as well!
Before my days as an engineer, I was a pianist for a string orchestra in high school. In one of my first concerts with the orchestra, the cramped stage was getting set up, and our budget keyboard was a misstep away from breaking. I’d rehearsed for the Harry Potter theme song and was still gathering my nerves when someone tripped over the keyboard’s wire, snapping it in two.
This was a problem—that was our only keyboard, and it just lost access to electricity. A contagious panic broke out. As it spread, it reached a cellist’s dad who came by. He diagnosed the situation, bit into the plug and re-attached its inner wires. He grabbed secondhand tape from an unused percussive instrument, wrapped the wires, and then pressed the power button. It turned on.
I asked him how he fixed it. He responded “I’m an engineer”. It was hard not to feel inspired by his Marvel-like moment. I immediately found conviction in wanting to be an engineer and help solve problems for others like he did for me.
I studied software engineering at the University of Waterloo. Coding felt magical—my first “Hello world” in Java quickly evolved into a plethora of index.html files, writing scripts to find free food on campus from events and regular overnight hackathons. My days eventually evolved into days full of software engineering, from a Google internship day job to evening development work for Hack the North.
But I had a hard time finding passion in my software engineering roles. I couldn’t see how my work was “fixing the wire” for others. I was convinced that I needed to move up the tech stack and become a designer to be closer to the user.
I bought Sketch and tried mastering the tool by making a sketch a day for 30 days. I spent two years trying to build a portfolio and gaining design experience, including an engineering internship role at pre-launch Figma and designing for Hack the North. And then I finally nabbed a formal design internship.
The role was what I imagined it to be—I was designing the UI that a user was interacting with. I was closer than ever to the user. I could see how people used my work. Although it was the day to day I expected, it still didn’t itch my desire to “fix the wire”.
This search continued for a few years. My journey spanned a wide range of roles, spanning software engineering at both large and small companies like Google and Figma, design at Quora, and product management at Uber. I even joined as the only engineer and designer at a YC startup and saw the product eventually get acquired after three years.
After that startup stint, I was on the job market looking for a new role. My core interest remained around solving real problems for users through a product.
The problem is that the job market is unforgiving for people who change roles. When I was applying, both software engineering and PM roles required many years of industry experience. I had neither, having worked as the only software engineer and designer for 3 years at a startup and having 3 years of product management experience, despite having 6 years of total industry experience. A hybrid role would have been a dream come true, but this wasn’t a standard role to have at a company.
I’d get far into interviews, only to get rejected because I didn’t have enough experience in the specialized role despite enough industry experience. I also applied to many PM roles but didn’t find a good fit due to my lack of recent PM experience. I was stuck between the cracks of engineering, product and design, having the skills to build a great product but not being the “right fit”.
Eventually, I started finding roles that fit between the cracks. While playing in a basketball rec league, I shared my situation and talked to my teammates about my ideal role. They didn’t have a job posting for that role but they saw the value in it. That conversation led to an interview the same week and an offer the following week. That’s when I joined Windsurf, then known as Codeium. Today, our main product is the Windsurf Editor, a VS Code fork with an agent that understands your codebase and your intent, providing you with the ability to build 10x faster.
The team was a small scrappy team of around 20 when I joined so there wasn’t a point in focusing on a single part of the tech stack. Similar to my past experiences, no problem felt like someone else’s problem—we were all given full agency to solve any problems that could improve the product. The breadth of my past experience across different roles gave me a lens on the engineering team’s problems. For example, how can you use design to improve the failure modes of tool calls? How do you compress a plethora of functionality in a fraction of the screen space? How do you design a human-in-the-loop experience for developers to seamlessly collaborate with an agent?
The role evolved into a state of mind instead of state of ownership. The focus of my role was “how can Windsurf bring as much delight to the user as possible?” instead of “own the design or code for this feature”. I define this focus as the role of a design engineer.
My goal as a design engineer has always been about how to solve problems for users. I spend my days reading through bug reports, feedback, both internal and external, looking at data, and trying to find elegant solutions to the problems I see. The solution space presented is never limited to just code—sometimes, it's a copy change or a design tweak, or it could be an entire facelift. Other times, it’s a combination of both design and engineering. Limiting yourself to one axis of change can limit you to a local maxima. Rotating through different perspectives as an engineer, designer and PM allows me to find a global maximum for our users.
Unlike traditional design or engineering functions, the power of a design engineer is the breadth of skills we have. Areas of ownership make sense when expertise is needed. However, there’s so much more to a delightful user experience than code or designs. It’s the ability to see through the cracks and to fill in the details that make an experience feel complete. It’s the ability to not only answer the “how” you do it, but the who, what, and why.
To fulfill this need, design engineers are not required to be experts of their tools unlike the traditional roles of software engineers or designers. Instead, they should be able to learn to bridge gaps, understand the user and create delight. Design engineers should be able to start backwards from the user and have a vision for the experience and then picking the tools, existing or new, to bring the vision to a reality.
What makes the role so exciting is that learning is a prerequisite of the role. There’s no unified form factor for solutions—solutions are bespoke for the problems that arise. The engineer that fixed my keyboard was never trained to bite into a plug. It was a means to an end—to bring delight to the end user and to solve a problem.
Bridging the gaps to create user delight is difficult. It’s what makes design engineering so difficult yet important. But why is design engineering rising today?
A lot of it can be attributed to the rise of AI tooling and model intelligence improving. As AI tooling becomes more powerful, the floor for skill sets becomes lower. Breadth will also always be valuable due to the unique perspective it brings. As a result, having breadth is increasingly important because the combination of its unique perspective and a greater ability to apply skills through AI tooling is key to finding a global maxima in product experiences for users.
This definition has increasingly become a dream role for me. Domain expertise is extremely important, but its ceiling on user impact is limited by the lack of breadth. I’ve had the chance to develop depth in many functions as a software engineer, product designer and a product manager professionally and to be able to marry all of those interests in one challenging role at Windsurf has given me a peek at what future product development teams could look like.
For anyone who also obsesses over the impact of their work on users, I encourage you to discover the broad world of design engineering, a state of mind focused on working backwards from the end vision instead of a focus on how to apply existing tools for new problems, a state of mind focused on questioning beyond just the “how” but also the who, what, and why.
Thank you for reading about my journey becoming a design engineer. If you’re interested in helping shape the future of software development, join us as a design engineer at Windsurf!
–
For more updates on design engineering, follow @designengclub on X.