Published on

Why Successful Technical Programmes Need Emotional Intelligence

Authors

Doing a recent course on Emotional Intelligence made me reflect on how it could relate to technical projects and teams.

Typically my approach has been often to focus on the implementation, try to make the right decisions, deliver incrementally, and hope that things fall into place over time.

However working as a Systems Architect, where you are not directly responsible for a build, particularly in mixed delivery environments, the technical side is often only half the battle. The harder part is often aligning people, managing expectations, and navigating different perspectives across teams.

That’s where it could be useful to consider Emotional Intelligence.

Research consistently shows that emotional intelligence is a stronger predictor of leadership effectiveness than technical ability alone (Goleman, 1995).

Goleman’s Emotional Intelligence in Technical Leadership

Daniel Goleman (1995) breaks emotional intelligence down into four core areas:

  • Self-awareness
  • Self-regulation
  • Social awareness (empathy)
  • Relationship management

The following image is taken from Positive Psychology, which has a great overview of different models.

Goleman's Model

In technical delivery, these show up more often than you’d expect.

For example:

  • Reacting to changing requirements mid-sprint
  • Dealing with pressure to deliver quickly vs resistance
  • Handling conflict between teams
  • Balancing technical priorities with stakeholder expectations
  • Managing competing interests from different groups of stakeholders
  • Responding effectively to different personalities within a team

Technical expertise defines the solution. Emotional intelligence often determines whether it actually gets delivered.

Agile Delivery and Emotional Intelligence

Agile is built around collaboration, feedback, and iteration. On paper, that should make delivery smoother.

In reality, a lot of the friction isn’t technical. It comes from:

  • Different stakeholder priorities
  • Tension between delivery speed and governance
  • Gaps in communication between teams

I’ve seen this personally when working on common platforms (e.g. Microsoft Fabric), which naturally affects a diverse range of stakeholders both technical and non-technical.

Looking at that through Goleman’s model:

  • Self-awareness – Recognising when delivery pressure is shaping your behaviour
  • Self-regulation – Managing frustration when things don’t move as quickly as expected
  • Empathy – Understanding perspectives through prioritisation
  • Relationship management – Aligning people rather than pushing solutions

A lot of what looks like a technical blocker is often something else.

When It Goes Wrong: Healthcare.gov

A well-known example of a failed software delivery is the launch of Healthcare.gov in 2013.

Despite significant investment and technical capability, the system failed at launch due to:

  • Poor coordination across teams
  • Lack of clear ownership
  • Communication breakdowns
  • Unrealistic expectations

There were technical issues, but many of the root causes weren’t technical.

From a Goleman perspective:

  • Limited self-awareness of delivery risk
  • Poor self-regulation under pressure
  • Lack of empathy for user impact
  • Weak relationship management across teams

It’s a good reminder that technical failure is often a symptom of something else.

Leading Without Authority

In architecture roles, leadership is rarely about direct authority. It’s more about influence.

That means:

  • Guiding decisions rather than making them
  • Aligning stakeholders with different priorities
  • Supporting teams without controlling them

This relies heavily on relationship management, one of Goleman’s core components.

Without it, even well-designed systems struggle to get delivered properly.

Balancing Delivery and Alignment

One of the consistent tensions in technical leadership is between:

  • Delivery (speed, outcomes)
  • Alignment (people, understanding, buy-in)

My natural tendency has been to prioritise delivery. But without applying emotional intelligence—particularly empathy and self-regulation—that can lead to:

  • Resistance
  • Misalignment
  • Rework later on

In most cases, spending a bit more time on alignment leads to better outcomes overall.

Key Takeaways

Goleman’s model is a useful way of thinking about technical leadership:

  • Self-awareness helps you recognise when pressure is affecting decisions
  • Self-regulation helps avoid reactive behaviour
  • Empathy improves how you understand stakeholders
  • Relationship management enables alignment across teams

Agile provides the framework, but emotional intelligence is what allows it to function properly.

Conclusion

Technical leadership is often seen as a combination of expertise and delivery capability.

In practice, success depends just as much on how people work together.

Emotional intelligence is what enables solutions to actually land.

References

  • Goleman, D. (1995). Emotional Intelligence: Why It Can Matter More Than IQ. Bantam Books.

  • Positive Psychology. (n.d.). Emotional Intelligence Frameworks. https://positivepsychology.com/emotional-intelligence-frameworks/

  • Scrum Alliance. (n.d.). The Scrum Guide. https://scrumguides.org/

  • U.S. Government Accountability Office. (2014). Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management. https://www.gao.gov/

  • McChrystal, S. (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio.