Seeing system dynamics in organizational change: 6) the scope of structural change

This is the sixth article in the series of seeing system dynamics in organizational change. We shall examine the topic of structural change in this and next articles. We first look at the scope of structural change - how big structural change is appropriate, and what factors and dynamics are involved in the choice.

Structure is a first-order factor

I have referred to Richard Hackman's work on how structure and coaching jointly affect team performance in various articles, e.g. Team-first or Organization-first, Huawei - LeSS without Scrum. I do not repeat his diagram here, but present it as a "limits to growth" dynamic.

Seeing system dynamics in organizational change - 6.1.jpg

R1-loop: Coaching for performance

We improve the coaching effectiveness, which improves organizational performance. Then, we further improve coaching. We expect to create a virtuous cycle.

B1-loop: Structure limits performance

The current structure becomes a limit, as it is inconsistent with the goal. Once the organizational performance is high, the structural change is small. This keeps the structural consistency low, which eventually limits the growth of the organizational performance.

The leverage in "limits to growth" system dynamic is to break the balancing loop, preferably in early time. This means to work on the structural change from early on.

Then, how big structural change is appropriate?

The scope of structural change

Let's first understand the scope of structural change and look at it as a continuum.

Seeing system dynamics in organizational change - 6.2.jpg
  1. No structural change. In traditional project setting, the group is formed virtually and temporarily. There is essentially no structural change.
  2. Structural change for one team. This one team is formed permanently, and the reporting line is changed accordingly; while the other teams remain in the old structure. There exist parallel organizations - one part in old structure and the other part in new structure.
  3. Structural change for all teams. All teams are formed at once, and the whole organization is in new structure.
Seeing system dynamics in organizational change - 6.3.jpg

Once the organization is huge, consisting of many teams in many areas, we may take intermediate step and change the structure for multiple teams - more than one team but fewer than all teams. This could mean structural change for (3a) all teams in one area, or (3b) one team in all areas. We could still change all teams in all areas at once, as shown in (4).

In summary, we could define the scope of structural change as a variable, from (1) smallest to (4) biggest.

  1. No structural change
  2. Structural change for one team
  3. Structural change for multiple teams
  4. Structural change for all teams

Structural consistency vs. stability

Suppose that the current structure is not consistent with our change goal, we need to increase the consistency in order to succeed the change.

Seeing system dynamics in organizational change - 6.4.jpg

B1-loop: Structural change for consistency

As structure limits organizational performance, we make more structural change, which brings the structure more consistent with the goal. As a result, the organizational performance improves.

B2-loop: Structural change breaks stability

The more structural change, the less structural stability, the more resistance to reduce the structural change.

This is particularly true when the structural change involves the dissolution of existing roles. It poses a threat to the psychological safety. This is why it is so important to ensure job safety but not role safety, as described in the article of "job safety but not role safety".

The structural consistency is the system goal here, while the structural stability is the secondary concern. We make structural change to optimize for the consistency, while address the stability concern in other ways.

Structural change scope vs. period

The scope of structural change affects change period too, i.e. how long the whole change will take. Think about a 20-team organization. If you make structural change for one team at a time, the scope of each change is small; but the change period is long. If you make structural change for all teams at once, the scope is big; but the period is short.

Seeing system dynamics in organizational change - 6.5.jpg

B3-loop: Small change scope to reduce risk

When we perceive the high change risk, our anxiety increases. This leads us to make smaller structural change. Smaller change scope is less complex, thus, its risk becomes lower.

R2-loop: The complexity from long change period

While making smaller structural change, the change period becomes longer. The long change period increases the complexity, thus, its risk becomes higher.

Why does the long change period bring in the additional complexity? A couple of main reasons:

  1. It requires strong discipline of the organization to get through the long change period, without losing the focus. There will be more crises in the longer period, which triggers our short-term thinking to shift the burden, as described in the article of "from survival need to shifting the burden".
  2. The parallel organizations are challenging to work with, as different parts of the organization are not consistent with each other, which easily causes confusion. The longer it is kept as parallel organizations, the more pains it has to go through.

Of course, the complexity from the change scope is also valid. It is indeed more risky to change a bigger part of the organization at one time. We need to balance between change scope and change period.

LeSS does not suggest to start from one-team change, but make the structural change at once for 2-"8" teams. However, LeSS Huge suggests to take incremental approach for "8"+ teams. That is the choice of LeSS regarding how big structural change you make at one time.

In the next article, we are going to dive deep in how to make incremental structural changes.

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