Working backward

Điều mình thích ở cuốn sách này là nó validate (kiểm chứng) nhiều thứ mà Tiki đã hoặc hướng đến để làm, trong đó có nhiều ý tưởng đã được chia sẻ bởi những bạn đã ... từng làm ở Amazon.

Cuốn sách này còn hay ở chỗ không chỉ nói về cái "what" (cần làm cái gì) hoặc "how" (cần làm thế nào) mà còn giải thích khá rõ về cái "why" (tại sao cần phải như vậy). Đối với mình, đặt câu hỏi "why" (hoặc kĩ hơn là "5 whys") và hiểu được cái "why" luôn là cái fundamentals nhất khi giải quyết vấn đề. Nó thể hiện tính cầu thị, sự tò mò, mong muốn hiểu được tận gốc vấn đề để giải quyết nó 1 cách trọn vẹn nhất. Khi đó, không nhất thiết cái mình triển khai nó sẽ giống y hệt như những cái Amazon đã làm, nhưng nó cũng sẽ có khả năng cao là có hiệu quả.

Đây là điểm mà mình thấy thiếu ở 1 số bạn middle-manager từ big corp (kể cả Amz). Họ có thể làm tốt ở môi trường trước đó vì nó đã quá qui củ và chuẩn chỉnh nhưng khi sang môi trường mới, họ không biết nên "bưng" cái nào từ môi trường cũ sang, không rõ nên "focus" vào đâu trước (trong những cái mà họ biết là đáng để focus vì ở môi trường trước đó đã focus vậy), lí do chính là họ không nắm cái "why".

Dưới đây mình đi sâu hơn vào những ý được chia sẻ trong sách, theo mình thấy là đi từ tổng quan công ty (core values có gì) rồi chi tiết xuống tiếp như làm sao để tuyển người tốt (hiring), tuyển xong thì làm sao giúp họ làm việc với hiệu suất tốt nhất (single-threaded leadership), các cách tương tác nên như thế nào (narrative trong meeting) và qui trình làm sản phẩm/dự án nên ra sao (working backward) cũng như cách đánh giá hoạt động công ty thế nào cho rõ ràng chính xác (input metrics)

1. Leadership principle (core values)

Ý chính trong phần này cũng được đề cập trong 1-2 sách về quản trị khác là "core value" không phải cái mình nói hay hô hào suông là được, mà là cái mình cần đưa vào các qui trình và câu chuyện hàng ngày, lập đi lập lại để mọi người thật sự thấy, làm và tin vào nó

Dưới đây là 1 quote mình khá thích, trong cuốn Peopleware

These motivational accessories, as they are called (including slogan coffee mugs, plaques, pins, key chains, and awards), are a triumph of form over substance. They seem to extol the importance of Quality, Leadership, Creativity, Teamwork, Loyalty, and a host of other organizational virtues. But they do so in such simplistic terms as to send an entirely different message: Management here believes that these virtues can be improved with posters rather than by hard work and managerial talent. Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.

2. Hiring (bar riser)

Ở Tiki hồi lâu có 1 bạn Engineering leader từ Amazon khi mới vào đã apply gần như là toàn bộ phần hiring process này. Khi đó nhiều người (kể cả mình) cảm thấy có vẻ không cần thiết và hơi rườm rà (4-5 vòng interview + debrief). Tuy nhiên, sau này khi nhìn lại thì mình cảm thấy đây đúng là 1 trong những cái nên làm đầu tiên tại 1 nơi mới và đúng là nên làm ở Tiki tại thời điểm ấy. Ở scale lớn, chỉ khi có qui trình tuyển dụng tốt thì khả năng thu hút được người tốt mới tăng lên và từ đó mới dẫn đến những thay đổi về chất lượng sản phẩm trong lâu dài.

Về chi tiết thì ý chính của qui trình này là làm sao giảm được càng nhiều càng tốt sự bias (thiên vị) và chủ quan trong qui trình tuyển dụng.

Tăng số vòng tuyển dụng nhằm bớt bias khi chỉ dựa vào sự đánh giá của 1 người (bias hay chọn người giống mình)
Yêu cầu người phỏng vấn cần viết ra đánh giá của mình nhằm giúp giảm bias (hoặc quên) khi cứ nhớ nhớ rồi đánh giá
Có người bar riser để giúp mọi người quen với qui trình và không thỏa hiệp với việc giảm độ khó nhằm tuyển người, cho dù có đang thiếu người đi chăng nữa. 1 sự thỏa hiệp khả năng cao là sẽ dẫn đến nhiều sự thỏa hiệp khác

