How to Get Experts to Work Together Effectively (Cara Membuat Para Pakar.......)

How should teams of experts working on knowledge-intensive projects be structured? Should they be hierarchical? Or will flexible, self-organized groups perform better?
(Bagaimana seharusnya tim ahli yang mengerjakan proyek pengetahuan-intensif distrukturkan? Haruskah hirarkis? Atau kelompok yang fleksibel, terorganisir sendiri akan lebih baik performanya?)

Teams often struggle with how to get the most value from the members’ expertise, to minimize conflict, to integrate their diverse expertise, and to leverage it during all phases of a project.
(Tim sering berkutat dengan cara mendapatkan nilai terbaik dari keahlian anggotanya, meminimalkan konflik, mengintegrasikan beragam keahlian mereka, dan memanfaatkannya selama semua fase proyek.)

The traditional approach is to put the person with the most experience and expertise in charge — for example, a head coach or a chief programmer. The assumption is that this person has the expertise to make the best decisions about how to allocate tasks and responsibilities. Teams that adopt this model feature a rigid hierarchy, whereby final decisions are centralized through this single, formally designated individual.
(Pendekatan tradisionalnya adalah dengan menempatkan orang dengan pengalaman dan keahlian paling banyak - misalnya, pelatih kepala atau pemrogram utama. Asumsinya adalah bahwa orang ini memiliki keahlian untuk membuat keputusan terbaik tentang bagaimana mengalokasikan tugas dan tanggung jawab. Tim yang mengadopsi model ini memiliki hierarki yang kaku, dimana keputusan akhir dipusatkan melalui individu tunggal yang ditunjuk secara formal tersebut.)

The downside of this approach is that when projects increase in complexity and team size, the central individual can become a communication and coordination bottleneck for the team.
(Kelemahan dari pendekatan ini adalah ketika proyek meningkat dalam kompleksitas dan ukuran tim, individu sentral dapat menjadi hambatan komunikasi dan koordinasi bagi tim.)

Another approach is to let teams self-manage. This approach is evident in, for example, agile software development methods. The assumption of this model is that team members are best equipped to match skills with needs and to organize their own tasks accordingly. These teams are characterized by broad, open sharing of expertise and by decentralized decision making. While this approach allows ideas to flow freely, it dramatically increases the number of people who need to frequently interact with each other. Thus the approach increases coordination demands and can reduce efficiency.
(Pendekatan lain adalah membiarkan tim mengatur diri sendiri. Pendekatan ini jelas dalam, misalnya, metode pengembangan software agile. Asumsi dari model ini adalah bahwa anggota tim paling siap mencocokkan keterampilan dengan kebutuhan dan mengatur tugas mereka sendiri sesuai dengan itu. Tim-tim ini ditandai dengan pembagian keahlian yang luas dan terbuka dan pengambilan keputusan yang terdesentralisasi. Meskipun pendekatan ini memungkinkan ide-ide mengalir dengan bebas, secara dramatis pendekatan ini meningkatkan jumlah orang yang perlu sering berinteraksi satu sama lain. Dengan demikian pendekatan tersebut meningkatkan tuntutan koordinasi dan dapat mengurangi efisiensi.)

Whether centralization (star structure) or decentralization (wheel structure) leads to better team performance has been a long-standing debate in team management. Most managers recognize the inherent challenges in each model. Perhaps intuitively, many seek a spot in between: neither strict hierarchy nor boundless flexibility. But is this really the best way to work?
(Apakah sentralisasi (struktur bintang) atau desentralisasi (struktur roda) mengarah pada kinerja tim yang lebih baik telah menjadi perdebatan lama dalam manajemen tim. Sebagian besar manajer mengenali tantangan yang melekat pada masing-masing model. Mungkin secara intuitif, banyak yang mencari titik di antaranya: bukan hirarki yang ketat ataupun fleksibilitas yang tak terbatas. Tapi apakah ini cara terbaik untuk bekerja?)

Our research reveals an unexpected answer.
(Penelitian kami mengungkapkan sebuah jawaban yang tak terduga.)

We studied how expertise was organized in 71 software development teams in a large U.S. high-tech company during the design and implementation phases of projects. A total of 484 individuals participated in our study; they had an average of 12 years of experience. We asked team members to nominate up to four individuals with design expertise on each team and up to four individuals with technical expertise. Next, we asked them to assess how valuable the named individuals’ expertise is to their work. (We calculated a team’s network of expertise by weighing how valuable their expertise was to their work.) We then created a network map of team expertise, based on the nominations and weighted by the reported value. This allowed us to use social network analysis to calculate the centralization of expertise for each team in the design phase and in the implementation phase.
(Kami mempelajari bagaimana keahlian diorganisir dalam 71 tim pengembangan software di perusahaan high-tech A.S. besar, selama tahap perancangan dan pelaksanaan proyek. Sebanyak 484 individu berpartisipasi dalam penelitian kami; Mereka memiliki rata-rata 12 tahun pengalaman. Kami meminta anggota tim untuk mencalonkan hingga empat orang dengan keahlian desain di setiap tim dan empat orang dengan keahlian teknis. Selanjutnya, kami meminta mereka untuk menilai seberapa berharganya keahlian individu tersebut dengan pekerjaan mereka. (Kami menghitung jaringan keahlian tim dengan menimbang seberapa berharganya keahlian mereka dalam pekerjaan mereka.) Kami kemudian membuat peta jaringan keahlian tim berdasarkan nominasi dan pembobotan nilai yang dilaporkan. Hal ini memungkinkan kami untuk menggunakan analisis jaringan sosial untuk menghitung pemusatan keahlian untuk setiap tim dalam tahap perancangan dan dalam tahap implementasi.)

