Why say “no”?  ## Metadata - Author: [[Mike McQuaid]] - Full Title: Why say “no”? - Category: #articles - Document Note: ## Summarize: This article offers valuable insights on the importance of setting boundaries and saying "no" effectively. Drawing inspiration from Brené Brown's BRAVING acronym, the author emphasizes that trust, built on boundaries, reliability, and integrity, is crucial in any relationship. Like a well-designed API, consistent and predictable responses make human relationships more pleasant. The author shares a personal experience where setting clear boundaries not only made them easier to work with but also set an example for their team. They advocate for "front-loading disappointment," being upfront about workload and estimates to manage expectations effectively. The article discusses when to say "no," encouraging readers to consider their current workload, stress levels, commitments, and long-term goals. It's acceptable to say "no" if it aligns with their capacity and priorities. The author advises artful communication while declining requests and avoiding the term "impossible." Seeking help from others and understanding the underlying reasons for disagreements can also facilitate effective communication. ## Bullet Points: - The importance of setting boundaries and saying "no" effectively. - Trust in relationships is built on boundaries, reliability, and integrity (inspired by Brené Brown's BRAVING acronym). - Human relationships are like APIs; consistent and predictable responses make them more pleasant. - Personal experience: Setting boundaries made the author easier to work with and set a positive example for their team. - "Front-loading disappointment": Being upfront about workload and estimates to manage expectations effectively. - Knowing when to say "no": Consider current workload, stress levels, commitments, and long-term goals. - Saying "no" is acceptable if it aligns with capacity and priorities. - Artful communication when declining requests, avoiding the term "impossible." - Seeking help from others and understanding reasons for disagreements can facilitate effective communication. ## Paraphrase: 1. The author shares a personal experience where they were commended for being strict with their boundaries, indicating that this characteristic made them easier to work with and set an example for their team members regarding work-life balance and expectations. This demonstrates that being mindful of personal limits and being unafraid to say "no" when necessary can lead to positive outcomes for both individuals and teams. 2. Similar to software engineering experiences with APIs, the author likens human relationships to consistent and predictable systems. Just as an API with inconsistent behavior is considered terrible, being inconsistent in one's responses to coworkers can negatively impact relationships. Thus, setting clear boundaries and providing honest estimates or responses fosters trust and makes interactions more pleasant and reliable. ### Conclusion: Setting boundaries and effectively saying "no" are essential for building trust and maintaining healthy relationships, both professionally and personally. Emulating a well-designed API, consistent and predictable responses lead to more pleasant interactions. Being strict with boundaries can positively impact teamwork and serve as an example for others. "Front-loading disappointment" by communicating honestly about workload and estimates helps manage expectations effectively. Knowing when to say "no" and artfully communicating the reasons behind it are important skills to maintain a healthy work-life balance. Seeking assistance from others and understanding reasons for disagreements can foster better communication and resolve conflicts amicably. ### Questions: 1. How can applying the BRAVING acronym (boundaries, reliability, and integrity) in relationships help build trust and enhance communication? 2. In what ways can treating human relationships like well-designed APIs lead to more predictable and pleasant interactions? 3. How can setting clear boundaries and saying "no" when necessary positively impact both individual and team dynamics in a professional setting? 4. What strategies can be employed to "front-load disappointment" and manage expectations effectively in personal and work-related commitments? 5. How can individuals strike a balance between saying "yes" and "no" to requests, considering their workload, stress levels, and long-term goals? 6. What are some effective communication techniques to decline requests while maintaining positive relationships and avoiding misunderstandings? 7. How can seeking help from coworkers or superiors be beneficial when one needs to decline certain requests? 8. What are the potential consequences of using the term "impossible" when declining a request, and how can it be better handled? 9. How can understanding the underlying reasons for disagreements in relationships lead to more constructive and empathetic communication? 10. In what other contexts can the concept of "front-loading disappointment" be applied, and how might it improve various aspects of life? ### Auto-tagging: boundaries, saying "no", trust-building, reliability, integrity, human relationships, API analogy, work-life balance, communication, setting expectations ### Index Creation: - Boundaries: importance, impact on relationships, role in trust-building - Saying "no": artful communication, impact on interactions, maintaining work-life balance - Trust-building: inspired by Brené Brown's BRAVING acronym (boundaries, reliability, integrity), API analogy - Work-life balance: setting boundaries, effective communication, managing expectations - API analogy: likening human relationships to consistent and predictable systems ### Table of Contents: 1. Why Say "No"? - Importance of Boundaries and Trust 2. Human Relationships as APIs - Consistency and Predictability 3. Personal Experience - Positive Outcomes of Setting Boundaries 4. Front-loading Disappointment - Honest Communication for Managing Expectations 5. Knowing When to Say "No" - Balancing Workload and Priorities 6. Artful Communication - Declining Requests Effectively 7. Seeking Help and Understanding Disagreements - Fostering Better Communication 8. The "Impossible" Scenario - Avoiding Miscommunication 9. Conclusion - Building Trust and Maintaining Healthy Relationships ### References: - Brené Brown's podcasts and books (mentioned in the article) - Personal experience and observations of the author - Conversations with @nerdneha, feedback from @kenyonj, and @katestud ### Future Research: - Conduct studies on the long-term effects of setting boundaries and saying "no" effectively on various types of relationships, including personal, professional, and community-based interactions. - Investigate how different communication styles impact the perception of "no" and how artful communication can be taught and developed in different contexts. - Examine the correlation between setting boundaries and employee well-being, job satisfaction, and productivity in various industries and organizational structures. - Explore the concept of "front-loading disappointment" in different settings, such as project management, customer relations, and leadership roles, to assess its effectiveness in diverse scenarios. ### Hypotheses: 1. Individuals who establish clear boundaries and effectively say "no" when necessary will experience higher levels of trust and satisfaction in their relationships. 2. Using the API analogy to frame human relationships will lead to improved communication and predictability in interactions. 3. Employees who prioritize work-life balance and say "no" when appropriate will demonstrate increased productivity and job satisfaction. 4. Artful communication when declining requests will result in more understanding and positive reactions from the requesting party. 5. Seeking assistance from superiors or colleagues to decline certain requests will lead to a more supportive and collaborative work environment. 6. Avoiding the term "impossible" when declining tasks will foster a more solution-oriented approach and prevent unnecessary limitations. 7. Understanding the underlying reasons for disagreements in relatio - Document Tags: [[commitment]] [[say no]] - Summary: I’ve developed a bit of a reputation inside and outside work as being pretty good with “saying no” and setting boundaries. In this post, I will help you do so, too. - URL: https://mikemcquaid.com/saying-no/ [#### Saying No](https://mikemcquaid.com/saying-no/) I’ve developed a bit of a reputation inside and outside work as being pretty good with “saying no” and setting boundaries. In this post, I will help you do so, too. I’ve been consuming a lot of Brené Brown’s [podcasts](https://brenebrown.com/podcasts/) and read [one of her books](https://brenebrown.com/book/atlas-of-the-heart/) recently, and they’ve got me thinking about what’s at the root of being able to say “no” regularly and well. [](https://www.linkedin.com/pulse/braving-trust-brené-brown/) Brown uses the [BRAVING acronym](https://www.linkedin.com/pulse/braving-trust-brené-brown/) to refer to the elements of Trust. Out of these, the ones that jump out to me for saying no are boundaries, reliability and integrity. To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker. To the software engineers reading this, I’m sure we’ve all worked with some APIs that have been great and some that have been terrible. An API with inconsistent and unpredictable behaviour with the same inputs is terrible. A poorly documented API is terrible. An API that attempts to accommodate your request and consistently times out rather than failing immediately is terrible. Human relationships are like APIs: consistent and predictable responses make them more pleasant. A bad API for your coworkers is when you’re someone who gives radically different estimates for the same work based on whether you want to impress the person or not. A bad API for your coworkers is when you state you’re on holiday or sick but still appear in conversations and meetings anyway. A bad API for your coworkers is when you tell them a 19:00 meeting is fine, but you’re hangry and irritable because you’ve missed dinner and your children’s bedtime. A previous performance review of mine from [a great manager](https://github.com/derekprior) started with the sentence “Mike is very strict with his boundaries”. “Oh no”, I thought to myself, “I’m going to get criticised for always prioritising being there for my children’s dinner and bedtimes four nights of the week”. Instead, he went on to say that this made me easier to work with, set an excellent example for other members of the team to not overwork and set expectations for new parents on the team. Ironically, in this case, being a little more selfish with my time and strict with my boundaries produced an outcome that benefitted the entire team. Having these boundaries clear and upfront is more complex but crucial for unexpected tasks. If when asked for an estimate, [you can tell there’s a bunch of complexity that the requester did not consider](https://mikemcquaid.com/hidden-complexities-of-software-estimation/) and know that your realistic one will disappoint them: you should give them the realistic estimate. If you already feel overwhelmed or have too much to do when asked to do something new: you should say “no” regardless. I call this “front-loading disappointment”. It’s better to have a conversation about your full workload or longer estimate now when people can prepare for it. Making them happy now and then disappointing them in a few months when you don’t deliver what they planned for you is worse. I’ve also found it less disruptive in my workplaces to ship a project earlier than planned rather than later than planned. If you’re the type of person who hates disappointing others: you’ll need to take my word for it that there’s reduced disappointment overall when it’s pushed earlier. Similarly, you’re not responsible for others disappointment with the facts they didn’t know before you (nicely) revealed them. ##### When to say “no” Ok, we’ve touched upon why you should say “no”, so let’s discuss when it’s appropriate to do so. What’s your current workload right now? How are your stress levels outside work? Do you have many commitments you need to meet soon to coworkers, family or friends? What are your goals for the next 3-12 months and what’s the best use of your time to achieve them? What tasks do you have on your plate that are “essential” rather than “nice to have”? Regularly asking yourself these questions can help prime you to remind you of them when receiving a request. When a new request comes in, and you’ve asked yourself the questions above, you’ll probably have a good sense of whether you can meet the needs and expectations of the requester or not. If you think you cannot right now: say “no”. Every “yes” is implicitly a “no” to something else you might not know yet. Don’t worry about if you’ve been saying “no” a lot recently; this is not necessarily a problem. Of course, if you’re saying no to every request from coworkers, friends and family, this could be a symptom of a broader problem. At work, though, it’s expected that there will be more demands on your time than your available time. If you’re saying “no” a lot, but you’re still delivering great work, and your coworkers and manager are happy with you: you’re doing enough. ##### How to say “no” There’s still a little bit of art involved in saying “no”. It may be that your “no” actually means “no because …, “no unless you …” or “no if this …”. These “no”s may be conditional on you as an individual, the timing of the request, the scope of the request or many other reasons. Try to share your reasoning with the person who has requested this of you; it may be that something you understood as critical to the task is actually optional and can be removed given the extra context of a “no because …” or “no unless …” provides. At least in software engineering, one word to avoid is “impossible”. There are very few things that are genuinely “impossible” (e.g. [the halting problem](https://en.wikipedia.org/wiki/Halting_problem)) and avoid it unless it’s one of those. If you’re saying you cannot do a task now, avoiding “impossible” ensures that you don’t try to generalise that to state that no one can do it ever. If you’re feeling like you’re saying “no” a lot and this is dragging you down, you can ask others to help you. The engineering/project/product manager or a [staff-plus engineer](https://mikemcquaid.com/what-is-a-staff-plus-principal-engineer/) on your project may be able to say no on your behalf. It may also be if you repeatedly state “no” to the same person that they are asking the wrong layer of the organisation, i.e. an individual contributor rather than their engineering manager or product manager. Finally, a “no” is generally a disagreement in either values or information. Figuring out which one applies now may help you figure out how best to communicate or get past the “no”. For example, my current GitHub organisation (Communities) has tight values alignment. When we need to communicate a “no” in Communities, it’s a matter of sharing missing information rather than resolving a values difference. In open source, my “no”s are often due to a misunderstanding about what [my obligations are (not) to those people who use my projects](https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/). Thanks to [@nerdneha](https://github.com/nerdneha) for talking through this post with me and to my long-suffering coworkers and contributors to the open-source projects I maintain for all my “no”s over the years. Thanks to [@kenyonj](https://github.com/kenyonj) and [@katestud](https://github.com/katestud) for providing excellent feedback on this post. ##### Latest Articles ##### Subscribe to be notified about new content, Why say “no”?, Mike McQuaid, 01h557dwypz45790c51m9yq0fw.