Category: Leadership

The Role of a Designer in an Engineering Organization What can HGTV teach engineers about engineering teams?

Awhile back, I had an interesting conversation with a product designer. She was, at the time, relatively new to our company and wanted get my opinion on a few things. We met for coffee, and talked a bit about our thoughts on the company in general. Then she posed a question to me: “What do you think the role of a designer is in an engineering organization like this?”

I paused for a moment, trying to come up with a useful answer. I’ve partnered with a number of designers throughout my career. And while there have certainly been similarities between these working relationships, each one has been fairly distinct. Apparently I was taking awhile to mull over the question, so she prompted me again:

“I talked to another engineer, who used the metaphor of building a house. He described engineers as being the architects who design the house, and the construction team that builds the house. So then, design’s role is to paint the house afterwards.”

“No,” I immediately told her, “that’s not right at all.”

The look of relief on her face told me that I’d given her the response she was looking for. Still, I wanted to answer her original question. And, not being one to mix metaphors, I wanted to stick with the home-construction theme.

Maybe TV can teach us something

So of course I turned to Love It or List It, a television show that airs on HGTV. Love It or List It has a simple premise: each episode features two (usually married) homeowners. Both are dissatisfied with their current home, but they disagree on how to solve the problem. One invariably wants to sell their home and move into another; the other insists on remodeling their current home. And thus, a sort of competition arises between the two “stars” of the show: real estate agent David, and designer Hillary. David tries to find the couple a brand new home to move into (and thus, “list” their current home), while Hillary remodels the couple’s existing home–or as much of it as she has budget for–to try to convince the couple to stay (aka “love it”).

It is Hillary that we are, of course, interested in here. From the outset, she works with the homeowners to identify their current situation: their problems with the current home, the requirements each would have in order to stay, their budget, etc. From there, she begins to generate ideas on how to renovate the home.

Importantly, she always collaborates closely with contractor Eric. While one might expect a contractor to simply carry out the designer’s vision, that’s not how Hillary and Eric typically interact. Instead, they work together to refine the designs and come up with the ultimate plan. For example, Hillary might float the idea to build a laundry room in a certain unused corner, only to told by Eric that the house’s existing plumbing would make that unfeasible… but hey! If we removed this other wall, then that would open up the perfect spot for a washer and dryer. And so on.

Once the designs are finalized and approved, we see glimpses of Eric and his team performing the actual demolition and construction. But collaboration between the two rarely ends there, as unexpected problems are encountered and they work together to resolve them. The end of every episode results in a stunning redesign, one of the homeowners invariably exclaiming “I can’t believe this is the same house!” and–at least so it seems to me–the homeowners typically electing to once again love their home.

Design is more than making things pretty

Painting a house
Not really the role of a designer

Or course, Love It or List It isn’t perfect metaphor for engineering organizations. For example, we might assert that Hillary’s role encompasses product management as well as design. But it’s a far cry better than the notion that designers are there to simply make a nearly-finished product look pretty.

Let’s take a step back and examine why I chose the Love It or List It metaphor over the slap-a-coat-of-paint-on-it metaphor:

  • First, designers don’t wait for engineers–or any other functional role–to decide what to build and how to build it. Instead, they help to drive the product definition before any line of code is written.
  • This means, of course, that designers don’t just come in at the end of a project. Instead, they collaborate with the entire team from the outset of the project.
  • Finally, design is about far more than just making things look good. While creating visual appeal is generally a big part of design (and for sure, Hillary’s remodels look stunning!) designers are there to contribute their understanding of user behaviors, and to help the product team to push the boundaries of how to solve their needs.

The designer and I riffed on this for a bit. By the end of our coffee break, we were both pretty happy with this metaphor. Weeks later, she and I soon found ourselves on the same team. We pushed this sort of cross-functional collaboration from the beginning. Our entire team–design, front/back-end and mobile engineering, product management, research, QA–would routinely meet to iterate over mockups, building on each others’ ideas until we’d found the best possible solution.

The end result? Solutions that were innovative, feasible, and I daresay in many cases, stunning. And for what it’s worth, team members who chose to love their jobs, rather than shopping for new ones.

Becoming Comfortable with the Uncomfortable Being a strong software engineering professional sometimes has nothing to do with software or engineering at all.

It’s comfortable to complain.

Most of us learned this the moment we were born. As babies, we quickly discovered that crying, loudly, got us what we wanted. A bit later in life, we applied these same lessons for ice cream, TV watching time, and staying up just a little bit later. As teenagers, well, complaining was just the thing to do.

