Empathy với engineer và designer

Mở đầu — vì sao bài này quan trọng

Có một sự thật phũ phàng mà nhiều PM mất vài năm mới nhận ra: bạn không tự tay tạo ra giá trị nào cả. Bạn không viết một dòng code. Bạn không vẽ một pixel nào. Mọi thứ khách hàng cầm trên tay — từ nút bấm, animation, đến tốc độ tải trang — đều do engineer và designer làm ra. PM chỉ "đẻ" requirement; engineer và designer mới là người "đẻ" ra sản phẩm thật chạy 24/7 và bị đánh giá bằng chính sản phẩm đó.

Điều này có một hệ quả rất quan trọng về quyền lực: trong hầu hết các công ty product, engineer và designer không report cho PM. Bạn không có quyền ra lệnh. Bạn không quyết định lương, không quyết định promotion của họ. Cách duy nhất bạn khiến sản phẩm tốt được build ra là khiến những con người này muốn làm việc với bạn, tin vào hướng đi bạn đề xuất, và cảm thấy bạn hiểu thế giới của họ.

Đó là lý do empathy với engineer và designer không phải là "kỹ năng mềm cho vui". Nó là điều kiện cần để bạn làm được việc. Một PM mà engineer thấy "ông này không hiểu gì về kỹ thuật, cứ phán bừa", hoặc designer thấy "bà này coi mình như cái máy vẽ theo wireframe", thì dù chiến lược có hay đến đâu cũng sẽ bị âm thầm cản trở: estimate bị thổi phồng, edge case bị phớt lờ, design bị làm cho có. Bài này dạy bạn cách bước vào thế giới của họ — hiểu họ sợ gì, quý gì, đo lường thành công bằng gì — để trở thành người mà cả eng lẫn design đều muốn về cùng một phe.

Khái niệm cốt lõi

Empathy ở đây không phải là "tử tế" hay "dễ tính". Đó là khả năng mô phỏng được thế giới quan của người khác chính xác đến mức bạn dự đoán được phản ứng của họ trước khi mở miệng. Để làm được điều đó với engineer và designer, bạn cần hiểu ba lớp: họ nhìn thế giới thế nào, họ quý điều gì, và đâu là những điểm đau bạn vô tình tạo ra.

Engineer nhìn thế giới thế nào?

Engineer sống trong một thế giới của hệ quả lâu dài. PM nghĩ theo "ship feature này tuần sau"; engineer nghĩ theo "đoạn code này tôi sẽ phải bảo trì hai năm tới". Khi bạn thêm một requirement nhỏ, bạn thấy một dòng trong spec; engineer thấy một nhánh logic mới, một bộ test phải viết, một khả năng vỡ ở production lúc 2 giờ sáng mà họ sẽ là người bị gọi dậy để sửa.

Hãy hiểu cơ chế blame bất đối xứng này: khi feature thành công, người ta nhớ tới PM và ý tưởng. Khi production sập, người ta nhìn vào engineer. Vì vậy engineer có một thiên hướng tự nhiên về sự thận trọng, về "technical debt", về việc làm đúng ngay từ đầu — không phải vì họ thích chậm, mà vì họ là người gánh hậu quả.

Engineer quý những thứ sau:

• Requirement rõ ràng và ổn định. Thứ engineer ghét nhất không phải là việc khó, mà là việc mơ hồ và thay đổi liên tục. Mỗi lần bạn đổi yêu cầu giữa chừng, bạn vứt đi công sức họ đã bỏ ra — và điều đó đau theo nghĩa rất con người.
• Được hiểu "tại sao". Engineer giỏi không muốn là thợ code theo đơn. Khi họ hiểu vấn đề kinh doanh đằng sau, họ thường đề xuất giải pháp tốt hơn cả những gì bạn nghĩ ra.
• Thời gian được tôn trọng. Lập trình cần "deep work" — những khối thời gian dài không bị ngắt quãng. Một cuộc họp 30 phút đặt giữa buổi sáng có thể phá hỏng cả 3 tiếng năng suất.
• Sự trung thực về trade-off. Engineer tôn trọng PM dám nói "tôi chấp nhận nợ kỹ thuật ở đây để kịp deadline, và đây là kế hoạch trả nợ", hơn là PM giả vờ rằng mọi thứ vừa nhanh vừa hoàn hảo.

