Winning stakeholders' trust

Trust between business stakeholders and engineering (and data, analytics, operations…) teams is a tricky matter.

This week I have been thinking a lot about stakeholder trust, particularly as seen from engineering, analytics or data teams towards its stakeholders. It’s usual for stakeholders to have a set of grievances against stream-aligned teams (in the Team Topologies lingo), like:

• We don’t get all the new features we want;
• Our requests take too much time to be delivered;
• What gets delivered does not fulfill the promises.

Sometimes, these stream-aligned teams may pass the hot potato to platform or enablement teams (again, Team Topologies lingo) by blaming the tooling, the knowledge support or the availability of data itself. But that’s usually a cop-out from its leadership¹.

Gaining trust is relatively easy. Even the following reads as just common sense, I have the feeling I also read this in some book (maybe Extreme Ownership? If you know which it may be, ping me on twitter).

How to (re)gain stakeholder trust?

• When a request arrives, assess it against the current requests.
• If it can’t be done against the current backlog of requests, say so to its stakeholder.
• Explain why, give visibility to current work requests, work streams and availability (see Note 1).
• Discuss on possibilities to shuffle current work owned from the same stakeholder.
• Agree on a plan of work, with some intermediate milestones and deliverables (see Note 2).
• You better fulfill this plan.
• Trust increases from this stakeholder.
• Repeat

Why do I suggest all this?

Trust is lost by failed promises. Sometimes this happens because a team has accepted to do everything, and this is also sometimes the solution that is tried to appease stakeholders. Teams then scramble to get everything done and obviously fail. Then the cycle repeats, but having failed on delivering already stakeholders won’t trust any promises or timelines.

By establishing strong communication of what and when, and 100% sticking to them, you make it clear that your team is dependable. This builds trust, and the more milestones and notification points you reach, the more this trust grows. Think of it this way:

• Promise a big deliverable. +5 to trust if done, -10 to trust if not done.
• Promise small milestones and communication points. +1 to trust for each, occasional -1 if news are very bad, -2 if the milestone is failed.

If you can keep adding +1s to this “trust store” in a consistent way, you will erase the deficit of all those -10s that have been accumulating over your team’s history.

Is it hard?

Sure. Stakeholders don’t want to know something can’t be done on their timelines. One way of helping with this is better communication, so you know they may have an idea before they commit to a timeline. Establishing this initial trust and contact points helps with communication, and is helped by increasing communication. Work on that.

Also, stakeholders don’t like bad news in general. But the work of a team lead is to bring the news, be them bad or good. If they are bad, time should come to evaluate why and how to avoid it happening in the future.

Now go and re-evaluate all your current work and start thinking if you really can hit all those deadlines you have set and whether you need to have a call with your stakeholders.

• Management
• Data
• Engineering
• Productivity