Trust Bugs in Software Team Dynamics

handshake_200.png:
Over the years, I’ve come to the conclusion that one of the most important class of bugs any team must fix is what I call “Trust Bugs”.

There are lots of sub-classes of trust bug, each with their own telltale manifestations, but assuming good intentions, trust bugs almost always have their root cause in mismanagement of a team or project. (Is there any difference?)

What is a Trust Bug?

It’s pretty simple really:

A trust bug is any project failure resulting from people or teams not trusting each other.

Ok, that seems stupidly obvious. But when you’re in the team, or you are the person it’s sometimes not so easy to see what’s going on.

An Example Trust Bug

A team of developers is tasked with building a set of custom UI controls that pull data from an online database. The database team has dutifully provided API documentation, and even an SDK for the current version, and is in regular communication with the UI developers.

The database team, in the meantime, is working on changing their underlying schema to version 2.0, and are under deadline pressure to complete this work. In the process, they’ll be updating their existing SDK, and deprecating their current API…

But because the project is secret, they haven’t said anything to the UI developers — even though they work at the same company on the same product.

Blam! Trust Bug!

The database team has information about their roadmap that is absolutely critical to the success of the UI team. But because the database update is both taking all their time, and is secret for so-called “business reasons”, they don’t share with the UI team.

So what happens next?

The UI team becomes increasingly agitated that they can’t even get answers to seemingly simple questions of the database team. They start to badmouth the database team at lunch, at social events, and to their managers.

In the meantime, the database team is becoming increasingly frustrated with the UI developers for bothering them all the time, while they’re heads down on a project with such critical business impact.

After all, if it weren’t critical, then why the heck would it be so secret?

So the database team completely cuts off the UI team, at least until the schema update project is done.

The UI team, which has a dependency on the database, assumes they can ship on schedule but then the rug is pulled out from under them, and they have to either scale back their plans, or push their release schedule back. Either way their product suffers, and everyone comes out looking incompetent.

It Only Gets Worse

moth.png:
So what does this mean for future projects?

At this point, the UI folks think the DB folks are idiots for living in their own world of schemas and database upgrades, and that they pretty much suck at project management and partner relationships, since they haven’t even updated their API documentation, much less their SDK. And when the SDK update does surface, it turns out it’s not backward-compatible and the UI team has to spend weeks updating their own code to even get running again.

And the DB people think the UI people are too demanding, and can’t respect their schedule. They just don’t understand how sensitive this project is, and how trivial the SDK and documentation are, compared to the real work of updating 6-petagazllion records on a live service, without taking down the entire company.

Worst of all, the managers of both teams feel the same way. They don’t trust each other, and the distrust is bolstered by bitch sessions over team lunches and happy-hour beers.

So the mangers and project managers start looking for a way out.

They build expensive process controls, centered around forcing each team to keep very strict commitments to the other. They institute communication protocols that require that everyone attend or present at multiple meetings each week. They want reports with spreadsheets and graphs that they can use to force the other team to meet their schedule, and not change plans in the middle of a project.

End result: Organizational Paralysis

It’s all about open communication!

The story above is probably an extreme example. But at many big companies, that’s exactly what happens, at least some of the time.

So how do you fix this? Open communication:

Make trust a priority

Let your people talk to each other! Don’t silo their communication about project to a “need-to-know” group unless you absolutely must.

Get teams to invest in each others’ success.

Don’t set up incentive systems that inherently make teams compete against each other. If you do, then you’ll end up with one winning team, and nine failing teams.

Find ways to reward cross-team collaboration, without forcing it.

If people are invested in their partnership’s success and not just their own team, then they’ll work super-hard to make the partnership successful.

And when people are allowed to share information freely, collaboration will be much easier.

When we don’t have enough information, people naturally become defensive (or even paranoid), and move to protect themselves and their own team or fiefdom rather than invest in products, customers or the company itself.

More soon…

I’ll write more in a future blog post about how to recognize Trust Bugs, and some specific things you might do to fix them.

One Comment

  1. Mom said:

    Trust bugs are everywhere. Even in relatively small groups, people may have preceived conflicting goals. Some may want to minimize work and let others do it. Others, charged with oversight, feel that they have to find errors or omissions in order to justify their salaries. Leaders may want to avoid conflict and keep things running smoothly even if problems are overlooked. The smaller the task, the more opportunity for people to personalize events. As in bigger organizations, conflict, defensiveness, even paranoia. And paralysis. Information, finding common goals, building a safe environment may permit trust to be rebuilt but there are no easy fixes.

    August 6, 2013
    Reply

Post a comment