The Human Factor: Why Psychology is Tech’s Most Undervalued Discipline

You’re the Mark Your Software Requirements Are Worthless

The Human Factor: Why Psychology is Tech’s Most Undervalued Discipline

From cognitive biases to team dynamics, the psychological insights that could revolutionise how we build products, manage teams, run businesses and drive innovation

Silicon Valley has conquered machine learning, perfected continuous deployment, and built systems that serve billions. Yet for all its technical mastery, the tech industry repeatedly fails at something far more fundamental: understanding people.

The evidence is overwhelming. Digital transformations fail at rates between 70-95%, with an average failure rate of 87.5% (Bonnet, 2022). Software projects consistently run over budget and behind schedule, wasting £millions. Developer burnout has reached epidemic proportions. User adoption of new features remains stubbornly low despite e.g. sophisticated A/B testing.

The common thread? These aren’t technical failures—they’re human failures. Failures of communication, motivation, decision-making, relationships, and understanding what actually drives behaviour.

The Industry’s Psychological Blind Spot

Walk through any tech office and you’ll witness a fascinating paradox. Engineers who can optimise algorithms to microsecond precision struggle to understand why their perfectly logical user interface confuses customers. Engineering gurus who architect fault-tolerant distributed systems can’t figure out why their teams are demotivated. Product managers who obsess over conversion metrics completely miss the emotional journey that determines whether users actually adopt their features.

This isn’t incompetence—it’s a systematic blind spot. Technical education trains us to think in features, algorithms, and deterministic outcomes. We learn to eliminate variables, optimise for efficiency, and build predictable solutions. But humans are gloriously, frustratingly unpredictable.

The blind spot runs deeper than individual ignorance. There’s a cultural disdain for anything psychology-related (interesting in itself from a psychology perspective). Mention “team dynamics” in a planning meeting and watch the eye-rolls. Suggest that cognitive biases might be affecting architectural decisions and you’ll be dismissed as pushing tree-hugging, woke “soft skills” nonsense. The tech industry has convinced itself that psychology is touchy-feely therapy speak, irrelevant to the serious business of building software and running businesses.

This dismissal comes at a massive cost. When we ignore psychology, we build products that solve the wrong problems, create team environments that burn out our best people, and make flawed decisions based on biases we don’t even recognise.

The Data-Driven Case for Psychology

Ironically, one of history’s most influential systems thinkers understood psychology’s business value perfectly. W. Edwards Deming—the statistician whose principles revolutionised manufacturing quality and helped rebuild Japan’s post-war economy—made psychology one of the four pillars of his “System of Profound Knowledge”. And from his persepctive, the most important of the four.

Deming didn’t treat psychology as a nice-to-have add-on. He argued that managers must understand human nature, motivation, and behaviour to build effective ways of working. His famous insight that 94% of quality problems stem from systems and management—not worker incompetence—was fundamentally psychological. Yet tech management, which claims to worship data-driven decision making, has ignored these insights from one of the most successful data-driven thinkers in history.

Modern research backs up Deming’s intuition. Studies consistently show that psychological factors are among the strongest predictors of software project success:

Research on agile development teams found that human-related factors—quality of relationships, team capability, customer involvement, and team dynamics—are the critical success factors, far outweighing technical considerations (Barros et al., 2024).

Studies of developer performance demonstrate that emotional states directly impact problem-solving abilities, with “happy developers” significantly outperforming their stressed counterparts on analytical tasks (Graziotin et al., 2014).

Analysis of team effectiveness reveals that personality traits and interpersonal dynamics have measurable impacts on code quality, delivery timelines, and innovation rates (Acuña et al., 2017).

The data is clear: psychology isn’t optional. It’s a core competency that determines whether technical brilliance translates into business success.

The Psychology Toolkit for Tech

Psychology isn’t a monolithic field—it’s a rich ecosystem of frameworks and insights that can transform how we approach technical challenges. Let’s explore just a few of the most powerful tools.

Cognitive Biases: The Bugs in Human Reasoning

Just as we debug code, we need to debug our thinking. Cognitive biases are systematic errors in reasoning that affect every decision we make, including the technical ones:

Confirmation Bias leads engineers to seek information that supports their preferred solution whilst ignoring alternatives. That’s why teams often stick with familiar technologies even when better options exist.

Sunk Cost Fallacy keeps teams investing in failing projects because of previous effort. We’ve all seen projects that should have been killed months ago but continued because “we’ve already invested so much.”

Planning Fallacy explains why developers consistently underestimate task complexity. It’s not laziness—it’s a predictable cognitive bias that affects every developer (and managers, too).

