Over the past few decades, technological advances took our everyday life by a storm. As computers become smaller and cheaper to manufacture, we find ourselves increasingly dependent on software applications – even in the most unexpected life areas. This trend will continue – while new discoveries push the frontier of miniaturization, more branches of science will soon recognize and take advantage of this breakthrough approach.

As we approach the dawn of molecular and – ultimately – atomic engineering, information technology will support – and finally replace – other fields of science and industry as a cheaper, safer and more predictable alternative. From chemical payloads used in medicine to man-driven vehicles, IT can eliminate most dangers and uncertainties traditionally associated with these environments.

Until we can design and bring to life a truly critical-thinking A.I., the burden of controlling all of these computers remains on us. This relatively sudden and ever-growing demand for computer engineers is what makes modern IT management a challenging task. There are three major concerns related to this field which can be analyzed on grounds of psychology.

Understaffing

The most obvious consequence of abovementioned rapid developments is a global understaffing of IT departments. Despite many educational institutions trying to catch up with the demand, high quality software engineers are scarce. This leads to programming positions being advertised constantly by both the private and public sector entities. Sometimes even governments get involved: in an attempt to attract more talent, Canada (understaffed by 185,000 in 2019) implemented a dedicated fast-tracked immigration program aimed at engineers (Faisal, 2015).

Unfortunately, the low barrier of entry makes most IT departments very unstable work environments. With many candidates overestimating their skills, the career ladders have been extended and majority of staff finds themselves stuck at the bottom for much longer than they originally anticipated.

American Psychological Association describes a sense of powerlessness as “a universal cause of job stress” (Miller, 1994). In order to prove one’s worth in modern IT, they might have to spend years submerged in the most mundane of tasks, as many businesses still consider everything from fixing their printers to managing their networks of thousands of desktops to be “computers department”. This elevates the stress levels of junior staff, unable to show their true value for extended period of time.
Once an engineer prospect finally manages to get a promotion, he or she faces another challenge. Most enterprise IT revolves around large scale projects, where efforts of an individual are hardly ever visible, let alone recognized and appraised. In fact, there is a whole family of tools designed to automatically evaluate and – if needed – reject one’s work if it’s deemed unworthy of being implemented in a final product. These practices, known as Continuous Integration (CI), are commonly used among the industry. Despite their great value as quality assurance tools, they tend to leave beginner developers alone with their mistakes, providing no feedback except for an emotionless rejection messages when they try to submit their work.

This beginner phase of a software developer career is exceptionally prone to the burnout effect. By feeling that “whatever they are doing makes no difference at all” (Corey, 1996), these employees are at risk of assuming they are simply not qualified for the job, which leads to them giving up hope and further decrease of their work quality. Their behavior possesses all the traits described two decades ago by Gerald Corey in Theory and Practice of Counseling and Psychotherapy (1996). It is a serious challenge for the management to fight burnout, because the sheer volume of incidents in a CI environment makes it impossible to review every submission manually.

At the same time, the anonymity and automation of the rejection process does work in favor of those responsible for terminating work contracts. It provides them with a virtual authority figure (“the system”, “the numbers”), which makes the ultimate decision, delivered onto their desks to execute.

Lengthy career paths are not the only source of burnout. Due to the nature of modern computer systems, everyday workflows of a typical programmer involve much more third party integrations than most education programs recognize in their syllabuses. These integrations tend to be repetitive, time consuming and appear tenuous, as they do not spark a lot of creative work. As Christopher Fry points out, “no less dangerous than repetitive strain injury of the hand is [the one] of the brain” (Fry, 2001).

While computer systems evolve and learn to converse using unified languages, we hope to see most of these integration issues go away.

Group Think

The second challenge a modern IT management needs to face is the complexity of decision-making process in software development. It is primarily caused by the abundance of frameworks available in the market and the unconventional structures of social groups formed by employees in this sector.

Few industries undergo as rapid and dynamic changes as the IT, and software development leads in this trend. New tools, ideas and concepts surface every month and it is virtually impossible for one person to keep up to date with all these emerging innovations. A natural result is stratification of technologies into functional groups, followed by similar divisions between the developers.

