Menu ▼

The Switch

The face in front of me is familiar. It shows a hint of surprise and disbelief, with a swarm of questions behind it. Only one gets out: “Why?”

That’s the reaction I get when engineers find out I switched from software development to design. The question often comes up when I meet new people professionally and this was also the case after joining Google. I shared my reasoning so many times I finally decided to write it down.

Working as a software engineer on customer facing or business-to-business products means you’ll usually get the specification (documents, mocks, prototypes) and implement it. Almost everything has been defined by the time you start and it’s very hard to change it. This is a critical point and I want you to realize the consequence—the vast greatness of your engineering skills won’t matter at all if you’re solving a wrong problem or solving the right problem in a wrong way. For example, by building a terrible user interface. Beautiful code and architecture wasted on something like that is a depressing thought, at least for me.

Finding a team with a proven process where everyone gets an opportunity to share their own expertise during outlining the initial solution is rare. The waterfall method—with specific phases well defined and people siloed—is still very common.

My idea was that by moving up the pipeline I would be able to influence the problem solving part a bit more. The pipeline usually starts with product/project managers and designers following closely. I’ve tried both roles, but leaned more towards design because more hands-on work gets done there. The idea worked—since I switched, I’ve been able to outline right solutions entirely or at least steer them in the right direction.

Two questions usually follow: one asked out loud, the other left hanging in the air.

“Do you miss coding?” is the loud one. Yes, I do. But I’m also very satisfied with what I’m doing at the moment and that takes away some of the pain. I also work on my website, build prototypes for testing and help with front-end stuff so it’s not like I don’t know how to exit Vim anymore.

The second one is: “Are engineers just implementors who can’t contribute to problem solving?” Absolutely not. It’s sad some people have that sentiment. Engineers amass a lot of technical knowledge and expertise. They bring a different perspective and innovative ideas to the table; that’s why I always try to bring them in early during the process.

So that’s it folks, the reasoning behind the switch, for better or worse. My working experience is split evenly between design and engineering up to this point in time. I’m looking forward to see what happens in the future—will one prevail or will a third option take over.

Previous blog post:
A cabin in the woods

Stay up to date:
Email · RSS feed · LinkedIn · Mastodon

Back to top ▲