The Software Architect as a Leader (สถาปนิกซอฟต์แวร์ในฐานะผู้นำ)

สถาปนิกซอฟต์แวร์ก็เป็นผู้นำเช่นกัน คอยชี้แนะทีมพัฒนาระหว่างที่พวกเขาอิมพลีเมนต์สถาปัตยกรรม เรายืนยันว่าประมาณ 50% ของการเป็นสถาปนิกซอฟต์แวร์ที่มีประสิทธิภาพคือการมีทักษะด้านคนที่ดี รวมถึงการอำนวยความสะดวกและความเป็นผู้นำ ในหัวข้อนี้ เราจะพูดถึงเทคนิคความเป็นผู้นำสำหรับสถาปนิกซอฟต์แวร์

The 4 Cs of Architecture (4 C ของสถาปัตยกรรม)

เราได้พูดหลายครั้งแล้วว่าการเปลี่ยนแปลงเป็นสิ่งคงที่ และไม่มีอะไรจริงไปกว่านี้อีกแล้วเมื่อการเปลี่ยนแปลงนั้นเกี่ยวข้องกับ สิ่งที่ซับซ้อนขึ้นเรื่อยๆ ไม่ว่าจะเป็นกระบวนการทางธุรกิจ เทคโนโลยี หรือแม้แต่ตัวสถาปัตยกรรมเอง ดังที่คุณเห็นใน Part III ของหนังสือเล่มนี้ สถาปัตยกรรมบางแบบก็ซับซ้อน มาก จริงๆ ถ้าสถาปัตยกรรมต้องรองรับความพร้อมใช้งานระดับ six nines (99.9999%) นั่นเท่ากับดาวน์ไทม์ที่ไม่ได้วางแผนไว้ประมาณ 86 มิลลิวินาทีต่อวัน หรือ 31.5 วินาทีต่อ ปี ความซับซ้อนแบบนี้เรียกว่า essential complexity กล่าวอีกนัยหนึ่งคือ "เรามีปัญหาที่ยาก"

สถาปนิก (และนักพัฒนา) มักตกหลุมพรางของการเพิ่มความซับซ้อนที่ไม่จำเป็นให้กับโซลูชัน ไดอะแกรม และเอกสารได้ง่ายมาก ขอยกคำพูดของ Neal มาอ้างอิง:

นักพัฒนามักถูกดึงดูดเข้าหาความซับซ้อนเหมือนแมลงเม่าบินเข้ากองไฟ และมักได้ผลลัพธ์แบบเดียวกันด้วย

Figure 25-1 แสดงไดอะแกรมการไหลของข้อมูลหลักของระบบประมวลผลแบ็กเอนด์ที่ธนาคารระดับโลกขนาดใหญ่มากแห่งหนึ่ง ระบบนี้ซับซ้อนโดย จำเป็น จริงหรือไม่ กล่าวคือมัน ต้อง ซับซ้อนขนาดนี้จริงหรือ? ไม่มีใครรู้ เพราะสถาปนิกเป็นคน ทำให้ มันซับซ้อนเอง ความซับซ้อนแบบนี้เรียกว่า accidental complexity พูดสั้นๆ คือ "เราทำให้ปัญหายากขึ้นเอง" บางครั้งสถาปนิกก็เพิ่มความซับซ้อนเพื่อพิสูจน์คุณค่าของตัวเองเมื่อสิ่งต่างๆ ดูง่ายเกินไป หรือเพื่อรับประกันว่าตัวเองจะยังคงอยู่ในวงของการตัดสินใจ หรือแม้แต่เพื่อรักษาความมั่นคงในงานของตัวเอง ไม่ว่าเหตุผลจะเป็นอะไร การนำ accidental complexity เข้ามาในสิ่งที่ไม่จำเป็นต้องซับซ้อนเลย เป็นหนึ่งในวิธีที่ดีที่สุดที่จะทำให้เสื่อมความเคารพ และกลายเป็นผู้นำและสถาปนิกที่ไม่มีประสิทธิภาพ

Figure 25-1. การนำ accidental complexity เข้ามาในปัญหา

