คนส่วนใหญ่เข้าใจว่า “Cascading OKR” คือการ copy Key Results ของ leadership ลงไปให้ทีมล่างรับช่วงต่อ — ทีมล่างก็เอา KR เดิมมาเขียนใหม่ในภาษาตัวเอง แล้วเรียกว่า “alignment แล้ว” สิ่งที่เกิดขึ้นจริงคือ KR ที่ทีมล่างไม่เคยอภิปราย ไม่เคยถามว่า “เราจะ contribute ยังไง” และไม่มีใครเชื่อตั้งแต่วันแรก ผลลัพธ์ปลายไตรมาส: ทีมล่างปิดงาน 30% ทีมบนคิดว่า cascade พัง ทั้งที่ปัญหาจริงคือ cascade ไม่เคยเกิดขึ้นเลย — มันเป็นแค่ top-down dump บทความนี้จะแยกให้เห็นว่า cascading OKR ที่ใช้งานได้จริงต้องมีอะไรบ้าง
ทำไม Cascading OKR ส่วนใหญ่พัง
หลังจากเห็นองค์กรหลายแห่งใช้ cascading OKR แล้วล้มเหลว รูปแบบความล้มเหลวซ้ำกันเป็น pattern ชัดเจน 5 อย่าง:
1. Top-down dump: CEO/leadership เขียน Company OKR เสร็จแล้วส่งให้ Department Head พร้อมคำสั่ง “ช่วย break down ลงทีม” โดยไม่มี workshop ไม่มี discussion — ทีมล่างได้รับ KR ของตัวเองทาง email ไม่เคยมีโอกาสถามว่า “realistic ไหม” หรือ “เราทำไหวจริงหรือเปล่า”
2. KR ทีมล่าง = paraphrase ของ KR ทีมบน: ถ้า Company KR คือ “เพิ่ม revenue 25%” ทีม Sales ก็เขียน “เพิ่ม revenue 25%” ทีม Marketing ก็เขียน “เพิ่ม revenue 25%” — ไม่มีใครแยกว่าตัวเองรับผิดชอบ ส่วนใด ของ revenue นั้น สุดท้ายไม่มีใครรับผิดชอบเฉพาะเจาะจง
3. ไม่มี horizontal alignment: Cascading vertically (บน → ล่าง) อย่างเดียวไม่พอ Marketing ตั้ง KR ส่ง MQL 1,200 leads แต่ Sales ตั้ง KR รับ SQL 400 deals — ไม่มีใคร reconcile conversion rate ว่ามันสมเหตุสมผลกัน เมื่อถึงไตรมาส Marketing ส่ง 1,200 จริง แต่ 70% ไม่ qualify Sales โทษ Marketing, Marketing โทษ Sales
4. Dependency hidden until it breaks: ทีม Product มี KR “launch feature X ภายใน Q2” — ทีม Engineering ไม่รู้ว่ามี KR นี้อยู่ จนกระทั่งสัปดาห์ที่ 8 Product มาตามงาน Engineering พบว่า resource ถูกจองไปทำ infra refactor แล้ว dependency โผล่ตอนสายเกินไป
5. Leadership ไม่ revisit alignment กลางไตรมาส: Cascade ที่ตั้งวันแรก ไม่ได้สมบูรณ์เสมอ — แต่ส่วนใหญ่ leadership ตั้งเสร็จแล้ว “ปล่อยให้ทีมรัน” จนถึง Quarterly Review พอ alignment หลุด ก็ไม่มีใคร re-align จนสายไป
3 รูปแบบของ Cascading ที่ใช้ได้จริง
ไม่ใช่ทุกองค์กรเหมาะกับ cascading แบบเดียวกัน เลือกตาม maturity ของ team และ size ขององค์กร
| รูปแบบ | วิธีทำงาน | ข้อดี | ข้อเสีย | เหมาะกับ |
|---|---|---|---|---|
| 1. Pure Top-Down | Leadership ตั้ง Company OKR → กระจายลงทุก department โดย Department Head เขียน KR ของทีมตาม | เร็ว ชัดเจน คุม direction ได้ | ทีมล่างไม่มี ownership, KR หลุดความเป็นจริง, ไม่มี horizontal check | องค์กรใหม่ ยังไม่มี OKR culture, ช่วง crisis ที่ต้อง pivot เร็ว |
| 2. Negotiated Cascade | Leadership ตั้ง Company OKR เป็น direction → Department Head ต่อรอง KR กับทีมตัวเอง → ส่งกลับขึ้นไป confirm | มี ownership ทุก level, KR realistic ขึ้น, alignment vertical แข็งแรง | ใช้เวลา 2–3 สัปดาห์ใน planning, ยัง miss horizontal alignment ได้ | องค์กรขนาด 50–500 คน ที่มี OKR culture พื้นฐานแล้ว |
| 3. Aligned/Networked OKR | Company OKR + Department OKR + Team OKR ตั้งพร้อมกันใน workshop เดียว — ทุกทีมเห็น dependency แบบ explicit | Horizontal alignment ดีที่สุด, dependency ไม่ hidden, ทีม cross-functional ทำงานได้ | ต้องใช้ facilitator มืออาชีพ, ใช้เวลา planning เยอะ, ต้องมี tool ช่วย visualize | องค์กร 200+ คน ที่มี cross-functional dependency เยอะ |
การ setup ที่ใช้งานจริงในไทยส่วนใหญ่ที่เห็นได้ผลคือ Negotiated Cascade + horizontal alignment workshop — เป็นทางสายกลางระหว่าง pure top-down กับ networked แบบเต็มรูปแบบ ตั้งและติดตาม OKRs อย่างมีประสิทธิภาพ มี framework เพิ่มเติมเรื่อง planning workflow ที่ใช้คู่กับ cascading
โครงสร้าง Cascade ที่ใช้งานได้ — ตัวอย่างองค์กร
สมมติบริษัท SaaS B2B ขนาด 80 คน Q2 มี Company Objective: “เพิ่มกำลังการเติบโตอย่างยั่งยืน เพื่อปูทางไป Series A” โดยมี Company KR: เพิ่ม ARR 25% (จาก 40M → 50M) ตัวอย่างนี้แสดง cascade ที่ “contribute จริง” ไม่ใช่ paraphrase
| Level | ทีม | Key Result | Contribute ยังไง |
|---|---|---|---|
| Company | — | เพิ่ม ARR จาก 40M → 50M | เป้าหมายรวมที่ทุกทีมต้องร่วม |
| Department | Sales | ปิด New ARR 8M (จาก 80 deals × ~100K avg) | รับผิดชอบ 80% ของ growth ใหม่ |
| Department | Marketing | ส่ง SQL 250 (conversion 32% → 80 deals) | Feed Sales pipeline ให้พอ |
| Department | Customer Success | เพิ่ม NRR จาก 105% → 115% (= 4M expansion) | ลด churn + เพิ่ม upsell ใน existing |
| Team | Sales — Enterprise Squad | ปิด 20 deals × 200K = 4M ARR | Segment ที่ทำ revenue สูงสุด |
| Team | Sales — SMB Squad | ปิด 60 deals × 67K = 4M ARR | Volume play |
| Team | Marketing — Demand Gen | สร้าง MQL 1,000 (40% → 400 SQL → ส่ง 250 SQL qualified) | ต้นน้ำ pipeline |
| Team | CS — Account Management | Upsell 30 accounts × ~130K = ~4M expansion | มาจาก 200 enterprise accounts ที่มีอยู่ |
สังเกต: ไม่มี KR ทีมไหน “copy” Company KR — ทุก KR เป็นชิ้นที่ คำนวณกลับไปได้ เป็น 10M ใหม่ + ลด churn 4M = 14M growth → match กับ Company KR ที่ต้องการ จะเห็นได้ว่า Sales ไม่ได้รับผิดชอบ 25% growth ทั้งหมด — แต่รับ 8M (16% ของ ARR base) ส่วนที่เหลือมาจาก expansion (CS) นี่คือ cascade ที่ contribute จริง
Horizontal Alignment — ที่หายไปบ่อยที่สุด
Cascading content เกือบทุกบทความพูดเรื่อง vertical (บน → ล่าง) แต่ปัญหา 70% ของ cascade ที่พังคือ horizontal — KR ของทีมหนึ่ง dependent กับ KR ของอีกทีม โดยที่ทั้งคู่ไม่รู้
กลับมาที่ตัวอย่างข้างบน: Marketing ตั้ง KR ส่ง SQL 250 → Sales ตั้ง KR ปิด 80 deals จาก 250 SQL conversion 32% สิ่งที่ต้อง align horizontally:
- SQL definition ตรงกันไหม? Marketing นับ “คุยแล้ว” Sales นับ “qualified BANT” → ตัวเลขจะไม่ match
- Conversion rate 32% เป็นค่าจริงในอดีตหรือเป็นความหวัง? ถ้าจริงๆ history คือ 22% → Marketing ต้องส่ง 360 SQL ไม่ใช่ 250
- SLA การ follow up: Sales ต้อง contact ภายใน 24 ชม. ไม่งั้น lead เย็น — ต้อง KR ทีม Sales เพิ่มไหม?
วิธีแก้คือทำ Alignment Map — ตารางง่ายๆ ที่แต่ละแถวคือ “dependency คู่” บอกว่าทีม A ต้องส่งอะไรให้ทีม B เมื่อไร และทั้งคู่ตกลงตัวเลขร่วมกัน
| From | To | What | Quantity | Cadence | SLA |
|---|---|---|---|---|---|
| Marketing | Sales | SQL ที่ผ่าน BANT | 250 / quarter | Weekly delivery | Contact ภายใน 24 ชม. |
| Sales | CS | Handoff ลูกค้าใหม่ | 80 deals / quarter | Within 3 days of close | Onboarding kick-off ภายใน 7 วัน |
| CS | Product | Feature request จาก enterprise | ~5 / month | Monthly review | Response ภายใน 14 วัน |
| Product | Marketing | Launch material สำหรับ feature ใหม่ | 2 launches / quarter | 2 สัปดาห์ก่อน launch | — |
Alignment Map ทำให้ dependency ที่เคย hidden กลายเป็น explicit ทุกทีมเห็นว่าตัวเองพึ่งใคร และใครพึ่งตัวเอง เมื่อทีมหนึ่ง miss ทีมอื่นรู้ทันที ไม่ใช่ไปรู้ตอน Quarterly Review เรื่องนี้เกี่ยวข้องกับ failure pattern ที่อธิบายใน ทำไม OKR ล้มเหลว — เกือบครึ่งของ failure case มาจาก horizontal misalignment ที่ไม่ถูก surface
Cadence ที่ทำให้ Cascade ไม่หลุด
Cascade ตั้งวันเดียวจบไม่ได้ ต้องมี cadence รักษาแนวตลอดไตรมาส:
Quarterly Planning (Week 0)
- Workshop 2 วันเต็ม — Day 1: Leadership ตั้ง Company OKR + Department Head ต่อรอง KR Day 2: Department Head + Team Lead ต่อรอง Team OKR + ทำ Alignment Map
- Output: cascade tree + alignment map + commit
Weekly Check-in (ทุกสัปดาห์)
- 15 นาที / ทีม — update progress, flag dependency ที่ delay, escalate ถ้า horizontal alignment เริ่มหลุด
- ดู workflow ที่ใช้ได้จริงใน Weekly OKR Check-in Template
Mid-quarter Re-alignment (Week 6–7)
- Critical step ที่หายไปบ่อย — Department Head ทุกคนเจอกัน 1 ชม. review alignment map ดูว่า dependency ไหนหลุด, ทีมไหน at risk
- ถ้าจำเป็น — ปรับ KR ของทีมที่ over-committed (transparent, ไม่ใช่ลด target ลับๆ)
Quarterly Review + Retrospective
- Score OKR + วิเคราะห์ว่า cascade ส่วนไหนพัง horizontal alignment ส่วนไหน effective
- Feed กลับเข้า planning ของไตรมาสถัดไป
โดยไม่มี mid-quarter re-alignment cascade จะหลุดเงียบๆ — ใช้ tool อะไรในการรักษา cadence อ่านเพิ่มเติมที่ OKR ด้วย Excel หรือ Software โดยเฉพาะส่วนที่พูดเรื่อง alignment visibility — Excel ทำ vertical cascade ได้ แต่ horizontal alignment พังเสมอ
5 ข้อผิดพลาดที่ทำให้ Cascading OKR พัง
| # | ข้อผิดพลาด | อาการ | วิธีแก้ |
|---|---|---|---|
| 1 | Top-down dump | ทีมล่างไม่มี ownership, ทำเพราะถูกสั่ง | เปลี่ยนเป็น Negotiated Cascade — ให้ทีมล่างต่อรอง KR ของตัวเอง |
| 2 | KR ทีมล่าง = paraphrase ของ KR ทีมบน | ทุกทีมรับผิดชอบเป้าเดียวกัน → ไม่มีใครรับผิดชอบจริง | ใช้ “contribute calculation” — แสดงตัวเลขว่าทีมรับผิดชอบ X% ของ company KR |
| 3 | ไม่มี horizontal alignment | ทีม A miss target → ทีม B รู้ตอน Q-review | ทำ Alignment Map ใน Quarterly Planning + review weekly |
| 4 | Dependency hidden | ทีม X รอ deliverable จากทีม Y โดย Y ไม่รู้ | Document dependency เป็น “From → To” table + visible ให้ทุกทีม |
| 5 | ไม่ revisit mid-quarter | Cascade ตั้ง Week 0 → ปล่อยรัน → พังเงียบๆ | Schedule mid-quarter re-alignment Week 6–7 บังคับให้ Department Head เจอกัน |
สรุป
Cascading OKR ที่ใช้งานได้จริงไม่ใช่การ copy KR ลงทีมล่าง — แต่คือการสร้าง contribution chain ที่ตัวเลขทุก level บวกกลับขึ้นไปได้ + horizontal alignment map ที่ทำให้ dependency ระหว่างทีม visible + cadence ที่บังคับให้ leadership ทบทวน alignment กลางไตรมาส ขาดส่วนใดส่วนหนึ่ง cascade จะหลุดเงียบๆ และเจอตอน Q-review ก็สายเกินไป
ทีมของคุณเห็น OKR ของทีมอื่นที่เกี่ยวข้องแบบ real-time หรือไม่? ถ้ายังต้อง update Excel หรือรอ slide deck รายเดือน — alignment infrastructure ขององค์กรคุณยังไม่ทันกับ cadence ที่ cascade ต้องการ การเห็น KR ของทีมที่เรา dependent อยู่แบบ real-time คือเส้นแบ่งระหว่าง cascade ที่ใช้งานได้กับ cascade ที่พังเงียบๆ