Saying "No" and Hearing "No"
Most software is made by teams of developers working together. These teams can function at different levels. Some very small teams have created extremely impressive pieces of software while some extremely large teams have failed to produce almost anything of value after years of work. We could situate every software development team on a spectrum of how well it performs with the extremes of the spectrum being "high performing" and "dysfunctional". What is interesting, is that the skill level of the developers on a team is just one of many factors that influence its performance. If we had a team composed of only extremely accomplished, genius, developers it would not be a foregone conclusion it would be high performing. It is quite possible that this team could be outright dysfunctional.
Anyone who has been a member of a dysfunctional team will have stories about how an interaction between two team members went horribly wrong. I suspect, if you could hear every such story in the world, they could be generalized to a fairly small set of dysfunctional behaviours.
One such dysfunctional behaviour I see frequently is the inability to say "no" clearly. This is readily observable in our day to day lives. If someone invites you to a party and you don't want to go, how often is your answer simply "no"? Of course there are a few Larry David types who find it natural to answer like this, but most of us need to couple our answer with some sort of excuse: "I can't make it because my parents are visiting."
This generally works in our social lives because the person extending the invite has been conditioned to hear the "no" inside this reply. Most people would know not to answer back with "that's cool, you can bring your parents too" or "aren't they visiting for the whole month?" If the invitee actually wanted to go to the party their response would have had a different nuance "I want to but I need to figure out something for my parents to do".
When you are the leader of a team that is building software, you are being invited to parties every day, parties like serverless, kubernetes, rust, typescript, and many more. Don't get me wrong. These are all great parties. But if all you do is go to parties, it's hard to build good software. What's more insidious, is that if your team spends all its time discussing whether or not to go to parties, you have no time to build software or attend parties!
Let's explore by looking at one of the most common software parties that team leads get invited to: the refactor party. A developer approaches the team lead: "I was working on the new AI feature and the existing code is a hot mess. If I can spend a week refactoring it then it will be much better and I can add the new feature in just a couple days."
Assume that the team lead immediately knows the answer to this proposal must be "no" and merely needs to figure out how to communicate it. There will be many cases where developers make proposals like this that are worthy of extensive discussion. This proposal is not such a case.
Let's explore the team lead's range of possible answers:
1. "No."
If you can pull it off, all the power to you. With most people, this Larry David answer will definitely harsh the vibe.
2. "Can you write this up in a formal proposal?"
Here, the team lead is punting on having to say "no". If the lead knows the answer is "no", it's a colossal waste of time to lead the developer down the garden path like this. This is the equivalent of saying "yes" to a party you never intend to go to and then messaging two hours before to say you're sick (and you're not sick).
3. "How long will it take to build without the refactor?"
I think a lot of people would recommend this answer but the problem is that it doesn't contain the word "no". It starts a conversation about the trade offs of the decision even though the team lead knows what the answer must be. The result will be a lengthy debate where the lead continually highlights the negatives until the developer hears the implicit "no".
4. "No, because [the refactor is a bad idea]."
This could be a good response but it also has the potential for a lengthy debate. If the team lead knows the codebase well and can emphatically demonstrate in a few sentences that the refactor makes no sense, this could be a fast "no". If not, it could lead to a lengthy intractable debate on the merits of the refactor. The more experienced the developer is, the less likely this response will work.
5. "No, because [we just need to get shit done]."
This is a very fast "no" which is hard for the developer to argue with. The problem is that if developers are proposing refactors that actually would greatly improve the codebase and the lead is always giving this answer, then the codebase will enter a death spiral. A lead can only use this answer every now and then.
6. "No, because I'd rather invest that time on [other project with greater potential impact]."
Personally this is probably the best default response because it brings the developer into the team lead's decision making framework where everything is a trade off on developer time. For this to work, the team lead must be unequivocal with their delivery of the "no" and the developer must hear it. Otherwise, you get a lengthy debate on priorities.
7. [Question was never asked]
Not technically an answer but it's important to note that the fastest way to say "no" to a question is to ensure the question is never asked to begin with. Teams where no developers ever come forth with their own ideas are deeply dysfunctional, but so are teams where developers come forth with every idea. Teams want to live in the middle of this spectrum.
Generalizing from these examples we can form some guiding principles for a team lead to navigate responding to a proposal from a developer. First, when a team lead is certain the answer to a proposal is "no" the time it takes to communicate that to the team must be as close to instantaneous as possible. This is done by stating "no" clearly while offering the most applicable justification in a way that signals to the developer that there is limited space for debate. If the developer receives a clear "no" and does not hear it, the team lead needs to give feedback to the developer on this.
A second goal of the team lead is to foster a culture where developers only come forth with proposals that have strong merit and fit with the objectives of the team. The lead must ensure that the culture is not overly repressive such that many good ideas are not coming forward at all nor overly accepting where developers are coming forth with every whim that crosses their minds. The team lead can accomplish this by making priorities clear and giving developers a view into the lead's decision making framework.
If you enjoyed this post, please follow me on Twitter to catch the next one or subscribe via email or RSS feed.