Leading with product and management
A tech lead never leads alone. You share the team with a product manager, an engineering manager and a designer, and most of the hard moments in the job (an urgent request, a slipping date, a disagreement about what comes first) are decided between you. This lesson shows how to split the work between you, keep a shared rhythm, trade off well, say no without damage and escalate together.
By the end you can
- Write a working agreement that says who decides what between the tech lead, the PM, the EM and the designer
- Run a short weekly sync that keeps the three leads free of surprises
- Hold a trade-off conversation about scope, date, quality and people, with a quality floor that is never traded
- Say no to an urgent request with what you would say yes to, the cost of yes and options
- Escalate a disagreement together, then commit to the decision and keep stakeholders informed
The everyday picture
Think of a family building a house. Three people run the job. The family's representative decides what the house is for: how many bedrooms, the budget, the date they need to move in. The site engineer decides how it is built so that it stands up: the foundations, the materials, the order of the work. The contractor looks after the crew: who is hired, who works which day, who is learning the trade. An architect makes sure the rooms work for the people who will live in them.
One evening the family asks for an extra room before the rains come. A good team does not let one person shout yes or no. The three sit down together. The engineer says what the room costs in weeks and what it does to the foundations. The contractor says whether the crew can do it. The family chooses: a smaller room, a later date, or no room. Nobody suggests thinner foundations. That is your job with Imran and Ken, every week.
Who owns what in the triangle
On the Store app team, the leadership is shared between three people, plus a designer. Each one owns a different question.
- Imran, the product manager, owns why and what. The problem, the outcome the team is chasing (stock accuracy up from about 82%), the priorities, and the conversations with stakeholders about what comes first.
- You, the tech lead, own how and how well. The technical design, the estimates and technical risks, how the work is split into slices, and the quality bar the code must meet.
- Ken, the engineering manager, owns who and how the team works. Hiring, performance, careers, the health of the team, staffing and the team's process.
- Leila, the designer, owns the experience. What a store worker sees and does on the scanner, tested with people like Ama.
The lines look clean on paper. The trouble lives where they overlap. A date for the offline stock counts pilot needs your estimate, Ken's view of capacity (holidays, on-call, a new hire) and Imran's view of what the business needs. Deciding who works on what needs your view of the work and Ken's view of each person's growth (Delegation and mentoring). Performance reviews need your evidence about the technical work, but Ken owns the review. If these overlaps stay unspoken, two things happen: decisions fall between you, or two of you make the same decision in different ways.
The fix is a working agreement. List the decisions that come up again and again. For each one, write who decides, who must be asked first, and who is told afterwards. Add two rules: how you disagree, and when you escalate. Keep it to one page, review it every quarter, and share it with the team so engineers know whom to ask. Camille Fournier's The Manager's Path (2017) describes how much the tech lead role changes from company to company, which is exactly why yours should be written down. Will Larson's Staff Engineer (2021) likewise describes the tech lead as working in close partnership with the team's manager.
A simple test tells you whether it works. Pick any recurring decision. Can each of the three of you name the person who decides it, without thinking? If two of you give different names, that line of the agreement needs a conversation.
Quick check
The head of store operations wants the offline stock counts pilot date in writing by Friday. Who should commit to the date?
A date sits on the overlap: it needs your estimate, Ken's capacity and Imran's priorities. Agreeing it together and letting Imran send it keeps one voice to the stakeholder. If Imran commits alone, the date has no estimate behind it. If you commit alone, you skip the capacity and priority questions and go around the person who owns the relationship.