Be the solution, not the problem: The 3 problem solving traits I'm vigilant for

A problem-solving attitude will make you stand out, get you noticed, and build your career (+14 tips on how to do it and stand out from peers).

As a Director (or anyone who’s running a project) I’m constantly vigilant for people who make a difference — as well as those who don’t. On one project in particular, I had two absolute extremes on my team.

During a design review our customer made the comment that they “didn’t understand the way the user interface was laid out.” They went on to suggest that the team should try out a few alternatives to improve the experience. At this stage in the project, the UX design was pretty much done (and had been done for a long time), so we no longer had user experience designers at the table. We had the engineering team. (I know, kind of waterfall and I didn’t love it, but this was our situation).

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

After the customer meeting we had a quick team debrief. I always like to do an internal debrief to make sure everyone has a chance to share ideas, concerns, or strategy. Michael was pretty quick to pipe up. I’d come to know Michael is at ease jumping into the conversation, which I love. What I didn’t love was what he said: “They’re asking us to change the UI. It’s not our job. I’m an engineer, I don’t do design work!”

I’ll be honest — my first reaction was to support him. I get it. I’m chiefly a back end engineer myself, and that’s where I’m most comfortable. What I felt he was saying — perhaps a bit bluntly and indelicately — was that he’s not comfortable or even skilled at UX design.

But that’s completely beside the point. The point is, our customer was unhappy and confused by the user interface we had built, and an unhappy customer isn’t going to get us anywhere. I made that point, adding, “I know it’s not exactly what we’re excellent at, but we need to do our best here and we absolutely can try out some alternatives. Between us, let’s see if we can solve the problem and if not, we’ll get the UX team to the table.” Michael wasn’t having any of it, and what he said next really stuck in my mind: “If they want a different UI, then they should design it.”

That’s when Jimmy chimed in. “Well, look, I’m no user experience designer either, but I’ve got to admit I feel kind of confused by some of this interface too.” Jimmy went on to describe how buying and selling assets (this was a trade application) was “kind of hard to figure out” and seemed like it needed more “brain power” than other apps he used. Before I knew it, the team was starting to tear apart the interface with some mutual frustrations — and, together, put forward some good solutions. The team even enjoyed fixing some poor user interface choices that had been holding them back. Nothing drastic, not a complete redesign, but enough to really smooth out some issues.

For instance, each transaction had a tiny little disclosure triangle (like this: “▾”). If you clicked it, it expanded to show you options for “buy,” “sell,” and “quote.” Everyone agreed it was kind of opaque and changing it to a button labelled “trade▾” would be much clearer. Along with a half dozen other little changes, our customer was delighted and we were moving forward again at a good pace. Most importantly, we solved the issue in a matter hours and our customer was happy again — instead of taking days (and dollars) to pull in the UX design firm again.

And in the end, what stuck in my mind was this:

1. Jimmy is an awesome problem solver, and willing to step-up and get the job done. Since then I’ve come to rely on him. He always comes to the table with a “solution mindset” — with the intention of tackling any problem, even if it’s outside his wheelhouse. (More on this later).

2. Michael is only interested in working in his own narrow space, not stretching and trying to solve whatever problems the team runs into. He doesn’t really care about the team or the customer — he only wants to work on problems that interest him.

In the coming months, this wasn’t the only challenging situation with Michael. At first I took the approach of encouraging Michael to take more time to listen to others, and to think about the long term value of expanding his own horizons. This mostly fell on deaf ears. I remember one more incident in particular: Michael walked up to a team huddle. We were talking about implementing an event streaming architecture, and using Kafka as the message broker. The team’s approach was good, but lacked some nuance and would eventually lead to scalability problems. Michael listened for a while, and after a bit I expected he’d chime in with some good ideas for the team.

Instead, he just said, “that’s not a best practice, you’ll have problems scaling it.” The team looked at Michael. I looked at Michael. After a moment, I asked, “what’s a better approach?” Michael rolled his eyes, said, “I don’t have time for this,” and walked off.

3 traits I’m vigilant for

I opened by saying that I’m constantly vigilant for people who make a difference. Here, Michael was making a difference — but it was a negative one. He was dragging everyone around him down.

Michael is what I would call uncoachable. He was in no way responsive to any strategy I used to improve his disposition and his willingness to work with others. There are three basic problem solving traits I’m on the lookout for: Uncoachable is one; another is coachable, and yet another is innate. The coachable problem solver is by far the one I’ve run into the most often. It identifies someone who is able to grow, expanding their own capabilities when given the benefit of coaching. The innate problem solver is one like Jimmy, who just has a natural talent and attraction for collaboratively solving problems.

The uncoachable trait happens. It’s rare, I can count on one (or maybe two) hands the number of people I’d put in this category. Once I identify someone as uncoachable, I act quickly to get them off my team — or even fire them. The negative impact to the team, to the project, to the customer means it is far more kind to let them go than keep them around. By keeping them, everyone comes to harm.

A few months after this, I got Michael transferred elsewhere. After that he rattled around the company for some time, moving from one team to another — but never really progressing. (A little more on this later, too).

In the meantime, Jimmy has become my go-to solver for everything. I want him on any team I’m building. He’s in high demand, too, because that’s the reputation he’s built across the company. Everybody wants someone like Jimmy on their team.

Since the “UX incident” Jimmy has been on half a dozen of my projects. He always comes to the table with great ideas and a willingness to engage in any problem, even if it’s outside his comfort zone. It doesn’t matter if it’s in his wheelhouse or not (which is DevOps) — he’s engaged, his brain power is pretty impressive, and he applies it to every conversation with the intention of creating better outcomes. He consistently impresses those around him by bringing that intention to make things better, however he can — whether it’s just participating in a conversation, or bringing an interesting solution.

How problem solvers impact the team

We’ll cover problem solving strategies, but first I think it’s important to understand the impact a problem solver has on their team. Some of this is obvious — but let’s dig a little deeper. Why do I prefer “Jimmies” over “Michaels?”

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!