The Business Analyst as Therapist

One of the common roles in which a business analyst is cast is that of the go-between. This go-between may be disguised as a bridge (between the business community and the IT project team), a translator (to decipher the business and technical jargon both sides tend to throw at each other), or a referee (whistle and flag optional). 

Blaming the traditional lack of communication between the “nerds” and the “suits” on jargon or lack of understanding ignores some basic cognitive differences between the two groups.

Developers who are untrained in psychology or cognitive behavior often miss the psychological factor in their relationships with the business community. That is why the intervention of a business analyst is helpful, if not necessary, to connect the two. It isn’t really in the terminology that each “side” uses, which is the basis for management depicting a business analyst as a “translator.” Learning different terms for things is not difficult if a person wants to do it. For example, I think it’s important for developers to take the time to learn the business they are writing software for. However, there are some who disdain the business and anything else that is not rationally based on a binary system of evaluation. 

Even if the developers learn business-speak, as should be the case in agile, according to the adherents, there is still the issue of understanding cognitive biases, emotional influences and irrational human behavior. Simply, people do not always decide or act rationally. Their actions and reactions are governed as much by emotion as by reason. Daniel Kahneman, a Nobel Prize winner, calls this fast and slow thinking. Fast thinking is our default, knee-jerk, emotional reaction, and it is governed by the amygdala. Meanwhile, slow thinking is the rational, reasonable thinking that takes place in the frontal cortex. 

Those who spend their careers, and in some cases lives, dealing with the absolute rationality of digital bits and unemotional computers (I am one of those) may not be able to make the leap into irrational human thinking. Computers don’t provide physical cues as to their thinking, so a technologist may not pick up the true meaning in something that’s said that anyone else would understand inherently. The developer is just looking to find out what is necessary to write code. The rest is noise. And there is nothing wrong with that. The issue is that business people do not think or operate at that level. Business people deal in ambiguities and feelings, and are not used to reducing things into binary equivalents. Business people like “may” and “depends” and abstracts while a technologist prefers “must” and “only” and concretes. It is more than just the language. It is really about the concepts, ambiguities, relationships and psychology.

When dealing with the dissonance between the user community and the IT solution team, a business analyst has to be well aware of psychological differences and not blindly focus on the facts. For example, business stakeholders may have a number of unstated expectations about the solution that live on throughout the project and only surface near the end when they see the final product in operation. That is when you hear “Well, this meets the requirements, but it is not what I want.” The developers have issues with this reaction, as well they should. When business stakeholders are broached with the question, “Why didn’t you tell us about this?” the stakeholders respond, “You didn’t ask!” Extracting these unstated expectations from the stakeholders’ heads requires skills usually possessed by psychologists, namely careful and complete elicitation, empathy, understanding and listening. 

Business analysts need to have at least a bit of psychologist in their approach to do their job successfully.

The idea of business analyst as psychologist is not far-fetched. Sometimes as a business analyst, you spend a lot of your time just listening, much like a psychiatrist, to complaints, gripes, fears of impending change, protests against impending change, fantasies about how the work should flow or the system should operate, as well as business workers’ problems with IT folks and IT folks’ problems with “stupid users.” There are also problems with managers, management, vendors, off-shore teams and probably co-workers. It is easy for both the BA and the person talking to get a sense of a therapy session. The business analyst is someone who is outside the responder’s business area and who comes in with the express purpose of making a change. And of course psychologists and therapists are all about making changes in a patient. Even though the business analyst is making a change to the organization, that change may affect the responder. Since the business analyst possesses the skills of elicitation, empathy and listening, the responder may open up about more than their idea for a new screen design.

There is also much psychology involved in negotiation, mediation and applying influence, all of which business analysts generally do in the normal course of their work. Each of these communication practices requires the ability to get to the real intent behind the positions, and to identify hidden agendas and deal with them effectively. The intent is often driven by emotional or psychological motives rather than rational business factors. And this is where the business analyst needs to understand human motivation, cognitive biases and emotional stances.

A psychologist or therapist might make a good business analyst, but considering the vast differences in pay scale, perhaps I should say the good business analyst might make a good psychologist or therapist.

Don’t forget to leave your comments below.