Seeing system dynamics in organizational change: 4) the best time to de-scale

This is the fourth article in the series of seeing system dynamics in organizational change. In this and next articles, we are going to look at one specific change in the large-scale product development organization: de-scale to scale. This means to simplify the organization to achieve agility, and this is the essence of LeSS too. One aspect is having fewer roles, as more roles lead to less responsible teams.

However, increasing number of roles is a downward spiral when an organization scales up. Among them, the major roles are managers and specialists. We will look at them separately.

More and more managers

The bee watchers in Dr. Seuss's book "Did I Ever Tell You How Lucky You Are?" are the best manifestation for more and more managers. They could indeed keep increasing forever.

Seeing system dynamics in organizational change - 4.1.jpg

This self-reinforcing nature is shown in the below dynamic.

Seeing system dynamics in organizational change - 4.2.jpg


B1-loop: Increase management control for better performance

When seeing a performance gap, we increase the number of managers to have more control, then, the actual performance goes up and the gap is reduced.

R1-loop: Management control decreases motivation thus performance

However, when we increase the management control, the intrinsic motivation from the people doing the real work decreases over time, thus, the actual performance goes down. In response to that, we have more managers and more control.

B1/R1-loops create the "fixes that backfire" system archetype. We are in the downward spiral of having more managers.

When organization scales up, it is even more natural to have more managers. Let's see the below dynamic.

Seeing system dynamics in organizational change - 4.3.jpg


B2-loop: Increase managers to reduce management load

When organization scales up, every manager has more people. The resulting higher management load decreases the actual performance. In response to that, we increase the number of managers, then, we have fewer people for one manager. This reduces the management load, then the actual performance goes up and the gap is reduced.

R2-loop: Managers create silos

When we have more managers, the silo effect gets stronger over time, which increases the management load. Then, the actual performance goes down. In response to that, we have more managers. This becomes self-reinforcing.

R3-loop: Managers hire people

When we have more managers, they tend to hire more people, so that the organization grows over time. Now we have more people for one manager, thus higher management load. Actual performance goes down, which calls for more managers. This becomes self-reinforcing too.

Both B2/R2-loops and B2/R3-loops create the "fixes that backfire" system archetype. We are in the downward spiral of having more people and more managers.

More and more specialists

When organization scales up, we have more specialists too. Let's see the below dynamic.

Seeing system dynamics in organizational change - 4.4.jpg

B3-loop: Split into many specialities to reduce required capability

When seeing a capability gap, we increase the number of specialities, leading to more specialists. This reduces the required capability, then the capability gap too.

B4-loop: Increase learning to improve actual capability

When seeing a capability gap, we increase the learning, thus our actual capability improves over time, leading to the reduced capability gap.

B3/B4-loops create the "eroding goals" system archetype. As there is more delay in B4-loop, B3-loop becomes dominant. We get more specialties and more specialists. See more from Over-specialization and waste of potential.

R4-loop: Specialists create people gap

When the specialists gotta work in their specialities, the varying requirements create people gap in different specialities over time. The people gap triggers the hiring or moving of the people into the organization, thus, growing the organization further. The bigger organization, the more specialities and the more specialists. This becomes self-reinforcing. See more from Why product development group ever grows.

We are in the downward spiral of having more people and more specialists.

The alternative path

De-scaling is to have fewer roles - fewer managers and fewer specialists. How is it possible to not have more managers and more specialists when we scale up the organization? Is there an alternative path?

Instead of having more managers, we:

  • design for self-organizing feature teams, so that teams take more responsibility in delivering the end-to-end customer value, and there is less load for managers;
  • increase management capability in teaching and coaching.

Instead of having more specialists, we:

  • design for generic product developers with multi-specialities, so that people adapt to varying requirements, and there is less people gap for the whole organization;
  • increase the effectiveness of cross-learning.

The downward spiral is one path, while de-scaling to scale is the other path. When is the best time to take the path of de-scaling? A client once asked me to help scale up their organization, so as to keep its agility. At the time, they were still small - around 20 people for product development, but they planned to scale up to 50-100 people. They were at the crossroads, and it was the best time for the change.

Yes! The best time to de-scale is when we are still in small scale and have few roles.

If we are already in large scale and have many roles, we shall face the bigger challenge to deal with existing roles, notably managers and specialists. That's the topic for next article.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai