What you own, and what you leave to others

A tech lead is responsible for how the team builds. On most teams that covers four areas.

1. Technical direction. Where the system is going over the next few quarters, the main design decisions, and the principles the team follows. You write it down so people can decide without asking you (Technical vision and design docs).
2. Quality. The code review culture, testing, reliability and technical debt. You set the bar and make it easy to meet (Quality, debt and AI tools).
3. Technical delivery. Breaking big work into slices, estimates, technical risks and unblocking people, so the team ships what it says it will (Slicing and planning work).
4. Growing engineers technically. Delegating real problems, pairing, reviewing designs in a way that teaches, and giving honest technical feedback (Delegation and mentoring).

An engineering manager (EM) owns the people side: hiring, performance reviews, pay, promotions, careers, people problems and the health of the team. At Mangrove that is Ken. The product manager owns what to build and why: the problem, the outcome, the priorities. That is Imran. Leila, the designer, owns how the experience works for store staff.

Some things belong to two people. Trade-offs between scope, date and quality need you and Imran together. Growing engineers needs you and Ken: you see their technical work every day, so you give Ken specific examples and coach the engineer; Ken writes the review and decides on promotion. You will usually have influence without authority over people. You can't give Sam a raise, and you shouldn't try to.

The method is simple to describe and easy to skip. In your first two weeks, sit with your EM and write the split down, one line per decision, with who decides and who gives input. Then share it with Imran and the team. Most conflicts between tech leads and managers come from a split that everyone assumed and nobody wrote. Leading with product and management builds on this agreement.

The shapes of the role

Titles vary a lot between companies, so look at what a role is expected to do. Three shapes are common.

• Tech lead. A senior engineer who leads one team's technical work and has no direct reports. They partner with an EM who manages the people. This is your role at Mangrove.
• Tech lead manager (TLM). One person does both jobs: the technical lead and the people manager. Google's engineering book describes the TLM as common on small or new teams. It can work on a small team. As the team grows, doing both jobs well gets much harder.
• Staff engineer. A level above senior on the individual contributor track, whose work reaches beyond one team. A staff engineer may lead a team, own a critical area, or move between hard problems.

Will Larson's book Staff Engineer (2021) describes four archetypes of staff-level work, drawing on interviews with staff engineers at many companies:

• The Tech Lead "guides the approach and execution of a particular team", usually working closely with one manager.
• The Architect is responsible for the direction, quality and approach of a critical area, such as payments or the data platform, across teams.
• The Solver digs into hard, messy problems and finds a way forward, often moving from one problem to the next.
• The Right Hand extends a senior leader's reach, borrowing their scope and authority to run work across a large organisation.

Larson is describing staff-level roles, and at many companies, Mangrove included, a team's tech lead is a senior engineer. The archetypes still help you, because they show where the path can lead. If you enjoy setting a team's direction and growing people, the next step may be leading a bigger area or the manager track. If you enjoy deep technical problems most, Architect or Solver work may suit you better.

Being a tech lead is a good way to try both tracks. You will mentor, run meetings and influence people, as managers do, and you will still own technical decisions, as staff engineers do. Notice which parts give you energy. Moving into management is a change of job, and it is fine to decide it is not yours.

How your week changes

In 2009 Paul Graham wrote an essay called "Maker's Schedule, Manager's Schedule". Managers, he wrote, work in one-hour slots and move from meeting to meeting. Makers, such as programmers and writers, need blocks of at least half a day, because an hour is barely enough to get started on something hard. For a maker, a meeting in the middle of the afternoon costs far more than an hour. In his words, "A single meeting can blow a whole afternoon."

A tech lead lives on both schedules. You have more meetings than before: planning, design reviews, one-to-ones with Ken and Imran, questions from other teams. And you still need maker time for designs, hard reviews and some code. The method is to shape the calendar on purpose:

• Batch meetings into fixed slots, for example Monday and Thursday mornings and the afternoons after lunch.
• Protect at least two half-day maker blocks a week and treat them like meetings with yourself.
• Set daily times for reviews and questions, so people know when they will hear from you.
• Write things down. A one-page design note answers the same question for six people at once.

The work itself changes too. You will write less code and do more reviewing, unblocking, writing and deciding. That feels slower at first, because a merged pull request is easy to see and an unblocked colleague is not. Measure yourself by what the team ships and how fast its engineers grow.

You should still code. It keeps your judgement honest and your reviews credible. The rule is to keep your coding off the critical path. Your week is full of interruptions, so any ticket the team waits on will be late if you hold it. Good work for a tech lead is useful but not blocking: a test tool, a prototype or spike that answers a design question, a bug fix, a script that removes a manual step, or pairing with someone on their ticket.

The "just code more" trap

Most new tech leads were promoted because they wrote good code fast. So when the team falls behind, the natural answer is to take the hardest ticket and work late. It feels responsible. It starts a loop that is hard to leave.

1. You code more, so you have less time for reviews, questions and decisions.
2. Pull requests wait for you, and people wait for answers only you can give.
3. The team slows down, and the people who wait stop learning to decide for themselves.
4. The date slips, the pressure rises, and you code even more.

The loop also builds a quiet risk. When you write all the hard parts, you become the only person who understands them. Your bus factor on those parts is one. When you are sick, on holiday or on call, the team is stuck.

The way out is the opposite loop. Review and unblock first each morning, so work keeps flowing. Give the hard problems to engineers with your support, so they grow. As they grow, you can delegate more and spend more time on direction. Warning signs that you are in the trap: you are the top committer on the team, you have more open pull requests than anyone, people message you before they try things, and the most important design lives only in your head.

Sometimes coding a hard part yourself is the right call, for example a short prototype that proves an idea before the team commits, or a real emergency. Do it on purpose, for a short time, and say so.

Your first 90 days as tech lead

The general advice for a new leader applies here too: learn before you change things, earn trust with an early win, then set the plan (Growing as a PM covers Michael Watkins' The First 90 Days). For a tech lead, the phases look like this.

1. Days 1 to 30: listen. Hold a one-to-one with each engineer and ask everyone the same questions, so you can compare answers. Meet Imran, Ken, Leila, Tomás and Ama. Do the users' work for a shift: count an aisle and receive a delivery in Ama's store, on the real scanner and the real Wi-Fi. Shadow the on-call engineer for a day. Read the last incident reviews, the open pull requests and the CI history.
2. Days 1 to 45: map the system and the team. Draw the system as it is: the React Native app on the scanners, the NestJS API, PostgreSQL, and every place where a dropped connection hurts. Next to it, draw a knowledge map: who understands each part, and where only one person does. Then map the team: each engineer's strengths, what they want to learn, and what they want next. Sam wants to become a tech lead himself; Joel is in his first job. Those facts shape what you delegate.
3. Days 30 to 60: a small early win. Pick one problem the team itself complains about, small enough to fix in a few weeks, and fix it with the team instead of for them. Good early wins for a tech lead are often about flow: slow reviews, flaky tests, a noisy alert, a painful release step.
4. Days 60 to 90: write a direction. A short technical vision for the next two quarters, a few working agreements (reviews, on-call, how decisions get recorded), and the first plan for the next big feature. Review drafts with the people you met in month one (tl-02).

The traps are the same as for any new leader, with a technical flavour. Rewriting the architecture in week two because you would have built it differently. Bringing the tools from your last team without asking why this team chose its own. An early win only you care about, such as a refactor nobody asked for. And a listening phase with no written result.