There haven been quite some good articles written about trust. If you want to start somewhere, read “Building a Culture of Trust” from Derek Brown. (No, really, go and read that article!). I often notice that people understand the need for trust and are willing to incorporate this in their companies. But more often than not, they fail in trusting developers. Ask yourself if you have experienced situations like these:
- You get an estimation from a developer how long development of a certain task/feature/project might take. If it’s to high, the bargaining start until they come up with a better “estimation”.
- Your developers tell you repeatedly that some piece of code needs to be refactored, but as things are working quite well for some years now, new features get a higher priority than the refactoring task. (BTW: It’s not always reasonable to improve a product by adding features).
Yes, I know that estimations are hard. But who could do it better than your developers? Yes, I know that refactoring seems useless from a business perspective. Put a lot of effort in a running system without getting visible output seems stupid. (At Quora, they think differently). Let’s assume for a moment that the people you (or your company) hired are smart people. It’s perfectly fine then to agree that at every given moment, they do the best they can given their abilities and the information they have.
So, if something goes wrong, it might not be their fault. You can adjust their abilities (by providing training) and the information they have. If your developers fail you, probably you have failed in these areas. But it’s hard to accept this and it’s far easier to blame them for your shortcomings. But doing this will lead to distrust in both directions.
Let’s face it: By allowing developers to develop your product, ship your features and deal with potentially sensitive customer data you already give them a lot of trust. Ask yourself why it’s so hard to accept that they do the best they can?