Want faster IT? Stop thinking like an engineer

Engineers love solving problems. Give an engineer a problem and you’ll get a solution, often a creative one reflecting ingenuity and skill. But sometimes that solution is a problem itself. 

When the solution goes far beyond what the problem requires, I call this the “race car solution.” If a user needs a bike and asks for a bike, sometimes they get a race car instead – an over-engineered solution to their problem that they didn’t ask for and don’t need. It does solve the problem, but likely ate up more time and resources than necessary.

[ Get more wisdom from Chris Fielding. Read also: How to retain talent: Sungard AS CIO's advice. ]

If you want to move faster in IT, addressing these over-engineered solutions can uncover efficiencies you didn’t know you had. It all starts with a more humanistic approach to problem-solving. 

Start by listening

It’s as simple as listening, but that’s easier said than done. Listening is about keeping yourself in check and focusing on what other people want. At times, that means reading between the lines based on context or history. Listening closely to what they truly want or need, and confirming what you’re hearing, will keep the project on track from the start. 

For instance, on one occasion our sales users informed us that one of our legacy systems was “slowing down sales.” Our technical team’s initial prognosis was to restart developing in the environment – that is, until the process leader pulled together a group of users, opened a dialogue, and got down to brass tacks. In the end, a few minor system setup revisions were all that was needed to achieve the desired outcome. This was ultimately a faster, more cost-effective solution.

In this case, simply listening was enough to solve our race car problem. But when listening alone isn’t enough, you’ll have to dig a bit to get at what the user is looking for. 

Questions engineers should ask 

Before attempting a solution, take the time to understand all of the constraints and requirements users are dealing with. Problems don’t always require an IT solution, after all.

In addition to active listening, engineers need to ask the right questions. Here are a few general ones to get started: 

• What’s the timeframe for this project? 
• What’s the budget for this project? 
• How important is this project compared to other priorities?
• How else could we solve this problem without an IT solution? 

When the marketing team came to us asking for an end-to-end solution to push data to a third party, we knew this could be a difficult request. So we offered an alternative solution. Instead of full automation, we suggested a combination of a process and a technical solution. This proposal offered more flexibility than the original request. In the end, IT achieved a higher net result with a simpler solution: Win-win.

If you don’t have a clear sense of the issue you’re being asked to resolve, it’s easy to end up with an unnecessarily complicated solution when all you needed was a simple fix. 

The IT leader’s role 

“Why?” This is arguably the most important question any leader can ask.

You shouldn’t ask this question only of the business teams; you should ask your own teams as well. You need to constantly challenge your team. You need to lead.

When your team says they’re going to need three months to work on the product catalog, ask them, “Why?” Can they do it in two? Furthermore, what will it cost to get the job done faster? What do they have to give up to make it work?

This approach can help engineers dispense with assumptions, get to the heart of the problem, and find the quickest path to the right solution. They can evaluate problems by creating clearer lines of communication among all parties involved. 

By asking the right questions and gaining a more complete understanding of the business needs, you’re going to get a better solution, and you’re going to get it faster. 

That is the point, right?

[ Do you communicate effectively? See 12 bad communication habits to break in IT. ]