เพื่อหลีกเลี่ยง accidental complexity เราใช้สิ่งที่เราเรียกว่า 4 Cs ของความเป็นผู้นำด้านสถาปัตยกรรม ได้แก่ communication (การสื่อสาร) collaboration (การทำงานร่วมกัน) clear (ชัดเจน) และ concise (กระชับ) ปัจจัยเหล่านี้ ดังแสดงใน Figure 25-2 (อย่าสับสนกับ 4 C ภายใน C4 Model ของการเขียนไดอะแกรม) ทำงานร่วมกันเพื่อสร้างผู้สื่อสารและผู้ร่วมงานที่มีประสิทธิภาพในทีม

Figure 25-2. 4 Cs ของสถาปัตยกรรม

ในฐานะผู้นำ ผู้อำนวยความสะดวก และนักเจรจาต่อรอง สถาปนิกซอฟต์แวร์จำเป็นอย่างยิ่งที่ต้องสามารถ สื่อสาร ได้อย่าง ชัดเจน และ กระชับ เช่นเดียวกันกับการที่ต้องสามารถ ทำงานร่วมกัน กับนักพัฒนา ผู้มีส่วนได้ส่วนเสียทางธุรกิจ และสถาปนิกคนอื่นๆ ได้ การให้ความสำคัญกับ 4 C ช่วยให้สถาปนิกได้รับความเคารพจากทีม และช่วยทำให้พวกเขากลายเป็นคนที่ทุกคนในโครงการนึกถึงเป็นอันดับแรกสำหรับคำถาม คำแนะนำ การให้คำปรึกษา การโค้ช และความเป็นผู้นำ

Be Pragmatic, Yet Visionary (เป็นคนที่ใช้เหตุผลเชิงปฏิบัติ แต่ก็มีวิสัยทัศน์)

สถาปนิกซอฟต์แวร์ที่มีประสิทธิภาพต้องเป็นทั้งคนที่ใช้เหตุผลเชิงปฏิบัติและมีวิสัยทัศน์ในเวลาเดียวกัน การพยายามสร้างสมดุลนี้ ไม่ใช่เรื่องง่ายอย่างที่ฟังดู มันต้องอาศัยวุฒิภาวะระดับสูงพอสมควรและการฝึกฝนอย่างมากจึงจะทำได้

คนมี วิสัยทัศน์ (visionary) คือคนที่คิดหรือวางแผนอนาคตด้วยจินตนาการหรือปัญญา การเป็นคนมีวิสัยทัศน์หมายถึงการใช้ความคิดเชิงกลยุทธ์กับปัญหา ซึ่งเป็นสิ่งที่สถาปนิกทำอยู่แล้ว สถาปนิกวางแผนสำหรับอนาคตและมั่นใจว่าสถาปัตยกรรมที่พวกเขาสร้างขึ้นยังคงมีชีวิต (ถูกต้องและมีประโยชน์) ไปอีกนาน อย่างไรก็ตาม สถาปนิกมักจะมองสิ่งต่างๆ เป็นเชิงทฤษฎีมากเกินไปในการวางแผนและออกแบบ จนสร้างโซลูชันที่ยากเกินไปที่จะอิมพลีเมนต์ หรือแม้แต่ยากเกินจะเข้าใจ

ทีนี้ลองดูอีกด้านของเหรียญ นั่นคือการเป็นคนที่ ใช้เหตุผลเชิงปฏิบัติ (pragmatic) การใช้เหตุผลเชิงปฏิบัติหมายถึงการจัดการสิ่งต่างๆ อย่างมีเหตุผลและสมจริง โดยอิงจากการพิจารณาเชิง ปฏิบัติ มากกว่าเชิง ทฤษฎี แม้สถาปนิกจำเป็นต้องมีวิสัยทัศน์ แต่พวกเขาก็ต้องนำโซลูชันที่ปฏิบัติได้จริงและสมจริงมาใช้ด้วย การเป็นคนที่ใช้เหตุผลเชิงปฏิบัติ เมื่อสร้างโซลูชันด้านสถาปัตยกรรมหมายถึงการคำนึงถึง:

• ข้อจำกัดด้านงบประมาณและปัจจัยอื่นๆ ที่เกี่ยวกับต้นทุน

• ข้อจำกัดด้านเวลาและปัจจัยอื่นๆ ที่เกี่ยวกับเวลา

• ทักษะและระดับความชำนาญของทีมพัฒนา

• การแลกเปลี่ยน (trade-off) และผลกระทบของการตัดสินใจด้านสถาปัตยกรรมแต่ละครั้ง