3. Separable, single-threaded leadership

Phần này nói về quá trình nhận thấy và xử lý vấn đề "các team phải phụ thuộc lẫn nhau" trong phát triển sản phẩm, đặc biệt khi công ty ngày 1 phình to. Nó cũng giải thích sự hình thành của nhiều hướng tiếp cận mà bây giờ đã rất quen thuộc trong công nghệ như API và micro-services, chính là để các team có thể hoạt động độc lập với nhau 1 cách tối ưu nhất.

Có 1 điểm sếp hiện tại của mình (ex-Amazon) hay nói, là bác ấy (vì lớn tuổi hơn mình nhiều) rất coi trọng "accountability" (tinh thần trách nhiệm), trong đó mỗi vấn đề chỉ nên có 1 người để "choke the neck" (nắm đầu hỏi thăm khi có vấn đề). Ngược lại, người đó sẽ được quyền quyết định mọi thứ về vấn đề đó. Mình thấy nó cũng chính là ý tưởng "single-threaded leadership" này.

4. Narratives (write-up rather than Powerpoint)

Ý mình thích nhất trong chương này là khi chuyển sang dùng tài liệu viết cho buổi họp, sự focus của người đọc và của decision maker sẽ không còn nằm ở chuyện người thuyết trình có trình bày 1 cách biểu cảm và thuyết phục hay không, slide trình bày có đẹp đẽ hay không mà nó sẽ được đặt vào đúng cái quan trọng nhất, là nội dung cần trao đổi và sự đầu tư của người viết trong đó. Nó là 1 dạng "substance over form".

Đối với mình đây cũng là điểm thể hiện triết lí "no bullsh*t" của Amazon nói riêng và những công ty muốn làm thật ăn thật nói chung, bạn muốn thuyết phục mọi người điều gì đó, cứ tìm tòi dữ liệu đầy đủ và viết ra đi, mọi người sẽ đọc và đánh giá 1 cách khách quan nhất có thể. Sẽ không có chỗ cho những thứ chim cò, màu mè, qua loa và chém gió đâu :)

Khi triển khai, theo mình cũng có nhiều hướng. Không nhất thiết cái gì cũng cần viết, chỉ cần áp dụng cho những vấn đề tương đối phức tạp. Ngoài ra, việc viết này cần được làm mẫu từ những người manager.

5. Working backward

Ý chính trong phần này tương tự với 1 ý hồi lâu mình đọc trong khóa học về "7 habits of effective people", đó là khi bắt đầu làm cần tính trước kết thúc nó sẽ như thế nào và tính nó kĩ càng nhất có thể, "begin with the end in mind". Đây cũng không phải quá mới nếu so với khi làm Product sẽ cần có mock-up trước khi bắt tay vào code, hoặc như Agile là sẽ làm MVP trước khi làm sản phẩm chi tiết. Ở đây người đọc sẽ lại thấy tầm quan trọng của việc "viết", cụ thể là viết Press Release (PR)/FAQ cho sản phẩm cần xây dựng.

Viết PR chính là lúc mình cần cô đọng lại những gì tinh túy nhất muốn đem lại cho khách hàng, và cũng có thể là lúc gặp phải vấn đề khó nhất: chưa rõ điểm hấp dẫn đó là gì hoặc phát hiện ra những điểm làm cho dự án không khả thi (chi phí xây dựng cao, thị trường tiềm năng nhỏ, phụ thuộc nhiều yếu tố bên ngoài v.v..). Có thể nói, viết PR/FAQ là kết hợp những cái tốt nhất giữa "Powerpoint" (sự cô đọng) và "narrative" (viết dài có phân tích kĩ) ở những phần trên.

6. Metrics

Phần này tổng hợp các ý liên quan việc "dùng metrics" ở Amazon, bắt đầu bằng việc nên quan tâm "controllable input metrics" (metric đầu vào có thể kiểm soát được) hơn là "output metrics". Đây là việc không dễ vì thường người ta sẽ quan tâm những cái có vẻ dễ nắm bắt và chia sẻ, ví dụ như Doanh số, Tăng trưởng. Tuy nhiên, chỉ nhìn vào đó sẽ không biết cần phải tác động vào những gì để cải tiến nó hoặc khi nó giảm cũng sẽ khó biết là do đâu. Đó là lí do Amazon quan tâm nhiều hơn đến việc tìm ra các Input metrics và đặc biệt là làm sao xác định được những input metrics nào là quan trọng