Availability Heuristic makes recent incidents seem more likely than they actually are, leading to over-engineering for problems that rarely occur. Aka Gold plating.

Understanding these biases doesn’t eliminate them, but it enables us to build processes that account for them. Code reviews help catch confirmation bias. Time-boxed experiments limit sunk cost fallacy. Historical data counteracts planning fallacy.

User Psychology: Beyond A/B Testing

Most product teams approach users like they approach code—looking for deterministic patterns and optimal solutions. But users don’t behave logically; they behave psychologically.

Loss Aversion: People feel losses more acutely than equivalent gains. This affects everything from pricing strategies to feature adoption. Users will stick with inferior solutions rather than risk losing what they already have.

Mental Models: Users approach new interfaces with existing expectations. Fighting these mental models creates friction; aligning with them creates intuitive experiences.

Choice Overload: Contrary to Silicon Valley dogma, more options don’t always create better outcomes. Too many choices can paralyse users and reduce satisfaction even when they do choose.

Social Proof: People follow what others do, especially in uncertain situations. This is why testimonials, usage statistics, and “trending” indicators can dramatically impact adoption.

Motivation Theory: What Actually Drives Performance

The tech industry’s approach to motivation is remarkably naive: pay people well, give them interesting problems, and assume they’ll perform. But decades of research reveal motivation is far more complex.

Self-Determination Theory identifies three psychological needs that drive intrinsic motivation:

Autonomy: People need control over their work. Micromanagement destroys motivation even when well-intentioned. The most productive developers choose their own tools, approaches, and priorities within clear constraints.

Competence: People need to feel effective and capable. This means providing appropriate challenges, learning opportunities, and recognition for growth. Boredom and overwhelm both kill motivation.

Relatedness: Humans need connection and shared purpose. Remote work and competitive environments can undermine this need, leading to disengagement even when technical work is satisfying.

Companies that design roles around these three needs see higher productivity, lower turnover, and more innovation. Companies that ignore them burn through talent despite offering competitive salaries.

Eric Berne’s Transactional Analysis: A Framework for Management

Among psychology’s many insights, one framework stands out for its practical application to management challenges: Eric Berne’s Transactional Analysis (TA).

Developed in the 1950s, TA provides a simple but powerful model for understanding interpersonal dynamics. Berne identified three “ego states” that everyone operates from:

Parent: The inherited voices of authority figures. When we’re in Parent mode, we’re either nurturing (“Let me help you”) or criticising (“You’re doing it wrong”).

Adult: Rational, present-moment thinking. This is where we process information objectively and respond appropriately to current situations.

Child: Our emotional, spontaneous, creative self. This includes both our playful, innovative side and our adapted, compliant side.

Every conversation involves transactions between these ego states. Understanding these patterns can transform management, team and group effectiveness, particularly in the fraught dynamics between management and workers.

TA in Action: Management vs WorkersThe Micromanaging Manager

Situation: Sarah, an engineering manager, constantly checks on her senior developers, questions their technical decisions, and demands detailed status reports. Team productivity plummets and two experienced engineers start looking elsewhere.

Traditional Analysis: “Sarah needs to trust her team more. The developers are being defensive.”

TA Analysis: Sarah operates from Criticising Parent (“I need to oversee everything”), which triggers her developers’ Rebellious Child (“Stop treating us like incompetent children”). The developers’ Adult expertise gets bypassed entirely.

Solution: Sarah shifts to Adult state: “What obstacles are blocking your progress? How can I help remove them?” This invites Adult-to-Adult collaboration rather than Parent-to-Child control and confrontation.

The Blame-First Post-Mortem

Situation: After a production incident, CTO Mark runs a post-mortem focused on “who made the mistake.” Junior developer Jenny, who deployed the problematic code, sits silently while Mark questions her testing procedures. The team leaves feeling demoralised rather than enlightened.

TA Analysis: Mark operates from Criticising Parent (“Someone needs to be held accountable”), triggering Jenny’s Adapted Child (shame and withdrawal). Other team members also shift to Child state, afraid they’ll be next.

Solution: Mark engages Adult state: “Let’s understand what systemic issues allowed this to reach production. How do we improve our processes?” This frames the incident as a learning opportunity rather than a blame assignment.

The Innovation Killer

Situation: Technical architect David consistently rejects new ideas from his team with responses like “That’s not how we do things” or “That technology is too risky.” The team stops proposing improvements and settles into maintenance mode.

TA Analysis: David operates from Criticising Parent, prioritising control over innovation. His team’s Natural Child (creativity and enthusiasm) gets suppressed, and they shift to Adapted Child—compliant but disengaged.

