Building confidence in engineering teams as a new product manager
Starting in a new organisation and new team can be daunting for some. It’s hard enough when you join a single discipline team. When you join a multi-disciplinary team it’s even harder! How do you bond with your team and build confidence amongst all team-members regardless of the discipline?
For example, your team might consist of the following:
- Software Engineers — specialising in front-end or back-end development;
- DevOps Engineers — working on infrastructure and platform;
- Quality Assurance — ensuring that what you specify and what the team produces is achieved functionally and non-functionally.
Your team are looking to you — the product manager to lead them on what the user needs are (through product discovery) and how they are satisfied with the product you’re building. That includes shipping a great feature that helps the business, but also a great feature that works operationally in production.
What can you do as a Product Manager to build confidence within the team?
1. Educate the team on product discovery
Double Diamond is a great way to illustrate product discovery and the work you need to do here as well as product development. For lots of engineers, the framework and discovery is a new concept. Educate them on how product discovery works, processes and the work you have to do here in addition to product development. That includes:
- User interviews – designing, conducting, capturing;
- Synthesis – boiling down transcripts into themes, challenges, opportunities;
- Experiments – Hypotheses, running experiments and metrics.
2. Use senior engineering leads early on
There are a few issues here you need to be aware of as a new product manager here.
The first issue occurs when you attempt to do two-week sprints and deliver a project to a team in chunks to avoid complicating things, the result is myopia. The team need a holistic understanding of the overall project and a chance to consider the whole “how” in relation to the why. To do that they need time to digest the idea, carry out impact analysis in terms of the codebase and consider the non-functional requirements of what is being built.
The second issue you need to be aware of is when you omit the product discovery insight and don’t involve the team. I’ve had countless occasions where engineers have asked “why a customer needs this” and either no reply or woolly response from a product manager. Share the insights from the interviews/synthesis/user journey mapping with them and give them the context they deserve.
The third issue also concerns myopia, but at the project level, rather than at the epic/story level. Get the engineering leads to start thinking about longer-term plans with the items on the roadmap. This provides them with an opportunity to future-proof to the right degree. You don’t want them to get into speculative generality territory, nor do you want them to not consider upcoming projects until the first sprint starts.
In order to do this, engineering leads need to have the capacity to perform architecture, design and “non-coding” duties 30 – 50% of the time. If they’re heads-down in the detail and not looking ahead there’s a car-crash waiting to happen at some point.
3. Understand team communication and history
Communication is paramount in engineering teams. Intra-team communication amongst engineers is normally good due to collaboration tools such as Slack, test feedback, continuous integration feedback and code reviews.
However, you need to fit into this as well and facilitating the Agile ceremonies is a good way to do this. You’re not there to run the meetings specifically. You are there as one of the Three Amigos to ensure product, engineering and quality assurance functions.
Without you doing this, there is nothing.
Sitting with the engineering leads to establish the current ceremonies and working practices is paramount, including, but not limited to:
- The cadence the team are working at today – e.g. 2, 4 weeks;
- The preparatory ceremonies (refinement and planning);
- The in-situ ceremonies (stand-ups)
- The closing ceremonies (demos and retrospective).
Ask the engineering leads about how things are working today in terms of the product/engineering interface in relation to these. That includes:
- Specification for the product and technical design for larger items;
- Decomposition of specifications (product and tech design) into epics, stories and at which point feedback is provided from the engineers;
- Change management – for the team and process – if it takes place when it happens (e.g. via the retrospective) and the last few changes. If change management isn’t in place, then ask why and how the team focuses on continual improvement.
Another great way to learn and improve is to learn from past experience. Talk to the engineering leads about their previous product manager, ask about all the good great and the “not so good” things whilst they were working with the team. Above all, try to learn from the mistakes (if there are any) and improve on the previous process.
4. Collaboration for behaviour specification
Collaborative sessions around product specification and technical specification are great. The best designs are those that combine both into a single view that can then be used for breakdown into epics, user stories and tasks.
Some of your epics are going to be platform/infrastructure-related, some of them are going to product-related. It’s key to understand the infrastructure tasks in relation to the business – especially those that are around monitoring & thresholds (SLI’s, SLO’S), performance (response time), reliability & uptime etc…
Once you understand this, you can flesh out the detail in the user stories with appropriate acceptance criteria to capture these. Do this with the engineering leads and team members to ensure feedback is captured before development starts. If you really can’t resolve something here, then chalkboard it, write it up and say you’ll come back to them with feedback after talking to customers. Nobody gets everything right, first time.
5. Share Outcomes and Success with the team
“Feature teams” are bad because they focus on delivering a feature without the context of the business objective (and ideally metric) you are attempting to improve. Linking business strategy with product and technical strategy is paramount to prevent miscommunication, mid-interpretation and bad feeling between departments.
Communicate the metric you are trying to affect with the feature to the team during specification. Make sure they understand what the metric is (some people won’t some of the terms) and how the feature relates to it.
One of my pet peeves is what happens after a feature is released. Quite often, the engineering team hear very little. Keep them abreast of adoption of the feature, feedback from customers and the way in which the metric you described earlier is affected.
If the team have the context then buy-in is much greater and the probability of success is much greater : )
In Conclusion
These are just a few suggestions on how to improve confidence if your teams as a product managers. There are lots of other ways, but if you’re following these then you’re off to a great start.
I’m a consulting CTO (fractional, interim) working between London and Bristol. I coach at Mind the Product and regularly write about topics in product and engineering.
FINALLY, A huge thanks to Irving Navarette (IrvingN) for the inspiration and ideas behind this blog post.
