Làm gì khác đi để scale tốt hơn

Bài viết trước của mình có tiêu đề về scale nhưng giống review kể chuyện hơn, bài viết này mình muốn chia sẻ thêm về những vấn đề có thể cần làm khác đi khi 1 team, 1 tổ chức muốn phát triển nhanh hơn

0. Lựa việc nào giúp scale mà làm

Khi làm việc gì, cần xem nó có giúp mình scale không. Scale có nhiều cách hiểu nhưng cách đơn giản nhất là nếu làm việc này nó sẽ có ích không chỉ cho lần này mà còn có tác dụng về sau thì là scale.

Ví dụ

• Dành thời gian vào việc tuyển dụng, sẽ có thêm nhân lực cho team, các nhân lực mới sẽ giúp team hoàn thành thêm nhiều việc khác sau này
• Dành thời gian training cho 1 bạn, bạn ấy sẽ đóng góp được nhiều hơn trong tương lai
• Giải thích vì sao cần làm 1 tính năng, dự án và làm cho team cảm thấy hào hứng --> team sẽ chủ động tìm tòi cách để giải quyết --> manager đỡ mất thời gian ngồi micro-manage

1. Dám giao việc

1  số bạn manager có background technical thường quen tự làm, cái nào thấy team làm chậm sẽ nhảy vào làm cho nhanh. Vậy nó giải quyết nhanh nhưng về lâu dài có 1 vài hạn chế

• Bạn nào làm chưa được sẽ không có cơ hội làm để rèn luyện thêm kĩ năng và khả năng chịu áp lực (làm sai, nghe user hoặc Product dí, làm lại được)
• Team sẽ thiếu động lực tự thân vận động vì thấy trường hợp nào nguy cấp thì có người hỗ trợ rồi
• Manager sẽ thiếu thời gian cho planning và nghĩ những cái giúp team scale (là công việc chính của người manager)

Người manager cần cân bằng giữa việc nhảy vào làm (thỉnh thoảng vẫn cần) và việc coaching, đưa ra hướng đi, để team làm, chấp nhận công việc sẽ chậm 1 chút hoặc có khi bị manager của mình phàn nàn (nên keyword là cần "dám") để đổi lại là team sẽ chủ động hơn trong tương lai. Đây là 1 khoản đầu tư.

2. Không quên bức tranh tổng quát

Thường sẽ có 3 level khi tiếp cận giải quyết vấn đề

• junior thì mới nhảy vào vấn đề gì cũng sẽ muốn giải quyết triệt để, thiết kế lại mọi thứ, đập đi làm lại cho xịn hơn
• senior thì sẽ đánh giá và giải quyết từ cái low-hanging fruit và có nhiều impact trước

Nhưng senior sẽ rất dễ từ từ quen ... dừng sau khi giải quyết low-hanging frut, "để mốt sửa triệt để sau" và cái "mốt" đó thường không bao giờ tới. Đôi khi cần hạ quyết tâm "sửa triệt để" và chấp nhận việc này

• sẽ lâu
• khó thấy impact ngay

Đây là lúc cần sự thông cảm của manager dành cho team nếu chưa thấy được ngay kết quả của dự án

3. Critical thinking

Luôn nghĩ xem còn còn gì có thể làm tốt hơn không, có gì mình tính thiếu không. Ví dụ

• Thấy số đẹp thì nghĩ xem có gì sai không
• Thấy estimate nhanh thì xem có thiếu assumption nào không

Khi có vấn đề gì xảy ra, cần làm incident report chi tiết và ghi lại thành tài liệu. Nó không nhằm đổ trách nhiệm chỉ cho cá nhân (mặc dù vẫn cần nêu rõ những ai, team nào liên quan) mà nhằm thể hiện là mình

• nghiêm túc trong việc tìm ra nguyên nhân gây lỗi
• thật sự hiểu nó (thật sự hiểu thì mới viết ra giải thích rõ ràng được)

Đồng thời rút ra được những bài học nào để lần sau không bị lại cùng vấn đề (ví dụ rút ra  cần cải tiến qui trình ra sao, vì đa phần lỗi sẽ liên quan qui trình hơn là cá nhân cụ thể)