Program managers, product managers, delivery leads, Scrum Masters, and other roles are everywhere these days, and there is constant tension between these roles and the developer roles at a lot of companies. In my observation there are two key reasons for this tension.
One of these reasons is at the organizational control level, the other is in the hands of the individual PM. If you want to be successful in a company building great technology products in a role like this, having the support of the technical team is a must, and it's easier than it might seem.
Let's start with the organizational challenge. In many companies, the PM role is seem as the part of the team that is connected to the "normal" part of the company. Your business, finance, operational and executive teams all feel like they can speak a bit more of that language, and Power Point is usually faster than code. It's very easy to make PM responsiveness to change a proxy for product development response to change. This is all well and good to start, but many software products don't go as well as people would like. When this happens, it's a natural reaction among management to increase the investment in things like product, project and program management. The visible, understandable part. After all, in most cases it's the development team that didn't get it done.
Over a few product cycles of add one more, you end up with a product/dev ratio that starts to mean that the second problem gets worse and worse. This ratio really matters, because while the part of the PM that is focused outside the team can certainly be increased, there is a limited amount of inside the team work that can easily be done by a set number of developers. If you have more pm than developers everyone will get frustrated and angry because all those great ideas can't be executed on.
The part of this that can be controlled by the individual is how tightly connected you are to the team you work with, and how aggressively you look for work within the team that supports the mission. Some PMs look at their role as define the idea and then let the team do the work. Far better is to figure out what work you can do within the team to make that idea real and better than it was when you first had it. This work is harder, but leads to much better products and happier teams.
By thinking about the problem at the same time as the full team, you will be able to bring more of the team's combined voice into the product, this will result in better alignment and shared vision in a way that a document or wire frame can't always deliver. Each and every day as part of a team the PM should be looking for ways to make something of value to the team and product. Instead of summarizing the status or work of the team, what can you make that allows the team to go faster. What tasks can you take on that your broad organizational skill set will make you ideally suited for? Make sure that your tasks and the things you create are part of the team work flow using the same tools and systems that the rest of the product is managed through. Keep it visible, talk about it at standup, ask for help and share progress and accomplishment with the team the same way a developer might.
You are solving problems every bit as complicated as a developer, just perhaps in a different language. If you can translate that language into the language of the team, you become a maker and contributor rather than a drain or outsider. It's easy to spot the PMs who are working this way in an organization, their connection to their teams feels almost physical, and they always know what's going on with their products. Their ability to estimate and alter course is enhanced, as is their ability to speak for the team; ultimately it's because they are an integrated part of making something rather than a bolt on observer.
Subscribe to partialSignal
Get the latest posts delivered right to your inbox