• ข้อจำกัดทางเทคนิคของการออกแบบหรือโซลูชันที่นำเสนอ

สถาปนิกซอฟต์แวร์ที่ดีจะพยายามสร้างสมดุลระหว่างการใช้เหตุผลเชิงปฏิบัติกับจินตนาการและปัญญาในการแก้ปัญหา (ดู Figure 25-3 )

ตัวอย่างเช่น ลองพิจารณาสถาปนิกที่ต้องเผชิญกับปริมาณผู้ใช้พร้อมกัน (concurrent user load) ที่เพิ่มขึ้นอย่างมากและกะทันหัน ด้วยสาเหตุที่ไม่ชัดเจน คนมีวิสัยทัศน์อาจคิดวิธีที่ซับซ้อนขึ้นมาเพื่อปรับปรุงความยืดหยุ่นของระบบ ด้วยการแยกฐานข้อมูลออกจากกัน และสร้าง data mesh ที่ซับซ้อนขึ้นมา นั่นคือกลุ่มของฐานข้อมูลที่กระจายตัวและแบ่งตามโดเมน ใช้แยกความกังวลเรื่องข้อมูลเชิงวิเคราะห์ออกจาก ข้อมูลเชิงทรานแซกชัน ในทางทฤษฎี แนวทางนี้ อาจ เป็นไปได้ แต่การใช้เหตุผลเชิงปฏิบัติหมายถึงการนำเหตุผลและความเป็นไปได้จริงมาใช้กับโซลูชัน ตัวอย่างเช่น บริษัทเคยใช้ data mesh มาก่อนหรือไม่? การแลกเปลี่ยนของการใช้ data mesh คืออะไร? โซลูชันนี้จะแก้ปัญหาได้จริงหรือ?

Figure 25-3. สถาปนิกที่ดีจะหาสมดุลระหว่างการใช้เหตุผลเชิงปฏิบัติกับการเป็นคน มีวิสัยทัศน์

การรักษาสมดุลที่ดีระหว่างการใช้เหตุผลเชิงปฏิบัติกับการมีวิสัยทัศน์เป็นวิธีที่ยอดเยี่ยมในการได้รับความเคารพในฐานะสถาปนิก ผู้มีส่วนได้ส่วนเสียทางธุรกิจชื่นชอบโซลูชันที่มีวิสัยทัศน์ซึ่งอยู่ภายในขอบเขตของข้อจำกัด และนักพัฒนาก็ชื่นชอบการมีโซลูชัน ที่ปฏิบัติได้จริง (ไม่ใช่แค่เชิงทฤษฎี) ให้อิมพลีเมนต์

สถาปนิกที่ใช้เหตุผลเชิงปฏิบัติจะเริ่มต้นด้วยการมองหาปัจจัยที่จำกัดความยืดหยุ่นของระบบก่อน การค้นหาและแยก bottleneck ใดๆ ออกมาจะเป็นแนวทางแรกที่ปฏิบัติได้จริงสำหรับปัญหานี้ ฐานข้อมูลกำลังสร้าง bottleneck ต่อเซอร์วิสที่ถูกเรียกใช้บางตัว หรือแหล่งข้อมูลภายนอกอื่นๆ ที่จำเป็นหรือไม่? ถ้าใช่ ข้อมูลบางส่วนสามารถแคชไว้เพื่อลดการเรียกฐานข้อมูลได้หรือไม่?

Leading Teams by Example (นำทีมด้วยการเป็นตัวอย่าง)

สถาปนิกซอฟต์แวร์ที่ไม่ดีมักจะ "ใช้ตำแหน่งกดดัน" ใช้ตำแหน่งของตัวเองบังคับให้คนอื่นทำสิ่งต่างๆ ส่วนสถาปนิกซอฟต์แวร์ ที่มีประสิทธิภาพจะทำให้คนอื่นทำสิ่งต่างๆ ผ่านการนำโดยเป็นตัวอย่าง เรื่องนี้ก็เกี่ยวกับการได้รับความเคารพจากทีมพัฒนา ผู้มีส่วนได้ส่วนเสียทางธุรกิจ และคนอื่นๆ ทั่วทั้งองค์กร (เช่น หัวหน้าฝ่ายปฏิบัติการ ผู้จัดการฝ่ายพัฒนา และเจ้าของผลิตภัณฑ์)

