How to respond to magical thinking in business?
August 15, 2011 6:43 AM   Subscribe

What's the best way to handle magical thinking in business settings?

I work in an IT environment as a project manager / director. I frequently come across what's essentially magical thinking and struggle with how to respond to it. It usually comes up when we're attempting to diagnose a particular bug or create new functionality. It usually takes one of two forms: 1. an unsolved problem is explained as the consequence of a completely unrelated function or system, or 2. the solution to a problem is incorrectly identified by ascribing functional interactions where none exist.*

I'd like suggestions for methods of respectfully but concretely communicating ultimately with the goal of getting back to actual problem-solving. The difficulty I have stems from wanting to be both respectful but direct when the issue is clearly a complete misunderstanding, possibly as a result of a lack of education about the underlying systems.

*An example for each: 1. Enormous data transfers are noticed between two servers. The explanation is that Developer A was logged in to the VPN and moved small text files from the server to a workstation. 2. SSL websites are returning errors to a user browser session. The problem is identified as the firewall blocking UDP ports.
posted by odinsdream to Work & Money (20 answers total) 9 users marked this as a favorite
Clarifying question - who are you trying to communicate to? What's their background?
posted by chesty_a_arthur at 6:47 AM on August 15, 2011

The same way you would address any other hypothesis: clearly, concisely, and in a way that should make coworkers feel that this possibility has been eliminated:

For instance:
1. Confirm that Developer A was not connected to the second server and that they were not running a process that does server-to-server transfer. VPN connections are client-to-server, and that is not the issue. Move on to the next idea.
2. SSL protocol does not use UDP, and server daemons providing SSL and HTTP service do not use UDP. Refer to the ports bound by the server process to show this is the case. Move on to next idea.
posted by mikeh at 6:50 AM on August 15, 2011

My usual approach to this is to assume I'm the person with the problem, and start asking questions to help me understand the explanation that was provided.

So for your first example, I'd ask something like: "But the file that was moved is really small, why would that cause so much data to be transferred?"

And for your second, probably a more general question like: "So why would blocking UDP ports cause that particular error?"

And if the answers don't really make sense, continue to ask follow-up questions until the person reveals that they actually don't understand what's going on. That happens when you start getting answers like "I don't really know why" or "It just works that way".

This same approach also works well on those occasions when I actually AM the person with the problem, because in that case the answers actually do start making sense.
posted by FishBike at 6:50 AM on August 15, 2011 [9 favorites]

I'm also a career IT person and in IT management and while I don't see much of this in my current role I've experienced what you describe. I think the key here is that we look upon technology quite differently than the end users. As an example, when I see an error screen on a web page I don't freak out because I can fix it, but the end users have no capability/authority/etc to solve the matter. It might as well be gremlins in the PC or a death ray from Mars as far as they are concerned.

As technologists we expect that computers will yield the same results given the same inputs. If they didn't then our work day would be total chaos. When someone brings up magical thinking answers it is because they don't know how to isolate cause & effort, the cost to really answer the problem is too high or they are lazy.

The solution, I've found, is to determine which of the three is motivating things. There are in fact weird bugs that aren't worth the effort to resolve. I can't stop production for half a day to find out why a file gets corrupted twice a year -- it is cheaper to pull it from backup and live with the bug, for example. Looked at in this way the magical thinking can be turned into pragmatic cost/benefit analysis. That is the way logic oriented people get action out of mystery.
posted by dgran at 6:56 AM on August 15, 2011 [4 favorites]

I'd treat it credibly like FishBike suggests. As an application engineer I'm too used to system engineers and other specialists ridiculing or dismissing suggestions that later turn out to be correct. There's so much funky, unpredictable stuff in IT that sometimes the off-the-wall suggestion has some merit to it, or at least gets people thinking about other possible solutions rather than a knee-jerk rejection.
posted by idb at 6:57 AM on August 15, 2011 [4 favorites]

Could you have more of a brainstorming session, asking, "What else could it be?" and getting a few possible suggestions before evaluating any of them? That way the person doesn't feel like you're shooting down their explanation without even thinking about it, and you might get some extra information.
posted by chickenmagazine at 7:11 AM on August 15, 2011

Echoing Fishbike and idb, sometimes issues have seemingly counterintuitive explanations.

You say you're an IT Director? I assume then, that if these people don't outright report to you, you at least have some kind of authority over them. Make them explain it until you understand.
posted by mkultra at 7:26 AM on August 15, 2011

If you're the manager in this situation what's wrong with just saying 'that doesn't make sense' - followed by an explanation of why it doesn't make sense. However, if you believe these people are giving these answers due to lack of education/understanding of the systems involved, why do you want their help diagnosing the problem?

If you go away, do the problems ultimately get resolved? Sometimes people give incorrect explanations to save face - ie. they know what's causing the problem and its something they did or something that was their responsibility and they don't want to admit it so they fob you off with something hoping that you wont care so long as it does actually get fixed. If that is what is going on then its really up to you if you want to call them on it or let them save face and fix the problem privately but I'm sure they'd prefer if you accepted their blag and left them alone to fix it.
posted by missmagenta at 7:33 AM on August 15, 2011

"How does that cause the behavior we're seeing?"
posted by rmd1023 at 7:34 AM on August 15, 2011

"Show me the logs."
"Show me the packet capture."

Not trying to be flip, but if you take personalities and education out of the issue, and instead focus on working together to understand a given dataset.

If your folks don't know how to take a packet capture or open a logfile, solve that problem first.
posted by These Premises Are Alarmed at 7:35 AM on August 15, 2011

"Can you reliably reproduce the problem based on this explanation?"
posted by bfranklin at 7:35 AM on August 15, 2011 [2 favorites]

