How Many CTOs?

How can engineering teams build trust with non-technical stakeholders?

Short answer

Engineering teams can build trust with non-technical stakeholders by ensuring reliability in delivery and maintaining transparent communication. Trust is fostered when teams deliver on their commitments and clearly communicate progress and challenges.

Engineering teams can build trust with non-technical stakeholders by ensuring reliability in delivery and maintaining transparent communication. Trust is fostered when teams deliver on their commitments and clearly communicate progress and challenges.

Reliability Over Speed

One of the key takeaways from our discussion is that reliability often trumps speed when it comes to building trust. Scott shared, "Reliability is more valuable than speed. There's no point in going fast if you still show up late." ▶ 3:53. This sentiment highlights the importance of setting realistic expectations and consistently meeting them. When engineering teams deliver what they promise, stakeholders can plan their activities, such as marketing and sales, around those timelines. This orchestration across departments is crucial for the overall success of the company.

Brad emphasized the mysterious nature of engineering work to non-technical stakeholders, likening it to an enigma. He noted that if stakeholders don't understand what engineers do and find them unreliable, it further erodes trust. "What's the point in going faster if you don't get there on time?" ▶ 8:30. Therefore, establishing a track record of dependable delivery is foundational to building trust.

Clear Communication and Prioritization

Another critical aspect of building trust is clear communication, especially regarding prioritization. Scott recounted a situation where a stakeholder pressured him about whether the team could take on a new task. He realized the better question was not "can we do it?" but "when can we do it?" This shift in perspective is crucial because it emphasizes prioritization over mere capability. "We're operating against a set of priorities that we agree to," Scott explained, highlighting the importance of aligning on what gets done first ▶ 12:06.

Brad and Scott both acknowledged that sometimes stakeholders need a thought partner to help them navigate prioritization. Scott mentioned, "Sometimes that stakeholder, CEO, head of product, whoever, they need a thought partner." By offering recommendations on where to slot new projects, engineering leaders can foster a more collaborative relationship with stakeholders, helping them understand the trade-offs and implications of their requests.

Transparency in Progress

Transparency in progress is another cornerstone of trust. Scott shared an example of how visualizing progress can help stakeholders see that work is being done. By tweaking the sprint planning dashboard to show QA activities, stakeholders could visibly see progress, which helped build trust. "So you'll definitionally see them doing their work because there's that level of the testing lane," Scott explained ▶ 43:43.

Breaking down large projects into smaller, demonstrable pieces can also mitigate the perception of a lack of urgency. Scott noted, "Mitigate the feeling of lack of urgency by leveraging some of these techniques that are already in Scrum," such as ensuring that every sprint ends with shippable or demonstrable software ▶ 47:08. This approach not only provides stakeholders with visible progress but also reinforces the team's reliability.

Addressing the Perception of Urgency

A recurring theme in the episode was the perception of urgency and how it affects trust. Brad pointed out that sometimes the engineering organization's behavior might inadvertently undermine the perception of urgency. "Are there parts of the way that the engineering organization is behaving that may inadvertently undermine the perception of urgency?" he asked ▶ 36:00.

Scott added that stakeholders often express concerns about a lack of urgency when they don't see changes happening as fast as they expect. This perception can be influenced by various factors, including unrealistic expectations set by vendors or a lack of understanding of the complexity involved in software development. Scott shared a story about a vendor claiming that a setup would take only 60 seconds, which set unrealistic expectations for the stakeholders. "I get anchored to that. Why is it taking you longer than 12?" he recounted ▶ 28:27.

In conclusion, building trust with non-technical stakeholders requires a focus on reliability, clear communication, transparency, and addressing perceptions of urgency. By consistently delivering on commitments and maintaining open lines of communication, engineering teams can foster a trusting relationship with their stakeholders, ultimately contributing to the success of the organization.