To our surprise, we found that the highest-performing teams were the ones that adopted a different configuration of expertise depending on the needs of the project phase. They decentralized design expertise when identifying solutions, and then centralized technical expertise to build them.
(Yang mengejutkan, kami menemukan bahwa tim dengan kinerja tertinggi adalah orang-orang yang mengadopsi konfigurasi keahlian yang berbeda, tergantung pada kebutuhan tahap proyek. Mereka mendesentralisasi keahlian merancang saat mengidentifikasi solusi, dan kemudian mensentralisasi keahlian teknis untuk membangunnya.)

Additionally, if the knowledge required for the project was complex, novel, or otherwise difficult to share, decentralizing expertise during design and centralizing it during implementation became even more important. Teams following this pattern achieved higher ratings on multiple measures of performance: higher coordination success, less team conflict, increased team effectiveness, and higher client satisfaction.
(Tambahannya, jika pengetahuan yang dibutuhkan untuk proyek tersebut rumit, baru, atau sulit untuk dibagikan, desentralisasi keahlian selama disain dan mensentralisasikannya selama pelaksanaan menjadi lebih penting. Tim yang mengikuti pola ini mencapai peringkat yang lebih tinggi pada berbagai ukuran kinerja: keberhasilan koordinasi yang lebih tinggi, konflik tim yang sedikit, peningkatan efektivitas tim, dan kepuasan klien yang lebih tinggi.)

Our findings suggest that different project phases require different ways of organizing expertise. Rather than doggedly following either a strictly centralized or decentralized approach, teams should recognize that the design and implementation phases deal with different kinds of knowledge. Specifically, in complex knowledge work the design phase favors divergent, creative exploration of a broad canvas of conceptualizations and ideas. Decentralized configuration of expertise is appropriate for this phase because:
(Temuan kami menyarankan bahwa tahapan proyek yang berbeda memerlukan cara-cara berbeda untuk mengorganisir keahlian. Alih-alih mengikuti dengan ketat pendekatan yang benar-benar terpusat atau terdesentralisasi, tim harus menyadari bahwa tahap perancangan dan implementasi berurusan dengan berbagai jenis pengetahuan. Secara spesifik, dalam tugas pengetahuan yang kompleks, fase desain lebih membutuhkan eksplorasi kreatif dan berbeda dari kanvas konseptualisasi dan gagasan yang luas. Desentralisasi konfigurasi keahlian sesuai untuk fase ini karena:)

• By broadly eliciting and sharing expertise during the design phase, high-performing teams can achieve a better understanding of ill-structured, poorly understood problems, and converge on and design an optimal solution.

(Dengan memunculkan dan berbagi keahlian secara luas selama tahap perancangan, tim berkinerja tinggi dapat mencapai pemahaman yang lebih baik tentang masalah yang kurang terstruktur, kurang dipahami, dan bertemu dan merancang solusi optimal.)

• While figuring out what needs to get done — encompassing requirements, gathering, and design — a decentralized approach reduces team conflict and leads to more effective solutions.

(Sambil mencari tahu apa yang perlu dilakukan - mencakup persyaratan, pengumpulan, dan perancangan - pendekatan terdesentralisasi mengurangi konflik tim dan mengarah pada solusi yang lebih efektif.)

• Broadly tapping team members’ expertise reduces the risk of myopic, insular thinking that can occur in a rigid hierarchy. This was confirmed by our finding that the more difficult it was to articulate a design problem, the more important it was to involve team members broadly.

(Mengumpulkan keahlian anggota tim secara ekstensif mengurangi risiko pemikiran buta dan picik yang dapat terjadi dalam hirarki yang kaku. Hal ini ditegaskan oleh temuan kami bahwa semakin sulit mengartikulasikan masalah desain, semakin penting untuk melibatkan anggota tim secara luas.)

Later, as the team moves into implementing that solution, centralizing expertise more narrowly among a few designated experts is appropriate because:
(Kemudian, saat tim tersebut bergerak menerapkan solusi tersebut, memusatkan keahlian secara lebih sempit di antara beberapa pakar yang ditunjuk sangat tepat, karena:)

• Building out a solution favors convergent deep knowledge of how best to concretely implement a solution.

(Membangun sebuah solusi lebih membutuhkan pengetahuan mendalam yang konvergen tentang cara terbaik untuk menerapkan solusi secara konkret.)

• Centralizing design expertise avoids the pitfalls of analysis paralysis. During implementation phase, a focus on building leads to increased efficiency.

(Memusatkan keahlian desain menghindari perangkap kelumpuhan analisis. Selama tahap implementasi, fokus pada pembangunan mengarah pada peningkatan efisiensi.)

• For implementing an already identified and specified design, having centralized expertise and clearly defined roles and responsibilities reduces team conflict and reduces coordination requirements.

(Untuk mengimplementasikan desain yang telah diidentifikasi dan ditentukan, memiliki keahlian terpusat serta peran dan tanggung jawab yang jelas, mengurangi konflik tim dan mengurangi persyaratan koordinasi.)

This research suggests that when managers are staffing, organizing, and managing knowledge projects, they should embrace flexible organization of expertise — based on the needs of the project phase — in order to maximize team performance.
(Penelitian ini menunjukkan bahwa ketika manajer mengelola, mengorganisir, dan memanajeri proyek pengetahuan, mereka harus merangkul organisasi keahlian yang fleksibel - berdasarkan kebutuhan tahap proyek - untuk memaksimalkan kinerja tim.)

 

By: Sri Kudaravalli, Samer Faraj and Steven L. Johnson - The Daily Harvard Business Review

 

Untuk info pelatihan (training), jadwal pelatihan (training), managerial training, tempat pelatihan (training), training for trainers, dan pelatihan (training) programs lain, silakan hubungi kami, BusinessGrowth, lembaga training Indonesia terkemuka.