เรื่องเล่าคลาสสิกเกี่ยวกับ "การนำด้วยตัวอย่าง ไม่ใช่ด้วยตำแหน่ง" เกี่ยวข้องกับกัปตันที่บังคับบัญชาจ่าสิบเอกระหว่างการรบ กัปตันซึ่งอยู่ห่างจากกองทหารมาก สั่งให้กองทหารทั้งหมดเดินหน้าไปยึดเนินเขาที่ยากลำบากเป็นพิเศษ ทหารซึ่งเต็มไปด้วยความสงสัย มองหาการยืนยันจากจ่าสิบเอกที่มียศต่ำกว่า จ่าสิบเอกซึ่งเข้าใจสถานการณ์ พยักหน้าเล็กน้อย และทหารก็เดินหน้าไปยึดเนินเขา ด้วยความมั่นใจในทันที

คติสอนใจของเรื่องนี้คือ ยศและตำแหน่งแทบไม่มีความหมายอะไรเลยเมื่อพูดถึงการนำคน นักวิทยาศาสตร์คอมพิวเตอร์ Gerald Weinberg มีชื่อเสียงจากคำพูดที่ว่า "ไม่ว่าปัญหาจะเป็นอะไร มันคือปัญหาเรื่องคนเสมอ" คนส่วนใหญ่คิดว่าการแก้ปัญหาทางเทคนิคไม่เกี่ยวข้อง อะไรกับทักษะด้านคนเลย และเกี่ยวข้องทั้งหมดกับ ความรู้ทางเทคนิค แม้ความรู้ทางเทคนิคจะจำเป็นแน่นอน แต่มันก็เป็นเพียงส่วนหนึ่งของการแก้ปัญหาใดๆ เท่านั้น

ตัวอย่างเช่น สมมติว่าสถาปนิกกำลังประชุมกับทีมนักพัฒนาเพื่อแก้ปัญหาที่เกิดขึ้นในโปรดักชัน นักพัฒนาคนหนึ่งเสนอไอเดีย และสถาปนิกตอบว่า "อืม นั่น มันไอเดียที่โง่มาก" ไม่เพียงแต่นักพัฒนาคนนั้นจะไม่เสนอไอเดียอีกต่อไป แต่นักพัฒนาคนอื่นๆ ก็จะไม่กล้าพูดอะไรอีกด้วย สถาปนิกได้ปิดกั้นการทำงานร่วมกันของทั้งทีมไปแล้ว

ลองดูตัวอย่างบทสนทนาอีกช่วงหนึ่งระหว่างสถาปนิกกับนักพัฒนา:

นักพัฒนา : "แล้วเราจะแก้ปัญหาประสิทธิภาพนี้ยังไงดี?"
สถาปนิก : "สิ่งที่คุณต้องทำคือใช้แคช นั่นจะแก้ปัญหาได้"
นักพัฒนา : "อย่ามาบอกผมว่าต้องทำอะไร"
สถาปนิก : "ผมกำลังบอกคุณว่ามันจะแก้ปัญหาได้"

นี่เป็นตัวอย่างที่ดีของการสื่อสารโดยไม่มีการ ทำงานร่วมกัน การใช้คำว่า "สิ่งที่คุณต้องทำคือ" ทำให้สถาปนิกปิดกั้นการทำงานร่วมกัน ทีนี้ลองดูแนวทางที่ปรับปรุงแล้ว:

นักพัฒนา : "แล้วเราจะแก้ปัญหาประสิทธิภาพนี้ยังไงดี?"
สถาปนิก : "คุณเคยลองใช้แคชหรือยัง? มันอาจแก้ปัญหาได้นะ"
นักพัฒนา : "อืม ยังไม่เคยคิดถึงเรื่องนั้นเลย คุณคิดว่ายังไง?"
สถาปนิก : "เอาล่ะ ถ้าเราใส่แคชตรงนี้..."

คำว่า "คุณเคยลอง...หรือยัง" เปลี่ยนคำสั่งให้กลายเป็นคำถาม คืนอำนาจการควบคุมกลับไปให้นักพัฒนา ทำให้พวกเขาสามารถสนทนา แบบร่วมมือกันกับสถาปนิกได้ วิธีที่คุณใช้ภาษาสำคัญอย่างยิ่งต่อการสร้างสภาพแวดล้อมที่ร่วมมือกัน