Designer nhìn thế giới thế nào?

Designer cũng tạo ra một sản phẩm hữu hình, nhưng nỗi đau của họ khác. Công việc của designer mang tính chủ quan hơn nên dễ bị "ai cũng có ý kiến" — từ CEO đến intern đều thấy mình có quyền phán "cái nút này nên màu xanh". Designer thường xuyên phải bảo vệ những quyết định mà người ngoài tưởng là "thẩm mỹ cá nhân" nhưng thực ra dựa trên nguyên tắc về khả năng dùng, về hành vi người dùng, về hệ thống nhất quán.

Designer quý:

• Được tham gia từ đầu, không phải cuối. Cơn ác mộng của designer là bị đưa cho một wireframe đã chốt và bị bảo "làm cho nó đẹp". Họ muốn ngồi cùng bàn lúc định nghĩa vấn đề, vì giải pháp thiết kế tốt nhất thường thay đổi cả cách đặt vấn đề.
• Phản hồi dựa trên vấn đề, không phải giải pháp. "Tôi không thích màu này" là phản hồi tệ. "Tôi lo người dùng lớn tuổi khó đọc chữ này trên nền sáng" là phản hồi vàng — vì nó cho designer một bài toán để giải theo chuyên môn của họ.
• Sự tôn trọng với craft. Khoảng cách giữa "ổn rồi" và "tinh tế" là nơi designer sống. Đừng coi 8 tiếng họ tinh chỉnh spacing là "phí thời gian vào tiểu tiết".
• Quyền truy cập vào người dùng và dữ liệu. Designer khao khát hiểu người dùng thật. Nếu bạn giữ research và data cho riêng mình, bạn đang lấy đi nguyên liệu họ cần để làm tốt.

Mẫu số chung: cả hai đều là "maker"

Điểm cốt lõi cần nhớ: engineer và designer đều là maker — người tạo ra thứ cụ thể và đặt danh tiếng nghề nghiệp vào đó. PM phần lớn là "talker" và "decider". Sự khác biệt về bản chất công việc này tạo ra nhiều xung đột vô hình. Maker cần thời gian liền mạch; talker sống bằng các cuộc họp. Maker sợ thay đổi vì nó phá hỏng thứ đã build; talker thấy thay đổi là "chỉ cập nhật spec thôi mà". Empathy bắt đầu từ việc bạn ý thức được mình thuộc phe nào và chủ động bù trừ cho sự khác biệt đó.

Tình huống thực tế

Ví dụ 1: Cú "estimate thổi phồng" tại một startup fintech ở TP.HCM

Linh là PM tại một startup ví điện tử có khoảng 40 người. Cô để ý một mẫu lặp đi lặp lại: mỗi feature cô đưa ra, team backend đều estimate 3-4 sprint, dài gấp đôi so với cảm nhận của cô. Cô bực bội, nghĩ rằng team "lười" hoặc "sandbag" (cố tình báo cao để dễ thở).

Trong một buổi 1-on-1 với tech lead tên Đức, thay vì chất vấn estimate, Linh hỏi: "Anh dẫn em đi qua một estimate cụ thể được không? Em muốn hiểu thời gian đi đâu." Đức mở ra: tính năng "chuyển tiền" mà Linh nghĩ là đơn giản thực ra phải xử lý idempotency (đảm bảo bấm hai lần không trừ tiền hai lần), reconciliation với ngân hàng đối tác, audit log cho compliance, và rollback an toàn khi giao dịch lỗi giữa chừng. "Phần em thấy là cái nút bấm. Phần bọn em lo là khi 50 nghìn giao dịch chạy đồng thời lúc 8 giờ tối mà server đối tác timeout."

