The worst question to ask as a technologist

"What do you want?" When I hear that being asked at the start of an IT engagement it sends shudders down my spine.

I have been on both sides of it and while it seems reasonable enough on its face, there is implied a certain blindness with respect to the goal of a technology project (or for that matter any other kind of engagement between a specialist and client). A blindness that almost inevitably results in wasted time, money, and political capital.

Often a finger is pointed at some deficiency on the part of the technical team as the reason behind a failed project. But while it may be true that there exist a few bad actors out there the vast majority of technologists, be they internal resources or external vendors, are well-meaning, ethical, and skilled in what they do.

There are many potential direct causes for failure but when a technologist is engaging with a business client that vexing question, "What do you want?", starts them down the wrong path from the beginning.

Instead they should be taking a pause to calibrate the entire effort by asking: "What problem are you trying to solve?"

The problem with the former question is that it's too focused on the implementation of the solution as the goal of the project. That is the immediate goal of the technical team but it's not the overall goal of the project. And it too easily devolves into asking the client to specify what that solution should look like.

But if a business client is working with a technologist, whether an internal or external resource, that is because that technologist has some expertise or capability that the client is lacking. The technologist is the expert in technical solutions, the client is the expert in their problem.

Taking a step away from the technology and asking the client to focus on their expertise by laying out in detail the problem they are trying to solve has two huge advantages.

The first is that it forces the client to articulate exactly what they are expecting. Their job is to advance the goals of their organization and their assumption in working with the technologist is that technology can help. But technology is only a tool, it's not an end unto itself.

The problem is that often non-technical folks treat technology like an end. Not because they are in the job of technology but exactly the opposite, they view it as a magic solution precisely because they are not experts. A key skill of an effective technologist is to be as much of an expert in what can't be done given the context of the project (budget, time, capacity, etc) as in what is possible.

By taking the time to explain their problem to an outside party who is not necessarily well versed in their domain the client helps to ensure that they understand it themselves: nothing helps you to understand something better than explaining it to someone else.

It also brings their focus back on the real reason for the engagement, restoring perspective and a sense of their own responsibility in achieving success instead of just handing everything off to technology and being disappointed when magic doesn't happen.

The second advantage is that focusing on the problem to be solved and not potential solutions de-links the two. Even the most well run projects inevitably run into issues that were not known at the start. Normally this results in a frantic effort to still meet requirements within the remaining time and budget.

What it comes down to is that compromise is always needed eventually.

With a focus on the solution, on specifications, it's hard to come up with creative options since ultimately failure is a black and white CYA definition of "does it meet requirements".

Compromise in this situation means that the requirements must be adjusted. An experienced client is used to this and accepts that things change but it still doesn't leave a good feeling because it means that at some level they are not getting "what they wanted".

That original answer to "what do you want" has frozen expectations and anything deviating from that causes tension.

In contrast, with a focus on "solving the problem", it becomes much easier to introduce other pathways to success, some of which may not even be technical in nature. The measure of success moves from "does it meet requirements" to a more effective, "is it helping to solve the problem".

Compromise loses that whiff of failure and instead becomes merely a different way to get to the same end goal of solving the problem. It doesn't matter as much how we get there so long as we do.

An effective project, that is to say one which achieves desired results, is rarely one with the perfect technical solution but rather one that builds in an ability to steer along the path to solving a clearly articulated problem for the client.

Technology is not a magic wand and the best technology will fail if implemented for its own sake. Talking about solving problems brings the focus back to the goal of the client rather than the goal of the project team, ensuring that expectations are met.