การนำการทำงานร่วมกันในฐานะสถาปนิกไม่ใช่แค่เรื่องที่ว่าคุณเองทำงานร่วมกับคนอื่นอย่างไร แต่ยังเกี่ยวกับการอำนวยความสะดวก ให้เกิดการทำงานร่วมกันระหว่างสมาชิกในทีมด้วย พยายามสังเกตพลวัตของทีมและสังเกตสถานการณ์แบบในบทสนทนานี้ ถ้าคุณเห็นสมาชิกในทีม ใช้ภาษาที่บังคับหรือดูถูก ให้พาพวกเขาไปคุยเป็นการส่วนตัวและโค้ชให้ใช้ภาษาที่ร่วมมือกันมากขึ้น สิ่งนี้ไม่เพียงสร้างพลวัตของทีม ที่ดีขึ้น แต่ยังช่วยให้สมาชิกในทีมเคารพกันและกันมากขึ้นด้วย

ถ้าคุณจำเป็นต้องให้ใครสักคนทำสิ่งที่พวกเขาอาจไม่อยากทำ บางครั้งวิธีที่ดีที่สุดคือเปลี่ยนคำขอให้กลายเป็นการขอความช่วยเหลือ โดยทั่วไปแล้ว มนุษย์ไม่ชอบถูกสั่งให้ทำอะไร แต่อยากช่วยเหลือคนอื่น ลองพิจารณาบทสนทนาต่อไปนี้ระหว่างสถาปนิกกับนักพัฒนา เกี่ยวกับความพยายามในการรีแฟกเตอร์สถาปัตยกรรมระหว่างรอบการทำงานที่ยุ่งมาก:

สถาปนิก : "ผมต้องการให้คุณแยกเซอร์วิสการชำระเงินออกเป็นห้าเซอร์วิสแยกกัน แต่ละเซอร์วิสรองรับฟังก์ชันการทำงานของการชำระเงิน แต่ละประเภทที่เรารองรับ เช่น เครดิตร้านค้า บัตรเครดิต PayPal บัตรของขวัญ และแต้มสะสม จะช่วยให้เว็บไซต์มี fault tolerance และความสามารถในการสเกลที่ดีขึ้น ไม่น่าจะใช้เวลานาน"
นักพัฒนา : "ขอโทษครับ รอบนี้ผมยุ่งมากจริงๆ ผมทำไม่ได้"
สถาปนิก : "ฟังนะ เรื่องนี้สำคัญและต้องทำให้เสร็จในรอบนี้"
นักพัฒนา : "ขอโทษครับ ผมทำไม่ได้ บางทีนักพัฒนาคนอื่นอาจทำได้ ผมยุ่งเกินไปจริงๆ"

นักพัฒนาปฏิเสธงานนี้ทันที แม้ว่าสถาปนิกจะให้เหตุผลแล้วว่ามันจะช่วยให้มี fault tolerance และความสามารถในการสเกลที่ดีขึ้นก็ตาม สถาปนิกกำลัง สั่งให้ นักพัฒนาทำสิ่งที่พวกเขายุ่งเกินไปจนทำไม่ได้ และข้อเรียกร้องของสถาปนิกก็ไม่ได้เอ่ยชื่อคนนั้นด้วยซ้ำ! ทีนี้ลองดูเทคนิค การเปลี่ยนคำขอให้กลายเป็นการขอความช่วยเหลือ:

สถาปนิก : "สวัสดีครับ Sridhar ฟังนะ ผมกำลังเจอปัญหาจริงๆ ผมจำเป็นต้องแยกเซอร์วิสการชำระเงินออกเป็นเซอร์วิสแยกกันสำหรับการชำระเงิน แต่ละประเภทเพื่อให้ได้ fault tolerance และความสามารถในการสเกลที่ดีขึ้น และผมรอนานเกินไปกว่าจะเริ่มทำ คุณพอจะยัดงานนี้ เข้าไปในรอบนี้ได้ไหม? มันจะช่วยผมได้มากจริงๆ"
นักพัฒนา (หยุดคิดครู่หนึ่ง) : "รอบนี้ผมยุ่งมากจริงๆ แต่ผมจะลองดูว่าทำอะไรได้บ้าง"
สถาปนิก : "ขอบคุณครับ Sridhar ผมซาบซึ้งมากจริงๆ ผมติดหนี้บุญคุณคุณนะ"
นักพัฒนา : "ไม่เป็นไรครับ ผมจะจัดการให้เสร็จในรอบนี้"

