Trust

There are a lot of reasons why trust within a team is important.  I’m going to delve into two, both of which when lacking manifest as waste.

Item the first:  Lack of trust among developers produces wastful code. I’ve been on enough teams to see how code manifests itself, on average, based on the trust level of the team.  Developers who trust the other developers don’t put a lot of time into over validation because they trust the developer who wrote the calling code won’t pass them garbage.  They also won’t put in a lot of excessive exception handling because they trust the code they are calling won’t throw a lot of garbage at them.  Since there is a lack of trust, they also won’t get up and talk to the other developer (“Stop throwing garbage”, “Stop passing garbage”, etc).  Code Reviews, Pair Programming, Code Analysis tools do a good job of catching this kind of activity and bringing it to light, but still don’t address how to build trust within a team.  I’m sure others have methods for dealing with this, but in my opinion the best way for a developer to gain trust is to not pass garbage…that’s the first step anyway.  It builds slowly from there:  Don’t pass garbase, Don’t accept garbage, build cred, repeat.

Item the second:  Lack of trust among team members produces wastful practices. This one is somewhat new to me.  Team Members who do not trust other team members will perform all sorts of wasteful activities in order to ensure that “things get done right” (The One Right Way Anti-Pattern?).   Emails that CC Management, Requiring team reviews of work at every juncture, Meetings, etc.  A big chuck of the things that interrupt flow seem to originate from this one team dysfunction.  This one seems tougher to address, as you have to find a way to re-introduce flow while also finding a way to satisfy the disbelief that things might actually work through the system, even if they work through it such a way that isn’t The One Right Way.

Ongoing…