Product Managers: How to Empower Your Engineering Team | Lucidchart Blog
Skip to main content

As a software engineer on a small scrum team, I have found that my relationship with the product manager has a significant and direct impact on my effectiveness. During my short tenure at Lucid Software, I’ve already had the opportunity to work with a handful of product managers. Here is what I have learned from my experiences collaborating with them.

Use as little process as possible

While methodologies like agile and scrum can have notable advantages, they need to be adapted and optimized for each team. In general, minimize the number of meetings and overhead so that engineers can get to programming. Making sure that the entire backlog of stories reflects current estimates is an example of an activity that should be abandoned. Additionally, don’t get too hung up on which roles should perform which day-to-day tasks; for example, whether you or the scrum master engineer clicks “Start Sprint” in JIRA probably doesn’t matter.

Don’t try to squeeze more code out of your engineers

I once worked with a PM who, when engineers would present differing estimates for a particular feature during estimation meeting, would record the lower of the two estimates in the system and move on. This led to over-scheduled sprints, which resulted in lower-quality code and unnecessary stress. This attitude also makes engineers feel like code monkeys, paid only to get a job done as quickly as possible rather than to take the time and creativity required to craft code that will yield greater returns in the long-term. Experienced engineers—and product managers—understand that there is only so much code that can be produced in a given period of time, and they plan accordingly.

A wiser PM whom I later worked with recognized the presence of differing estimates as underlying uncertainty/ambiguity and instead used the higher of the two in his planning and prioritization. Work moved forward much more smoothly (and was of much higher quality) on his team.

Don’t play the “role power” card

In fact, remove that one from the deck altogether. At Lucid Software, one of our core mantras is “teamwork over ego.” The moment a team member needs to assert expertise explicitly, the possibility of an effective relationship of trust diminishes. In fact, one of my favorite parts about working at Lucid is that even though there are people with prestigious credentials and incredible expertise, not one of them has a private office or carries any sense of elitism.

Remember that engineers can have valuable input when it comes to the direction of your product or the details of the user experience. Likely they feel as passionately about it as you do. When a disagreement arises, employ insights from user data or utilize other experts at the company—don’t say “we’re building it this way because I am the Product Manager and it’s my job to make these decisions.”

Have a flexible timeline

Estimating is hard, and humans are notoriously terrible at it. It’s rare that building a feature or user story takes precisely the amount of time that an engineer estimates it to take. Usually, it takes longer than anticipated. Be willing to be flexible when this happens. If every story is treated as an emergency that absolutely must get done immediately, you will start to seem like the boy who cried wolf. If there really is a hard deadline, proper communication with the engineers will often elicit from them the extra effort needed to get it done on time.

Be in sync with the rest of the product team

I once worked on a redesign/rework project that was planned by a PM and UX designer that were passionate about improving a particular feature. A few sprints later, when we were midway through a full implementation, all the project managers in the organization shuffled teams, and the new project manager assigned to my team put the project on hold in favor of other priorities. His concern was that the update we were implementing wasn’t the right approach to improving this feature. A few weeks after that, a different project manager from another team expressed frustration because our half-baked improvement of the feature may have negatively impacted a larger epic that his team was working on. Among the lessons learned from this experience was that many concerns could have been avoided by having effective communication channels in place.

Conclusion

The relationship between engineers and product managers can be as challenging to fine-tune as it is critical to get right. Striking the correct balance, however, will yield greater effectiveness and higher-quality output for the team as a whole.