4 minutes read | 751 words by Ruben BerenguelSome links are affiliate links
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 leadership1.
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.
This comes straight from DeGrandis’s Making Work Visible. Usually most teams field requests from several stakeholders who are likely not communicating among themselves (this is a problem for another occasion). This is equivalent to being in a very crowded restaurant that only has private rooms for dinners. You order something, it takes a while and you can only assume delivery is slow. But it’s just that you don’t know how many other people are ordering at the same time as you.
This should include first exploratory steps and additional discussion points. So, you agree with your stakeholder to present results by date A… unless something unexpected happens before date B, in that case you will talk with them on day B, explain and reassess. With B significantly earlier than A, depending on the amount of work, complexity and workloads. This needs to be agreed with the stakeholder, preparing alternative timelines that allow for this. Sounds hard, but can be done. You and your stakeholder need to be on the same page.
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.
Generalising is bad, but in general lack of trust can’t be passed down easily. ↩︎