This brings us to another archetypal feature of the IT industry: a frequent formation of opposing “camps”. They are usually organized by supporters of two (or more) technologies providing similar or overlapping features. Post forming, the camps display traits of rivaling groups almost identical to results of The Robbers Cave Experiment. The hostility is usually unjustified, as the products supported by each camp might not even be in direct competition against each other. And yet, as it happened in Muzafer Sherif’s research from almost seven decades ago, the groups show “in word and deed, repeated hostility toward one another, […] unflattering attitudes and stereotypes” (Sherif, 1998).

Some of these conflicts break the otherwise solid walls of IT societies and gain recognition in general population. Others remain subjects of heated debates within the community itself. They usually carry the power to polarize views and present a serious issue for the IT management, due to their tendency to turn otherwise reasonable professionals into blind followers. This phenomenon of “fanboyism” is very prominent across the software developers’ population and does affect their overall credibility.

Still, as an exact science, IT provides a concept of generally recognized truth, which can help take advantage of otherwise unwanted psychological effects. For instance: group polarization at the end of brain storming session usually represents an objectively good solution. A further analysis of the subject usually leads to reinforcement of views, backed up by facts rather than personal opinions.

Because most theories can be quickly verified either by experiments or looking up relevant data online, individuals with break-through concepts can be rewarded for their discoveries rather than ostracized and forced into conformity. Herd mentality is generally frowned upon inside the community.

Another fact that adds to complexity of decision-making is the distributed structure of many IT departments. Software development can be provided as a remote service and in many cases, it is: companies move their R&D centers overseas to reduce costs or even sign up individual contractors to work from remote locations. Oftentimes the result is a network of engineers who never meet each other and hardly ever hold live discussions, but at the same time share the responsibility over a single project.

The unique characteristic of software development compared to other group tasks is based on its extreme modularity. Existing trends in the Silicon Valley revolve around micro services, which divide large and complex paradigms into simple components and then provide a communication bus to facilitate a dialogue between them. As long as a single block conforms to these communication protocols, it can be designed and developed in a complete isolation from other elements.

While this approach promotes individual creativity and helps keep the industry up to date with recent discoveries, it does limit interactions between developers to an absolute minimum. To a bystander, an IT structure in a modern enterprise might appear disorganized and chaotic, while at the same time being vulnerable to typical threats of group decision making.

Charlan Jeanne Nemeth in her Psychological Basis of Quality Decision Making brings up a tragic example of The Challenger, when a chief engineer responsible for the faulty part was asked to “take off his engineering hat and put on his management cap” (2012). The danger of group thinking and tendency to read the majority’s vote as sign of a right decision is elevated when the actual responsibility and expertise is split between individual segments of code.

Indecisiveness, which in exact sciences usually indicates missing information, tends to be thwarted by community interactions, providing a false sense of security on what should be treated as red flags. Andrea Patalano and Zachary LeClair found in their study, that “individuals working in groups were, on average, about as confident in their choices as the most highly decisive individuals working alone” (Patalano, 2011). This is not a desired outcome when a group is effectively a collection of particulars with experience limited to their own field of expertise.

Apart from the most spectacular disasters like the Iranian nuclear centrifuges infected with Stuxnet, the vast majority of IT fiascos are direct results of negligence. From a potential attacker point of view, the software modules he targets are exposed as standalone units. When chosen as a target for exploitation, even the smallest part of code must withstand the trial on its own. Sadly, if it does get breached, its author is usually singled out as the only person to blame. If we look at the most recent incidents of data leaks, such as Hillary Clinton email scandal or Panama Papers, it turns out all it takes is one person failing to secure a single building block of software for the whole setup to be left exposed.

It is in the hands of IT executives to balance between the over-confidence and self-criticism of their subordinates, as excessive levels of either could seriously affect the final product.

The IT Archetype

Finally, the third obstacle which does affect large-scale software development in both positive and negative ways is the common perception – a schema – of IT professionals.

It is generally recognized that engineering staff does tend to follow their own rules of social interactions. This idea, usually over-emphasized in numerous cinema blockbusters, has recently become a central point for critically acclaimed TV shows, like The IT Crowd or The Big Bang Theory.

