Build a Real Management Team

Real development team is already rare, let alone real management team. When talking about real team, I mean that the group has common goal and takes shared responsibility. Usually, management team is not a real team, but a working group. This is indicated by every member having clear individual responsibility. Even though it is claimed that they have common goal, it is mostly the leader who is accountable for it, and other members are mostly responsible for their own parts. This is the traditional organization hierarchy.


As the hierarchy is defined by reporting line, let's look at various settings when we create cross-functional feature team in adopting Scrum.


1. from multiple managers to one manager


As the traditional organization is often based on functions and components. When we move from single functional and component team structure to cross-functional and feature team structure, if original reporting structure remains, members in the same team will report to different managers. Those managers are still responsible for their own functions and components. Even though they are members in management team, they do not take shared responsibility. This is not desirable for team, as the more managers, the more difficult it becomes in alignment.


Reporting line - functional.png


Therefore, the common advice is to change the reporting line and make the whole team report to same manager. Then, those managers become cross-functional managers. However, this does not make them take shared responsibility in management team, as usually they are still responsible for their own teams.


Reporting line - cross-functional.png


2. from one manager to multiple managers


Recently, in my LeSS course, a few participants from same product organization shared that the members in their teams report to multiple managers, but NOT managers for different functions and components. Instead, it was a bit like everybody randomly picking up a manager. It sounded weird at first, then, it revealed an interesting purpose of doing that. They want to build a real management team!


Reporting line - random.png

The rationale is, when any team is not owned by one manager, it would avoid the situation of any manager only responsible for their own teams. Instead, multiple mangers will collectively  ensure the success of all teams. In this setting, any misalignment among managers would become serious impediment towards well-working team. What impressed me was that they made informed choice, with the attitude of experimentation.


This reminded me of my NSN (Nokia Siemens Networks) experience. When I led a department with 100+ people, we had 4 R&D managers, together with me we formed a management team. We put deliberate efforts in building a real team - taking shared responsibility for the whole department goals.


We tried:


  • Managers acted as ScrumMaster for teams who did not directly report to them. See Manager as ScrumMaster paper.
  • Created department initiatives to foster collaboration among R&D managers, especially on removing organizational impediments, continuous improvement, and community of practices.
  • Not cascade down department objectives to next level for R&D groups, but kept it at department level.
  • Instead of me giving the feedback to every manager as part of performance appraisal, we had management team feedback session, everybody giving and receiving feedback in the open.


We did not try having members in one team report to different managers by random. What an interesting experiment, ever though its effect remains to be checked.


I applaud for any attempt in building the real management team, as it is hard, but a lofty goal to seek.

Read more

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai