พอดีว่าผมพึงปรับการ review ผลงานกลางปี จากการที่ให้พนักแต่ละคนมา review จับ Tech Lead, Engineer manager ไปใช้การ Review ที่เน้น Impact และโฟกัสที่ Improvement มากขึ้น โดยใช้ 360 Review
และเนื่องด้วยเป็นการทดลองใช้งานครั้งแรก โดยไม่ได้ทำเรื่อง setup goal ของแต่ละคนและทีม เลยทำให้เห็นจุดที่หลายๆ คนมักทำพลาดเหมือนๆ
ซึ่งส่วนหนึ่งเป็นเพราะการ review ครั้งแรกนี้ ไม่ได้มีการกำหนด goal หรือ impact ให้พนักงานตั้งแต่ตั้นจึงทำให้ผมลัพธ์ที่ออกมาไม่ได้แปลกใจเท่าไหร่
เพื่อให้เป็นประโยชน์แก่คนที่ผ่านไปผ่านมา จึงเอามาสรุปไว้สักหน่อย
1. Growth area ไม่ผูกกับเหตุการณ์จริง (ปัญหาใหญ่สุด — เจอเกือบทุกฉบับ)
ส่วนใหญ่บอก "pattern" หรือ "trait" แต่ไม่บอกว่า เคสไหน เมื่อไหร่ ทำอะไร เช่น "มี business case ตกหล่นจนเกิด bug" แต่ไม่ระบุว่าเคสอะไร คนรับ feedback เลยเอาไปแก้ไม่ได้ และ EM ก็ตรวจสอบใน calibration ไม่ได้ เกณฑ์ที่ควรยึดคือต้องมี Situation + Behavior ชัด ก่อนจะสรุปเป็น pattern
2. ปน "สิ่งที่เห็น" กับ "สิ่งที่เดา" (observation vs interpretation)
หลายฉบับเขียนการตีความสภาพจิตใจ/เจตนาราวกับเป็นข้อเท็จจริง เช่น "กดดันตัวเองจนไม่มีความสุข" หรือ "fix solution ควรรับฟังมากขึ้น" เราสังเกตได้แค่พฤติกรรม ส่วนที่เหลือเป็นการเดาข้างใน ต้องเขียนแยกชั้น: "ผมเห็นว่า X (ข้อเท็จจริง) เลยรู้สึกว่า Y (การตีความ)" ตรงนี้แหละที่เคยทำให้เราสะดุดกันเองตอนเคส Nammon
3. คำชมลอย ๆ ไม่มีหลักฐาน (adjective over evidence)
"ศักยภาพที่โดดเด่น", "ผู้นำที่มีความสามารถ", "ยอดเยี่ยม"
ฟังดูดีแต่ยกไปใช้ใน calibration ไม่ได้ ลองทดสอบง่าย ๆ ว่า "ประโยคนี้จะเป็นเท็จไหมถ้าเอาไปใช้กับคนธรรมดาทั่วไป" ถ้าไม่เป็นเท็จ แปลว่ายังไม่ใช่ signal จริง ต้องแปลงเป็น พฤติกรรม → ผลลัพธ์
4. Impact อ่อน และ แทบไม่มีใครใส่ตัวเลข
ช่อง Impact เขียนกว้าง ("delivery มีคุณภาพ") ทั้งที่หลายจุดใส่ตัวเลขได้ เช่น กู้ transaction กี่รายการ ลดเวลา/ลดเคสเท่าไร กี่ทีมหยิบ tool ไปใช้ ตัวเลขทำให้ทั้งคำชมและ impact น่าเชื่อถือขึ้นมาก (ยอมรับว่าส่วนหนึ่งเป็นเพราะทีมยังไม่มีวัฒนธรรมเก็บ metric)
5. Growth area นุ่มเกินไป จนกลายเป็นคำชม
วัฒนธรรมเกรงใจทำให้ growth area กลายเป็น "จุดแข็งที่พูดให้นุ่ม" หรือหลบการพูดตรง (เช่น "เรื่องอื่นไม่น่ากังวล") บางฉบับ growth area กลายเป็นคำชมไปเลย ต้อง normalize ว่า feedback เชิงพัฒนาที่เจาะจง = ความหวังดี ไม่ใช่การตำหนิ
6. ไม่ปิดด้วย "ask" ที่ทำได้จริง + กรอกฟอร์มไม่ครบ
หลายฉบับของ peer review มันจบแบบลอยๆ ไม่บอกว่าอยากให้ทำอะไรต่อ และบางคนเว้นช่อง Impact / "anything else" ว่าง ทำให้ข้อมูล 360 ไม่เท่ากันในแต่ละคน
Checklist ก่อนเขียน peer review
เพื่อให้เราเขียน peer review ได้ดีขึ้น แนะนำให้ทุกความเห็นควรผ่าน 4 ข้อนี้ก่อนส่ง
1. มีเหตุการณ์จริงไหม?
เล่าได้ไหมว่า เคสไหน ช่วงไหน เขาทำอะไร — ถ้าเล่าเป็นเหตุการณ์ไม่ได้ แปลว่ายังไม่พร้อมเขียนเป็น feedback (คำชมลอย ๆ อย่าง "เก่งมาก/ศักยภาพสูง" ตกข้อนี้)
2. แยก "สิ่งที่เห็น" ออกจาก "สิ่งที่เดา" แล้วหรือยัง?
เขียนพฤติกรรมที่สังเกตได้ก่อน แล้วค่อยบอกการตีความแยกกันให้ชัด — "ผมเห็นว่า X เกิดขึ้น → เลยรู้สึกว่า Y" อย่าเขียนการเดาสภาพจิตใจ/เจตนาเป็นข้อเท็จจริง
3. บอก impact หรือยัง?
พฤติกรรมนั้นส่งผลอะไรต่องาน/ทีม/ลูกค้า? ใส่ตัวเลขหรือผลลัพธ์รูปธรรมได้ยิ่งดี (ลดเวลาเท่าไร กี่เคส กี่ทีมได้ใช้)
4. ปิดด้วย ask ที่ทำได้จริงหรือยัง?
อยากให้เขาทำอะไรต่อในรอบหน้า — เจาะจงและ actionable ไม่ใช่ "ให้รอบคอบขึ้น" ลอย ๆ
ตัวอย่างที่ผ่านครบ 4 ข้อ
ตอน incident package renewal (S) ทุกคนคิดว่าเป็นปัญหา API แต่เขาไล่ขุดจนเจอ root cause จริง (B) ทำให้ทีมแก้ถูกจุดและปิดเคสได้ในวันเดียว (I) — รอบหน้าอยากให้ช่วยสรุป pattern การ debug แบบนี้แชร์ให้ทีมด้วย (A)
(S=Situation, B=Behavior, I=Impact, A=Ask)
เท่านี้การเขียน self assessment และ peer review จะมีคุณภาพมากขึ้น