Why you Should Invest in Relationships With Your Engineering Team [Mind the Product]
A healthy relationship between product management and engineering is critical to building successful products. It’s also essential to creating a team where great people want to work.
In a perfect product development world, communications are seamless, specifications are clear, and product and engineering teams work together without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.
Here are some of the ways I’ve found for product managers to ensure they have a great relationship with the engineering team.
Share Leadership and Credit
One of the ways product managers damage relationships with engineers is by not sharing the credit. This sometimes can happen unknowingly, for example when product managers always take on the role of presenting to executives, leading meetings, giving demos, or announcing results. Instead, in my experience, product managers can build trust by allowing others to present results, demo to executives, and share in the glory of a job well done. One thing that has worked well for me is to have the team members demo major releases in rotation.
Another way I’ve found to be useful to share leadership and credit is with OKRs. These are team goals that get shared across the company. We assign them to the person who contributes the most towards their success, whether it’s an engineer, PM, designer, user researcher, or data scientist. With this system, more people get to take on leadership roles and everyone gets recognition for their work.
Great efforts are almost always achieved by the team and deflecting praise towards the team builds trust and is the greatest reward for success.
Include Engineers in Product Decisions
Some product managers think it’s their job to have all the ideas and do all the product thinking. They’ll go off with their designers and come up with a grand vision to toss over the wall to the engineers for implementation. In my experience, engineers should be involved in the product thinking process. Understanding the “why” and the upside is a great motivator and might even have a positive impact on their implementation choices. I have also had cases where the engineering team pointed out corner cases or the impact of a choice on somewhere else in the product, something which the product team missed.
Building great products is a collaborative process that works well if everyone agrees on the product vision and strategy. Why wait to involve engineering in your roadmap planning until you have set the product direction? Transparency builds trust and trust leads to great effort. Involve engineering early and often, so everyone has a chance to contribute to the product vision and buy into where the product is headed. I have seen teams that see engineering as a vendor to the product team, which I believe is not a great practice to set a strong base for collaboration between the two teams.
Clarify Roles and Reinforce Them With Mutual Respect
An easy way to muddle any work relationship is with unclear roles and lack of respect. As product manager you are expected by engineering to understand the highly creative nature of their job and bring them:
a) requirements which are based on customer needs
b) a specification which describes properties of a solution to a real problem
So, leave them the freedom to do their job. This means don’t specify the solution or explain how to do it. They are expected and happy to come up with possible technical solutions. As you create the user story and get ready to hand it over, take the time to work through it in the team to ensure a common understanding.
Clarity of purpose, planning, and responsibility pays rich dividends. Product managers should own the “what” and “why”, engineers own the “how”.
Product managers can also create friction with the engineering team by discounting the effort involved in refactoring, test development, bug fixing, documentation, or other similar activities (while still expecting quality software).
Another problem is bias. It is difficult to gather information from customers and their statements do require synthesis. Some product managers short-circuit the process by describing their own preferences rather than actual customer requirements. This is particularly true when the product manager is themselves a prospective user of the product. There is nothing more irritating than investing thousands of hours to build something that only one person, the product manager, really wants to use. The best approach, in this case, is to be transparent with the team, and spell out the assumptions, and even accept if clarity is not there.
Clear Away Inefficiency and Help Your Teammates Succeed
In my opinion, one of the core responsibilities of a product manager is to make engineers more productive and efficient. Instead, often product managers end up adding bureaucracy and inefficiency, for example, by trying to solve every problem with more meetings or asking engineers to put in work without convincing them that it’s worth it.
Product managers should be productivity multipliers. They should look for every kind of creative way to help their teammates be more efficient and effective. They should build product processes to ensure everyone is aligned with the business’ north star at the beginning to avoid unnecessary changes later.
For example, I always ask my product team to make a top priority to answer a question or test a feature that would help to unblock the engineering team (especially if they are working on a task in a Sprint that has already been set in motion). Abrupt reprioritization during a task or sprint brings a higher cost. So product managers should be sure any changes are absolutely necessary and in line with the scope.
I’ve also found it useful to ask product managers to explain the user stories during backlog grooming before the start of a sprint. Articulating features and user stories in detail makes you appreciate the nuances of what you’re asking for and what it takes to build it. It also gives the team a way to comment and ask questions, ultimately helping to refine what you’re asking for before a line of code is written.
Never Commit Without Them
Product managers should resist the temptation to commit to dates, make estimations of effort, or communicate project schedules without consulting their engineering team. Product managers who come from an engineering background are especially susceptible to this, but it’s easily fixable by ensuring your engineering lead is looped in before any major commitment is made to any of your stakeholders.
That said, it’s okay for product managers to challenge estimations (internally with your engineering team, and with sound reasoning), before communicating project schedules to stakeholders. Just make sure that you are aligned with your team before you reach that point. A definite no-no is to arbitrarily underestimate the amount of work required by given features or initiatives and cut schedule estimates for business convenience without justification.
Remember That Trust is a Two-way Street
If the product team is constantly questioning whether another group is able to do their job, over-managing and not providing enough space, they’re showing that they don’t trust that team or those individuals to be successful without their constant oversight. This lack of respect doesn’t foster a relationship based on trust. And rebuilding trust is way harder than creating it in the first place.
If you have properly communicated your vision and provided context into the “why” behind decisions, your work is done. You don’t need to micromanage or question the “how”.
In my experience, the single biggest thing that engineers dislike about product managers is a lack of understanding of the highly creative, flexible nature of software development. You see this frequently when product managers have no technical background (and no interest in learning about it), and only evaluate progress by what they can see in a user interface.
I think that all of the best answers here boil down to one key thing that drives engineers crazy about product managers – too many of them don’t take the time or effort to understand what it is that their engineers actually do.
Invest in Relationships
The only way to truly build empathy is to connect with other teams on a personal level, which is why companies go on outings and schedule team-building activities. While “mandatory fun” may not be how you want to spend your day, getting to know people outside the conference room and cubicle setting can strengthen relationships and make people more likely to trust you.
One of the main functions of a product manager is to be an effective communicator across all departments.
Foremost you want to openly preach the product vision. People need to know where to expect the value of the product to come from.
Additionally, the basic rules of successful communication and teamwork apply:
Take time to build and foster rapport.
- Don’t annoy the engineers by keeping them in the dark. They’ll benefit from clear, transparent, honest communication.
- Assume engineers are capable of giving valuable input and feedback. Be open to new ideas, even if they conflict with the current vision.
- If your product is one of many having to compete for resources, it’s much easier if you have good relationships with your internal suppliers. Take the time to understand their key drivers, to ask them what information they need from you, and how they want the information delivered.
Don’t Fear Failure
Showing that you’re human and willing to admit your mistakes can actually improve your overall standing. When failures, setbacks, and shortcomings occur, don’t try to sugarcoat them for stakeholders. Instead, give them proper context in the overall narrative.
Only sharing the good and hiding the bad and the ugly can backfire. Highlight what is going well, and frame challenges in the context of what you’re doing to navigate and solve for them. When scope changes or timeline shifts may be required, engaging the right stakeholders at the earliest opportunity can often lead to unexpected resolutions.
Product managers are supposed to have all the answers, but they’re not supposed to be psychic. There’s no shame in saying “I don’t know” and asking for help, information or advice – this actually improves the impression you give others because it shows you’re listening and actively seeking out the opinions of others.
A willingness to admit that product managers don’t have all the answers and your curiosity to find them will lead to better decision-making and greater trust within the team. This authentic approach speaks to a product manager’s character as a leader.
Asking questions also shows that you both trust and value what others have to offer. If they feel appreciated and understand that you’re gathering information from multiple sources it will improve others’ trust in the final decisions.
Establish a Shared Vocabulary
The most difficult part of building team relationships and fostering communication by far is having a shared understanding and alignment to a common goal. And that requires establishing a shared vocabulary, the basis for meaningful discussion.
The product manager’s role, in this case, is to bring about alignment by clearly defining the role the product plays in that vision and also the role it plays in people’s lives. When teams discuss a feature or functionality, people tend to use even simple terms in very different ways. When someone from the support team says that we have identified a major “pain point” for users, they might actually be talking about a feature request. Simple terms like “need, requirement, feature, functionality, and user experience” may mean very different things to different team members.
Standard document templates will deliver consistency and will also help product managers through the tasks required to manage and develop products. If we converse using the same language, our teams become stronger and our message over time becomes clearer.
Conclusion
Healthy relationships between product managers and engineers are critical to the success of any project. With shared leadership, inclusive decision making, mutual respect, and a commitment to helping each other succeed, you can build a team that delivers results and attracts great people.
The post Why you Should Invest in Relationships With Your Engineering Team appeared first on Mind the Product.
Source: Mind the Product https://www.mindtheproduct.com/why-you-should-invest-in-relationships-with-your-engineering-team/
Post a Comment