ก่อนอื่น การเอ่ยชื่อคนคนนั้นทำให้บทสนทนาเป็นส่วนตัวและคุ้นเคยมากขึ้น แทนที่จะเป็นข้อเรียกร้องทางวิชาชีพที่ไม่มีความเป็นส่วนตัว การใช้ชื่อและสรรพนามที่เหมาะสมระหว่างบทสนทนาหรือการเจรจาต่อรองช่วยสร้างความเคารพและความสัมพันธ์ที่ดีต่อสุขภาพได้ คนไม่เพียงชอบได้ยินชื่อของตัวเอง แต่มันยังสร้างความรู้สึกคุ้นเคยด้วย ฝึกจำชื่อคนด้วยการใช้ชื่อพวกเขาบ่อยๆ ถ้าคุณพบว่าชื่อไหนออกเสียงยาก ให้ค้นคว้าการออกเสียงที่ถูกต้อง แล้วฝึกจนออกเสียงได้สมบูรณ์แบบ เมื่อมีคนบอกชื่อของตัวเองกับคุณ เราชอบพูดชื่อนั้นซ้ำและถามว่า เราออกเสียงถูกไหม ถ้าไม่ถูก เราก็จะทำแบบนี้ซ้ำจนกว่าจะออกเสียงได้ถูกต้อง

ประการที่สอง สถาปนิกในบทสนทนาก่อนหน้ายอมรับว่าตัวเองกำลัง "เจอปัญหาจริงๆ" และการแยกเซอร์วิสจะ "ช่วยพวกเขาได้มาก" วิธีนี้ไม่ได้ผลเสมอไป แต่การใช้ประโยชน์จากแรงกระตุ้นพื้นฐานของมนุษย์ในการช่วยเหลือผู้อื่นมีโอกาสสำเร็จมากกว่าบทสนทนาแรก ลองใช้วิธีนี้ในครั้งต่อไปที่คุณเจอสถานการณ์แบบนี้

อีกเทคนิคความเป็นผู้นำที่ได้ผลเมื่อคุณพบใครสักคนเป็นครั้งแรก หรือทักทายคนที่คุณเจอเป็นครั้งคราว คือการจับมือและสบตากับคนนั้นเสมอ การจับมือเป็นทักษะด้านคนที่สำคัญ มีมาตั้งแต่ยุคกลาง มันบอกให้ทั้งสองฝ่ายรู้ว่าเป็นมิตรไม่ใช่ศัตรู และสร้างสายสัมพันธ์ระหว่างกัน อย่างไรก็ตาม ควรตระหนักถึงมิติทางวัฒนธรรมของการจับมือด้วย ตัวอย่างเช่น ในสหรัฐฯ สหราชอาณาจักร ยุโรป และออสเตรเลีย การจับมือเป็นวิธีทักทายที่ยอมรับได้ ในขณะที่วัฒนธรรมอื่นใช้การทักทายแบบอื่น (เช่นญี่ปุ่นที่ใช้การโค้งคำนับและจังหวะการโค้ง) ถึงกระนั้น บางครั้งการจับมือธรรมดาก็ทำให้ถูกต้องได้ยาก

การจับมือควรมั่นคง แต่ไม่บีบแรงเกินไป มองตาคนนั้น การมองไปทางอื่นระหว่างจับมือเป็นสัญญาณของการไม่เคารพ และคนส่วนใหญ่จะสังเกตเห็น นอกจากนี้ อย่าจับมือนานเกินไป แค่สองหรือสามวินาทีก็เพียงพอแล้ว และก็อย่าจับมือมากเกินไปด้วย ถ้าคุณมาออฟฟิศทุกเช้าแล้วเริ่มจับมือ ทุกคน มันแปลกพอที่จะทำให้คนรู้สึกอึดอัด แต่การประชุมประจำเดือนกับหัวหน้าฝ่ายปฏิบัติการเป็นโอกาสที่ดีที่จะยืนขึ้น พูดว่า "สวัสดีครับ Ruth ดีใจที่ได้เจออีกครั้ง" แล้วจับมือ Ruth อย่างรวดเร็วและมั่นคง การรู้ว่าเมื่อไหร่ควรจับมือและเมื่อไหร่ไม่ควร เป็นส่วนหนึ่งของศิลปะที่ซับซ้อนของทักษะด้านคน

