Why Think Alone When You Have a Whole Team?

English — Why Think Alone When You Have a Whole Team?

Say we’re adding an email that goes out after a customer submits a request. It looks like a small task. We could pick someone to build it and move on. But then a teammate asks whether the email means “we’ve received your request” or “your request has been approved.” Someone else wonders what happens if the customer clicks Submit twice. A third person has worked on the email service and knows what tends to go wrong. A few minutes into the conversation, we understand the work rather differently.

That’s the kind of discussion I’d like to have with a team. Each person brings something the others might have missed, and the plan gets better while it’s still easy to change. If everyone waits for the lead to come up with an answer, we lose most of that. It feels a bit like having a whole rack of powerful CPUs and only using one. I’d much rather make use of the people in the room, including the person who hasn’t worked on this before and needs us to explain what we mean.

As the lead, I have a part in whether that conversation happens at all. If I open with a finished plan, people may assume the decision is already made. Sharing the problem first gives them something to work out with me. I can explain what the customer needs, what we know, and what we’re unsure about, then leave room for suggestions. When I do have an idea, I need to be willing to change it. Being attached to my own solution is understandable; making everyone else work around that attachment is less useful.

Of course, talking through a problem can go on for a while. At some point, someone has to make the call, and it should be clear who that is. If it’s me, I owe the team an explanation of why we’re taking this approach and which trade-offs we’re accepting. I also own that decision if it causes problems later. We can move ahead even when someone would have chosen differently, provided we’ve considered their concern and they understand the reasoning. We can come back to the decision when we learn something new.

Once we agree on an approach, the work needs a person who will follow it through. With the email task, that starts with making sure the requirement is understood: when the message should be sent, what it should say, and what should happen when things go wrong. Then there’s the implementation, code review, and testing, including both the happy path and failure cases. After that come deployment and checking that it actually works for customers. When I talk about ownership, I mean keeping track of that whole piece of work, knowing what still needs doing, and getting the right people involved.

There will be parts the task owner can’t do alone. Suppose testing shows that some customers would receive the email twice. The person working on it has checked a couple of likely causes but is still stuck. At that point, telling a teammate what they’ve found and asking them to take a look is a sensible next step. QA may know how to reproduce it consistently. Another engineer may know why a request is being retried. Working through the problem together helps the task move forward and leaves the person who asked with a better understanding for next time.

It’s easy for me to say “ask for help early.” How I respond when someone does matters more. If I immediately ask why it isn’t finished yet, I’m giving them a reason to keep the next problem to themselves. I’d rather start with what’s happening, what they’ve tried, and what would help. Sometimes that means finding someone to pair with them. Sometimes we need to reduce the scope or change a deadline. I also need to be clear about priorities and the decisions they can make themselves, so taking initiative doesn’t turn into guessing what I want.

Following a task through includes the last part, when the code is running in production. For our email change, we’d check that the right messages arrive, that we aren’t sending duplicates, and that delivery failures are visible. Before deploying, we should know who will verify those things, who will monitor the change, and who can help if something goes wrong. The task owner coordinates with those people until it’s running reliably. That doesn’t make them the only person on call. If someone else takes over, they need enough context to know what’s been checked and what’s still outstanding.

That need for context goes beyond a handover. If one person is the only one who understands the email flow, the team will keep coming back to them for every change and every failure. They may be perfectly happy to help, but they’ll still become a bottleneck. A teammate should be able to take a day off without being the only person who can explain how something works. Making time to share that knowledge is part of getting the work done well.

I’d start with something practical: walk another person through the flow and leave a few notes they can actually use. Where does sending begin? Where do we look when an email doesn’t arrive? Was there a reason we ruled out another approach? The code won’t always answer that last question. A short explanation can save someone a lot of guessing later. And when the implementation changes, those notes need to change with it. Over time, more people can review the work, spot a problem, or pick it up when needed, while each task still has a clear owner.

I like the working atmosphere that makes this possible. People can ask a basic question without making a speech to apologise for it. They can disagree about an approach and still enjoy working together afterwards. There’s room to joke, chat, and work in different ways, with a shared understanding of what we’ve committed to. If a date starts looking unlikely, saying so early gives everyone a chance to adjust. A relaxed team still has difficult days; being able to talk honestly makes those days much easier to get through.

The changes I’d look for as a lead are fairly ordinary. Someone who used to wait for instructions starts bringing a proposal. A teammate can explain a part of the system they didn’t understand a month ago. People finish work without needing a reminder at every step, and ask for help before a small problem becomes a late surprise. I get to learn from their ideas too. As that happens, I can spend more time on the things the team needs from me, instead of being involved in every decision just because I’m the lead.