Solution: David engages Adult state when evaluating proposals: “Walk me through your thinking. What problems does this solve and what risks do we need to mitigate?” This validates creative thinking while maintaining appropriate oversight.

The Abdication Executive

Situation: VP of Engineering Lisa assigns a complex microservices migration with minimal guidance: “You’re smart people, figure it out.” Three months later, teams are building incompatible services and the project is behind schedule and over budget.

TA Analysis: Lisa operates from Free Child—enthusiastic but irresponsible, delegating without providing necessary structure. Her team is forced into Adapted Child, trying to guess her expectations while being set up for failure.

Solution: Lisa engages Adult state to provide context and constraints: “Here’s why we’re migrating, here are our business and technical constraints, and here’s how we’ll measure success. What approach do you recommend?” This treats her team as professional partners rather than subordinates.

Beyond TA: The Broader Psychology Toolkit

Transactional Analysis is just one tool in a comprehensive psychology toolkit. Other frameworks provide equally valuable insights:

Group Dynamics: Bruce Tuckman’s model of team development—forming, storming, norming, performing—explains why new teams struggle initially and how to accelerate their progression to high performance.

Change Psychology: Understanding why people resist change (loss of control, uncertainty, increased complexity) enables more effective technology adoption and organisational transformation.

Decision Science: Research on how people actually make decisions (versus how we think they should) can improve everything from user interface design to enterprise sales processes.

Behavioural Economics: Insights like anchoring effects, framing bias, and loss aversion can dramatically improve product design, pricing strategies, and user engagement.

The Business Case for Psychological Literacy

Understanding psychology isn’t about being nice—it’s about being effective especially in the domain of people. Companies that develop psychological literacy see measurable improvements:

Better Product-Market Fit: When you understand user psychology—their biases, emotions, and decision-making patterns—you can design experiences that truly resonate rather than just optimising random metrics.

Higher Team Performance: Research consistently shows that team dynamics, motivation, and emotional states directly impact code quality, innovation rates, and delivery speed.

More Effective Fellowship: Fellows who understand frameworks like TA, motivation theory, and cognitive biases make better decisions, communicate more effectively, and build higher-performing teams.

Improved Change Management: Understanding the psychology of change—why people resist it, how they adopt new behaviours, what motivates transformation—enables more successful technology adoptions and organisational changes.

Stronger Customer Relationships: Sales, support, and customer success teams become far more effective when they can recognise psychological patterns and respond appropriately.

Building Psychological Literacy

Developing psychological competence means building skills in several areas:

Pattern Recognition: Learning to identify psychological patterns in yourself and others—ego states in interactions, cognitive biases in decision-making, team dynamics that help or hinder performance.

Framework Fluency: Understanding proven models like TA, motivation theory, cognitive bias research, and team psychology. These aren’t abstract theories—they’re practical tools for solving real problems.

Emotional Intelligence: Developing the ability to recognise and work with emotions rather than pretending they don’t exist or dismissing them as irrelevant to technical work.

Systems Thinking: Recognising that human systems are as complex and important as technical systems. Team dynamics, user behaviour, and organisational culture follow patterns that can be understood and optimised.

Research Literacy: Understanding how to evaluate psychological research and apply evidence-based insights rather than relying on intuition or management fads.

This doesn’t require everyone to become psychologists. It means recognising that psychology offers evidence-based tools for solving the human problems that consistently derail technical projects.And one or two people on a team, with psychology skills, are distinct assets.

The Future Competitive Advantage

Your current tech stack will become obsolete. Your architecture will be rewritten. Your product features and products will be replaced. But organisations that master the human elements of the technology business will build lasting competitive advantages.

The companies that thrive in the next decade won’t just have better engineers—they’ll have better people smarts. They’ll understand what motivates their teams, what drives their customers, and what biases affect their decisions. They’ll build products that work for real humans rather than idealised users. They’ll create environments where people do their best work rather than burning out.

Psychology isn’t a “soft skill” addition to technical competence—it’s a force multiplier that makes everything else more effective. When you understand how people actually think, feel, and behave, you can design better experiences, create more effective teams, make better decisions, and build more successful organisations.

The tech industry’s next breakthrough won’t come from a new programming language or cloud service. It’ll come from finally bridging the gap between technical excellence and psychological mastery.

Because at the end of the day, all technology is about people. The sooner we start working with psychology in mind, the sooner we’ll build things that actually work for the beautifully complex humans who use them.

Bob Marshall's Blog

Bob Marshall's profile
55 followers