Empowering the Dev Team: The Project Manager's Role in Fostering Autonomy and Ownership

When developing software, it is common for some team members to appear non-committal or less enthusiastic about the application. There are many ways to get buy-in from the team, some of which are through empowerment and ownership. Clients handle their projects differently, with some wanting to be involved in day-to-day decisions and development, while others are more interested in the results. Project managers often serve as the buffer between their team and both types of client environments. This doesn’t mean that project managers are required to do precisely as the client is doing, though.

I have dealt with both kinds of clients over the years. Often, those who were overly controlling of the contract were doing so due to budgeting or regulation concerns. Sometimes it was due to prior experience with bad project management, a lack of transparency, or poor budgeting. Sometimes it was just due to an overbearing client or stakeholder. It happens. Clients who are only interested in results can be just as bad, though. They won’t focus on the project until they receive results. If the results aren’t what they imagined, it can severely disrupt the project. Scope changes and rework become expensive and will push back the team’s commitment.

I bring these cases up because the first case will hinder the autonomy of a team, while the second one will diminish ownership. Why is that, you may ask? If a client is concerned with the minutiae, then the team’s experience while developing, designing, and architecting something is limited drastically to precisely what they are being asked to do. Rarely have I seen a project that is so detailed that it doesn’t benefit from the team’s expertise. Typically, when a client came to my organization for an application, it was because they did not have the proper knowledge or resources to develop it internally.

Please don’t confuse business knowledge with technical knowledge on that last point. Many clients will come forward with subject matter expertise, having a clear vision of what they want. That is not what I am discussing here. I am referring to those who claim to know exactly what technologies are required and how they should be implemented. I have been in this industry for a long time, and there isn’t a day that goes by that I haven’t had an idea about something and someone with intimate knowledge of what we were doing could be done differently, cheaper, and with better results than what I envisioned. One of the best ways to foster autonomy for a group is to get the client on board with allowing the team to do their jobs. The client should always be involved, but the project manager should buffer the team from command-and-control scenarios and allow them to do what they are trained to do. This will also help the team to foster a level of ownership in their work, especially if they feel encouraged to think “outside of the box.”

For clients who are not as involved, try to get them more involved. Increase communication by inviting them to see what the team is building for them. Ask them to provide feedback and let them know they are part of the process (and will inevitably own the results as well).

Doing these things will help remove some of the impediments that inevitably arise around project teams. Too much dictation or too little involvement from clients is a significant reason that teams do not feel a need to own a product. If it isn’t essential to the client, then why should it be important for the development team?

There are other topics that I could bring up about accountability, responsibility, and whatnot, but I’ll save that for another day.