The Secret Approach to Working with Your Tech Lead
Questions PMs and Engineering Leads must ask to foster a stronger relationship and a better roadmap
Too many non-technical PMs I’ve met throughout the years didn’t know how to challenge their engineering team when considering features. This led to non-productive prioritization discussions, or worst, no discussions at all.
Coming from a business background, having trade-off discussions with my tech lead used to be an uncomfortable thought. One time, early in my Product career, my tech lead and I were finalizing our quarterly roadmap. As he was raising his suggestions and estimations, I was trying to poke holes to better understand how we can reduce estimations while hitting our goals. It came across as offensive and led to us spending too much time arguing the wrong stuff. Ultimately, I didn’t have the right tools in my arsenal, so I’ve mostly followed.
Years later, after exchanging with many Product and Tech leads, I came up with an approach that turns these early discussions into collaborative sessions rather than Engineering versus Product.
Except for these sessions, there are also the long-term product vision discussions that involve both the PM and tech lead, allowing the latter to consider deeper tech investments given a longer time horizon. Yet, in this article, I’ll focus on the micro, which are the questions both tech and product leads should ask when discussing features’ scope and duration.
Don’t Skip Your Tech Lead
Your tech lead is your closest sparring partner and by not leveraging this relationship, you’re at risk of losing much more than just your roadmap.
- You won’t be able to assess the complexity of your initiatives, preventing you from being able to identify low hanging fruits and prioritize based on effort.
- You’ll lose the opportunity to bounce ideas with someone that knows the technical ins-and-outs of your product.
- Building trust with your engineers will be much harder, as you’re most probably wrong with your estimations and solution candidates, leading to them feeling like code-monkeys. Mutual trust leads to a more committed team.
Unfortunately, many PMs understand the above yet find it hard to execute in involving their tech team, leading to a dynamics where the tech team executes upon PM’s requests rather than being an equal contributor. This is a symptom of a poor relationship, which is unsurprisingly, the #1 challenge surfaced by Berlin’s Product Community.
Start with Preparation
When planning the next features, most of the work is being done before writing a single user story. You want to approach your tech lead after you have mapped initiative candidates and their high-level requirements (step 3 below). Those will be surfaced based on quantitative and qualitative research: user interviews, stakeholders’ feedback, DB queries, productboard, etc.
Prior to this meeting, make a habit to self-contemplate:
- Why are we working on this now?
- What are the alternatives to this approach?
- Is there a manual way to do XXX so we can reduce technical scope?
Consider using no-code solutions. With today’s tools, PMs can go quite far before defaulting to engineering. - Did I consider doing YYY instead of XXX?
For example, “did I consider using human operations instead of building our own email auto-reply flow?” - How fast should it be? Should it work offline? Do I see this becoming a core component of our product, therefore we should build it in a more robust way, or is it just an experiment?
Or any other questions affecting the technical architecture. - If experimental, consider excluding over-the-top scope, e.g. over-tracking, pixel-perfect design, language support, etc.
These questions will not only foster a better discussion with your tech lead but also force you to further challenge your own assumptions — and more often than not, you’ll find yourself changing scope.
Explore with Your Tech Lead
So you’re ready to bounce with your tech lead, now what?
Schedule a session with the goal of coming up with a list of feature candidates and their estimations. In this session, you’ll share your initiatives and the research that led you there.
Then, as you estimate and deliberate each initiative, use the following 10-questions together with your tech lead to avoid blind spots and trigger a more vigorous discussion:
- How much time will it take to build XXX? Please elaborate
It’s not about the exact estimation, rather a rough one allowing you to prioritize. If it’s a reasonably complex technical solution requiring research, it’s normal for the engineer to circle back on this one. - How confident are we in this estimate?
High confidence will lead to higher accountability while low confidence might reveal it wasn’t thought through or there’s research required. - What will cut the estimation in half?
Radical thinking helps you and your tech lead to come up with innovative ideas. - What if we reduce product scope by removing YYY?
An example can be “what if we only support German?”. Often, ‘Done’ is better than ‘Perfect’, especially in fast-paced startups — don’t be afraid to challenge your initial scope while still bringing value to users. - Is there a way to reduce technical scope?
For example, by not integrating our solution to our Continuous Deployment flow — when setting up new services you usually need to configure your deployment so it’ll be done automatically every time a new code is being pushed. By going for manual deployment, you might be saving some precious release time in the costs of engineering time. - How much time will it take to address technical debt in the future, if we decide to?
In cases you’ve intentionally left out a few tasks for the sake of a faster release, don’t forget to check the cost of a context switch. This is usually being overlooked and might slow down your team in the future by leaving a complex architecture or a non-tested code behind. - Did we already build something similar to YYY we can learn from? Is there any engineer in the company that has experience in these areas?
- Do we have any dependencies with other engineering teams?
For example, both teams have a shared codebase. - In which ways can I support you to reduce our estimation?
- Will having MORE people help? Will having FEWER people help?
I’ve summarized these questions into a cheat sheet you can use in your next 1:1 session ⚡
Final words
Many teams these days treat their PM as a team lead or as a Scrum Master. This sets the wrong expectations and leads to an oversubscribed PM and a disempowered tech lead. By involving your tech counterpart early in the product development process, having an open professional discussion with the abovementioned questions in mind, you’ll be setting your team up for success.
This collaborative approach fosters a strong relationship and builds trust that manifests in a stable product but more importantly — a place where both your tech lead and yourself mutually contribute to your professional growth and team’s success.
If you enjoyed this article, you may also enjoy this one:
- Top 5 Challenges Surfaced by Berlin’s Product Community. Based on dozens of 1:1 product mentoring sessions.
