Looking article matching

Làm đúng thì bình thường. Làm sai thì "đúng rồi, con gái mà."

01/06/26 09:27

Cùng một buổi sprint review. Cùng một loại bug. Cùng một kết quả: fixed.

Bạn fix trong hai tiếng - sếp gật đầu: "Giỏi đấy." Minh fix trong ba tiếng - sếp gật đầu: "Thông minh thật."

Hai từ khác nhau. Nghe thoáng qua thì như nhau. Nhưng không phải.

Giỏi là khen kỹ năng. Thông minh là khen con người. Một cái nói về thứ bạn làm được. Một cái nói về thứ bạn là (con gái mà).

Bạn không tưởng tượng ra sự khác biệt đó. Bạn không nhạy cảm quá. Các nhà nghiên cứu đã đo được điều này - bằng số liệu, bằng thí nghiệm có kiểm soát, bằng hàng nghìn bản performance review được phân tích.

Thành công của bạn được giải thích bằng may mắn, bằng nỗ lực, bằng hoàn cảnh thuận lợi. Thành công của họ được giải thích bằng năng lực. Hai cùng một kết quả - hai cách đọc khác nhau.

Đó không phải nghịch lý ngẫu nhiên. Đó là cơ chế - và nó có tên.

Áp lực phải giỏi gấp đôi - không ai nói thành lời, nhưng ai trong cuộc cũng biết

ap-luc-phai-gioi-gap-doi-khong-ai-noi-thanh-loi-nhung-ai-trong-cuoc-cung-biet

Nếu bạn là phụ nữ trong ngành IT, bạn có thể chưa nghe tên "prove-it-again bias" - nhưng bạn đã sống trong nó.

Đó là buổi presentation bạn chuẩn bị kỹ gấp đôi so với đồng nghiệp, không phải vì bạn ít tự tin hơn, mà vì bạn biết margin for error của bạn nhỏ hơn. Một lần trình bày vấp váp, và người ta nhớ. Một lần trình bày tốt, và người ta gật đầu rồi tiếp tục - không thêm, không bớt.

Đó là lần bạn raise một bug nghiêm trọng trong code review và phải giải thích ba lần trước khi được ghi nhận. Trong khi đồng nghiệp khác raise bug tương tự và được merge request trong vòng một tiếng.

Đó là hồ sơ xin việc bạn chỉnh đến lần thứ năm trước khi ấn gửi - trong khi biết rằng ứng viên khác với cùng trình độ sẽ không mất nhiều năng lượng đến thế cho một email.

Áp lực phải giỏi gấp đôi không được phát biểu thành lời. Không có ai ngồi xuống và nói: "Vì bạn là con gái, bạn phải chứng minh nhiều hơn." Nó không cần được nói - vì nó đã được học từ đủ mọi nguồn, đủ mọi lần, đến mức bạn tự áp nó lên mình trước khi người khác kịp áp.

Đặt tên cho thứ đang xảy ra: Prove-it-again bias

Prove-it-again bias là khái niệm được nghiên cứu bởi Joan C. Williams và các cộng sự tại Trung tâm WorkLife Law - mô tả hiện tượng phụ nữ, đặc biệt phụ nữ trong các ngành được coi là "nam giới", phải liên tục chứng minh lại năng lực của mình, ngay cả sau khi đã chứng minh.

Đàn ông thường được giả định là có năng lực - và được thể hiện điểm yếu mà không ảnh hưởng đến đánh giá tổng thể. Phụ nữ bắt đầu từ vị trí ngược lại: năng lực được giả định là thấp hơn, và mỗi sai sót đều được ghi nhớ không cân xứng.

