Learning to Say No

The journey

When one begins a career in software development, their daily activities often mostly involve writing code. There may be a team standup on the calendar every day, and perhaps a sprint review or a retrospective every week. Other than these team-related meetings, their calendar is probably very open with minimal interruptions. Each day is likely filled with six to seven hours of delivering code.

As software developers progress through their careers, they typically take on more responsibility. The first progression might be more responsibility within their development team. Taking on harder tasks and mentoring less experienced developers are often steps on the path to a better title, a better paycheck, and more responsibility. Once a developer can do those activities effectively, the job can often blossom into a variety of responsibilities. Leading teams, interfacing with internal and external stakeholders, driving technical direction, and architecting new features are just some of the things an experienced developers may find themselves doing.

Saying yes

No matter where you are on this journey, you may have already realized that one way to build your career is to say "yes" a lot. When you get asked if you can carry the task over the line, or run the sprint review when the team lead is on vacation, or talk to the product manager about that new feature, you probably say "Sure thing!" That is great! If you don't feel like you've hit the limit on your potential, keep doing that. A can-do attitude will take you a long way in your career.

If you've been saying "yes" for years, you're probably starting to get several asks from various individuals by now. Do you hear the questions below, or questions like them frequently?

• Can you get that feature done this sprint?
• Would you teach the customer support team how to triage this issue?
• Can you jump in with that sales conversation to help get this prospect on board with our tech?
• Can you evaluate this new technology we should use?

If you get these types of asks at least three or four times a week, and you're saying yes to all of them, you are probably feeling pretty stressed out about the code you're trying to write. You probably don't have the time to write high-quality code, you miss your sprint targets, or you wind up being the critical path for your team. Luckily, there is a solution to this problem - say no to some of these questions.

How to know when you're too busy

The reality is that you've worked for years saying yes to get to the point in your career where your peers trust you with the responsibilities behind their questions. You have sound technical judgment, you're the "glue" between technical and non-technical team members, and you can just get things done. You can't just start saying no to these types of questions. Instead, you must develop strategies to handle these kinds of questions when you receive them.

I have found that the key for me is to have a way to track the things I am responsible for at any given moment. I have a Personal Kanban board that I manage for myself in Trello. The shape of that board changes from time to time depending on how many asks I'm getting and how many development tasks I have in progress, but the usage of it is a constant. Using this board, I can visualize at any given moment what I'm responsible for right now.

Using this board, I'm much more equipped to know what I can take on at any moment. Did I just get a last-minute ask to teach a client how to do something? Do I need to figure out if I'm going to pick up a meaty sprint task? The Personal Kanban board will tell me if I have too much in progress right now to be able to commit to doing that teaching. If the board is pretty empty, I gladly say yes. But, if the board is full, I have to find a way to say no.

I believe it is important to manage your own Personal Kanban board. While you may have an issue tracking system that you use with your co-workers, managing your own board ensures you have the issues you need to solve represented as you understand them. It doesn't have to be a digital system, either - it could be post-it notes at your desk, a regular notebook, or something else. Just make sure it is a system that works for you.

How to say no

When your system is telling you that you need to say no, it is important to do it kindly. The best way to say no is to not shut down the person asking you for help. Assuming you would gladly perform the ask, but you can't right now due to other work, the key is to convey that you currently have other priorities for the individual making the ask to you. If you think you'll have more time in a week, ask them if you could do it next week. If they need this accomplished sooner, attempt to identify another member of your company that could help them. You want to be able to help them, even when you can't say yes. If the ask doesn't make sense, ask some clarifying questions to help your peer better understand what they are asking for.

You'll probably make some mistakes from time to time when saying no. You may not say it enough, say it too much, or not say it in a way that is perceived as kind. It's ok to make mistakes as you learn to say no. Retrospect and learn from them when they happen.

It is just part of the job!

At a certain point in every development role, saying no is just part of the job. You have to protect your calendar so you can accomplish the tasks you've previously committed to. Saying it kindly, and attempting to help in different ways, will keep your co-workers, stakeholders, and clients happy to work with you.