Outside Hollywood studios, a successful software developer can be perceived as an avant-garde individual with somewhat limited appreciation for social norms. The main reason behind this is a projection of the anti-conformist attitude (very prevalent in IT communities and one of the driving forces behind its galloping growth) onto their everyday affairs.

Consequently, the traditional model, where executives are put in charge purely because of their management skills, does not work well in software development. Supervisors lacking a deep insight and knowledge of their peers’ tools will not gain respect and recognition required to perform their tasks effectively. The IT managers are commonly required to facilitate communication with external departments, which in turn interact with customers and end users. It has been extremely rare for system developers to participate in such dialogues, which only reinforced the rationale of them being isolated from usual business interactions in an enterprise.

This confined nature of IT communities sets a stage for their unanimity when dealing with the “outsiders”. Some of the most powerful hacking groups in the industry prevailed for years unified only by a common goal, despite absence of other factors that produce liking, such as: similarity, proximity, familiarity and ownership (Heider, 1958). In many cases communication between their members is entirely anonymous, even pseudonyms are removed to substitute any sense of individual identity with a common goal.

Similar, but less extreme configurations are customary in IT departments. It is not uncommon for a single software project to be built by engineers from multiple continents and time zones, who communicate with each other almost exclusively using the dedicated development tools. Despite being deprived of many factors of interpersonal interactions such as real-time dialogue, recognizing facial expressions of their peers and proximity of the work place, professional IT communities expand on sense of belonging and shared views of the environment and people outside the community. Skilled managers can recognize this trend and take advantage of it by arranging engineers in groups so that they provide support to each other (most notably: programming in pairs and task forces).

The concept of software developers (and most engineers in general) being noticeably different from other society members is yet another view popularized by mainstream entertainment. The stereotype has been reinforced for years and now passes as something natural: for instance, it is generally expected for IT professionals not to follow the dress code of a corporation and to socialize mostly between each other. This isolation of IT personnel is a self-powering engine, where initial segregation leads to a growing communication gap between developers and other employees and/or customers, who use their software in everyday work.

Traditionally, team leaders acted as spokesmen for the software divisions, gathering feedback and providing support to end users. This is only recently shifting into more open approach, where technicians are given opportunities to interact directly with users of their product. The reason behind this change is not just increased productivity and shorter development cycles – IT work is constantly gaining more recognition as a driving force of modern business and science, which leads to increased social popularity of the individuals involved in this trade. Classic traits of a typical programmer: “laziness, impatience and hubris” (Bentley, 2006) are now recognized as virtues that spark innovation and creativity, rather than signs of being socially inept.

Conclusion

In conclusion, I would like to point out a unique situation that modern IT executives usually find themselves in. On one hand, the high dynamic of changes and still prevalent social stigma associated with archetypes of software engineers make it challenging to develop stable management patterns, which would guarantee results in most of the scenarios. On the other hand, understanding of psychological factors at play can help not only to recognize obstacles, but also use them to improve efficiency and satisfaction of the IT workforce.

References

Bentley, J. E, (2006). Personality Traits of a Great Programmer. Charlotte, NC: Wachovia Bank Publishing

Charlan Jeanne Nemeth. (2012). The Psychological Basis of Quality Decision Making. IRLE Working Paper No. 128-12. Berkeley University of California

Corey, G. (1996), Theory and Practice of Counseling and Psychotherapy. Boston, MA: Cengage Learning

Faisal, S. (2015), Labour Market Outlook 2015-2019. The Information and Communications Technology council, Canada

Fry, C. (2001), Programming on an Already Full Brain. Retrieved from MIT website http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Already-Full/Already-Full.html

Heider, F. 1958. The Psychology of Interpersonal Relations. NY: Wiley.
Miller, L. H., & Smith A. D (1994), The Stress Solution. New York, NY: Pocket Books

Patalano, A. L., & LeClair, Z. (2011). The influence of group decision making on indecisiveness. Judgement and Decision Making, 6, 163-175

Sherif, M. & Harvey, O. J. & Hood, W. R. & Sherif, C. W. & White, J.(1988). The Robbers Cave Experiment: Intergroup Conflict and Cooperation. [Orig. pub. as Intergroup Conflict and Group Relations]. Middletown: Wesleyan University Press.