In the technology industry Product Manager <-> Tech Lead relationships are notoriously negative. I have personally worked with several PM/TL pairings that were strained at best, and so last year when I got the chance to step up to Technical Lead, I was worried about what it would take to navigate the tricky nature of this relationship.
In my personal experience in the tech startup world, this tension comes about because businesses struggle to get away from the “just ship it” feature factory mindset.
In its early years, a laser focus on shipping features helps companies achieve growth and maintain competitive advantage. A successful startup will often end up a victim of its own success - with a platform so large and complex that time to deliver new features grows and innovation slows.
At this point, engineers start to grumble about being held back by technical debt, and product teams start to complain that tech can’t deliver. This often leads to a negative feedback loop, where Product tries to crack the whip, and Tech will dig in their heels. It is, at best, deeply dysfunctional, and harmful to the health of a company.
Breaking out of that cycle requires a culture shift that elevates product and tech as equal teams who have an aligned interest in delivering value. (i.e. no more product roadmap funnels or “just do this now” conversations).
Fundamentally, it means everyone taking stock of their rights and responsibilities.
Ideally, this means that tech teams have have:
- A responsibility to ensure they can deliver features efficiently by maintaining the health of their tech estate, and a right to delay or turn down work if their tech estate cannot receive the changes required by a new feature.
- A responsibility to undertake remedial work on their tech estate if their platform is not open to new feature requests, and a right to take the time to do it correctly.
- A right to a seat at the table when Product are iterating on their roadmap, and a responsibility to contribute to those discussions with a view to how they can contribute to the health of their organisation.
On the product side you will want to see:
- A responsibility to develop upcoming work with external stakeholders in such a way that tech are brought problems to solve rather than features to implement, and a right to request tech undertake urgent remedial work in situations that are potentially harmful to the organisation.
- A responsibility to work with tech to develop short, medium and long term backlogs that incorporate operational, technical and product priorities, and a right to request changes to the order of those priorities as and when required.
- A responsibility to work with tech without imposing artificial deadlines dictated by a product roadmap, and a right to expect tech to have delivery of that roadmap as their number one goal.
These types of changes can be extremely difficult for an organisation that is used to working in traditional product cycles, as they require a fundamental shift in not just tech and product, but across the whole business.
The Product Manager in particular will find they need to spend time educating the rest of the business on the “new” ways of working, which can sometimes be a painful experience. If senior leadership, including the CEO and CTO, are not behind these changes then you might as well forget it.
In my previous role I was pleasantly surprised to find that my initial fears about working with the product teams were unfounded. This was partially because I worked with an excellent Product Manager, but also because the leadership team were actively looking for a better way to align the tech and product roadmap, and ended up putting in place many of the ways of working outlined above.
By no means does that mean that everything was easy, or that there was a complete lack of tension between Product and Tech - but it put us in a better place, where our key driver became constant improvement and iteration, rather than a treadmill fraught with animosity and tension.