That’s how I’d judge whether I’m doing the job well: are we getting better at the work, and at working together? A team that grows more capable gives everyone more room to contribute. The next time we sit down with an unclear task, there are more people who can help make sense of it. What’s something on your team that used to need the lead’s input, but people can now handle themselves?

Tiếng Việt — Có cả một team, sao phải nghĩ một mình?

Giả sử team đang nhận một task gửi email sau khi khách gửi yêu cầu. Nhìn qua thì khá đơn giản, chọn một người làm rồi chuyển sang việc tiếp theo cũng được. Nhưng khi ngồi bàn, một bạn hỏi: email này báo đã nhận yêu cầu, hay báo yêu cầu đã được duyệt? Một bạn khác nghĩ tới chuyện khách bấm gửi hai lần. Người từng làm phần gửi mail thì biết vài chỗ dễ lỗi. Mới trao đổi một lúc, cả nhóm đã hiểu công việc rõ hơn hẳn lúc đầu.

Mình thích những buổi bàn việc như vậy. Mỗi người thấy thêm một điều mà người khác chưa nghĩ tới, rồi cùng sửa cách làm khi mọi thứ vẫn còn nằm trên giấy. Còn nếu ai cũng chờ leader nghĩ ra đáp án, những góc nhìn đó dễ bị bỏ qua. Có cả dàn CPU hạng nặng mà chỉ xài một con thì phí quá. Ngay cả bạn chưa từng làm phần này cũng có thể giúp cả nhóm nhận ra chỗ chưa rõ, đơn giản vì bạn ấy cần được giải thích trước khi bắt tay vào làm.

Ở vai trò lead, mình cũng góp phần quyết định buổi trao đổi sẽ diễn ra thế nào. Nếu mở đầu bằng một phương án đã đâu vào đấy, anh em có thể hiểu là mình đã chốt rồi. Mình nghĩ nên bắt đầu từ vấn đề đang cần giải quyết: khách cần gì, team đã biết gì, còn chỗ nào chưa chắc. Có chung những thông tin đó thì mọi người mới dễ góp ý. Mình có ý tưởng thì cứ đưa ra, nhưng cũng phải chấp nhận sửa nếu nghe được cách hợp lý hơn. Thật lòng mà nói, thích phương án mình nghĩ ra là chuyện bình thường. Còn đã muốn nghe ý kiến của anh em thì phải để những ý kiến ấy có cơ hội thay đổi phương án đó.

Bàn bạc một hồi rồi cũng cần chốt để còn làm. Ai quyết định việc này nên rõ từ đầu. Nếu người đó là mình, mình cần giải thích vì sao chọn cách này, chấp nhận những hạn chế nào, và chịu trách nhiệm nếu lựa chọn ấy gây ra vấn đề về sau. Có bạn vẫn nghiêng về cách khác cũng không sao. Mọi người có thể cùng làm khi hiểu lý do của quyết định và biết điều mình góp ý đã được cân nhắc. Sau này có thêm thông tin thì mình lại xem xét tiếp.

Chốt được cách làm rồi, mỗi task cần có người theo tới nơi. Với việc gửi email, người nhận cần làm rõ lúc nào gửi, nội dung nói gì, và gặp lỗi thì xử lý thế nào. Sau đó là code, nhờ review, kiểm tra cả luồng chạy bình thường lẫn những trường hợp không như mong muốn. Code sẵn sàng rồi vẫn còn triển khai và kiểm tra xem khách có dùng được đúng như dự tính không. Đó là điều mình hiểu khi nói tới ownership: nhận một việc, nắm được việc ấy đang tới đâu, còn thiếu gì, và chủ động tìm người phối hợp để làm cho xong.

Sẽ có những đoạn người nhận task chưa tự giải quyết được. Giả sử lúc test phát hiện email bị gửi trùng, đã kiểm tra vài chỗ nghi ngờ mà vẫn chưa tìm ra nguyên nhân. Lúc này, kể lại những gì đã thử rồi nhờ một người cùng xem là hợp lý. Có thể QA biết cách làm lỗi xuất hiện đều đặn hơn, hoặc một bạn khác biết vì sao hệ thống đang gửi lại request. Cùng gỡ được chỗ đó thì công việc đi tiếp, mà người đang làm cũng hiểu thêm để lần sau tự xử lý được.

