I have just finished Francis Fukuyama: Trust, plus, as the last two posts shows I have been thinking about teamwork and communication, and I had a few really great conversations with some of my co-workers, and all of these made me think.
I have written about how I think communication is important, I have written about how I see teamwork as a really important thing, and last week I’ve answered a question on LinkedIn which was a kind of “10 most important things” for a project manager.
My conversation with a project manager at the company was mainly about how he thinks that soft skills are way less important than hard skills, and how I think that while hard skills are important, soft skills can kill or keep alive a project and are at least as important than hard skills.

So the how to manage a project, what are important to successfully pull off one was a subject that I have thought about a lot.

And that’s how I ended up with the title: On trust we build.

No matter how I look at a project, there is one important thing that makes it work, or makes it fail, and that is trust.

Trusting your client, your partners, your project team, your managers, the people all around you is important. Yes, I know, people betray trust, people will try to cheat you, people will slack off, people will do shoddy work.

That sucks. I know. And they will do this, because they don’t trust you, they don’t trust their boss, and they don’t trust themselves.

Oh, yes, I am not talking about the trust where YOU trust others. I talk about the trust that is either missing in the project or it is there. I don’t talk about only you, I talk about everyone.

And there is the point where several things you and your company did in the past comes in. Seth Godin says

The best time to look for a job next year is right now. The best time to plan for a sale in three years is right now. The mistake so many marketers make is that they conjoin the urgency of making another sale with the timing to earn the right to make that sale. In other words, you must build trust before you need it. Building trust right when you want to make a sale is just too late.

And that applies here too. If your company is has a bad name on the market, why should anyone trust you? If you were not a trustable person before push became to shove, why should your team trust you? If you don’t trust yourself, and thus you don’t trust your client, why should your client trust you?

Trust you have to earn, but earning trust is hard, and like with love, you can destroy with one word uttered at the worst moment. It has the “nasty habit of disappearing overnight.” And rebuilding is even harder than earning it.

But without trust, nothing will work. If your team and client don’t trust each other, they won’t communicate clearly and freely, they will withhold important information, they will keep secrets, they will not tell everything just to keep the edge, the advantage in case someone betrays the other.

If there is no trust, then there will not be teamwork, no matter what you do, no matter how hard you try, actually the harder you try, the less success you will have.

And if there is no trust, then you can have all the mightiest hard skills, the best processes, the most advanced technology, you can have the brightest and most ingenious engineers on the Earth, you will fail miserably, your metrics will be false, your processes will be gamed, your engineers will always keep an eye out in case someone wants to take advantage of them.

Without trust you will sink like a stone. And maybe your project will be successful – e.g. not killed off and grudgingly accepted in the end – it will not be really a success.

How does it connect to a project? The second lesson I personally learned from the project I wrote about in “It’s a Babel Fish”, was the necessity of teamwork.

Yes, I know, it’s basic and everyone stresses it all the time, teamwork is important, teamwork is indispensable, but most of the time it’s about teamwork with your co-workers, the developers in your own company.

What I mean is the teamwork with the client, and your partner contractors. Duh, you say, that’s agile. I don’t know if it is agile or not, I think it’s basic common sense – which, as we know is not that common -, what I know that not working as a team with your customer, and with the other contractors, or worse, treating them as antagonists, hurts your project big time.

It should be like on the picture above. The whole project depends not only on the players – the developers of your team – but on the fans and the cheer team – the client and the other participants of the project – too.

Too many times I saw that after the contract has been signed everyone goes home and starts to work independently, not really caring about what the other does – of course, there are all the mandatory e-mails, the excel files, the task lists, the status reports speeding back and forth, that gives the appearance of working together, but that’s all, if you scratch the surface you quickly discover that there is no real knowledge, actual nobody knows what the others are doing. All you have to do is ask any member of the project team “what is the client doing with the project?” and you will find it out rather quickly.

And if you have some disruptive elements in your project – like people at the client company, who wants the project to fail, a situation that rather frequent – then you will have a pretty hard time.

And as not working a team means there is no real communication either, you end up peering into the “Fog of War”, which makes avoiding and defending against surprises almost impossible.