โพสต์นี้เขียนตอนที่ผมกำลังจะขึ้นไลฟ์ครั้งแรกในชีวิตครับ หัวข้อคือ Productivity in Engineering Organization เอาจริงๆ ตื่นเต้นมาก เพราะปกติผมเป็นคนชอบจดชอบเก็บความรู้ไว้กับตัวมากกว่า แต่พอต้องเอาเรื่องที่คิดอยู่ในหัวมาเรียบเรียงให้คนอื่นฟัง มันบังคับให้เราต้องคิดให้ชัดขึ้นจริงๆ
สิ่งที่ผมอยากสื่อในวันนั้นคือ productivity ในองค์กรไม่เหมือน productivity ส่วนตัวครับ เวลาเราพูดถึง productivity ส่วนตัว เรามักนึกถึงการทำงานให้เร็วขึ้น จดให้เป็นระบบขึ้น แต่พอเป็นระดับทีมหรือองค์กร ตัวชี้วัดที่แท้จริงไม่ใช่ว่าคนคนเดียวพิมพ์โค้ดได้เร็วแค่ไหน แต่คือทั้งทีมส่งของออกไปได้ลื่นแค่ไหนต่างหาก
จุดที่ผมว่าสำคัญที่สุดคือ การลดแรงเสียดทาน ครับ งานวิศวกรรมส่วนใหญ่ที่ช้า ไม่ได้ช้าเพราะคนเขียนโค้ดช้า แต่ช้าเพราะรอ รออนุมัติ รอ review รอ environment รอความชัดเจนว่าจะทำอะไรกันแน่ ถ้าเราไปโฟกัสที่การเร่งคนให้พิมพ์เร็วขึ้น มันแก้ไม่ตรงจุด สิ่งที่ควรทำคือไปหาว่าตรงไหนที่งานมันค้าง แล้วเอาสิ่งกีดขวางตรงนั้นออก
อีกเรื่องคือเครื่องมือและ process ควรช่วยลดภาระทางความคิด ไม่ใช่เพิ่ม ถ้าทุกครั้งที่จะเริ่มงานต้องเสียพลังไปกับการนึกว่า “ต้องทำตามขั้นตอนอะไรบ้าง” นั่นแปลว่าระบบยังออกแบบมาไม่ดีพอ ระบบที่ดีคือระบบที่ทำให้สิ่งที่ถูกต้องเป็นสิ่งที่ทำง่ายที่สุดโดยอัตโนมัติ
การได้เตรียมไลฟ์ครั้งนี้สอนผมอย่างหนึ่งครับ ว่าการแบ่งปันความรู้ไม่ได้ให้ประโยชน์แค่กับคนฟัง แต่มันบังคับให้ตัวเราเองเข้าใจเรื่องนั้นลึกขึ้นด้วย
ยาวไปไม่อ่าน สรุปก็คือ:
- productivity ขององค์กรไม่เท่ากับ productivity ส่วนตัว
- ตัวชี้วัดจริงคือทีมส่งของได้ลื่นแค่ไหน ไม่ใช่คนเดียวเร็วแค่ไหน
- งานช้าเพราะ “รอ” มากกว่าเพราะคนช้า — ให้ลดแรงเสียดทาน
- ระบบที่ดีทำให้สิ่งที่ถูกต้องเป็นสิ่งที่ทำง่ายที่สุด
I wrote this just as I was about to do my very first live talk. The topic was Productivity in Engineering Organizations, and honestly I was nervous — I’m usually the type who likes to take notes and keep knowledge to myself. But having to take what’s floating around in my head and arrange it for other people forces you to actually think clearly.
What I wanted to get across that day is that organizational productivity is not the same as personal productivity. When we talk about personal productivity we usually mean working faster, taking neater notes. But at the team or org level, the real metric isn’t how fast one person types code — it’s how smoothly the whole team ships.
The point I think matters most is removing friction. Most engineering work that’s slow isn’t slow because people write code slowly; it’s slow because of waiting — waiting for approval, for review, for an environment, for clarity on what we’re even building. If you focus on pushing people to type faster, you’re solving the wrong problem. What you should do is find where the work stalls and take the obstacle out.
The other thing is that tools and processes should reduce cognitive load, not add to it. If every time you start a task you have to burn energy recalling “what are the steps I’m supposed to follow,” that means the system still isn’t designed well enough. A good system makes the right thing the easiest thing to do, almost automatically.
Preparing this talk taught me one thing: sharing knowledge doesn’t only benefit the audience. It forces you to understand the subject far more deeply yourself.
TL;DR:
- Organizational productivity is not the same as personal productivity.
- The real metric is how smoothly the team ships, not how fast one person is.
- Work is slow because of “waiting,” not slow people — remove friction.
- A good system makes the right thing the easiest thing to do.