Nói “có gì vướng thì báo sớm” khá dễ. Cách mình phản ứng khi anh em báo mới là điều khiến người ta có muốn nói tiếp hay không. Nếu vừa nghe có lỗi đã hỏi sao chưa xong, lần sau mọi người sẽ ngại mở lời. Mình muốn hiểu đang kẹt chỗ nào, đã thử những gì và cần thêm gì để làm tiếp. Có lúc cần một người ngồi cùng, có lúc phải bớt phạm vi hoặc tính lại thời gian. Bản thân mình cũng cần nói rõ việc nào ưu tiên và những phần anh em có thể tự quyết, để mọi người chủ động mà không phải đoán ý leader.

Theo việc tới nơi còn có cả đoạn code đã lên production. Với thay đổi gửi mail này, team cần kiểm tra khách nhận đúng nội dung chưa, còn gửi trùng không, và lỗi gửi mail có được ghi nhận để xử lý không. Trước lúc triển khai, mọi người nên thống nhất ai kiểm tra, ai theo dõi và có vấn đề thì nhờ ai hỗ trợ. Người nhận task phối hợp với những người đó cho tới khi biết tính năng đã chạy ổn. Điều này không có nghĩa là một người phải trực và lo hết mọi chuyện. Khi bàn giao, người tiếp nhận cần biết đã kiểm tra những gì và còn điều gì phải theo dõi.

Chuyện hiểu công việc của nhau cũng không nên đợi tới lúc bàn giao mới tính. Nếu chỉ một người biết luồng gửi mail chạy thế nào, mỗi lần sửa hay gặp lỗi, cả team lại phải tìm người ấy. Bạn đó có nhiệt tình giúp đến mấy thì cũng chỉ có từng ấy thời gian. Mình mong anh em có thể nghỉ một ngày mà không phải bận tâm vì trong team chẳng ai khác hiểu phần mình đang làm. Muốn vậy thì cần dành thời gian chia sẻ ngay trong quá trình làm việc.

Có thể bắt đầu rất đơn giản: ngồi cùng một bạn, đi qua luồng xử lý và ghi lại vài điều hữu ích. Mail bắt đầu được gửi từ đâu, không nhận được thì kiểm tra chỗ nào, vì sao lúc trước chọn cách này mà bỏ cách kia. Nhìn code chưa chắc đã biết hết những chuyện đó. Vài dòng giải thích sẽ giúp người sau đỡ phải đoán, miễn là khi sửa cách làm thì mình sửa luôn tài liệu. Dần dần, có thêm người review được, nhận ra được vấn đề và tiếp tục công việc khi cần. Kiến thức được chia sẻ, còn từng task vẫn rõ ai đang phụ trách.

Mình thích làm việc ở một nơi mà hỏi câu cơ bản cũng không thấy ngại. Anh em có thể tranh luận về cách làm rồi vẫn vui vẻ làm cùng nhau. Vẫn có lúc đùa, có chuyện để tám, và mỗi người có thể có cách sắp xếp công việc riêng, miễn là giữ những điều đã thống nhất với nhau. Nếu thấy khó kịp hẹn thì nói sớm để còn thu xếp. Team thoải mái vẫn có những ngày căng thẳng, nhưng được nói thật chuyện đang gặp và biết có người sẵn lòng giúp thì dễ thở hơn nhiều.

Để biết mình làm lead có ổn không, mình sẽ nhìn vào những thay đổi khá bình thường như vậy. Một bạn trước hay chờ hướng dẫn giờ đã tự đưa ra phương án. Một phần hệ thống tháng trước còn chưa hiểu, giờ đã có thể giải thích lại cho người khác. Công việc được làm tới nơi mà không cần nhắc từng bước; gặp khó thì anh em tìm nhau sớm, thay vì đợi sát ngày mới biết có chuyện. Mình cũng học thêm từ cách nghĩ, cách làm của mọi người. Khi team làm được nhiều hơn, mình có thời gian lo những việc team đang cần, thay vì quyết định chuyện gì cũng phải có mặt.

Với mình, làm leader tốt là giúp cả nhóm ngày càng làm việc giỏi hơn và phối hợp tốt hơn. Mỗi người hiểu thêm một chút, chủ động thêm một chút thì cả team cũng có thêm người để tin cậy. Lần sau ngồi xuống với một task chưa rõ, sẽ có nhiều người cùng nghĩ cách giải quyết. Ở team anh em, có việc gì trước đây cứ phải hỏi leader, mà giờ mọi người đã tự xử lý được?