Chapter 16: High-Performance Leadership and Management (Part III: Transformation)

Context

This chapter is a contributed case study by Steve Bell and Karen Whitley Bell, presenting what applying the book’s capabilities and practices looks like in practice — and what it can provide for innovative organizations.

The Nature of Transformation

Technology transformation is not a project with an end date. It’s a continuous journey of capability development. The key insight from the research:

You can’t buy or copy high performance. You must develop your own capabilities in ways that fit your particular context and goals.

This requires:

  • Sustained effort
  • Investment
  • Focus
  • Time

What High-Performance Leadership Looks Like

Creating the Conditions

High-performance leaders create conditions where:

  • Teams can experiment and learn continuously
  • Failure is treated as information, not cause for punishment
  • People are empowered to make decisions about their work
  • Technical excellence is valued and invested in

The Role of Leaders in Transformation

Leaders cannot do the technical work themselves, but they can:

  1. Remove organizational impediments — processes, structures, politics that prevent teams from working effectively
  2. Secure resources — budget, time, tools for teams to invest in capability improvement
  3. Provide air cover — protect teams from external pressure while transformation is underway
  4. Set direction and priorities — help teams focus on capabilities with highest leverage
  5. Model the behaviors — embody the generative culture they want to create

Transformational vs. Transactional Leadership in Practice

Transactional (what to avoid):

  • Managing by metrics without context
  • Rewarding individual output over system outcomes
  • Change management theater (CABs, excessive approvals)
  • Focusing on tools and technology without addressing culture

Transformational (what to cultivate):

  • Investing in team learning and development
  • Creating psychological safety to experiment
  • Aligning individual work to organizational mission
  • Building trust through consistent, transparent behavior

The ING Case Study Pattern (referenced in chapter)

Leading organizations that have achieved high performance typically follow a pattern:

  1. Start with a compelling vision grounded in business need
  2. Identify key capability gaps relative to the 24 capabilities in Appendix A
  3. Build cross-functional teams with full ownership end-to-end
  4. Implement CD foundations first (version control, CI, test automation)
  5. Invest in architecture to enable team independence
  6. Measure both delivery performance and employee satisfaction
  7. Create feedback loops at every level (technical and organizational)

The Never-Done Nature of Improvement

High performance is not a destination. The data shows:

  • What was “high performance” in 2014 was no longer high performance by 2017
  • The bar keeps rising as the best keep improving
  • Standing still = falling behind

This is why maturity models fail: they imply an endpoint. Capability models embrace continuous improvement as a permanent posture.

Starting Points for Transformation

If starting from a low-performance baseline, the research suggests these as highest-leverage interventions:

  1. Version control everything — app code, config, infrastructure scripts. Foundational to everything else.
  2. CI with trunk-based development — short-lived branches, automated build on commit. Reduces integration pain.
  3. Automated test suite (developer-owned) — reliable tests that run on every commit.
  4. Reduce batch sizes — smaller features, more frequent releases.
  5. Peer review instead of CABs — lighter change management that actually works.
  6. Make work visible — kanban boards, monitoring dashboards.
  7. Establish psychological safety — blameless postmortems, inquiry-based failure response.

The Reinforcing Nature of All 24 Capabilities

The capabilities are not independent checkboxes. They reinforce each other:

  • CD practices → generative culture → better decision-making → CD practices improve
  • Loosely coupled architecture → team autonomy → experimentation → better products
  • Learning culture → psychological safety → honest measurement → data-driven improvement

This is why transformation requires sustained effort — you’re building a self-reinforcing system, not installing a tool.