How to increase engineering engagement
10 tips to improve product team’s performance and your life as a product manager.
The bond between product managers and engineers is foundational and can either make or break your company. Engineers turn product visions into reality, but the level of quality and speed of executing that vision may vary quite a lot depending on if engineers are disinterested or engaged in their work.
Developers who are engaged can improve Product Manager’s life three ways:
Reduced Workload: When engineers are more aware of the business context, product managers can focus on higher-level strategy and vision instead of micromanaging tasks and timelines.
Relevance and Impact: An engaged engineering team is more aligned with the product’s goals, leading to work that is not only completed but also relevant and impactful.
Speed and Efficiency: High engagement translates to faster development cycles as the team works collaboratively and proactively.
Imagine the engineering team’s engagement as an accelerator to your product team. For the sake of this article, let’s imagine it has 4 levels:
Indifferent
Characteristics: Not aware of the product vision, roadmap or goals; engineers focus solely on their own tasks.
Implications: High dependency on project management; development is slow and quality is poor.
Interested
Characteristics: Basic understanding of tasks; work gets done, but PM still drives much of the planning and specification.
Implications: While processes function adequately, PM still bears the burden of coordination and oversight.
Engaged:
Characteristics: Active discussion about approaches; engineers take initiative in technical problem-solving.
Implications: Team dynamics improve, allowing for collaborative planning and a more autonomous engineering process.
Empowered:
Characteristics: Engineers are proactive, involved in research, ideation, and problem-solving; capable of self-organising.
Implications: High efficiency and responsiveness; PM can focus on strategic initiatives rather than day-to-day management.
Engaging your engineering team in product management is crucial for driving better outcomes. This post explores approaches to involve your development team more deeply in the product life cycle, from creating interest in the product to empowering them to take more responsibilities.
Creating interest in engineers
Doesn’t matter if you have an indifferent engineering team or an engaged one - these are smart and valuable practices to every PM.
1. Get to know your engineers
First, take the time to get to know your team. Schedule a 30-minute meeting with each engineer to introduce yourself, share your goals, and most importantly, listen to their experiences. Ask about their preferred working methods, what has worked well in the past, and what they'd like to change in the current process. By implementing their suggestions where possible, you demonstrate that their input is valued, building trust and engagement from the start. Ask if they know what is the team’s goal and do they understand why they are building something. If not, this is a great place and time to discuss it with them and answer any questions they might have.
Have these meetings when you join a new team, want to initiate a change or feel something is off in the team. Play it by the ear.
2. Build a strong relationship with your Tech Lead
If you have a tech lead in your engineering team, establish weekly meetings to discuss team dynamics, organisational changes, and align on product management priorities. This regular touchpoint ensures continuous communication and helps bridge the gap between product and engineering perspectives.
Make sure your Tech Lead is the first one to hear about any changes happening, concerns you have around engineering, or ideas about changing how you work. Build trust and create ample opportunities for this to become an equal partnership where both feel supported, respected and needed.
3. Make sure engineers understand their impact to product
Transparency is key to engagement. Share weekly insights, KPIs, and goals with your team via Slack or another communication platform. Encourage discussion and questions about these metrics, helping engineers understand the impact of their work and fostering a sense of ownership in the product's success.
Use team meetings and communication channels to recognize and praise good behaviours, such as cross-team collaboration or exceptional communication. This positive reinforcement helps set the standard for desired interactions and encourages more engineers to engage proactively with product management tasks.
4. Have retrospectives
Doesn’t matter if you are working in a kanban style, doing sprints or anything else, the single most important tool for boosting engineering engagement is retrospectives! Having a regular biweekly or weekly retro, is a safe place to discuss how the team is doing and collectively implement small improvements on how you work as a team.
As a PM, you need to be an active participant. Not the one running it, this should be the tech lead, but you should definitely not be an observer. Share your perspective on what's going well and what could be improved. Your engagement in these sessions sets an example and encourages reciprocal involvement from the engineering team in product management activities.
Retrospectives are an opportunity to discuss the wider context of the team's work, including progress on timelines, feature performance, and any challenges in understanding each other's roles. This open dialogue helps align the team and address any gaps in communication or understanding.
Step by step you will see engineers opening up, taking responsibility, engaging with each other and making efforts to make team work better.
From Interested to Engaged
Great, you now have an engineering team, who is interested in the product they are building and feel good about moving the needle. Now it’s time to push them a bit more to become engaged with what they are building.
5. Involve engineers in planning
Involving engineers in the planning process is crucial. Organising workshops where you present your thoughts and challenges for the upcoming quarter allows engineers to get early insights into priorities. This not only makes them feel included but also gives them a platform to provide feedback.
At least quarterly gather their input on tech debt and potential improvements they’ve noticed to include in the planning. Ask them also to include why they think tackling these is important and provide any related data they have. This way, they can think critically about the impact of their suggestions, and you’ll have the context needed for prioritisation. By discussing and prioritising these points together, you foster a collaborative environment where engineers feel their voices matter.
Make sure they know where the roadmap is located and they understand the timelines. You can give an update on this weekly in the team comms channel or in a weekly retro.
6. Expanding responsibilities
For me, it has always been a huge red flag if the tech lead is planning all the work and making all architectural decisions. This really stifles any collaboration and learning in the team. Discuss with your tech lead how everyone in the engineering team can assume more responsibility.
You might consider implementing a rotating epic owner role, where each engineer takes a turn helping to scope larger projects and dividing it into tasks and taking responsibility for the delivery. This not only promotes leadership skills but also ensures that the entire team is aligned on the work ahead.
Another option is to introduce architecture meetings. The Tech Lead assigns engineers specific pieces of a spec to figure out a technical solution to. In the meeting the engineers will then present their prepared implementation notes and can discuss through the details with the team and foster ownership of their work. These discussions can lead to a more cohesive team dynamic, as engineers collaborate to refine and optimise the work ahead. This should also come with the responsibility of delivering the work.
7. Enable knowledge sharing
Enabling knowledge sharing within the team can significantly boost engagement. You could introduce a weekly crowd programming hour where people will huddle up to solve an issue, or host biweekly “kitchen talks” where team members share insights from their recent work or new technologies they’ve explored. Brainstorm with the team what kind of knowledge sharing is needed or suits best the situation. These formats not only celebrate individual expertise but also create a culture of continuous learning.
From Engaged to Empowered
Excellent! You now have a team of eager and engaged engineers. And hopefully by now they have taken the responsibility of organising their own work and you as a PM should not have to create or keep tabs on any Jira ticket. Let’s go one step further and see if we can get them involved in research and ideation.
8. Expose engineers to users
Involve engineers in user research to deepen their understanding of customer needs. While it's not feasible for them to participate in every aspect of discovery, consider rotating engineers into user research calls or sharing highlights from customer interactions. This exposure helps engineers connect their work directly to user problems and needs.
To further immerse engineers in customer perspectives, implement a monthly challenge where each team member spends an hour reading and potentially responding to customer support emails to see who can solve most customer problems. This hands-on experience with user issues can be both enlightening and motivating for the development team.
9. Enable communication with stakeholders
One powerful way to empower your engineers is by facilitating direct communication with stakeholders. It’s important that internal stakeholders know who to reach out to when they have questions or need clarification.
One effective approach is to have engineers who worked on new features share release notes with the wider team. This could be done through video demonstrations or written updates in a Slack channel. Not only does this give engineers a platform to showcase their work, but it also creates a sense of accountability. They’ll need to understand the details of what they built and how it fits into the larger product picture. When stakeholders can ask questions directly, it fosters collaboration and ensures that engineers are aware of the broader impact of their work.
Additionally, including epic owners or tech leads in stakeholder meetings can bridge gaps between engineering and other teams. This involvement not only enhances communication but also ensures that engineers are actively participating in discussions that affect their work.
10. Include engineers in problem solving
When engineers are engaged and invested in their projects, they can become invaluable partners in problem-solving. It’s beneficial to involve them in the discovery phase, where customer problems are identified and discussed. Instead of bringing the entire engineering team into every meeting, consider including a tech lead or rotating research partner. This allows for focused input while ensuring that the engineering perspective is represented.
By integrating engineers into ideation sessions and discussions about technical feasibility, you tap into their expertise and insights. They can provide crucial input on what’s possible, helping to shape solutions that are both innovative and realistic. This collaborative approach not only enhances the quality of the solutions developed but also fosters a culture of shared ownership and accountability.
Change takes time and it is ok
Getting from indifferent to empowered doesn’t happen in a day, not even a week. It can take months and a lot of patience. Be prepared to make mistakes, miscommunicate and give space to others. Above all make sure changes are consensual. And if things fail - do a retro with the team and brainstorm together how to improve. The PM can nudge the team in a direction, but they shouldn’t do everything for the team, so prepare to do some convincing and encourage engineers to drive those changes. Because that is what you ultimately want - engineering to work efficiently with minimal PM input.
If you liked this post and are interested in getting notified of new posts in tpg.ee, we recommend subscribing to our newsletter.
All nice and fluffy! Zooming out, we see the following key topics:
1) Reduced, normalized workload, sustainable pace. Unrealistic load / deadlikes is typically the key reason for such issues and it is hard to implement all the nice things listed, both for Dev and PM
2) Management skills and managers. Leadership. Without it, it's not gonna happen. PMs have a long history of trying to change the dynamics of management using guerilla methods. Very few succeed
3) Part basic management, part common sense. None of the nice things don't happen where you do not have
* clearly defined responsibilities and
* 'process' or more likely key steps in the would be process - who does what based on what
* this means you actually have sensible managers on key positions who can agree and they actually have management skills. You need to solve these problems because you have a problem with leadership
4) The common denominator of most of the suggestions is to embed developers into the PM/stakeholder space and possibly get a better insight of the Dev space. Some items are often rejected nobrainers that Dev should be involved in planning. First, all this takes extra resource / time and still, you need to keep the clear division of labor. You cannot make everything perfect quickly
4) Your mileage will vary. People are different. Some just do not care about stuff beyond their coding stuff. Sometimes it is a gentle pressure, sometimes just leave them alone. You cannot force-feed happiness