← Về trang Blog

🤝 Giver vs Taker — Người tạo giá trị và người lấy giá trị

Trong công việc, người có ảnh hưởng không phải lúc nào cũng là người giỏi nhất. Đôi khi, đó là người làm cho những người xung quanh tốt hơn.

---

🧭 Ba kiểu hành vi trong công việc

Trong môi trường làm việc nhóm — đặc biệt là trong software development — mỗi người thường rơi vào một trong ba kiểu hành vi chính:

1. Giver — Người tạo giá trị

Giver là người chia sẻ kiến thức, hỗ trợ đồng đội, làm rõ vấn đề, giúp người khác tốt lên, và làm cho hệ thống xung quanh vận hành tốt hơn.

Họ không chỉ hỏi: "Tôi làm xong việc chưa?" — Họ hỏi: "Team có tốt hơn nhờ sự có mặt của tôi không?"

2. Taker — Người lấy giá trị

Taker là người ưu tiên lấy lợi ích cho mình trước. Họ có thể giỏi, nhanh, thông minh, nhưng hành vi của họ làm giảm niềm tin trong team.

3. Matcher — Người cân bằng

Matcher sống theo nguyên tắc "có qua có lại". Ai giúp mình thì mình giúp lại. Ai không giúp mình thì mình cũng không cần giúp.

Matcher không xấu. Họ công bằng, có tính trao đổi, và ít khi lợi dụng người khác. Nhưng nếu cả team chỉ toàn Matcher, văn hóa sẽ khó đột phá — vì ai cũng chờ người khác chủ động trước.

---

💡 Giver ≠ Người hy sinh mù quáng

Một hiểu lầm lớn là nghĩ Giver là người tốt bụng đến mức ai nhờ gì cũng làm, cứu mọi việc, ôm hết việc khó, và cuối cùng bị lợi dụng.

Đó không phải Giver trưởng thành. Đó là Selfless Giver — cho đi không có ranh giới.

Giver tốt không làm thay mọi việc. Giver tốt giúp người khác tự làm tốt hơn.

---

🔍 Dấu hiệu của Taker trong công việc

Một người có xu hướng Taker thường có các hành vi sau:

• Chỉ giúp khi có lợi cho mình
• Giữ context để người khác phải phụ thuộc vào mình
• Nhận công khi thành công, tránh trách nhiệm khi thất bại
• Thường nói "việc đó không phải của tôi"
• Tối ưu KPI cá nhân bất chấp ảnh hưởng đến team
• Ít chia sẻ kiến thức
• Review code để thể hiện mình giỏi hơn là giúp code tốt hơn
• Dùng thông tin như lợi thế quyền lực
• Hay kể công của mình nhưng ít ghi nhận đóng góp của người khác
• Khi có lỗi, phản xạ đầu tiên là bảo vệ bản thân

---

🎯 Tại sao Giver tạo ảnh hưởng dài hạn

Giver tạo ảnh hưởng vì họ làm tăng năng lực chung của hệ thống.

Trong team, một cá nhân giỏi có thể giải quyết một việc nhanh. Nhưng một Giver giỏi có thể làm nhiều người khác giải quyết việc tốt hơn.

• Một tài liệu tốt giúp nhiều người onboarding nhanh hơn
• Một buổi chia sẻ debugging giúp cả team xử lý issue tốt hơn
• Một review code chất lượng giúp người viết code tốt hơn lần sau
• Một decision log giúp team hiểu lý do chọn giải pháp và tránh tranh cãi lặp lại
• Một hành động nhận lỗi rõ ràng giúp team tin nhau hơn
• Một lần làm rõ requirement giúp tránh nhiều ngày rework

Về dài hạn, người tạo giá trị cho hệ thống sẽ có influence bền vững hơn người chỉ tối ưu lợi ích riêng.

---

🧩 Giver trong software team

Developer

• Viết code để người khác đọc được, không chỉ máy chạy được
• Viết test giúp team tự tin thay đổi
• Để lại context trong PR description
• Review PR bằng cách giúp người khác tiến lên
• Không giấu context kỹ thuật
• Khi xong task, kiểm tra xem có đang block ai không