Linh nhận ra estimate không hề thổi phồng — cô chỉ đang nhìn 10% bề nổi. Từ đó cô đổi cách làm: với mỗi feature liên quan tới tiền, cô chủ động hỏi "có rủi ro idempotency, reconciliation hay compliance nào không?" ngay trong buổi viết spec. Engineer thấy được hiểu, và bắt đầu chủ động chia sẻ các trade-off thay vì phòng thủ.

Bài học: Khi một con số có vẻ vô lý, đừng giả định người ta sai. Hãy giả định họ đang nhìn thấy thứ bạn chưa thấy, và hỏi để được dẫn vào thế giới của họ. Empathy thường bắt đầu bằng một câu hỏi tò mò thay vì một lời phán xét.

Ví dụ 2: Designer bị biến thành "máy vẽ" tại một công ty thương mại điện tử

Tại một sàn thương mại điện tử ở Singapore với team product khoảng 200 người, một PM tên Minh có thói quen tự vẽ wireframe khá chi tiết trong Figma rồi đưa cho designer "hoàn thiện UI". Minh nghĩ mình đang giúp tiết kiệm thời gian. Trên thực tế, designer tên Hương cảm thấy bị tước mất phần thú vị nhất của công việc — và sản phẩm cũng tệ đi, vì wireframe của Minh vô tình khóa cứng một luồng (flow) không tối ưu.

Bước ngoặt đến khi tỷ lệ hoàn tất thanh toán (checkout) tụt 6% sau một bản redesign. Trong buổi mổ xẻ, Hương nói thẳng: "Em đã thấy luồng này có vấn đề từ đầu, nhưng anh đưa wireframe chốt rồi nên em nghĩ không phải việc của em đề xuất lại." Câu nói đó khiến Minh giật mình.

Minh thay đổi cách hợp tác: thay vì đưa wireframe, anh bắt đầu mỗi feature bằng một "problem brief" — chỉ mô tả vấn đề người dùng, mục tiêu kinh doanh, ràng buộc, và số liệu hiện tại, không kèm giải pháp UI. Anh để Hương dẫn dắt phần thiết kế. Ba tháng sau, một luồng checkout do Hương thiết kế lại từ gốc đã nâng tỷ lệ hoàn tất lên 9% so với baseline — vượt cả mức trước khi tụt.

Bài học: Khi bạn đưa giải pháp thay vì vấn đề, bạn vô tình hạ cấp designer thành công cụ thực thi và bịt mất chuyên môn quý nhất của họ. Empathy với designer nghĩa là trao bài toán, không trao đáp án.

Ví dụ 3: Cuộc họp giết chết buổi sáng

Tuấn là PM mới, rất nhiệt tình. Anh thích "sync nhanh 15 phút" và hay đặt họp vào 10 giờ sáng — ngay giữa buổi làm việc tập trung của team. Anh không hiểu vì sao mỗi lần đặt họp, engineer lại thở dài và phản hồi nhát gừng.

Một senior engineer cuối cùng giải thích riêng cho Tuấn về khái niệm "maker's schedule vs manager's schedule": với người viết code, một cuộc họp giữa buổi không chỉ tốn 15 phút mà phá vỡ cả trạng thái tập trung sâu, và cần 20-30 phút nữa để vào lại được. Một buổi sáng có ba cuộc "sync nhanh" rải rác đồng nghĩa với một buổi sáng gần như không code được gì.