Education is always the answer - and I don't mean condescension. It does sometimes mean long and in-depth conversations covering what to you or I would be simple technical concepts, but once you take the time to explain things through a few times, they'll come to trust your judgement without question. Until that point, don't lecture, scold or dismiss - discuss. Treat them like intelligent adults, even if they just said something you consider dumb.
posted by Slap*Happy at 7:54 AM on August 15, 2011 [1 favorite]

Eliminate their proposed explanation as a possibility through testing.

I have to deal with this kind of crap all the time with voip, and the only way to get people out of the mindset that 'x is the problem' for whatever 'x' is, is to take 'x' out of the equation.
posted by empath at 7:58 AM on August 15, 2011

"Show me the logs."
"Show me the packet capture."

Exactly, Stacktrace or GTFO
posted by empath at 7:59 AM on August 15, 2011

I'm a network engineer. I often have to deal with people not understanding underlying technologies. My go-to technique in this situation when I need to be very diplomatic is to acknowledge the input and how it could impact the situation, then explain why it's unlikely to be the proposed issue, and then ask for further information and logs.

To take your VPN example "So we have traffic between servers A and B? Bill your suggestion with VPN might be the case if the files Developer A moved to his desktop from server A were actually hosted on server B. We can check if server A has a mount point on server B. But typically we wouldn't expect to see this amount of traffic from a user on a VPN connection so let's also (modulate the shield harmonics / generate a tachyon pulse / whatever real troubleshooting seems appropriate.)"

This seems to keep the team moving in the right direction without much drama. I wouldn't make them explain it to you until they crack - I'm not much for calling out CxO's.
posted by anti social order at 8:27 AM on August 15, 2011

This isn't magical thinking as much as it is a misunderstanding of the fundamentals of IT.

If you want to build a skill here, work on hearing the ludicrous suggestion and then acknowledging it neutrally. Then explaining kindly why it can't be that, but then using the crazy suggestion as a segue into a more likely solution. You'll also earn bonus points if you indicate that the person making the insane suggestion put you on to the correct solution's trail.

"Interesting... But I think in this case, the UDP ports are probably causing a different issue, not this one. That said, your idea gave me a thought: it could actually be a server firmware issue. Thanks, Ron."
posted by yellowcandy at 9:19 AM on August 15, 2011

Channel your inner six-year-old and keping asking "Why?"

I got into IT after several years of digital prepress. There were a few people who would refuse complex jobs, saying that a particular device or server "didn't like them" or "knew it was them." In fact, they were just Doing It Wrong, but I had to figure out why before I could solve the problem.

Beware that going down this path will make people uncomfortable, because it makes them confront the fact that they don't really know what they're doing. Proof denies faith, and all that.
posted by wenestvedt at 10:17 AM on August 15, 2011

I agree with all the previous commenters, especially Fishbike, suggesting to ask questions until you can get the other person to see that they don't really understand.

Additionally, if this is what you would view as 'magical thinking' in your industry, consider yourself lucky. /worked in a store selling environmentally friendly and 'natural' products.
posted by Midnight Rambler at 4:01 PM on August 15, 2011 [1 favorite]

After working in IT for a while, I think your problem can be summarized with the following operating assumption: It's always the other guy's fault. If users can't log into your system it must be LDAP's fault. If you can't download a file it's because Kerberos is blocking you. You might think that knowing the ins and outs of a system gives you far more knowledge of the myriad of ways might have gone wrong to explore. Nope, we blame the things we know least about. So for example, when our JBoss server seems to exhibit split brain behavior on reboot unpredictably, the discussion resolved around JGroups settings. I naively suggested changing the cluster protocol from UDP to TCP, on the offhand chance reliability was the problem. No improvement thus far. Bit of magical thinking on my part, but nobody's come up with a better solution yet.

So the solution is education and cross-functional training. And maybe a bit less access control and information on a need to know basis. The more you know about a given system, the easier it is to dismiss a bad hypothesis. Now that I've learned a lot more about LDAP and other Authentication systems, some situations I ran into in the past are obvious and the solutions I came up with suboptimal. But nobody else in my team in the past really knew much about it. And I suspect that nobody besides the team I'm with now comes close. That's partly because of poor knowledge transfer / documentation, and partly because of access controls that prevent people from poking around. I feel especially sorry for the guys who's job is to write middleware between two packages without being given access to either production system.

And if, in your position as project manager, you assure me that you don't have the resources for training, you can add more screening for debugging and technical skills to the interview process. That way it's HR's fault.
posted by pwnguin at 7:30 PM on August 15, 2011

If the issue is clearly a misunderstanding stemming from an incomplete understanding of the underlying systems, then don't imagine that "magical thinking" is the problem. Even if that's what it sounds like. I know you all hear a lot of legitimately crazy shit that people pull out of their asses to explain a problem, but I would gently suggest that your characterization sounds not-dissimilar to the behavior that is bothering you.

I interpreted your question to be regarding other IT personnel. If you're talking about end users:

As an example, when I see an error screen on a web page I don't freak out because I can fix it, but the end users have no capability/authority/etc to solve the matter. It might as well be gremlins in the PC or a death ray from Mars as far as they are concerned.

Or maybe because it's standing in between the user and the information they need to do their job? Of course we end users don't know how to fix it. If an error message popped up on your screen that prevented you from accessing the server logs until you provided feedback on the strengths and weaknesses (in precise yet scrupulously diplomatic language) for a proposal or white paper or strategic plan, wouldn't you kinda freak out?
posted by desuetude at 11:07 PM on August 15, 2011

« Older Watch out, Carl Sagan, I'm coming for your job   |   How do I grow long hair, as a guy? Newer »
This thread is closed to new comments.