Senior Developer

• Không làm "hero" cứu mọi production issue một mình
• Hướng dẫn junior cách suy nghĩ, không chỉ đưa đáp án
• Tạo convention, checklist, decision log
• Giảm bus factor cho team
• Biến kiến thức cá nhân thành tài sản chung

QA

• Báo bug rõ step, expected, actual, evidence, impact
• Không dùng bug để "bắt lỗi" developer, mà giúp sản phẩm tốt hơn
• Chia sẻ pattern lỗi để team phòng tránh
• Tham gia làm rõ acceptance criteria từ sớm

Product Owner / Business Analyst

• Không chỉ ném requirement sang team
• Làm rõ business goal và trade-off
• Giải thích vì sao tính năng quan trọng
• Giúp team hiểu người dùng thực
• Chấp nhận feedback ngược

Tech Lead / Team Lead

• Chia sẻ context thay vì giữ context để giữ quyền lực
• Tạo môi trường mọi người dám hỏi
• Bảo vệ team khỏi nhiều không cần thiết
• Ghi nhận đúng người
• Phát triển người kế cận
• Thiết kế system để team tự chạy tốt hơn
• Không biến mình thành nút thắt cổ chai của mọi quyết định

---

🚧 Giver cần kỹ năng từ chối

Một Giver trưởng thành phải biết từ chối. Nếu không, họ sẽ thành người cứu hoa thường trực và làm hỏng chính mình.

Từ chối không có nghĩa là bỏ mặc. Từ chối tốt là giữ boundary trong khi vẫn tạo giá trị.

---

🪞 Câu hỏi tự soi

Tuần này, ai làm việc tốt hơn nhờ sự hỗ trợ của tôi?

• Tôi đã chia sẻ kiến thức gì giúp team mạnh hơn?
• Tôi đã làm rõ điều mờ hồ nào cho team?
• Tôi có giúp người khác tăng năng lực hay chỉ làm thay?
• Nếu tôi nghỉ 2 tuần, team có vẫn chạy được vì tôi đã để lại system tốt không?

Tuần này, tôi có đang hành xử như Taker không?

• Tôi có chỉ giúp người có lợi cho mình không?
• Tôi có giữ context để người khác phụ thuộc vào mình không?
• Tôi có nhận credit nhiều hơn phần đóng góp thật không?
• Khi team fail, phản xạ đầu tiên của tôi là sửa hay tự bảo vệ?
• Tôi có xem người khác là partner hay resource?

---

📝 Bài tập áp dụng

---

💬 Tóm lại

• Giver không phải người cho đi vô điều kiện. Giver là người tạo giá trị có trách nhiệm.
• Taker lấy giá trị từ hệ thống. Giver bơm giá trị vào hệ thống.
• Team mạnh hơn khi kiến thức không bị giữ làm quyền lực.
• Giver cá nhân giúp một người tốt hơn. Giver leader làm cả hệ thống tốt hơn.
• Matcher giữ công bằng, nhưng Giver tạo đà phát triển.
• Một Taker giỏi có thể đạt kết quả ngắn hạn, nhưng để lại di sản văn hóa độc hại cho tổ chức.
• Giúp người khác không có nghĩa là làm thay việc của họ.
• Giver trưởng thành biết nói "không" để bảo vệ giá trị lớn hơn.
• Câu hỏi của Giver là: Team có tốt hơn nhờ mình không?
• Influence bền vững đến từ việc làm người khác mạnh lên.

---

🏁 Kết luận

Giver không phải là người hy sinh vô điều kiện. Giver là người tạo giá trị làm người khác và hệ thống xung quanh tốt hơn.

Trong môi trường làm việc hiện đại, đặc biệt là software team, năng lực cá nhân vẫn quan trọng. Nhưng ảnh hưởng dài hạn đến từ việc giúp cả team mạnh lên.

Taker có thể thắng nhanh. Matcher giữ công bằng. Nhưng Giver mới là người xây được lòng tin, văn hóa học hỏi, và năng lực bền vững cho tổ chức.

---