Engineers vs. Analysts | CPI's Interactive Intelligence Blog

Engineers vs. Analysts

Subscribe to this Blog:


Enter Email:


Validate Code:

David Currier


Sounds a bit like a major league game, right? Well, believe it or not, I see this game played out nearly every time I participate in a design meeting. And today, I stumbled across a video that makes my point with painful accuracy:

 


A bit extreme? Here’s an actual exchange from a conference call I participated in that came to mind while watching this video. I didn’t have a recording, so it’s not word for word, but pretty close.

Executive: “We’ve got a problem in our call center. We have so many calls right now that customers are waiting in queue for up to an hour. This is unacceptable! What can we do to fix this?”

[discussion]

Me: “There may be a bit of tweaking that could be done in the skills-based routing to make call handling a little bit more efficient. But the main problem here is that there just aren’t enough agents to handle the volume of calls coming into the system any faster than you already are. We discussed this last year and provided headcount forecasting that projected a significant increase in the number of agents that would be needed this year at this time… but there are only a fraction of this number on the floor.”

Executive: “Well, I like to think of the call center like a supermarket. When there are a bunch of customers waiting in line, you open more checkout lanes to handle them faster. We need to create more queues and transfer calls into them so that they can be handled more quickly.”

Me: “That is a great analogy! However, opening more checkout lanes means you need more cashiers to run them. If we simply open more checkout lanes, then we’ll have to take cashiers away from ones that are already open to run them. And once customers get to the register, we’ll be sending them to yet another lane to wait yet again for another cashier. Unfortunately, this will make the situation worse than it already is.”

Executive: “I don’t agree. I believe that my analogy is correct and I’d like you all to get it done. I don’t have time to discuss this, so just make it happen. [click]”

[silence]


Observations

Here are a few of the lessons I thought of:

  • Listen to the subject matter experts you have access to! Seriously, we generally know what we’re talking about and become rather uncomfortable when asked to explain why something is not working as expected when our expertness was ignored.

  • If you’re a subject matter expert, do your best to understand the end goal of the customer unit… especially if you’re having trouble understanding what it is you are being asked to do. The engineer in the video above did a great job of asking how the solution should look when completed – think: “What are you trying to accomplish?” In other words, there might be more than one way to accomplish it.

  • Support your subject matter experts. I am incredibly grateful to have project managers that get this and do their best to help customers understand that when I make a recommendation, it is a good idea to give it serious consideration.

  • As a subject matter expert, realize that your recommendations will not always be followed, and that it might be a good thing. Yes, you’re an expert. But you’re not a deity. Get used to it. Listen to the business need, and realize that there might be a really good reason for doing something a particular way… even if it seems inefficient.

 

The Moral of the Story

Really, there shouldn’t be an engineers vs. analysts mentality at all. If I were to re-create the video sketch as it should have played out, all parties would have quickly realized that there was a fundamental disconnect in understanding the overall goal of the project AND the technical requirements to achieve it. They would have honed in on the desired end result of the project and collaboratively discussed various ways to get there. The non-technical participants would have accepted to the technical limitations explained by the engineer. The engineer (with his project manager) would have realized that they may have misunderstood what the customer was trying to accomplish, and worked together to meet the needs of their customer. Perhaps the proposed solution of drawing lines just wasn’t a good fit for the business need.

While the video I included in this post is humorous, the reality of it can become frustrating for both parties. What are some ways you have handled similar situations? And what lessons have you learned? Let us know, we'd like to hear from you!




comments powered by Disqus

Posted in