Văn phòng gần như trống, còn project board vẫn giống hệt tháng trước. Vài card đổi cột, vài rủi ro mới được thêm, và một decision đã được đổi tên ba lần mà vẫn không rõ hơn. Bạn đóng laptop chậm lại, vì cái mệt không chỉ đến từ công việc. Nó đến từ cảm giác nỗ lực không còn biến thành tiến triển.
Rời khỏi một project là chuyện khó nói, vì nghe rất giống bỏ cuộc. Đôi khi đúng là vậy. Có những lúc công việc chỉ đang ở đoạn giữa khó khăn, và rời đi chỉ là cách bảo vệ sự thoải mái. Mọi project có ý nghĩa đều có một mùa mà sự hào hứng ban đầu đã hết, vấn đề hiện rõ, còn vạch đích thì chưa thấy. Mùa đó xứng đáng có sự kiên nhẫn.
Nhưng cũng có một loại project khác, nơi việc ở lại trở thành một khoản thuế lặng lẽ đánh vào judgment, sức khỏe và integrity. Team làm rất nhiều, nhưng decision cứ reset. Goal thay đổi nhưng không ai gọi tên trade-off. Rủi ro được nêu ra rồi lịch sự bị bỏ qua. Quality được yêu cầu nhưng thời gian cho quality bị lấy đi. Người ta được yêu cầu ownership nhưng không có authority. Trong môi trường đó, persistence có thể thôi là kỷ luật và trở thành phủ nhận.
Bước đầu tiên là phân biệt đoạn giữa khó khăn với dead end. Một đoạn giữa khó vẫn có đường. Goal khó nhưng hiểu được. Owner có thể ra decision. Constraint là thật nhưng còn bàn được. Feedback làm plan thay đổi. Mọi người có thể mệt, nhưng công việc vẫn đang học. Dead end thì khác: cùng những câu hỏi quay lại mà không được giải, thông tin mới không làm hành vi đổi, và accountability luôn nằm ở đâu đó khác.
Trước khi rời đi, thường đáng để thử sửa. Viết vấn đề ra một cách rõ ràng. Hỏi decision nào đang cần. Đề xuất scope nhỏ hơn. Gọi tên rủi ro bằng ngôn ngữ business có thể đánh giá: thời gian, tiền, niềm tin, compliance, thiệt hại khách hàng, capacity của team. Một lời than phiền mơ hồ rất dễ bị bỏ qua. Một trade-off rõ ràng cho project thêm một cơ hội để thành thật.
Cũng hữu ích khi hỏi điều gì cần thay đổi để bạn ở lại. Không phải mọi thứ, chỉ đủ. Một owner thật. Scope đóng băng trong hai tuần. Thời gian sửa test suite. Quyền bỏ một feature rủi ro. Một decision rõ là ưu tiên quality hay ngày release. Nếu bạn không thể gọi tên một điều kiện hợp lý, có thể bạn đã biết câu trả lời. Nếu bạn gọi tên được mà không ai phản hồi, đó cũng là thông tin.
Giá trị cá nhân cũng quan trọng. Một số project yêu cầu những thỏa hiệp chỉ đơn giản là không thoải mái. Một số khác yêu cầu những thỏa hiệp làm bạn nhỏ lại. Ship một feature còn accessibility gap nhưng có mitigation plan khác với việc giấu một security risk. Đi qua một migration rối khác với việc bị yêu cầu nói sai với khách hàng. Rời đi đôi khi là cách giữ công việc tương lai còn khớp với kiểu professional mà bạn muốn trở thành.
Sức khỏe không phải lý lẽ kịch tính, nhưng là lý lẽ thật. Một project ăn hết mọi buổi tối, chen vào mọi cuối tuần, và vẫn không chịu ra decision rõ hơn thì không chỉ là managed kém. Nó đang vay mượn từ con người mà không ghi nhận khoản nợ. Đôi khi câu hỏi thành thật không phải là bạn có đủ mạnh để tiếp tục không. Câu hỏi là project này có xứng với cái giá nó đang đòi từ đời sống của bạn không.
Nếu quyết định là rời đi, cách rời đi vẫn quan trọng. Ghi lại điều bạn biết. Làm trạng thái hiện tại trở nên nhìn thấy được. Handoff rủi ro mà không trả đũa. Đừng viết lại câu chuyện để bạn trở thành người hợp lý duy nhất trong đó. Một exit sạch không phải yếu đuối. Đó là sự tôn trọng dành cho những người ở lại và cho chính tiêu chuẩn của bạn.
Có thể sẽ có cảm giác tội lỗi. Người tốt thường thấy mình có trách nhiệm với việc chưa xong, nhất là khi đồng đội vẫn ở trong khó khăn. Nhưng trách nhiệm có ranh giới. Bạn có thể quan tâm đến một project mà không hiến vô hạn thời gian cho một cấu trúc không chịu thay đổi. Bạn có thể chúc team tốt đẹp và vẫn chọn không tiếp tục trả một cái giá đã hết hợp lý.
Rời đi không phải kỹ năng nên dùng tùy tiện. Nhưng cũng không phải kỹ năng nên né mãi. Career được xây không chỉ bằng những thứ ta hoàn tất, mà còn bằng những thứ ta học cách ngừng mang. Opportunity cost rất lặng. Mỗi tháng ở trong một dead end cũng là một tháng không dùng để xây thứ lành mạnh hơn, học điều thật hơn, hoặc phục vụ user qua một hệ thống thật sự có thể cải thiện.
Nếu bạn đang quyết định có nên ở lại với một project khó hay không, câu hỏi hữu ích có thể rất đơn giản: nó khó vì công việc có ý nghĩa và con đường vẫn đang dần rõ, hay nó khó vì hệ thống từ chối học? Cái đầu tiên đáng được kiên nhẫn. Cái thứ hai có thể xứng đáng với một lời tạm biệt cẩn thận. Nhiều người trong chúng ta chỉ học được sự khác biệt sau một lần ở lại quá lâu. Trải nghiệm đó đắt, nhưng nó có thể làm decision sau thành thật hơn.