Even as fledgling software engineers, we’ve gotten rewarded for complaining. Pointing out what’s wrong with an organization–its practices, its codebase, etc–initially got us positive attention. We should be using constants instead of hard-coded values in this class? Well done! We’ll assign someone to fix that. Our stand-ups should be moved from 9:45 to 10:00 in case people get in late? Good point. We’ll see about moving them. We should have detailed diagrams of our service architecture on our Wiki? Uh, sure… someone will get to it when they have time.

Because, let’s face it: complaining is easy. But pointing out flaws will only get you so far. At some point, someone needs to address those flaws. And before too long, you may find that your complaints are becoming a liability, and that it’s time to stop grumbling about problems and start doing something about them.

And if you’re like most of us, you’ll pick something comfortable. You write code, after all, so why not find some code to fix? You’ll spend an afternoon refactoring a class to make it more testable. You’ll spend an evening applying the command design pattern to some data access objects. Heck, maybe you’ll spend a weekend coding up a little framework to support your new command-design-pattern-data-access code (and, maybe, someone will actually use it). You’ll show everyone your work, and they’ll tell you what a good job you’ve done. And you’ll feel great, confident that you’ve shown everyone that you’re willing to do whatever it takes to help the organization succeed.

Except for one problem: you haven’t done that all. You’ve shown that you can create fun, interesting coding projects and do them. And before too long, folks will start getting tired of seeing the latest pet project you’d spent your time on while they’d been slogging away at un-fun, uninteresting tasks.

So what’s an enterprising engineer, who truly wants to solve problems and prove their worth, to do?

The answer is easy: find something that’s hard. Something that everyone knows needs to get done, but no one wants to do. Something that’s outside of your comfort zone. Maybe even so far out that you don’t know how to get it done.

In 2015 I joined a company, a Java shop, that was running its applications on Java 7. As I’d been developing on Java 8 for about a year at that point, I was a little disappointed. So naturally I made a glib comment to my new co-workers, and received some knowing grumbles in return. This, or some variation of it, happened for the next few months. Someone would ask in an engineering meeting when we would finally be moving to Java 8. The answer would always be the same: someone has to step up and make it happen.

Finally, one day, I decided that I would be that someone. I knew the task would be tough. I had a full workload, of course, so this effort would be above and beyond what I was hired to do, especially given that I was taking it on voluntarily. There was a lot of risk involved. Even if it went smoothly, we were bound to run into build issues from time to time, and everyone would know who to blame. And in the worst case scenario, I could introduce insidious runtime issues that would reveal themselves early some morning in production.

Plus, I flat out didn’t know how to do it. Installing Java 8 on my own Mac was one thing. But getting the entire organization–its various development, QA, and production environments; monolithic applications and microservices; homegrown libraries and frameworks–all upgraded? I mean, I’m a software architect, not a sys admin!

But I figured the flip side would be that I’d provide a huge service to the organization, modernizing it, and making a number of engineers happy. Besides, I wanted to use streams and lambdas, dammit!

So I announced that I would lead the effort. And it was indeed a large task. I researched the issues commonly encountered by companies doing the same thing. I created a detailed list of dependencies, which drove the order in which applications were to be upgraded. I recruited members of the devops and QA teams, as well as members from individual engineering scrum teams, to be a part of the effort. And indeed, as the project progressed, more than one engineering team ran into vexing build issues.

But most surprising to me was that everybody was fully on board. Despite the effort involved, despite the road bumps encountered, every last person involved was willing to pitch in and help push through. I noticed that the wiki page I’d set up to document common issues and solutions started flourishing with input from other teams. Within a few months, every system in the company was running on Java 8. Years later, I would still receive the occasional word of thanks from engineers in the organization.

Later in the same company, I found myself–along with a number of engineers and engineering managers–complaining about various recruiting and interviewing policies that the engineering organization had adopted. The answer came back: “Someone else needs to come up with better solutions to bringing in good engineering candidates.” I paused for a beat, then agreed: if I’m complaining about it, then I should be willing to find a solution. Again, I didn’t have any particular love for, or skills with, the topic at hand. I certainly was not a recruiter. But it was something that nearly everyone agreed needed to be done. So I assembled a series of agendas, and pulled together small teams to tackle each one. And slowly, we began to improve our recruiting a hiring process.

Since then, I’ve simply taken it for granted that if I identify a legitimate pain point in the organization, it’s my job as a member of that organization to help solve it–whether it has anything to do with software or not. As I spend less time writing code and more time in management and leadership roles, of course, I find myself tasked with a variety of non-engineering issues on a daily basis.

But even if you plan to write code for a living until the day you die (or, more optimistically, retire) taking on non-technical challenges is always a good idea. You’ll boost your own confidence, and your stature within the organization. You’ll get to work with different people, and learn some new things.

And you’ll find yourself with fewer things to complain about.