Tuấn áp dụng ngay vài thay đổi: gom các cuộc họp vào đầu giờ hoặc cuối ngày, chuyển những thứ không cần real-time sang trao đổi bất đồng bộ (async) qua văn bản, và thiết lập "no-meeting afternoon" cho team. Velocity của team tăng rõ rệt trong vài sprint, và quan trọng hơn, engineer bắt đầu thấy Tuấn là người bảo vệ thời gian của họ — một đồng minh chứ không phải nguồn gây nhiễu.

Bài học: Empathy đôi khi nằm ở những thứ rất cụ thể như lịch họp. Hiểu rằng thời gian liền mạch là tài nguyên sống còn của maker, và bảo vệ nó, là một trong những hành động xây niềm tin nhanh nhất bạn có thể làm.

Hướng dẫn từng bước

Đây là một quy trình thực tế để xây dựng và duy trì empathy với eng và design:

• Học đủ ngôn ngữ của họ để hỏi câu hỏi đúng. Bạn không cần biết code hay biết vẽ. Nhưng bạn nên hiểu các khái niệm cốt lõi: với eng là technical debt, edge case, idempotency, scalability, API; với design là design system, accessibility, user flow, fidelity. Đủ để khi họ nhắc tới, bạn gật đầu thật chứ không gật cho qua.

• Trao vấn đề, không trao giải pháp. Mỗi khi bắt đầu một việc, viết một "problem statement" rõ ràng: ai gặp khó, khó ở đâu, tại sao nó quan trọng với kinh doanh, ràng buộc là gì, đo lường thành công bằng gì. Để eng và design tự đề xuất "làm thế nào".

• Mời họ vào sớm, khi mọi thứ còn mềm. Đưa eng và design vào giai đoạn khám phá (discovery), không chỉ giai đoạn thực thi. Quyết định kiến trúc và quyết định thiết kế tốt nhất được đưa ra khi vấn đề còn chưa bị khóa cứng.

• Phản hồi vào vấn đề và mục tiêu, không vào tay nghề. Thay vì "đổi màu này đi", hãy nói "tôi lo người dùng không nhận ra đây là nút bấm được". Bạn nêu mối lo; để chuyên gia chọn cách giải.

• Hỏi "có rủi ro hay trade-off nào tôi chưa thấy không?" Câu hỏi này, hỏi đều đặn, làm hai việc: nó cho bạn thông tin quý, và nó báo hiệu rằng bạn tôn trọng tầm nhìn của họ về những thứ bạn không thấy.

• Bảo vệ thời gian tập trung của họ. Gom họp, dùng async khi có thể, và làm tấm khiên chắn những yêu cầu nhiễu từ bên ngoài. Đây là empathy thể hiện bằng hành động, không bằng lời.

• Khen công khai, đúng người, đúng việc. Khi feature thành công, nêu tên engineer và designer đã làm ra nó trước mặt lãnh đạo. Maker đặt danh tiếng vào sản phẩm; ghi nhận công khai là phần thưởng có ý nghĩa nhất.

Lỗi thường gặp & mẹo

Lỗi: Giả vờ hiểu kỹ thuật để "ghi điểm". Engineer phát hiện ra ngay khi bạn nói bừa về thứ bạn không hiểu, và niềm tin sụp đổ tức thì. Mẹo: thành thật nói "phần này tôi chưa nắm rõ, anh giải thích giúp tôi với" — sự khiêm tốn chân thành xây niềm tin nhanh hơn nhiều so với việc tỏ ra thông thái giả tạo.

Lỗi: Coi estimate cao hay "tiểu tiết thiết kế" là sự lười biếng hoặc cầu toàn vô ích. Mẹo: mặc định rằng có lý do bạn chưa thấy, và đi tìm nó bằng câu hỏi trước khi kết luận.

Lỗi: Đổi requirement liên tục mà không thừa nhận chi phí. Mỗi lần đổi ý, bạn vứt đi công sức của người khác. Mẹo: khi buộc phải đổi, hãy nói rõ "tôi biết điều này làm hỏng phần các bạn đã làm, tôi xin lỗi, và đây là lý do đáng để đổi" — sự thừa nhận làm dịu nỗi đau rất nhiều.

