In 1999 I was working as a Legal Systems Analyst at a respected law firm in Washington, D.C. My job was to meet with internal clients, understand their needs for improved systems and work with them to craft responsive solutions. At its core, an essential part of my job was to read and understand users and their needs.

Late that summer I received a phone call from an acquaintance offering me a position as a Regional Operations Manager responsible for onsite IT services at his company’s client sites west of the Mississippi (and a couple east). He knew about my background with network and system administration and thought of me when they created the position. I joked often (still do), that in taking that position I went from finding the “thing I was meant to do” (a story for another day) back to “my printer doesn’t work.” But when all the pros and cons were assessed, it was clear it was too good an opportunity to pass up.

So I packed up all my goodies and headed West.

When I arrived, I had a team of about a dozen desktop support technicians and network engineers working for me in cities scattered hither and yon. I had to learn to manage remotely and how to create a culture where a virtual team operated like a traditional one. I wanted my engineers, many with no onsite management, to develop their skills and customer focus so that they were largely autonomous, knew when to escalate issues and always provided excellent customer service.

These skills are often challenging for junior level employees regardless of industry. I have found in IT that folks on both ends of the spectrum of grace with customers ranging from timid to arrogant, often had poor listening skills. Too many lacked empathy. In particular, more gifted techs without maturity or experience would often draw conclusions and make unequivocal statements of fact about problems and solutions without truly talking with their customers. They were usually well intentioned but often wrong as a result. That was a particular pet peeve of mine.

One workday, as I was meeting with my team at one site, a client walked in, frantic, and said she had a meeting starting in a few minutes and couldn’t print necessary paperwork. One tech jumped up to follow her to her printer, another turned to check the status of print queues, etc. and everybody was satisfied.

Except me.

That’s not to say I was unhappy with my team. My engineers were hopping-to. They were hustling to solve the printing problem. I was pleased with how responsive and professional they were. But I knew they could do better. Fresh out of a position as a Systems Analyst, my focus had been identifying and anticipating users’ needs. My team, as gifted as they were, had been focused primarily on the hardware. As a result, they missed a huge opportunity to delight our client because their focus was on solving the technical problem at hand rather than on our user’s. “Why wasn’t the printer working?” they were asking, instead of “How can we help her get her documents printed in time for her meeting?”

It came to me very clearly in that moment that in IT there are always two problems: the technical one and the business one.

It became a mantra of mine that I ingrained into our work culture. My techs heard it over-and-over. If a client alerted them to a problem and they could not tell me both the technical problem and the business one, I told them I did not consider their job done. They weren’t necessarily responsible for solving the business problem but I required that they know what it was.

We did tackle both problems that day. We knew that our client had to have printed documents at the ready within minutes. We didn’t yet know how complex the problem with her printer was so I sent a third tech out to arrange to have the client email him the document so he could print it for her while the other two knuckled down to take care of the rest.

Recognizing the Two Problems allowed us to address our client’s immediate need. By doing so, we had also bought ourselves extra time to really focus on what was going on with the network printing. She had her paperwork and we could turn our attention, without urgency, to the matter at hand.

The bigger win was that from that day forward our mantra — always two problems — equipped my technicians with an easy touchstone that they could return to any time they were called on to address challenging problems without a manager at hand. Some embraced it, others accepted it but, by and large, their capacity for identifying and addressing users true concerns was dramatically improved.

Our clients were better served.

I work in software engineering now. Our work is about building tools and services for users so there’s some inherent awareness of business problems that comes with that territory. In fact, Systems Analysis and UI/UX are essentially entire professions based on addressing the “second problem.”

Unlike in IT, the Two Problems in software and systems are often harder to tease out from one another. That’s not a bad thing. If they’re too entwined to differentiate, then one solution, one focused effort, should handle both.

But, in the end, I believe articulating both problems is still an exercise worth pursuing. Understanding both makes communications between software engineers, analysts and designers more productive. It also equips small teams with the tools to fill in when those professionals aren’t available. Habitually asking one’s self “what need does this solve for my users?” or “how will this delight my users?” will make even those of us who prefer to hover over a keyboard better at what we do.

Now that I’m not in IT, it requires a bit more effort to identify what part of the picture I’m missing. But as I consider adding more engineers to my team, I think it’s time to dust off the old mantra and remind myself that there are always two problems.