ในฐานะผู้นำ ควรระมัดระวังที่จะเคารพและรักษาขอบเขตส่วนตัวระหว่างคนทุกระดับ การจับมือเป็นวิธีทางวิชาชีพในการสร้างสายสัมพันธ์ ทางกาย เพราะมันเป็นสิ่งที่ดี บางคนจึงคิดว่าการกอดคนจะยิ่งดีและสร้างสายสัมพันธ์ได้มากกว่า แต่ไม่ใช่แบบนั้น การกอดในสภาพแวดล้อมทางวิชาชีพ ไม่ว่าจะเป็นสภาพแวดล้อมแบบไหน อาจทำให้คนรู้สึกอึดอัด และอาจถึงขั้นกลายเป็นการล่วงละเมิด ในที่ทำงานได้ เช่นเดียวกันกับความประพฤติทั่วไปในที่ทำงานหรือเวลาเดินทางไปกับเพื่อนร่วมงาน ควรหลีกเลี่ยงการกอด ยึดถือ ความประพฤติทางวิชาชีพตามสามัญสำนึก และใช้การจับมือแทน

ผู้นำที่ดีควรกลายเป็น "คนที่ทุกคนนึกถึงเป็นอันดับแรก" ในทีม คือคนที่นักพัฒนาไปหาเมื่อมีคำถามและปัญหา สถาปนิกซอฟต์แวร์ ที่มีประสิทธิภาพจะไขว่คว้าโอกาสและลงมือนำทีมด้วยความคิดริเริ่ม โดยไม่คำนึงถึงตำแหน่งหรือบทบาทของตัวเองในทีม ถ้ามีใครกำลัง ดิ้นรนกับปัญหาทางเทคนิค ให้ลงมือทันที เข้าไปช่วยเหลือหรือให้คำแนะนำ เช่นเดียวกันกับสถานการณ์ที่ไม่เกี่ยวกับเทคนิค ถ้าสมาชิกในทีมเข้ามาทำงานด้วยท่าทางเศร้าหมองและกังวลใจ เหมือนมีบางอย่างผิดปกติแน่ๆ สถาปนิกซอฟต์แวร์ที่มีประสิทธิภาพอาจเสนอ ที่จะคุยด้วย "เฮ้ Antonio ผมกำลังจะไปซื้อกาแฟ ไปด้วยกันไหม?" แล้วระหว่างเดิน พวกเขาก็สามารถถามว่าทุกอย่างโอเคไหม วิธีนี้เปิดโอกาสให้เกิดบทสนทนาที่เป็นส่วนตัวมากขึ้น และในกรณีที่ดีที่สุด อาจเป็นโอกาสในการให้คำปรึกษาและโค้ชด้วย อย่างไรก็ตาม ผู้นำที่มีประสิทธิภาพก็จะให้ความสนใจกับสัญญาณทั้งทางวาจาและไม่ใช่วาจา (เช่น สีหน้าและภาษากาย) และรู้ว่าเมื่อไหร่ควรถอยออกมา

อีกวิธีหนึ่งในการสร้างตัวเองให้เป็นคนที่ทุกคนนึกถึงเป็นอันดับแรกในทีม คือการจัดเซสชัน "lunch and learn" แบบไม่เป็นทางการ เป็นระยะๆ เกี่ยวกับเทคนิคหรือเทคโนโลยีเฉพาะอย่าง เช่น ดีไซน์แพทเทิร์นหรือฟีเจอร์ใหม่ๆ ของภาษาโปรแกรมรุ่นล่าสุด ถ้าคุณกำลังอ่านหนังสือเล่มนี้อยู่ แสดงว่าคุณมีทักษะหรือความรู้เฉพาะบางอย่างที่คนอื่นไม่มี การจัดกิจกรรมเหล่านี้ไม่ใช่แค่ การให้ข้อมูลที่มีค่าแก่นักพัฒนาหรือแสดงความเชี่ยวชาญทางเทคนิคของคุณเท่านั้น แต่ยังเป็นโอกาสในการฝึกฝนทักษะการให้คำปรึกษา และการพูดในที่สาธารณะ และยังบ่งบอกว่าคุณคือผู้นำและที่ปรึกษาด้วย .