Lỗi: Empathy một chiều, chỉ chiều theo eng và design mà quên kinh doanh. Empathy không có nghĩa là luôn nói "có". Mẹo: hiểu sâu thế giới của họ để có thể giải thích trade-off một cách thuyết phục khi bạn buộc phải nói "không" hoặc "chưa". Empathy là cây cầu hai chiều, không phải sự nhượng bộ.

Mẹo bổ sung — học cách họ ăn mừng và đau khổ. Hãy có mặt khi production sập lúc nửa đêm, dù bạn không sửa được code. Sự hiện diện đó nói lên rằng bạn ở cùng chiến hào, không phải đứng ngoài chỉ tay.

Bài tập thực hành

• Bài tập "dẫn tôi qua estimate". Chọn một feature sắp tới mà bạn thấy estimate có vẻ cao. Trong buổi planning hoặc 1-on-1, hỏi engineer dẫn bạn qua từng phần thời gian đi đâu — với thái độ tò mò, không chất vấn. Ghi lại ít nhất ba thứ kỹ thuật bạn chưa từng nghĩ tới. Mục tiêu: tập kỹ năng nhìn xuống dưới bề nổi.

• Viết lại một brief thành "problem-first". Lấy một tài liệu spec gần đây mà bạn đã đưa kèm giải pháp UI. Viết lại nó: xóa hết phần giải pháp, chỉ giữ vấn đề người dùng, mục tiêu, ràng buộc và chỉ số. Đưa cho designer và quan sát xem họ đề xuất gì khác với những gì bạn đã nghĩ.

• Audit lịch họp của team. Nhìn lại lịch một tuần qua: bạn đã đặt bao nhiêu cuộc họp giữa buổi làm việc tập trung của eng? Thử nghiệm: tuần tới gom toàn bộ họp về đầu hoặc cuối ngày, chuyển ít nhất một cuộc sang async, và hỏi team xem họ cảm nhận thế nào.

• Phỏng vấn thế giới quan. Mời một engineer và một designer mỗi người một buổi cà phê 30 phút. Chỉ hỏi: "Điều gì khiến công việc của bạn khó hơn nó cần thiết? PM nào trong sự nghiệp khiến bạn làm việc tốt nhất, và họ đã làm gì?" Lắng nghe, không phản biện. Tổng hợp lại những điểm chung — đó chính là bản đồ empathy cá nhân của bạn.

Tóm tắt

Empathy với engineer và designer không phải là sự tử tế xã giao — nó là điều kiện để bạn làm được việc, vì họ là người thực sự tạo ra sản phẩm còn bạn thì không, và họ phần lớn không report cho bạn. Engineer sống trong thế giới của hệ quả lâu dài và blame bất đối xứng; họ quý requirement rõ ràng, hiểu được "tại sao", thời gian tập trung và sự trung thực về trade-off. Designer chịu áp lực "ai cũng có ý kiến"; họ quý được tham gia sớm, được trao vấn đề thay vì giải pháp, và được tôn trọng tay nghề. Cả hai đều là maker đặt danh tiếng vào thứ họ làm ra.

Những hành động cụ thể tạo nên empathy: học đủ ngôn ngữ để hỏi đúng, trao vấn đề thay vì đáp án, mời họ vào sớm, phản hồi vào mục tiêu chứ không vào craft, hỏi về rủi ro bạn chưa thấy, bảo vệ thời gian liền mạch của họ, và ghi nhận công khai. Tránh giả vờ hiểu, tránh coi sự thận trọng là lười biếng, và luôn thừa nhận chi phí khi bạn buộc phải đổi ý. Làm được những điều này, bạn không chỉ build ra sản phẩm tốt hơn — bạn trở thành PM mà cả eng lẫn design đều muốn về cùng một phe.