Don't explain your technical considerations to stakeholders
When working in a team, it is common that stakeholders want to understand the technical considerations behind certain decisions. While transparency is generally a good thing, I believe that explaining technical details to non-technical stakeholders can often do more harm than good.
The context
This blog post is based around a some discussions I had at work recently, and my view is formed by similar experiences in my many years as a software developer. In these discussions, some stakeholders with more-than-average technical knowledge and insights may ask for an explanation or our reasoning behind certain technical decisions.
Do not explain
I think we should not make the mistake of discussing technical things with stakeholders.
Reasoning
The main risk of diving into technical explanations is creating distrust. When stakeholders hear complex trade-offs or implementation details, they may feel the need to verify, question, or even override technical decisions. This can lead to problems:
Stakeholkers are given the opportunity to intervene in technical matters they do not fully understand. This can diminish the authority of the development team and lead to micromanagement.
Developers may feel that their expertise is being doubted, leading to frustration and decreased morale. This can create an adversarial relationship between stakeholders and the development team.
Time spent justifying technical decisions distracts from building the product. This can lead to inefficiency and friction.
Ultimately, the root cause is a lack of trust. When stakeholders trust the team’s expertise and processes, there is no need to justify every internal decision. This aligns with insights from management and software experts: Frederick Brooks notes that management decisions should not be burdened by unnecessary technical detail. Marty Cagan emphasizes that teams should focus on delivering value rather than over-explaining implementation choices.
Alternatively
Instead of explaining technical specifics, you should focus on building trust and communicating outcomes. Keep a high level perspective, define some key epics, and consistently and reliably deliver updates on progress.
Stakeholders never really care about the technical details. So instead of indulging their curiousity, focus on what they do care about and what they should care about: Delivery timelines, product quality, and business value.
Some tricks and tips I picked up:
- Acknowledge their competence, and thank them for their interest. Then quickly explain that it is best to focus on outcomes rather than technical details.
- Frame your response as context, not justification. What that means is that you provide enough information to help understand that it is not arbitrary, but avoid going into deep technical detail.
- Avoid the trap of listing details
- Reinforce trust. Mention that you are focusing on doing things efficently and effectively. Promise that you are using the best route available, and that you will raise any significant issues if they arise.
Focus on the results. Emphasize how the
- Highlight impact: Explain how decisions affect product goals, customer value, or business objectives.
- Frame risks simply: Discuss potential consequences without delving into low-level implementation.
- Show process reliability: Reassure stakeholders that the team follows best practices and informed methods.
By focusing on trust and outcomes, teams maintain efficiency and stakeholder alignment while avoiding unnecessary technical friction. This approach aligns with Agile thinking, which prioritizes delivering value and working solutions over exhaustive technical explanation. By emphasizing outcomes rather than implementation details, teams foster collaboration and build confidence with stakeholders, allowing the