Organisational Change and Team Structures

All courses / Architecture as Code / Module 5 / Chapter 17

Learning objectives

After the lesson the participant can:

• Describe the four transformation stages by team structure, decision making and automation maturity.
• Explain how psychological safety and blameless retrospectives sustain cross-functional collaboration.
• Design a change approach that engages stakeholders as partners and uses pilots to build momentum.
• Select leading indicators that connect technical improvement to business and cultural outcomes.

Key concepts

Transformation stages

Four progressive stages: siloed functions with ticket handoffs, basic collaboration with shared goals but separate execution, cross-functional teams with collective ownership, and product-aligned teams that are autonomous within guardrails on self-service platforms.

Psychological safety

A condition in which teams can learn from incidents without blame. The chapter describes high-performing organisations as treating failures as tuition fees for valuable lessons, with senior leaders modelling vulnerability.

Decision rights with shared standards

The pairing that keeps autonomy and alignment in harmony: teams know which decisions are theirs, and shared standards keep their choices compatible.

Dual-ladder career structures

Career frameworks that recognise deep expertise and cross-disciplinary breadth so that people can advance without leaving technical tracks, alongside technical leadership programmes and rotation opportunities.

Leading indicators

Measures that teams can influence directly, such as deployment frequency, recovery time and developer satisfaction, preferred over lagging indicators that confirm success or failure only after the chance to correct has passed.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Teaching plan

Discussion

1. The chapter says resistance often signals legitimate concerns about job security, skill gaps or process disruption. Which concerns would you expect in your organisation, and how could they be addressed directly?
2. What do senior leaders have to do, visibly, before staff believe that an honest mistake will not be penalised?
3. Why does the chapter warn against promoting the best engineers into management roles, and what alternative does it offer?

Written exercise

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

1. How does the chapter's table characterise decision making in product-aligned teams?

   1. Handoffs through tickets and change requests
   2. Autonomous within guardrails
   3. Meetings and shared backlogs
   4. Approval by a central architecture board
   Show the answer

   B. Autonomous within guardrails
   Product-aligned teams, the fourth stage, are autonomous within guardrails, supported by self-service platforms and full automation. Tickets and shared backlogs describe the first two stages.

2. What dual purpose do pilot projects serve, according to the chapter?

   1. They reduce headcount and shorten procurement cycles
   2. They replace formal training and remove the need for sponsorship
   3. They test business-critical systems first and expose the teams with the weakest skills
   4. They prove feasibility and create reference stories for sceptical stakeholders
   Show the answer

   D. They prove feasibility and create reference stories for sceptical stakeholders
   Pilots prove technical feasibility while creating reference stories that persuade sceptical stakeholders; the chapter recommends low-risk, high-visibility use cases.

3. Which kind of indicator does the chapter's measurement guidance emphasise?

   1. Leading indicators that teams can influence directly
   2. Lagging indicators confirmed at programme end
   3. Activity counts such as the number of training sessions held
   4. Infrastructure metrics alone, without cultural measures
   Show the answer

   A. Leading indicators that teams can influence directly
   The framework emphasises leading indicators that teams can influence directly, and balances technical, business and cultural dimensions instead of focusing narrowly on infrastructure metrics.