Software engineering leadership often swings between two extremes.
At one end sits the hard-nosed, data-driven manager who tracks every metric, every ticket, and every delivery milestone. At the other sits the people-first leader who focuses almost exclusively on morale, wellbeing, and team harmony.
The truth is that great software leadership lives somewhere in the sliding scale inbetween.
The most effective engineering managers understand that software development is both a production system and a human system. Ignore the production system and delivery suffers. Ignore the human system and delivery eventually suffers too.
The Seduction of Metrics
Modern engineering leaders have access to more data than ever before.
Tools can provide insights into:
- Lead time for changes
- Deployment frequency
- Change failure rate
- Recovery time from incidents
- Cycle time
- Pull request throughput
- Defect rates
- Customer satisfaction scores
The most influential set of engineering performance measures comes from the DevOps Research and Assessment (DORA) programme. DORA's research found that software delivery performance can be effectively assessed through measures such as deployment frequency, lead time for changes, change failure rate, and recovery time after failures. These metrics are associated with organisational performance and team wellbeing. [dora.dev], [about.gitlab.com]
Used correctly, metrics help answer important questions:
- Are we becoming faster or slower?
- Where are our bottlenecks?
- Are our quality controls effective?
- Can we predict delivery with confidence?
- Are process improvements actually working?
Metrics provide an objective lens through which to view a complex system.
The problem arises when leaders forget that metrics are indicators, not reality.
The Danger of Managing the Dashboard
Anyone who has led software teams for long enough has seen the dark side of measurement.
When deployment frequency becomes the target, teams may split work unnaturally to inflate numbers.
When story points become a performance metric, estimates mysteriously increase.
When individual productivity is measured using commits or pull requests, engineers optimise for activity rather than outcomes.
This is a classic example of Goodhart's Law:
When a measure becomes a target, it ceases to be a good measure.
The purpose of metrics is to create understanding, not judgement.
The healthiest engineering organisations treat metrics as conversation starters:
- "Why has lead time increased?"
- "What is causing defects?"
- "Why does this team have more incidents?"
- "What obstacles are slowing delivery?"
These questions focus on the system rather than the individual.
Software Development Is a Human Activity
While dashboards tell us what is happening, they rarely explain why.
A sudden drop in productivity might be caused by:
- Technical debt
- Unclear requirements
- Organisational change
- Burnout
- Personal challenges
- Team conflict
- Loss of psychological safety
No reporting tool can fully reveal these realities.
This is where the pastoral side of leadership becomes essential.
Pastoral care in software leadership does not mean avoiding accountability or lowering standards.
It means recognising that engineers are people before they are resources.
Good managers understand:
- Career aspirations
- Personal motivations
- Strengths and weaknesses
- Sources of stress
- Family pressures
- Professional frustrations
This knowledge provides context that numbers alone cannot.
Psychological Safety Matters More Than Most Metrics
One of the most important insights from organisational research came from Google's Project Aristotle.
After studying around 180 teams and examining hundreds of attributes, researchers found that the defining characteristic of successful teams was not seniority, intelligence, experience, or team composition. The strongest differentiator was psychological safety: the belief that team members can speak up, ask questions, share concerns, and admit mistakes without fear of humiliation or punishment. [rework.wit...google.com], [psychsafety.com], [leaderfactor.com]
This finding should make every engineering leader pause.
Because many delivery problems are actually communication problems:
- The engineer who knew the architecture was flawed but stayed silent.
- The tester who spotted a risk but felt unable to challenge a deadline.
- The new joiner who was afraid to admit they did not understand.
- The exhausted developer who continued working despite being close to burnout.
Psychological safety cannot be measured through deployment frequency.
It is built through trust, consistency, humility, and genuine care.
Why Managers Matter
Research consistently shows that managers have an outsized impact on team engagement.
Gallup's research has repeatedly found that managers account for approximately 70% of the variance in team engagement. Teams with engaged managers tend to demonstrate stronger performance, productivity, and wellbeing outcomes. [gallup.com], [gallup.com], [news.gallup.com]
This matters because engagement is not created by motivational speeches or free pizza.
It emerges when people feel:
- Valued
- Heard
- Supported
- Challenged appropriately
- Recognised
- Trusted
The engineering manager sits at the centre of these experiences.
A manager who merely reviews metrics can miss the warning signs entirely.
The Balanced Leadership Model
The best engineering leaders operate with what might be called dual awareness.
They simultaneously monitor:
System Health
Using objective measures such as:
- DORA metrics
- Quality indicators
- Customer outcomes
- Reliability measures
- Team throughput
Human Health
Using subjective but equally important observations:
- Morale
- Energy levels
- Stress indicators
- Psychological safety
- Team relationships
- Career development progress
Neither dimension alone is sufficient.
A team delivering rapidly while burning itself out is not healthy.
A team that is happy but cannot deliver customer value is not healthy either.
The goal is sustainable performance.
Practical Ways to Balance Both
1. Treat Metrics as Signals, Not Weapons
Never walk into a one-to-one armed with graphs intended to prove underperformance.
Instead ask:
"I noticed this trend. What are you seeing?"
Curiosity generates insight.
Judgement generates defensiveness.
2. Make One-to-Ones Sacred
The most important leadership tool is often the simplest.
Regular, uninterrupted conversations create opportunities to discuss:
- Ambitions
- Frustrations
- Blockers
- Learning goals
- Personal wellbeing
Many issues are spotted months before they appear in delivery metrics.
3. Reward Learning, Not Just Delivery
Teams grow stronger when people can admit mistakes.
Celebrate:
- Incident reviews
- Lessons learned
- Knowledge sharing
- Process improvements
Not just successful releases.
4. Watch for Invisible Contributors
Some of the most valuable engineers:
- Mentor others
- Defuse conflict
- Improve documentation
- Build relationships
- Increase team resilience
These contributions rarely appear on dashboards.
Good managers notice them anyway.
5. Build Slack Into the System
High-performing teams are not continuously operating at maximum utilisation.
Just as athletes require recovery time, engineering teams require space for:
- Learning
- Experimentation
- Refactoring
- Innovation
- Reflection
Relentless efficiency often destroys long-term effectiveness.
The Leader's Real Job
Ultimately, engineering management is not about maximising a metric.
It is about creating an environment where talented people can consistently do great work.
Metrics help us understand the health of the delivery system.
Pastoral care helps us understand the health of the people operating it.
Neither is optional.
When leaders focus exclusively on numbers, they risk treating humans like machines.
When leaders focus exclusively on feelings, they risk losing sight of outcomes.
The most successful software organisations recognise that excellence emerges when both perspectives are held simultaneously: rigorous measurement of performance alongside genuine care for the people delivering it.
That balance is not a compromise.
It is the essence of effective engineering leadership.
References
DORA. DORA's Software Delivery Performance Metrics. Available at: https://dora.dev/guides/dora-metrics/ [dora.dev]
GitLab. DORA Metrics: Software Delivery Performance Guide. Available at: https://about.gitlab.com/topics/devops/dora-metrics/ [about.gitlab.com]
Google re:Work. Understand Team Effectiveness (Project Aristotle). Available at: https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness [rework.wit...google.com]
Poyton, B. Google's Project Aristotle. Psychological Safety. Available at: https://psychsafety.com/googles-project-aristotle/ [psychsafety.com]
Gallup. How Leaders Can Improve Employee Engagement and Company Culture? Available at: https://www.gallup.com/workplace/712895/leaders-improve-employee-engagement-company-culture.aspx [gallup.com]
Gallup. How Managers Impact Team Productivity. Available at: https://www.gallup.com/workplace/713033/managers-and-team-productivity.aspx [gallup.com]
Beck, R., & Harter, J. Managers Account for 70% of Variance in Employee Engagement. Gallup Business Journal, 2015. Available at: https://news.gallup.com/businessjournal/182792/managers-account-variance-employee-engagement.aspx [news.gallup.com]
No comments:
Post a Comment