Today I read an intriguing HBR article on trust that got me thinking about the principle of “Trust but Verify” as a leader. While I recognise the value of this principle in certain circumstances, I have reservations about the inputs and context presented in the article, which ultimately led to the conclusion that “A little skepticism never hurt anyone— or any team” especially when viewed from a software development standpoint. Here’s my take on it:
The study referenced in the article looked at the impact of trust on team performance over a 4 month period and concluded that “trust dampened performance” I believe the core problem is the lack of a short feedback loop rather than trust itself. 4 months provides ample time for individuals and teams to veer off course or make poor decisions.
My understanding is that the article seems to confuse the autonomy of individual team members with the autonomy of the team as a whole. Highly autonomous members do not necessarily make highly autonomous teams. I do not consider a set-up where “members worked independent of one another” a team, but at best a group of individuals who share work and require additional processes and coordination to achieve coherent outcomes. While the article acknowledges the impact of overhead, it seems to overlook the fact that it is the primary reason for failure.
So instead of “trust but verify,” I would suggest the following:
⏰🔄 Trust but coach to gather feedback as soon as possible.
🤝🚀 Trust but coach to be a team and collaborate together.