--- title: "How to say NO by saying YES" url: "https://www.5whys.com/articles/how-to-say-no-by-saying-yes-1.md" canonical: "https://www.5whys.com/articles/how-to-say-no-by-saying-yes-1.html" published: "2009-09-14T20:01:57+00:00" updated: "2009-09-14T20:15:15.056000+00:00" tags: ["Decision Making", "Shu", "Visual Task Board"] author: "Roy Osherove" description: "How a visual task board lets a team say no to a manager's urgent request by showing its real cost, letting the manager reprioritize the work themselves." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to say NO by saying YES Johanna Rothman, a dear friend and one of the most excellent management consultants I've seen,  [has a post about managers who won't take no for an answer](http://jrothman.com/blog/mpd/2009/09/when-managers-cant-hear-no.html). Read it, it's interesting! But I'd like to approach the same issue from a different angle - Instead of looking at why the manager wants something, let's try and look on why we say "No" to that something (This is a good place to try the [five whys technique](http://en.wikipedia.org/wiki/5_Whys)).  Usually we'll find that we say no because the requested item might be of lower priority and could interfere with much more pressing items. Sometimes we'll just feel like the manager is asking fomr something just because he\\she can - and we don't like people wasting our time. Instead of saying no, let's let the manager figure out if a "No" is indeed in order. WHat you'd need for this is at the very least [a Visual Task board](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html) or an excel file with the list of tasks you're doing and backlog of items to be done, **ordered by priority**. Next time the manager comes in and asks for something  in the middle of something else, drag them over to look at the task board. Now, create a new post it note with the task at hand, and ask thema simple question: > How important is this? If they say "I'd love to have it today", ask them : > OK, that means we will have to stop working on one of these following tasks (point to the "in progress" column).  Are you OK with us stopping to work on \[pick one of the cards in progress\]? If they say yes - great. Not only did you find an important feature to work on, you've also let the manager know the cost of doing that feature: Stopping to work on another feature. But what usually happens is that the manager soon realizes that this cost exists, and may not want to replace an existing in progress task  - since these are all pretty important as well. The manager might say "well, no, it's not **that** important".  This is the point where you ask them to actually place the card in the "TODO" column just above one of the other tasks in it. They get to **choose** which is more important. More often than not, the task at hand will not be important enough to trump any of the existing "TODO" cards, so it will be at the bottom. Now you've gained something else - the manager has agreed knowingly to delay that feature request, since they know its true cost. Visual Task boards help you teach your manager when to say "NO' all on their own. ## Read next - [Step #2 – Use a big visible board with post it notes](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html): How a team lead can use a big visible whiteboard with sticky notes to track tasks, expose developers juggling several tasks, and show management the load. - [Daily Standup Meetings - Introduction and 5 useful tips](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html): How to run a daily standup meeting with the three questions, why each question matters, and five hard-learned tips for keeping it under 15 minutes. - [Step #1 – Claim Your Territory, Own your team](https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html): Why a dev lead must claim the team's territory: keep implementation decisions inside the team, be its single entry point, and ask why outsiders interfere. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/