Hãy nghĩ về hai manager bạn đã có — một người làm bạn tốt hơn, và một người không. Người không làm bạn tốt hơn có lẽ đã giữ bạn bận: ticket được giao, review được ký, standup được tham dự. Người thực sự làm bạn tốt hơn có lẽ đã làm điều gì đó tinh tế hơn. Họ giao cho bạn một vấn đề hơi quá lớn, ở đủ gần để bắt bạn nếu bạn ngã, rồi quan sát trong khi bạn tự mình tìm ra. Đó là toàn bộ nghề thủ công của việc cố vấn, ngay ở đó.
Tôi đã dẫn dắt các nhóm kỹ thuật từ tám đến mười một người qua các startup và scale-up, và sự khác biệt giữa những nhóm phát triển nhanh và những nhóm dừng tiến hầu như luôn quy về một điều: liệu những người senior có đang đầu tư vào những người junior không. Không phải trông nom họ. Không phải làm việc của họ. Đầu tư — với thời gian, với sự tin tưởng, với độ khó được thiết kế cẩn thận.
Bài này là mọi thứ tôi ước ai đó đã nói với mình trước lần đầu tiên cố vấn một kỹ sư. Nó cũng, thành thật mà nói, là bản ghi về những lỗi tôi đã mắc phải và phải học lại. Nếu bạn là senior engineer vừa được giao ai đó để cố vấn, hay tech lead đang xây dựng nhóm, tôi hy vọng nó giúp bạn tránh được một số bài học đó.
Tại sao cố vấn là đòn bẩy
Có một sự cám dỗ — đặc biệt nếu bạn trưởng thành như individual contributor — là nghĩ về cố vấn như một chi phí. Thời gian bạn dành để giải thích một khái niệm là thời gian bạn không viết code. Nhưng cách nhìn này có toán học hoàn toàn sai.
Nếu bạn có tám kỹ sư trong nhóm, sản lượng của nhóm bạn là công việc của tám người. Ngay khi bạn giúp ai đó đang hoạt động ở 60% năng suất lên đến 80%, bạn đã thêm 20% của một người vào sản lượng nhóm — không cần tuyển dụng, không cần chi phí onboarding, không cần ba tháng để người mới trở nên hiệu quả. Nhân con số đó với cả nhóm và cả năm, và cố vấn là một trong những khoản đầu tư đòn bẩy cao nhất bạn có thể thực hiện.
Có cả hiệu ứng nâng trần. Những nhóm tốt nhất tôi từng là thành viên không phải là những nhóm có nhiều ngôi sao nhất — mà là những nhóm có sàn cao nhất. Khi mọi kỹ sư trong nhóm đều có thể tin tưởng xử lý độc lập một vấn đề khó, bạn có thể di chuyển nhanh hơn nhiều so với nhóm dồn tất cả qua một hoặc hai người senior. Cố vấn nâng sàn đó lên.
Và còn khía cạnh giữ chân, quan trọng hơn người ta thừa nhận. Kỹ sư không bỏ công việc — họ bỏ sự trì trệ. Lý do số một tôi nghe từ các kỹ sư rời bỏ các nhóm là một phiên bản nào đó của "tôi đã ngừng phát triển." Một văn hoá nơi những người senior đầu tư vào junior là văn hoá nơi mọi người ở lại, và nơi kiến thức tổ chức của bạn không đi ra ngoài cửa mỗi mười tám tháng.
Gặp mọi người ở nơi họ đang ở
Lỗi cố vấn lớn nhất tôi thấy — và đã tự mắc phải sớm — là đặt thử thách sai level. Giao cho ai đó một task họ có thể làm trong giấc ngủ và họ sẽ chán. Giao cho họ thứ gì đó thực sự ngoài tầm với và họ sẽ chơi vơi. Phép màu xảy ra trong một dải giữa hai cực.
Nhà tâm lý học phát triển Lev Vygotsky gọi đây là vùng phát triển gần nhất. Ý tưởng đơn giản: có những thứ bạn có thể làm độc lập, những thứ bạn không thể làm ngay cả với sự giúp đỡ, và — giữa những cái đó — những thứ bạn gần như có thể làm, mà bạn có thể làm được với sự hỗ trợ đúng đắn. Vùng giữa đó là nơi học tập thực sự xảy ra. Đó là nơi thử thách mà không hoảng loạn sống.
Trong thực tế, điều này có nghĩa là tìm task một bước qua những gì họ đã làm trước đây, không phải mười bước. Junior đã xử lý các API endpoint đơn giản sẵn sàng sở hữu một tính năng độ phức tạp vừa phải, không phải thiết kế lại toàn bộ hệ thống. Kỹ sư mid-level đã deliver một số tính năng solo sẵn sàng dẫn dắt một tính năng liên quan đến phối hợp xuyên nhóm, không phải trở thành tech lead qua một đêm.
Làm thế nào bạn biết vùng của ai đó ở đâu? Bạn hỏi và quan sát. Hỏi họ phần nào của task cảm thấy rõ ràng và phần nào cảm thấy mơ hồ. Theo dõi nơi họ chậm lại trong phiên pairing. Chú ý loại câu hỏi họ đặt ra (những câu hỏi kiến trúc lớn thường báo hiệu họ đang ở gần rìa; những câu hỏi cú pháp nhỏ thường không). Bạn sẽ hiệu chỉnh nhanh nếu bạn đang chú ý.
Công cụ dạy học cụ thể
Có một vài kỹ thuật tôi quay lại mãi. Không cái nào đặc biệt.
Pair programming, làm đúng
Pairing là cách nhanh nhất để truyền đạt kiến thức ngầm — loại không sống trong tài liệu, những bản năng về nơi một vấn đề thường ẩn hay tại sao pattern đó gây đau sau này. Nhưng pairing chỉ dạy khi junior đang lái, không phải senior. Nếu bạn ngồi xuống và bắt đầu gõ trong khi họ xem, bạn đã thể hiện năng lực. Bạn chưa giúp họ xây dựng bất kỳ năng lực nào.
Phiên bản pairing thực sự có tác dụng: đặt bàn phím trước mặt họ, ngồi bên cạnh, và thuật lại những gì bạn đang nhận thấy. "Tôi sẽ xem xét edge case ở đây trước — điều gì xảy ra nếu list này rỗng?" Chờ đợi. Để họ suy nghĩ. Để họ sai. Sự khó chịu khi không nhảy vào là cái giá để thực sự dạy được điều gì đó.
Code review như một kênh dạy học
Hầu hết code review tập trung vào code. Cố vấn tốt biến nó thành cuộc trò chuyện về tư duy. Thay vì chỉ gắn cờ rằng function quá dài, hãy giải thích tại sao — cái gì trở nên khó hiểu, cái gì bị hỏng đầu tiên khi codebase lớn lên. Tôi đã viết nhiều hơn về cơ chế làm điều này một cách nhã nhặn và hiệu quả trong Cách Review Code Nhã nhặn, nhưng góc cố vấn đáng thêm vào đây: review là một trong số ít nơi bạn có thể bắt lý luận của ai đó và định hướng lại nó trước khi nó trở thành thói quen.
Một điều tôi học được: đặt câu hỏi trong review thay vì đưa ra sửa chữa. "Điều gì xảy ra nếu hai request cùng lúc hit cái này?" hữu ích hơn "cái này không thread-safe." Nó mời họ suy nghĩ qua vấn đề; nó không chỉ đưa cho họ câu trả lời.
Giải thích lý luận của bạn thành lời
Senior engineer có lượng kiến thức nén, vô hình khổng lồ — họ chỉ quên rằng họ có nó. Khi bạn đưa ra quyết định, hãy thuật lại nó. "Tôi đi với in-memory map đơn giản ở đây thay vì với tới Redis, vì ở quy mô này độ phức tạp thêm chưa xứng đáng." Câu đó, mất ba giây để nói, có thể mất một kỹ sư junior nhiều tháng thử và sai để học một mình.
Bạn không cần thuật lại mọi thứ. Nhưng làm lý luận của bạn rõ ràng — đặc biệt tại các điểm quyết định nơi câu trả lời không rõ ràng — là một trong những thứ sinh lợi cao nhất bạn có thể làm cho ai đó đang học nghề.
Stretch task với lưới an toàn
Cách dạy học hiệu quả nhất tôi biết là giao một thứ hơi quá lớn, rồi ở gần. Không phải lăm le — họ cần không gian để đấu tranh — nhưng sẵn sàng. Check-in tại các milestone tự nhiên. Để họ đến với bạn khi có blockers thay vì anticipate mọi cái. Mục tiêu là họ cảm thấy độc lập dù lưới an toàn đang ở đó.
Một biện pháp bảo vệ quan trọng: stretch task cần deadline thật với stakes thật, nhưng stakes không quá cao đến mức thất bại là thảm hoạ. Kỹ sư junior đốt cháy toàn bộ cuối tuần on-call trên task họ chưa sẵn sàng sẽ trở nên ngại rủi ro hơn, không có năng lực hơn. Khớp kích thước của stretch với mức hệ thống có thể chịu đựng nếu sai.
Đừng giải quyết cho họ
Đây là cái khó nhất. Khi ai đó bị kẹt và bạn biết câu trả lời, cần kỷ luật thực sự để không đưa ra. Nhưng ngay khi bạn làm, bạn đã chuyển từ dạy học sang làm việc. Lần tiếp theo họ gặp vấn đề tương tự, họ sẽ quay lại với bạn thay vì tự mình giải quyết.
Thứ có tác dụng thay thế: đặt câu hỏi hướng dẫn đúng. "Thông báo lỗi thực sự nói gì?" "Bạn đã nhìn vào cách chúng ta xử lý trường hợp tương tự trong module payments chưa?" Mục tiêu là cung cấp cho họ bước tiếp theo trong suy nghĩ của chính họ, không phải câu trả lời.
Khi ai đó mang đến cho bạn một vấn đề, hãy chờ ba mươi giây trước khi nói bất cứ điều gì. Thường họ sẽ tự trả lời câu hỏi của mình trong thời gian đó. Nếu không, phản hồi đầu tiên của bạn nên là một câu hỏi, không phải một giải pháp.
Thang tự chủ
Một trong những mô hình tư duy rõ ràng nhất tôi đã tìm thấy cho cố vấn là nghĩ về tự chủ như một cái thang. Bạn đang ở đâu trên thang xác định bạn cần cung cấp bao nhiêu ngữ cảnh, bạn check-in chặt chẽ như thế nào, và bạn giao loại task nào. Mục tiêu của cố vấn luôn là di chuyển ai đó lên một bậc — không phải kéo họ lên đỉnh qua một đêm, mà là tiếp tục di chuyển.
| Bậc | Cách họ vận hành | Sự tham gia của bạn trông như thế nào |
|---|---|---|
| 1 — Được chỉ đạo | Cần hướng dẫn từng bước; không chắc về hầu hết quyết định. Hỏi trước khi hành động với hầu hết mọi thứ. | Bạn định nghĩa task chi tiết, review mọi PR kỹ lưỡng, check-in hàng ngày, và thuật lại lý luận của bạn liên tục. |
| 2 — Được hướng dẫn | Có thể xử lý công việc quen thuộc độc lập; cần input cho tình huống mới. Mang blockers đến bạn thay vì đoán. | Bạn đặt mục tiêu rõ ràng, định nghĩa phạm vi, và review quyết định chính. Bạn check-in vài ngày một lần, không phải hàng ngày. |
| 3 — Cộng tác | Đề xuất cách tiếp cận của họ, suy nghĩ qua trade-off, và chủ động gắn cờ rủi ro. Mang cho bạn các lựa chọn, không chỉ vấn đề. | Bạn hành động như một sounding board hơn là người hướng dẫn. Bạn review cách tiếp cận trước khi thực thi nhưng tin tưởng vào việc thực thi. |
| 4 — Được ủy quyền | Chịu trách nhiệm hoàn toàn về một vấn đề: phạm vi, thực thi, giao tiếp stakeholder. Escalate chỉ khi thực sự cần. | Bạn check-in tại milestones. Bạn sẵn sàng khi họ muốn ý kiến thứ hai, nhưng họ hoàn toàn dẫn dắt. |
| 5 — Được tin tưởng | Bạn sẽ giao cho họ bất kỳ vấn đề nào trong nhóm, kể cả những cái bạn không chắc cách giải quyết. | Mối quan hệ ngang hàng. Hai bạn học từ nhau. Vai trò của bạn là cung cấp phạm vi và đứng sang bên. |
Hầu hết sinh viên mới ra trường bắt đầu ở bậc một. Hầu hết kỹ sư được tuyển với hai ba năm kinh nghiệm bắt chỗ ở bậc hai. Hành trình từ đó phụ thuộc nhiều vào mức độ chủ động manager và nhóm của họ đầu tư vào việc di chuyển họ lên.
Lỗi phổ biến nhất tôi thấy là đối xử với ai đó như thể họ đang ở bậc thấp hơn họ đã đạt được. Nếu ai đó đang hoạt động ở bậc ba nhưng bạn vẫn quản lý họ ở bậc một — review mọi PR chi tiết, check-in hàng ngày — bạn đang làm họ chậm lại, không giúp họ. Tin tưởng là thứ bạn mở rộng dần dần; nó không phải là phần thưởng bạn trao khi ai đó đã "chứng minh" hoàn toàn bản thân.
Tin tưởng được mở rộng trước khi có sự chắc chắn — đó là điều làm nó là tin tưởng. Nếu bạn chờ cho đến khi ai đó có track record hoàn hảo trước khi tin tưởng họ với thứ gì đó khó, bạn đã từ chối họ những điều kiện cần để xây dựng track record đó ngay từ đầu.
Nuôi dưỡng senior, không chỉ đóng ticket
Nhiều sự chú ý cố vấn dành cho junior — và đúng là như vậy, vì delta từ junior đến mid-level dốc và nhu cầu hỗ trợ rõ ràng. Nhưng kỹ sư mid-level dừng lại trở thành những người đóng ticket và không bao giờ lên đến senior là một trong những sự mất mát phổ biến nhất và có thể phòng ngừa được trên nhóm kỹ thuật.
Khoảng cách giữa mid-level và senior ít liên quan đến kỹ năng kỹ thuật hơn hầu hết người nghĩ. Kỹ sư mid-level kỹ thuật mạnh bị đình trệ vì họ chưa có cơ hội sở hữu thứ gì đó đủ lớn để phát triển sự phán đoán đến từ phạm vi.
Nuôi dưỡng một senior có nghĩa là cung cấp cho họ:
- Phạm vi, không chỉ task. Kỹ sư mid-level được giao một chuỗi ticket sẽ hoàn thành những ticket đó và không gì khác. Giao cho họ một vấn đề — một khu vực của hệ thống để sở hữu, một khả năng để xây dựng — và họ phải phát triển sự phán đoán để phân rã nó, sắp xếp thứ tự, và đưa ra trade-off. Sự phán đoán đó là điều định nghĩa senior.
- Quyền sở hữu rõ ràng. Đặt họ vào phòng nơi quyết định về khu vực của họ được đưa ra. Để họ trình bày cách tiếp cận của mình cho stakeholder. Để họ bảo vệ nó khi bị thách thức. Điều này không thoải mái lúc đầu và vô giá theo thời gian.
- Trách nhiệm cố vấn. Ghép một kỹ sư mid-level với junior để cố vấn là một trong những chất xúc tác tốt nhất tôi biết cho sự tăng trưởng của họ. Dạy học đòi hỏi sự hiểu biết ở cấp độ khác với làm việc. Nó cũng buộc họ phải diễn đạt những sự phán đoán họ đang đưa ra một cách trực giác, đó chính xác là bước từ mid-level lên senior.
- Ảnh hưởng kỹ thuật ngoài công việc trực tiếp của họ. Để họ dẫn dắt quyết định về tiêu chuẩn, viết ADR, hay dẫn dắt post-mortem kỹ thuật — tất cả những điều này xây dựng chiều rộng ảnh hưởng mà kỹ sư senior cần có.
Các lỗi cố vấn đáng được đặt tên
Tôi đã mắc hầu hết những lỗi này. Những cái tôi không mắc phải cá nhân, tôi đã xem những kỹ sư giỏi khác mắc phải mà không nhận ra.
- Giải cứu quá sớm. Nhảy vào ngay khi ai đó gặp khó khăn cảm thấy hữu ích. Nhưng không phải vậy. Đấu tranh có hiệu quả là nơi sự tăng trưởng sống. Giải cứu là cho khi ai đó bị kẹt quá lâu mà không có con đường tiến lên — không phải cho dấu hiệu khó khăn đầu tiên.
- Phản hồi mơ hồ. "Cái này có thể sạch hơn" không nói với ai điều gì. "Function này đang làm ba việc — đặt tên nó theo bất kỳ cái nào trong số đó sẽ gây hiểu nhầm, và nó sẽ khó test" là phản hồi họ có thể hành động theo. Sự cụ thể là sự tử tế.
- Chỉ ủy quyền công việc nhàm chán. Nếu những task bạn giao cho kỹ sư junior luôn là công việc stakes thấp nhất, visibility thấp nhất, cơ học nhất, bạn đang giữ việc học thú vị cho mình và cho họ một sự nghiệp lao động tẻ nhạt. Họ nhận ra. Họ rời đi. Các stretch task phải bao gồm cả những thứ hay nữa.
- Không thực sự đầu tư thời gian. "Tôi sẵn sàng cho câu hỏi" không phải là cố vấn. Cố vấn đòi hỏi thời gian được lên lịch, được bảo vệ — một-một thường xuyên với agenda cố vấn thực sự, không chỉ cập nhật trạng thái; review code có chủ đích; phiên pairing có kế hoạch. Nếu bạn làm đúng, nó tốn hai đến ba giờ mỗi tuần. Nếu nó không tốn gì, bạn có lẽ không làm điều đó.
- Làm nó về bản thân bạn. Mục tiêu là sự tăng trưởng của họ, không phải sự hài lòng của bạn khi có một mentee chu đáo. Đôi khi quyết định đúng cho họ liên quan đến cơ hội trong nhóm khác, hay phản hồi rằng codebase của bạn có vấn đề đang làm việc học của họ khó hơn. Mentor tốt đặt mentee lên trước.
Cố vấn hoạt động như thế nào ở các quy mô khác nhau
Các nguyên tắc cốt lõi không thay đổi theo quy mô công ty, nhưng cơ sở hạ tầng xung quanh chúng thay đổi rất nhiều.
| Giai đoạn công ty | Cố vấn thường hoạt động như thế nào | Cẩn thận với |
|---|---|---|
| Startup (<30 kỹ sư) | Không chính thức và dựa trên mối quan hệ. Cố vấn xảy ra trong dòng công việc — pairing, review, và gần gũi hàng ngày. Không có chương trình chính thức, nhưng thường rất mãnh liệt vì bản thân công việc là stretch task. | Senior engineer bị chôn trong output quá nhiều để đầu tư vào người khác. Cố vấn bị lấn áp bởi sự khẩn cấp. |
| Scale-up (30–150 kỹ sư) | Công ty đủ lớn để có career ladder nhưng thường chưa xây dựng cơ sở hạ tầng cố vấn chính thức. Chất lượng cố vấn biến đổi rất nhiều theo nhóm. Một số senior xuất sắc; số khác chưa bao giờ nghĩ đến nó. | Kết quả không nhất quán. Junior ở một nhóm phát triển nhanh; junior ở nhóm khác dừng lại hai năm. Công bằng trở thành vấn đề thật sự. |
| Enterprise (150+ kỹ sư) | Các chương trình chính thức: ghép đôi mentorship, framework nghề nghiệp có cấu trúc, ngân sách học tập, phân bổ thời gian chuyên dụng. Nhiều quy trình hơn, đôi khi hữu ích và đôi khi là giấy tờ lấn áp mối quan hệ thực sự. | Quy trình thay thế cho đầu tư thực sự. Ghép đôi mentorship trên giấy tờ mà thực chất chỉ là cà phê hàng tháng và không có thách thức thực sự. |
Tại một startup tôi từng là thành viên, không có chương trình cố vấn chính thức, nhưng ba senior trong nhóm có một thỏa thuận không được nói ra: mọi kỹ sư junior sẽ là chủ sở hữu chính của ít nhất một tính năng quan trọng trong sáu tháng đầu tiên của họ. Các tính năng được đặt phạm vi để có thể đạt được với sự hỗ trợ, không phải tầm thường. Các senior sẽ pair trên những phần khó và review mọi thứ kỹ lưỡng, nhưng junior dẫn dắt. Đến cuối một năm, những kỹ sư junior đó là mid-level trong mọi thứ trừ title.
Tại một công ty lớn hơn tôi gia nhập sau đó, có một chương trình cố vấn rất tinh vi — ghép đôi chính thức, check-in hàng quý, template tài liệu chung cho mục tiêu. Và nó hầu như không có tác dụng, vì template tài liệu đã trở thành việc cố vấn. Không ai theo dõi liệu các kỹ sư junior có thực sự nhận được công việc tốt hơn hay chỉ giấy tờ tốt hơn. Bài học tôi rút ra: mối quan hệ và thách thức có chủ đích là điều quan trọng. Mọi thứ khác là giàn giáo.
Những điều cốt lõi cần nhớ
- Cố vấn là đòn bẩy. Phát triển năng lực của một kỹ sư có lợi nhuận kép đối với sản lượng và giữ chân nhóm — nhiều hơn nhiều so với những giờ nó tốn.
- Vùng thử thách là nơi học tập sống. Task nên một bước qua khả năng hiện tại của họ, không phải mười. Quá dễ tạo ra sự nhàm chán; quá khó tạo ra tê liệt.
- Công cụ dạy học có tác dụng: pairing với junior lái, câu hỏi-không-sửa-chữa trong code review, thuật lại lý luận của bạn thành lời, stretch task với lưới an toàn, và chống lại sự thôi thúc giải quyết cho họ.
- Thang tự chủ cho bạn ngôn ngữ chung về vị trí ai đó và họ đang đi đâu. Mở rộng tin tưởng một bậc trước khi bạn chắc chắn.
- Tăng trưởng mid-to-senior xảy ra thông qua phạm vi, quyền sở hữu, cố vấn người khác, và ảnh hưởng kỹ thuật — không chỉ là những ticket khó hơn.
- Các bẫy phổ biến: giải cứu quá sớm, phản hồi mơ hồ, chỉ ủy quyền công việc nhàm chán, và không đầu tư thời gian thực sự.
- Mối quan hệ là chương trình. Các cấu trúc chính thức giúp ích ở quy mô, nhưng chúng là giàn giáo. Công việc thực sự là thách thức có chủ đích, phản hồi thành thật, và tin tưởng được mở rộng trước khi có sự chắc chắn.
Đây là bài thứ hai trong một loạt nhỏ về văn hoá kỹ thuật. Nếu bạn chưa đọc, phần một về review code nhã nhặn bao gồm cơ chế đưa ra phản hồi theo cách dạy dỗ mà không làm nản lòng — đó là cùng kỹ năng, được áp dụng ở cấp độ PR. Sẽ có thêm bài viết về văn hoá, tuyển dụng, và cách các nhóm thực sự hoạt động.