Trong thực tế, điều đó hiện diện theo nhiều cách:

  • Trong code review: Feedback cho code của bạn thường chi tiết hơn, đặt câu hỏi nhiều hơn về logic cơ bản - ngay cả khi code đúng và rõ ràng.
  • Trong performance review: Từ ngữ mô tả phụ nữ thường tập trung vào thái độ, sự hợp tác, sự khiêm tốn - trong khi cùng năng lực đó ở đồng nghiệp nam được mô tả bằng ngôn ngữ kỹ thuật, lãnh đạo, tầm nhìn.
  • Trong credit attribution: Ý tưởng của bạn, khi được thực thi bởi người khác, thường về đến người khác trước - như buổi standup sáng thứ Hai ở Bài 02.
  • Trong cơ hội được trao: Những assignment "cấp độ cao" - lead một module, đại diện team trong buổi họp lớn, mentor người mới - thường đến tay người được giả định sẵn là có năng lực. Bạn phải hỏi. Họ được hỏi.

Không có cơ chế nào trong số này là ngẫu nhiên. Tất cả đều là biểu hiện của cùng một pattern gốc: năng lực không được giả định, nên phải liên tục được chứng minh.

Cái vòng lặp mệt mỏi không ai nhìn thấy

Điều khiến prove-it-again bias trở nên đặc biệt tốn sức không phải bản thân việc phải chứng minh - mà là tính vô tận của nó.

Bạn làm tốt một project. Được ghi nhận. Tốt. Nhưng kỳ vọng không tăng theo. Lần sau, bạn vẫn bắt đầu từ điểm xuất phát. Năng lực không được cộng dồn theo thời gian như cách nó được cộng dồn cho người khác.

Đồng nghiệp bạn không cần tự hỏi sau mỗi lần thành công: "Họ có thật sự công nhận mình không, hay chỉ vì project đó dễ?" Họ không cần tự hỏi: "Lần này mình may. Lần sau sẽ lộ thật." Họ không cần dành một phần năng lượng để quản lý cái cảm giác đó.

Bạn thì có.

Và khi cả hai cùng ngồi vào làm việc mỗi sáng, điểm xuất phát về mặt tinh thần của hai người không giống nhau - dù cùng một màn hình, cùng một keyboard, cùng một task.

Đây không phải bi kịch hóa vấn đề. Đây là sự thật mà nhiều nghiên cứu về emotional tax và belonging uncertainty trong môi trường thiểu số đã ghi lại nhất quán. Cái gánh nặng vô hình đó là thật, nó tốn năng lượng thật, và nó ảnh hưởng đến kết quả thật.

Biết tên - và điều đó thay đổi gì

Biết tên của thứ đang xảy ra với mình không giải quyết được vấn đề. Prove-it-again bias vẫn ở đó. Tiêu chuẩn kép vô hình vẫn ở đó. Cái nhìn đó vẫn ở đó.

Nhưng biết tên thay đổi một thứ quan trọng: nó tách bạn ra khỏi cơ chế.

Khi bạn không biết tên, bạn giải thích những gì xảy ra bằng bản thân mình. Có lẽ mình chưa đủ giỏi. Có lẽ mình cần chuẩn bị kỹ hơn. Có lẽ lần sau mình phải khác đi. Bạn internalize một hệ thống bên ngoài thành câu chuyện bên trong về chính mình.

Khi bạn biết tên, bạn có thể đặt câu hỏi: Đây là prove-it-again bias. Đây không phải bằng chứng về năng lực của mình. Đây là pattern có tên, có nghiên cứu, có hàng triệu người khác cũng trải qua.

Điều đó không có nghĩa là bạn phủ nhận mọi góp ý, mọi feedback, mọi phê bình - có những thứ thật sự cần cải thiện và quan trọng để lắng nghe. Điều đó có nghĩa là bạn có khung để phân biệt: cái này là feedback có giá trị, cái kia là noise của hệ thống.

Và khi bạn có thể phân biệt, bạn ngừng để noise của hệ thống lọt vào như thể nó là sự thật về bạn.

Bạn không cần chiến đấu với nó mỗi ngày. Bạn chỉ cần ngừng dùng tiêu chuẩn của người khác để tự đánh giá bản thân mình.

