Effective I-O Psychologist and Technologist Collaborations

How can technologists get along with I-O psychologists in the field? This is one of the most common questions I get when consulting. Typically, it starts with something like, “IO: Every time we ask for something to be changed, it seems like IT drags its feet and complains,” or alternatively, “IT: Every time the I-Os ask for something, it shows they don’t understand what they are asking for. At all.” Everyone gets frustrated and development projects seem to take triple the time they should.

So why does this happen?

The key is recognizing that psychologists have a very different base working model of the world than IT experts do. Because of their training, IT experts tend to think in terms of systems – there are inputs, processes, and outputs – and fixing problems means modifying those systems or designing new ones by changing either the data coming in, what’s done with it, or how it is presented.

Psychologists do not think this way. Psychologists instead tend to view systems as fixed entities. For example, few psychologists think of Excel as multiple layers of input, calculation, and data display/visualization subsystems working in tandem. To them, it’s just a “spreadsheet app.”

That ultimately means that psychologists typically do not really appreciate the complexities of system design or inter-system communication. My favorite example of this is in web design from my own experience – a non-systems-thinker (not an I-O in this case, but close enough) was using a web-based survey platform created by a company, but the thinker didn’t like where the logo was placed and asked it to be moved about an inch to the right.

The non-systems thinker did not at all understand why that was a huge and complicated request, yet it was. You see, under the hood, the display system had been built in such a way that the rest of the page was aligned to that image’s placement. You might ask, “Well why would they have done that?,” but as any IT person knows, the code you’ve got is the code you’ve got. Perhaps it should have been written differently the first time, but it’s far too late to change that now. At this point, a lot of things need to be reworked to get that image moved, and all that time is expensive.

To a person with an IT background, the risk of this happening is way more obvious. When another IT person asks, “Can you move the image?,” what they are really asking is, “Do you know if the system has been created in such a way that moving that image will be a small or large project?” To your average I-O psychologist, the website is a static object – just push the image over, what’s the big deal?

This sort of difference in perspective also works the other way. Psychologists tend to conceptualize humans as hugely complicated input-process-output machines but often don’t interconnect those systems. For example, a classic psychological principle is the “mere exposure effect” which describes how familiarity with something generally leads to a preference toward that thing. For example, if you purchase a clock and your roommate/significant other doesn’t particularly like that clock, over time, after seeing it every day, they will like the clock more.

A classic study on mere exposure was about people; it found that the people living at the bottom of the stairwell in an apartment building tended to have more friends in the building than anyone else. They attributed to this to the fact that more people literally passed in front of their door and thus had greater opportunity to say hello. More hellos = more exposure = more friends. The mere exposure effect.

This sort of “fact” about human nature, plus hundreds or thousands of other such facts, form a sort of catalog of effects in a psychologist’s mind: “if you do this to a person, they will be more likely to do that” or “people like this tend to behave that way.”

Some of these “rules” are very specific, which a lot of IT folks don’t really appreciate. So they will just slap together some requested software prototype, assuming it’ll be worked out in testing, making a bunch of little decisions that they see as unimportant, and the psychologists will have a myriad of seemingly random requests, some of which are much more difficult to change than others.

I have found that this sort of misalignment is at the core of problems in IT-psychologist cross-functional teams. The best way to address it is training.

The IT folks need to learn that humans are very complicated and to consult the psychologists on anything human-related in the systems they are building, down to pretty fine details. You need to anticipate the sort of things psychologists might request and build flexibility in assuming they will want changes later. Don’t build to spec; build to possibility (this is also at the core of agile development, but you need to be more careful about it here).

The psychologists need to learn that the systems they are messing with are very complicated and to assume that any small change they request is likely hugely more complex under the hood. Don’t become frustrated when things you think are small can’t be changed; instead, look for workarounds, keep an open mind, and remember that two technical requests with the same outcome are still different requests. “Move the image 1 inch to the right” is a different request from “Add 1 inch of whitespace to the left of the image so that it looks like the image is 1 inch to the right.” One is much easier than the other.

If you work on a tech-IO cross-functional team, someone needs the expertise to identify these sorts of translation issues when they come up. Otherwise, partnerships become dysfunctional. Everyone gets frustrated, assuming the other side is purposefully being difficult.

So, the takeaway? If you are developing technology and I-Os are involved, get an I-O with some IT expertise, an IT expert with some I-O expertise, or preferably, (at least) one of each!