Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười tech lead ở Việt Nam về DEI (Diversity, Equity, Inclusion — Đa dạng, Công bằng, Hòa nhập), bạn sẽ nghe được hai luồng phản ứng phổ biến. Một là "đó là chuyện của HR, không phải việc của tôi". Hai là "đó là chuyện của công ty Mỹ, ở Việt Nam mình đâu có phân biệt chủng tộc". Cả hai cách nghĩ này đều là những cái bẫy khiến team của bạn yếu đi mà bạn không nhận ra.
Sự thật là DEI trước hết là một bài toán về chất lượng kỹ thuật, không phải chỉ là một chỉ tiêu đạo đức hay PR. Các nghiên cứu lớn của McKinsey (báo cáo "Diversity Wins" 2020, khảo sát hơn 1000 công ty) cho thấy nhóm doanh nghiệp có đội ngũ đa dạng nhất về giới tính có xác suất vượt trội lợi nhuận cao hơn 25% so với nhóm kém đa dạng nhất; đa dạng về sắc tộc thì con số là 36%. BCG cũng chỉ ra rằng công ty có ban lãnh đạo đa dạng tạo ra doanh thu từ đổi mới (innovation revenue) cao hơn 19 điểm phần trăm. Với một tech lead, ý nghĩa rất cụ thể: team đa dạng ship sản phẩm tốt hơn vì họ nhìn thấy nhiều edge case hơn, ít bị group-think hơn, và phản ánh đúng hơn tập người dùng thực tế mà sản phẩm phục vụ.
Bài này không dạy bạn làm chính sách nhân sự cấp công ty. Nó dạy bạn — người trực tiếp dẫn dắt vài kỹ sư — hiểu ba khái niệm D, E, I khác nhau ra sao, chúng ảnh hưởng thế nào đến chất lượng kỹ thuật, và bạn có thể làm gì trong phạm vi quyền lực rất hữu hạn của mình để team vừa đa dạng hơn, vừa mạnh hơn.
Khái niệm cốt lõi
Diversity, Equity, Inclusion — ba thứ khác nhau
Nhiều người dùng "DEI" như một khối chữ dính liền, nhưng ba chữ này chỉ ba việc rất khác nhau và bạn phải phân biệt được.
Diversity (Đa dạng) là câu hỏi "trong phòng có những ai?". Đó là sự đa dạng về giới tính, độ tuổi, xuất thân vùng miền, trường lớp (không phải ai cũng từ Bách Khoa hay FPT), background nghề nghiệp (người tự học code, người chuyển ngành), tình trạng khuyết tật, và cả đa dạng về cách tư duy. Diversity là con số đầu vào — bạn đếm được nó.
Inclusion (Hòa nhập) là câu hỏi "những người trong phòng có thực sự được lên tiếng và được lắng nghe không?". Bạn có thể tuyển được một nữ kỹ sư giỏi, nhưng nếu trong mọi buổi design review cô ấy không bao giờ được nói hết câu, ý kiến bị bỏ qua, thì bạn có diversity mà không có inclusion. Diversity là được mời đến bữa tiệc; inclusion là được mời lên sàn nhảy.
Equity (Công bằng) là câu hỏi "điểm xuất phát và cơ hội có được điều chỉnh cho công bằng không?". Đây là chỗ dễ nhầm nhất. Equity khác Equality (cào bằng). Equality là cho mọi người cùng một thứ; equity là cho mỗi người thứ họ cần để có cơ hội ngang nhau. Ví dụ: một junior mới ra trường và một junior là mẹ đơn thân đi làm lại sau nghỉ sinh — cho cả hai cùng một khối lượng on-call ban đêm là "bình đẳng" nhưng không "công bằng".
Vì sao đa dạng lại tạo ra kỹ thuật tốt hơn
Cơ chế không phải phép màu, nó là toán học của việc ra quyết định.
Thứ nhất là giảm group-think. Khi cả team đều là nam, cùng độ tuổi 25-30, cùng học một trường, cùng dùng iPhone đời mới, cùng đường truyền cáp quang 300Mbps, họ có xu hướng đồng thuận nhanh — và đồng thuận sai. Một team như vậy dễ bỏ qua việc người dùng ở tỉnh dùng máy Android tầm trung với mạng 3G chập chờn.
Thứ hai là broader edge case awareness (nhận biết trường hợp biên rộng hơn). Đây là ví dụ kinh điển: các hệ thống nhận diện khuôn mặt đời đầu của nhiều hãng lớn có tỷ lệ lỗi cao với da sẫm màu và với phụ nữ, đơn giản vì đội xây dựng và bộ dữ liệu huấn luyện thiếu đa dạng. Không ai cố tình; họ chỉ không có người trong phòng để hỏi "khoan, cái này chạy với người khác chúng ta thì sao?".
Thứ ba là phản ánh người dùng. Nếu sản phẩm của bạn phục vụ phụ nữ Việt Nam (ví dụ một app thương mại điện tử mỹ phẩm) mà team engineering 100% là nam, bạn đang thiết kế cho một tập người dùng mà không ai trong team thực sự là.
Phạm vi quyền lực của tech lead
Quan trọng: bạn không phải CEO, không đặt ra được chính sách lương toàn công ty hay chỉ tiêu tuyển dụng. Nhưng bạn kiểm soát bốn thứ có sức nặng bất ngờ: (1) cách viết job description và cách phỏng vấn cho team của bạn; (2) ai được nói trong các cuộc họp bạn chủ trì; (3) ai được giao task ngon để thăng tiến; (4) văn hóa vi mô hằng ngày. Đó là nơi bạn tạo ra thay đổi thật.
Tình huống thực tế
Tình huống 1 — Team fintech ở TP.HCM và cái nút "tên"
Một startup fintech tại TP.HCM (gọi là công ty A) có team backend 8 người, toàn nam, phần lớn tốt nghiệp cùng một trường. Họ xây form đăng ký với validation tên: chỉ cho phép chữ cái không dấu, tối đa 30 ký tự, không khoảng trắng cuối. Khi ra thị trường, support ngập tickets. Người tên "Nguyễn Thị H'Yên" (tên có dấu nháy, người dân tộc thiểu số) không đăng ký được. Người tên bốn chữ dài hơn 30 ký tự bị cắt. Một khách hàng lớn tuổi để khoảng trắng thừa vì gõ điện thoại bị lỗi.
Diễn giải: Không ai trong team ác ý. Họ chỉ validate theo đúng cái tên của chính họ — ngắn, không dấu, không ký tự đặc biệt. Đây là group-think về mặt dữ liệu. Sau sự cố, team mời một tester nữ lớn tuổi và một bạn quê ở vùng có nhiều đồng bào dân tộc tham gia rà edge case. Trong hai buổi họp, họ phát hiện thêm bảy trường hợp tên hợp lệ mà hệ thống từ chối.
Bài học: Diversity không phải khẩu hiệu — nó trực tiếp cứu bạn khỏi bug production. Một người có background khác trong phòng bằng cả một checklist edge case mà bạn không nghĩ ra.
Tình huống 2 — Nữ senior không được lên tiếng ở Grab-style team
Một team platform tại một công ty tech quy mô khu vực (bối cảnh giả định hợp lý kiểu Grab/Shopee ở Đông Nam Á) tuyển được một nữ senior engineer rất giỏi từ Singapore. Sáu tháng sau cô xin chuyển team. Khi tech lead hỏi lý do, câu trả lời làm anh giật mình: "Trong design review, cứ mỗi lần tôi nêu ý, hai bạn nam ngắt lời. Khi một anh khác nói lại đúng ý đó mười phút sau, cả team gật gù khen hay."
Diễn giải: Công ty có diversity (đã tuyển được cô) nhưng không có inclusion. Hiện tượng này có tên trong nghiên cứu: "hepeating" (đàn ông nhắc lại ý phụ nữ và được ghi công) và "manterrupting" (ngắt lời). Tech lead sau đó áp dụng ba luật họp đơn giản: (1) round-robin — mỗi người nói lượt của mình không bị ngắt; (2) "no interrupt" rule, ai ngắt lời bị nhắc ngay; (3) ghi công đúng người: "ý này ban đầu là của Mai nêu". Ba tháng sau, khảo sát nội bộ về mức độ được lắng nghe của team tăng rõ, và cô senior đó ở lại.
Bài học: Tuyển được người đa dạng chỉ là một nửa việc. Nếu môi trường không cho họ đóng góp thực sự, bạn vừa lãng phí tiền tuyển vừa mất người giỏi. Inclusion là công việc hằng ngày của tech lead trong từng cuộc họp.
Tình huống 3 — On-call và bài toán equity
Một team 6 người ở một công ty SaaS Hà Nội chia lịch on-call "công bằng": mỗi người một tuần xoay vòng, kể cả ca đêm và cuối tuần. Nghe rất fair. Nhưng trong team có một bạn là mẹ của con nhỏ 1 tuổi, và một bạn đang chăm bố bệnh. Cả hai bắt đầu kiệt sức, chất lượng xử lý sự cố ban đêm của họ giảm, rồi một người xin nghỉ.
Diễn giải: Đây là nhầm equality với equity. Tech lead điều chỉnh: cho phép swap ca linh hoạt, ai nhận thêm ca đêm được tính comp-time hoặc phụ cấp, và những người có ràng buộc gia đình được ưu tiên ca ngày. Tổng khối lượng vẫn được chia đủ, nhưng theo nhu cầu thực tế của từng người. Kết quả: MTTR (thời gian trung bình khắc phục sự cố) ban đêm ổn định trở lại vì người trực tỉnh táo hơn.
Bài học: Equity không phải là "dễ dãi" hay "thiên vị". Nó là thiết kế hệ thống để mỗi người đóng góp được ở mức tốt nhất. Với on-call, một người kiệt sức trực đêm còn nguy hiểm hơn là không trực.
Hướng dẫn từng bước
Đây là cách một tech lead áp dụng DEI trong phạm vi thực tế của mình, theo thứ tự ưu tiên.
Bước 1 — Đo cái đang có (baseline). Bạn không quản lý được cái bạn không đo. Đếm thầm: team bạn đa dạng ở những chiều nào, thiếu ở chiều nào? Trong 5 cuộc họp gần nhất, ai nói nhiều nhất, ai gần như im lặng? Ai được giao những task "sáng giá" (feature mới, được demo trước sếp) và ai luôn nhận task bảo trì? Ghi lại, đừng đoán.
Bước 2 — Sửa pipeline tuyển ở khâu bạn kiểm soát. Rà lại job description: bỏ những yêu cầu ngầm gây loại trừ như "cày đêm nhiệt huyết", "văn hóa gia đình bóng đá bia bọt". Nghiên cứu cho thấy JD liệt kê quá nhiều "must-have" khiến ứng viên nữ ít apply hơn nam. Trong vòng phỏng vấn của bạn: dùng bộ câu hỏi chuẩn hóa như nhau cho mọi ứng viên (structured interview) để giảm thiên kiến, và chấm theo rubric thay vì "cảm giác hợp gu".
Bước 3 — Thiết kế họp để inclusion xảy ra. Áp dụng round-robin cho các buổi ra quyết định quan trọng. Với người ít nói, hỏi trực tiếp và tôn trọng: "Lan, em nhìn hướng này thế nào?". Cho phép đóng góp bất đồng bộ (viết comment vào RFC/doc trước họp) để người hướng nội và người không mạnh tiếng Anh vẫn góp được ý chất lượng.
Bước 4 — Phân bổ cơ hội công bằng. Cố tình luân phiên task sáng giá. Nếu bạn để ý một nhóm luôn nhận việc "vô hình" (viết doc, fix bug lặt vặt, tổ chức họp), hãy tái cân bằng. Sự nghiệp thăng tiến nhờ visibility, mà visibility đến từ task được giao.
Bước 5 — Điều chỉnh theo nhu cầu (equity). Linh hoạt on-call, giờ làm, hình thức remote cho người có ràng buộc khác nhau, miễn là kết quả công việc đảm bảo. Đánh giá con người theo output, không theo số giờ ngồi ở bàn.
Bước 6 — Tạo an toàn để nói ra. Điều này liên kết với chủ đề psychological safety (sẽ học sâu ở bài sau), nhưng phần thuộc DEI ở đây là: khi ai đó nêu một vấn đề về hòa nhập, đừng phòng thủ. Cảm ơn họ, và hành động.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi DEI là chỉ tiêu số lượng. "Team phải có 30% nữ" mà không lo đến inclusion sẽ dẫn đến tuyển vào rồi mất người, tệ hơn là không làm gì. Diversity mà thiếu inclusion là cái xô thủng đáy.
Lỗi 2 — Nhầm equity với cào bằng hoặc với hạ chuẩn. Equity không có nghĩa là tuyển người kém hơn hay dễ dãi trong đánh giá. Nó là san bằng điểm xuất phát, không phải san bằng kết quả. Standard kỹ thuật vẫn giữ nguyên cho tất cả.
Lỗi 3 — Tokenism (làm cho có). Mời một người thuộc nhóm thiểu số vào mọi cái ảnh, mọi panel để "trông đa dạng", nhưng không cho họ quyền thực. Điều này còn phản tác dụng hơn không làm gì.
Lỗi 4 — "Culture fit" trá hình. Nhiều team loại ứng viên vì "không hợp văn hóa", mà bản chất là "không giống chúng ta". Hãy đổi sang tiêu chí "culture add" — người này bổ sung được gì mà team đang thiếu?
Lỗi 5 — Tưởng Việt Nam không có vấn đề DEI. Ta không có nhiều vấn đề sắc tộc kiểu Mỹ, nhưng có rất nhiều chiều khác: định kiến giới trong ngành tech (nữ vẫn bị nghi ngờ năng lực kỹ thuật), phân biệt trường/vùng miền, kỳ thị người tự học hoặc chuyển ngành, và bỏ quên nhu cầu của người có gia đình. DEI ở Việt Nam có màu sắc riêng, nhưng có thật.
Mẹo: Bắt đầu nhỏ và cụ thể. Đừng cố "làm DEI" như một dự án lớn. Chọn một hành động — ví dụ áp dụng round-robin trong standup tuần này — làm cho tốt, rồi mở rộng. Thay đổi văn hóa đến từ những vi hành động lặp lại nhất quán, không đến từ bài diễn văn.
Bài tập thực hành
- Audit inclusion cá nhân. Trong cuộc họp technical tiếp theo bạn chủ trì, âm thầm ghi lại: mỗi người nói bao nhiêu lần, ai bị ngắt lời, ý của ai được ghi công. Sau họp, đối chiếu với cảm nhận ban đầu của bạn. Bạn có ngạc nhiên không?
- Rà một JD. Lấy một job description của team bạn (hoặc tự viết một cái). Gạch chân mọi cụm từ có thể gây loại trừ ngầm (yêu cầu quá đà, ngôn ngữ thiên về một nhóm). Viết lại cho trung lập và hấp dẫn với tập ứng viên rộng hơn.
- Phân bổ task. Liệt kê 10 task lớn gần nhất của team và ai đảm nhận. Ai nhận task "sáng giá", ai nhận task "vô hình"? Vẽ một kế hoạch luân phiên cho quý tới.
- Thiết kế lại một quy trình theo lăng kính equity. Chọn on-call hoặc lịch làm việc. Viết một phương án linh hoạt vẫn đảm bảo tổng khối lượng và chất lượng, nhưng phù hợp nhu cầu đa dạng của thành viên.
- Tìm một edge case bị bỏ quên. Chọn một tính năng team vừa ship. Tự hỏi: "Tính năng này chạy thế nào với người dùng rất khác chúng ta — lớn tuổi, mạng yếu, tên đặc biệt, khuyết tật thị giác?". Ghi ra ba edge case bạn nghĩ team đã bỏ qua.
Tóm tắt
DEI trong engineering trước hết là một đòn bẩy chất lượng kỹ thuật, không phải chỉ là nghĩa vụ đạo đức. Ba chữ D-E-I là ba việc khác nhau: Diversity là ai có trong phòng (đầu vào đếm được), Inclusion là họ có thực sự được lên tiếng và lắng nghe không (văn hóa hằng ngày), Equity là điểm xuất phát và cơ hội có được điều chỉnh công bằng không (khác với cào bằng). Team đa dạng và hòa nhập ship sản phẩm tốt hơn vì họ ít group-think, nhìn thấy nhiều edge case hơn, và phản ánh đúng người dùng thật — như ba tình huống về form đăng ký lỗi, nữ senior bỏ đi, và on-call kiệt sức đã cho thấy.
Là tech lead, bạn không đặt chính sách công ty, nhưng bạn kiểm soát bốn đòn bẩy mạnh: cách phỏng vấn, ai được nói trong họp, ai được giao task ngon, và văn hóa vi mô hằng ngày. Hãy đo baseline, sửa pipeline tuyển ở khâu của bạn, thiết kế họp để inclusion xảy ra, phân bổ cơ hội công bằng, và điều chỉnh quy trình theo nhu cầu thật. Tránh các bẫy: coi DEI là chỉ tiêu số lượng, nhầm equity với hạ chuẩn, tokenism, "culture fit" trá hình, và ảo tưởng "Việt Nam không có vấn đề". Bắt đầu nhỏ, nhất quán, và nhớ rằng mỗi người có background khác trong phòng chính là một lớp bảo vệ khỏi những sai lầm mà một mình bạn không bao giờ nhìn thấy.