diff --git a/categories/communication/rules-to-better-meetings.md b/categories/communication/rules-to-better-meetings.md index 585c9cfb4b7..a24732f52db 100644 --- a/categories/communication/rules-to-better-meetings.md +++ b/categories/communication/rules-to-better-meetings.md @@ -9,6 +9,7 @@ index: - only-invite-the-minimum-number-of-people-possible - the-3-criteria-that-make-a-good-meeting - share-the-agenda +- recognize-anchoring-effects - stick-to-the-agenda-and-complete-the-meetings-goal - creating-action-items - loop-someone-in @@ -21,12 +22,12 @@ index: Meetings that lack efficiency frequently occur because: -- People are not prepared -- There is a lot of discussion but no resulting "action items" -- Rat holes - Time is wasted digressing to unrelated topics -- People forget the meeting is on and do not attend -- People turn up late with no notice -- Meetings go well overtime +* People are not prepared +* There is a lot of discussion but no resulting "action items" +* Rat holes - Time is wasted digressing to unrelated topics +* People forget the meeting is on and do not attend +* People turn up late with no notice +* Meetings go well overtime If you have a 1-hour meeting with 5 people in attendance, you're not just wasting 1 hour if it's not productive, your wasting 5 man hours. One hour for each attendee. That's a lot of man hours! diff --git a/rules/recognize-anchoring-effects/rule.md b/rules/recognize-anchoring-effects/rule.md new file mode 100644 index 00000000000..4cac6d187c7 --- /dev/null +++ b/rules/recognize-anchoring-effects/rule.md @@ -0,0 +1,68 @@ +--- +type: rule +title: Do you recognize the effects of anchoring in decision making? +uri: recognize-anchoring-effects +authors: + - title: Tanya Leahy + url: https://ssw.com.au/people/tanya-leahy + - title: Michael Smedley + url: https://ssw.com.au/people/michael-smedley +guid: 69b80ab3-e4fa-4624-93a5-3ec6c01141d8 +created: 2024-05-03T18:29:33.0000000Z +related: + - share-the-agenda + - stick-to-the-agenda-and-complete-the-meetings-goal +redirects: [] + +--- + +Anchoring is a cognitive bias where an initial piece of information (the "anchor") heavily influences subsequent judgments and decisions. This bias can infiltrate various aspects of our lives, including workplace interactions and negotiations. Recognizing how anchoring works is crucial to making informed and unbiased decisions. Custom software is difficult to estimate and using an anchor too early or without the necessary rigour can create issues. + +For example, in meetings, it's vital to be aware of anchoring, as the first opinions can shape entire discussions. + + + +`youtube: https://youtu.be/JL4OoKJyNrc` +**Video: Jeff Bezos: Truth is uncomfortable | Lex Fridman Podcast Clips (6 min)** + +## Negative impacts of anchoring + +An anchor can limit adaptability, making it harder to find mutually agreeable solutions. For instance, a developer’s best guess on a project budget might discourage the client from choosing your solution looking for other options that could be better suited and more cost-effective. + +### Key reasons to avoid providing an anchor + +* **Limited information:** Early estimates often lack the detailed requirements and complexity analysis needed for an accurate price. Setting an anchor prematurely creates a false sense of precision and sets unrealistic expectations + +* **Loss of flexibility:** A strong initial anchor can stifle negotiation and make it harder to adapt your proposal as more information becomes available. This can hurt your ability to arrive at a price that's fair for both you and the client + +* **Damaged trust:** If the final estimate varies significantly from the initial anchor, it can erode the client's trust in your process. Transparency and an open discussion of uncertainties upfront are key to building a strong client relationship + +### How to deal with anchoring + +Sales need to establish the client’s anchor, if they have one, by asking: + +1. "Can you describe the process you need improved and its main challenges?" +2. "How does this issue impact productivity or costs?" +3. "What's your decision-making process and who's involved?" +4. "What's your timeline and budget for a solution?" + +::: greybox +When asked for an early estimate on a new project, a developer might say **"I reckon it'll cost around $50,000"**. This off-the-cuff estimate sets an unverified anchor that might restrict further discussion and lead to budget constraints based on a premature guess. +::: +::: bad +Figure: Bad example - Premature estimation without due diligence can lead to inaccurate budgeting and client expectations +::: + +::: greybox +Conversely, when asked for an early estimate, a more experienced developer might respond, **"To give you an accurate estimate, we should conduct a Specification Review where we can consider all aspects of the project. This way, we can provide a detailed and reliable estimate that reflects the project's complexity"**. +::: +::: good +Figure: Good example - Suggesting a Spec Review ensures that any estimates provided are well-informed and considered +::: + +### Key Takeaways + +* **Be aware of how anchoring bias can influence decisions,** both within yourself and others +* **Proactively seek diverse perspectives** to mitigate the bias +* **Approach initial information critically,** even if it seems compelling, to avoid getting overly 'anchored' in one viewpoint +* **Use anchoring strategically** for setting expectations or initiating negotiations, but be prepared to adjust as needed