Áp lực phải giỏi gấp đôi - và lựa chọn bạn thật sự có

ap-luc-phai-gioi-gap-doi-va-lua-chon-ban-that-su-co

Không có giải pháp nào ở đây là "cứ làm tốt thì tự khắc được công nhận" - vì nếu cơ chế gốc không thay đổi, làm tốt hơn chỉ nâng thanh chứng minh lên cao hơn.

Nhưng có một lựa chọn nhỏ hơn, cụ thể hơn: chọn tiêu chuẩn bạn dùng để tự đánh giá mình.

Không phải tiêu chuẩn của người luôn hoài nghi. Không phải tiêu chuẩn của hệ thống được xây dựng để giả định bạn chưa đủ. Tiêu chuẩn của chính bạn - dựa trên bằng chứng thật, hành động thật, kết quả thật mà bạn đã tạo ra.

Bạn fix bug đó trong hai tiếng. Đó là sự thật. Bạn đã làm việc này hai năm. Đó là sự thật. Bạn biết mình đang làm gì. Đó là sự thật.

Những sự thật đó không phụ thuộc vào việc ai đó gọi bạn là giỏi hay thông minh - hay không gọi gì cả.

Câu hỏi để lại: Lần cuối bạn tự hào về điều mình làm được - mà không đính kèm câu "nhưng có thể chỉ là may" - là khi nào?

Câu hỏi đó không cần trả lời công khai. Chỉ cần hỏi thật lòng.

Tiếp theo trong series:
Bài 01 · Họ nhìn tôi và thấy "con gái học IT" - không phải lập trình viên
Bài 02 · Căn phòng họp 8 người, và bạn là cô gái duy nhất. Lại.
Bài 04 · Tôi có đủ giỏi không? — câu hỏi tôi hỏi mình mỗi ngày trước khi apply
Follow HR1Tech để đón chờ các bài tiếp theo

HR1Tech - Online Recruitment Platform for the IT Industry

Find jobs and recruitment multi-industry. Discover more at: www.hr1jobs.com

Tôi có đủ giỏi không? — câu hỏi tôi hỏi mình mỗi ngày trước khi apply

"Tôi có đủ giỏi không?" - Khám phá hội chứng Impostor Syndrome ở nữ giới ngành IT. Cùng HR1Tech phá vỡ rào cản tự hoài nghi và tự tin ứng...

Làn sóng sa thải ngành công nghệ 2026: Trí tuệ nhân tạo đang âm thầm tái định nghĩa cấu trúc nhân sự toàn cầu

Nửa đầu năm 2026 chứng kiến một nghịch lý kỳ lạ của thung lũng Silicon: trong khi các báo cáo tài chính của các tập đoàn công nghệ liên...

Khi AI Viết Code Nhanh Hơn Bạn Nghĩ: Áp Lực Đào Thải Hay Cú Lừa Của Thời Đại?

Khi AI viết code nhanh hơn bạn nghĩ là nỗi lo thật của developer. Nhưng AI có thay thế con người hay chỉ đang thay đổi cách lập trình...

Developer Burnout: Đừng Để Dòng Code Cuối Cùng Là Sự Chịu Đựng Của Bạn

Developer burnout không chỉ là mệt mỏi sau giờ làm. Đó là tín hiệu cảnh báo khi áp lực code, deadline và AI khiến lập trình viên cạn năng...

Báo Cáo MarTech 2026: Lương Và Lộ Trình Chuyển Đổi Công Nghệ Số

Phân tích chuyên sâu từ Báo cáo Martech 2026 về sự trỗi dậy của hệ thống tác viên thông minh và tiêu chuẩn kết nối dữ liệu mới dành cho...

Google AI Studio: Công cụ Lập trình AI Đỉnh Cao Cho Mọi Nhà Phát Triển Năm 2026

Làm chủ Google AI Studio 2026 để xây dựng ứng dụng AI với mô hình Gemini. Khám phá các tính năng đột phá và bứt phá sự nghiệp IT cùng nền...