Lesson 116 - Negotiation Tips for Software Architects
Summary
TLDRIn this Software Architecture Monday lesson, Mark Richards, an independent consultant and founder of developer2architect.com, shares key negotiation tips for software architects. He emphasizes the importance of negotiation skills in navigating enterprise politics and getting buy-in for architecture decisions. Key tips include knowing when to fight for decisions, the power of demonstration over discussion, using the divide and conquer technique, and focusing on business value in negotiations. Richards also stresses the need for involving developers in decision-making and qualifying costs or time to strengthen negotiations.
Takeaways
- 😀 Negotiation skills are essential for software architects, as most architectural decisions will be challenged by developers, other architects, or business stakeholders.
- 😀 Knowing when to fight for a decision and when to let it go is critical. Fight for architecture decisions that impact key system characteristics like availability, responsiveness, and scalability.
- 😀 Demonstration defeats discussion. Using visual aids, metrics, and demonstrations to explain architectural decisions is often more effective than simply talking about them.
- 😀 The divide and conquer strategy helps break down complex problems and reduce time and cost by focusing on the specific aspects that need attention.
- 😀 Focusing on business value in negotiations with stakeholders is key. Highlighting how a decision impacts time-to-market or customer experience can gain more support than discussing technical aspects.
- 😀 Involving developers in architecture decisions ensures buy-in and adherence. If developers understand why a decision is made and are involved in its creation, they are more likely to support it.
- 😀 It's crucial to justify decisions properly and collaborate with developers to validate assumptions. Developers are more likely to follow decisions when they feel part of the process.
- 😀 Architects should avoid using cost or time delays as negotiation tools unless those costs are well-researched and clearly quantified. Always be specific about how decisions impact time and cost.
- 😀 Architects should learn to negotiate in terms of qualified costs or time, using these factors as trade-offs to persuade stakeholders to make informed decisions.
- 😀 Negotiation skills for architects also include turning a negotiation into a value conversation, where business outcomes like speed of delivery or cost savings are prioritized over technical details.
Q & A
What is the primary negotiation skill that software architects need to develop?
-Software architects need to develop negotiation skills to effectively navigate the political climate within the enterprise and gain buy-in for their architectural decisions from developers, other architects, and business stakeholders.
Why is it important for architects to know when to fight for a decision and when to let it go?
-It's important because constantly fighting for every architectural decision can create a tense work environment and diminish respect. Architects must discern which decisions impact key architecture characteristics (e.g., availability, scalability) and which ones are more about personal preference, so they know when to assert themselves and when to compromise.
What is meant by 'DDD' in the context of negotiation tips for architects?
-In this context, 'DDD' stands for 'Demonstration Defeats Discussion.' It emphasizes the power of showing a solution or issue visually rather than engaging in prolonged verbal discussions, which can be ineffective in convincing others.
How can demonstrating an issue or solution help in a negotiation?
-Demonstrating an issue or solution, such as using metrics and charts, can make the problem tangible and easier for others to understand, leading to quicker buy-in and agreement compared to just discussing the problem.
What does the 'divide and conquer' rule mean in the context of negotiation for architects?
-The 'divide and conquer' rule means breaking down complex or absolute requirements into smaller, more manageable pieces. This approach can help avoid all-or-nothing situations and allow for more focused discussions, often reducing both cost and time for implementing solutions.
Why is it important for architects to focus on business value during negotiations with stakeholders?
-Focusing on business value, such as time to market and delivering features quickly, helps capture the attention of business stakeholders who care more about these outcomes than the technical details of architecture decisions.
What is the role of developers in architectural decision-making, according to the script?
-Developers should be involved in architectural decision-making because their involvement increases the likelihood of gaining their buy-in and ensures they understand the rationale behind decisions. This collaboration also helps validate the architect's assumptions and assertions.
How does the concept of 'qualified cost or time' help architects in negotiations?
-The concept of 'qualified cost or time' helps architects turn negotiations into practical trade-offs by providing concrete data about how additional costs or delays might affect the project. It also enables architects to demonstrate potential savings, offering a more informed and balanced approach to decision-making.
What is the impact of not involving developers in architectural decisions?
-If developers are not involved in architectural decisions, they are less likely to follow those decisions because they may not understand the reasoning behind them, leading to reduced collaboration and possible resistance.
How can architects handle situations where business stakeholders do not understand the technical aspects of a decision?
-Architects can handle this by reframing the discussion to emphasize the business impact, such as focusing on how certain architectural decisions will improve time to market or help deliver features faster, thus making the discussion more relevant to business stakeholders.
Outlines
This section is available to paid users only. Please upgrade to access this part.
Upgrade NowMindmap
This section is available to paid users only. Please upgrade to access this part.
Upgrade NowKeywords
This section is available to paid users only. Please upgrade to access this part.
Upgrade NowHighlights
This section is available to paid users only. Please upgrade to access this part.
Upgrade NowTranscripts
This section is available to paid users only. Please upgrade to access this part.
Upgrade NowBrowse More Related Video
Lesson 66 - Durable Interface Strategy of Enterprise Architecture
Lesson 156 - Zachman Framework in 10 Minutes
Lesson 167 - Architecture vs Design
Lesson 64 - Classic Alternatives Strategy of Enterprise Architecture
Lesson 63 - Prescriptive Strategy of Enterprise Architecture
Lesson 65 - Distributed Strategy of Enterprise Architecture
5.0 / 5 (0 votes)