"before you can improve any system ... you must understand how the inputs affect the output of the system"

the right input metrics get the entire organization focused on the things that matter most

1 ý hay nữa tương tự như ở qui trình tuyển dụng cũng có đề cập, là làm sao để "bớt bias" khi thu thập và phân tích số liệu liên quan metrics. Việc thu thập số liệu được gợi ý giao cho 1 bên thứ 3 độc lập không phải business owner (ở Amazon là Finance team). Bên cạnh đó, mọi người được khuyến khích có những cách kiểm tra chéo để đảm bảo là dữ liệu được thu thập đúng như ý đồ sử dụng. Ngoài ra, các câu chuyện lượm lặt (anecdote) cũng được cung cấp thêm cho business owner (ví dụ từ phòng Chăm sóc khách hàng) để giúp họ có cái nhìn tổng quan hơn về qui trình, kết hợp định lượng (metrics) và định tính (anecdote).

As you develop the collection tools, make sure they are measuring what you think they are measuring

Start with the customer and work backwards by aligning your metrics with the customer experience

Buổi meeting dùng để rà soát metrics (ở Amazon gọi là Weekly Business Report - WBR) được tổ chức như thế nào cho hiệu quả cũng được chia sẻ trong sách. Business owner sẽ là người chịu trách nhiệm về các metrics và cần chủ động xem dữ liệu/report trước buổi họp và giải thích khi có sự dao động đáng chú ý ở các metrics đó. Buổi WBR cần được tổ chức đều đặn và tương tự như ở các buổi meeting khác cần giúp mọi người cảm thấy thoải mái khi chia sẻ về các vấn đề phát sinh, tránh blaming.

Tóm tắt lại thì mình thấy có các ý sau nổi bật sau khi đọc cuốn này

tầm quan trọng của việc "làm rõ vấn đề", từ đó dẫn đến 1 công cụ rất thích hợp để làm rõ, đó là "viết"
tầm quan trọng của việc "viết", từ viết chuẩn bị cho cuộc họp đến viết PR/FAQ
viết nói riêng và nhiều việc khác ở Amazon không giới hạn chỉ ở level nào mới cần làm mà ngay cả senior level vẫn cần thực hiện tốt. Nó được ghi rõ trong "Deep dive" (Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.). Điều này khác ở nhiều công ty là senior leader sẽ thường "chỉ tay năm ngón" nhiều hơn
tầm quan trọng của việc "giảm bias", giúp "đánh giá chính xác hơn" (trong tuyển dụng) cũng như "đo lường chính xác hơn" (khi áp dụng input metrics)
self-awareness cao, luôn nghĩ là còn gì đó có thể làm tốt hơn (always day one), luôn suy nghĩ làm sao để làm tốt hơn trong tất cả những việc mình làm, từ tuyển dụng (bar riser), tương tác (single-threaded leadership), meeting (narrative), làm sản phẩm (working backward) và tối ưu qui trình (input metrics)

Còn 1 điểm thú vị nữa mình nghĩ đến, là tại sao những cái có thể coi là "bí thuật" trong cách vận hành của Amazon thì ngày càng được nhiều người biết đến (từ các ex-Amazon khi sang công ty khác hoặc từ những cuốn sách như cuốn này), 1 vài ý cũng đã được nhắc đến trong các sách viết về quản trị, nhưng lại không có quá nhiều công ty đạt được thành công như Amazon ? Câu trả lời theo mình, là ở execution.

Mọi người đều có thể biết Amazon làm gì để xử lí vấn đề này, tuy nhiên mình có đủ kỉ luật và quyết tâm để thực hiện khi gặp vấn đề đó hay không ? Những người khác trong team có đủ kỉ luật và quyết tâm giống mình không (vì chỉ 1 vài người muốn thì sẽ là không đủ) ? Rồi ví dụ có, thì bình thường không nói nhưng khi gặp những vấn đề khác urgent hơn chen vào, mình có ... dám không thỏa hiệp để vẫn kiên định với hướng xử lí ban đầu hay không ? Hay lại muốn "đi đường tắt" chỉ 1 lần thôi (và sẽ dẫn đến các lần khác lúc nào không hay).

Trả lời những câu hỏi đó là trả lời được vì sao ai cũng biết, nhưng không có quá nhiều Amazon như hiện nay :)