The Role of Trust in the Developer-Project Manager Relationship

There's a lot that can be said about the relationship between your organisation and your software development firm. We've covered several aspects, including how to communicate with the company building your program and overseeing the transition. We've talked a lot about how to spot red flags and what kind of things you should be concerned about in your program development.

But what about the relationship, more specifically, between the development firm team and your in-house team? How do you know if the relationship between the two entities is a healthy one?

Trust is imperative. It's important to find a firm that understands, values, and acknowledges your organisation's goals. Without this trust, you might be asking for trouble. We've spent so much time, however, focused on what you need to do to keep this important relationship healthy that we've slightly neglected to share what you should rely on from your developer.

Trust truly is a two-way street.

If there is trust between you and your developer, you know they are working with your best interests at heart. While this may seem obvious, sometimes it's difficult to truly relinquish total control and listen to the expert. This might mean that on occasion, you may need to listen to your developer's input about how to do something or even when or what to do.

It's hard to remember that they've done all this before when they're working on a massive part of your socially-minded business. Hearing your developer out will not only make your relationship stronger, but may even save you some headaches in the long run.

Building trust takes time and great communication.

This kind of trust and communication takes time and commitment from both sides. You should expect great, clear communication from them, but you need to offer the same. The developer should take the lead in providing clear, regular, and relevant communications. If they are not communicating effectively with you and your team, it could be a sign of deeper issues.

Structured communication (such as documentation and issue lists) are important. Don't be alarmed by unstructured conversations. These should still be a part of your check-in routine and may help one or both of you brainstorm together.

Take the time to really talk to your developer.

Don't just communicate, discuss how you're feeling about the project and invite your developer to do the same. A great way to do this is to open a time to do some "retrospectives" Take a few moments with your developer to exchange your honest feelings about the good things, the neutral areas, and the spots that you feel could use some work in your project. Open the door for your developer to share their honest feelings with you, too.

By both you and your developer sharing your genuine feelings about the project, not simply what's working and what's not, you're reestablishing the initial blocks of trust you began building at the start of your relationship. Clear and effective communication will be the key in the process. Read more about how retrospectives can help prevent small issues into becoming big ones in this great article.

There are certainly many important things that affect and can impact the role of trust in your relationship with your developer. Perhaps the most important part to remember, though, is that you're two teams of humans working toward a common goal. If the trust is present, the project will flourish into something spectacular.