Hugh at GapingVoid has some interesting things to add to Sigurd Rinde’s (at Forthcoming) post about Trust which I think, at least for me, relates to their earlier comments on culture and technology which I talk about here.
Sigurd says:
Fact #1:
Trust is what makes a company exist. Without trust no customer, no investors, no suppliers, no place in society.
Fact #2:
Transparency equals trust. That simple.
To which Hugh adds:
Transparency's a tricky one. Transparency relies on human beings, and human beings are generally a frickin nightmare.
And
At the company you work for, how afraid is the average person of making a mistake? Of not being right? Of backing the wrong horse and being found out later?
And then there's your answer. The less afraid he or she is, the more transparent your company can be, with itself and with the outside world. The more afraid he or she is, the more opaque you'll have to remain.
I think about trust, in my work as a project management process and software consultant, in a more specific way. In my post about Culture and Technology I talked about trust with regard to project team members filling in timesheets. For the technology to be of optimal usefulness to the organization team members need to feel comfortable putting bad news in their timesheet entries. When they use the timesheet system to tell the project manager that they worked 30 hours this week on a task that they were scheduled to work on for 40 hours can they TRUST that this info will not be used to fire those that are not working up to the plan? (This is assuming that they are working short of the plan because they are working hard but other things are coming up and disrupting them. It does not apply to those that are short on their plan because they are just blowing work off.) There are too many organizations that put together project schedules that assume that a person that works an 8 hour day will be productive on the project for a full 8 hours a day and when they are not (which they cannot possibly be) they look at the team member as if they are to blame for the task or project for being behind schedule.
This example is one that shows cultural and process ‘issues’ and in many cases the technological issues of not understanding the software they use to create the schedules. But at the ground level it is a matter of trust. Does the team trust the project manager (or “management” as a collective) to use the data in what they (the team) feels is responsible and in a larger sense does the team trust the project manager to be doing the “right things” in planning and modeling the project (even if the team does not actually, technically know what the right thing is)?
I think that Hugh and Sigurd should write a book together! These guys are great! Though I guess, in a way, their back and forth could later be seen as a sort of virtual book. I think there is an interesting point of exploration there concerning how to compile related posts from across different blogs into a virtual ‘whole’. But that is for bigger brains than mine to figure out. :-)
Comments