The Tech Lead Book That Finally Tells You the Uncomfortable Truth
Most engineers who step into a tech lead role expect it to be a natural extension of what they already do: write better code, make bigger architectural decisions, earn more credibility. Then week one hits. Calendar’s full. Slack is exploding. And you’re somehow still expected to ship features while figuring out why two senior developers are fighting over a JSON library at 3pm.
Leveling Up as a Tech Lead by Anemari Fiser is a rare book: one written specifically for tech leads, not engineering managers, not CTOs, not staff engineers. Fiser spent years as a Thoughtworks tech lead and has since coached over 500 tech leads across dozens of companies. The result is a refreshingly direct manual for one of the most misunderstood roles in tech.
Here are the most surprising, counter-intuitive, and genuinely useful lessons from the book.
1. The Tech Lead Role Is 100% More About People Than Tech — And Most People Aren’t Ready to Hear That
The book opens with a claim that makes many engineers uncomfortable: the tech lead role is fundamentally a people management role, whether your job description says so or not. Fiser is blunt about it — you can’t ensure delivery without regular check-ins, you can’t raise technical excellence without giving feedback and resolving conflict, and you can’t lead without managing people.
What makes this counterintuitive is how the role is marketed. “Tech lead” sounds technical. Candidates are evaluated on architecture skills and system design. Then they get the job and discover that most of their daily problems are interpersonal: a developer who doesn’t take ownership, two teammates who can’t agree, a stakeholder who doesn’t trust the team’s estimates.
“Most tech problems are people problems.”
This isn’t a soft observation — it’s the book’s central thesis. Every subsequent chapter is built around this idea. If you’re looking for a book about distributed systems, this isn’t it. If you’re looking for a book about leading people who build distributed systems, this is the one.
2. You Don’t Need to Be the Most Technical Person on Your Team (And Trying to Be Is a Trap)
One of the most liberating insights in the book: your value as a tech lead does not come from technical depth. It comes from technical breadth — knowing enough to guide decisions, ask the right questions, and not become a bottleneck.
Fiser shares a personal story of leading a team on a major feature delivery under a tight three-month deadline despite having limited knowledge of the tech stack and no prior relationships with the company. The team delivered. Not because she out-coded everyone, but because she focused on unblocking people, aligning the backlog, and ensuring knowledge was shared rather than hoarded.
The trap many new tech leads fall into is trying to maintain their identity as the top technical contributor while also handling leadership responsibilities. This path leads to burnout and resentment — yours and the team’s. The moment you shift from “I need to know everything” to “I need to enable people who know things,” everything gets easier.
3. Most Technical Problems Are Actually Unresolved Relationship Problems
Two developers spending hours debating which JSON parsing library to use? Fiser encountered this early in her career and made what she calls the classic mistake: she dove into the technical debate to find the “right” answer. Later she learned to ask questions instead.
When she did, she discovered the real issue: these two developers had a recurring underlying conflict. They couldn’t agree on pretty much anything. The JSON library was just the current arena.
This pattern shows up constantly in engineering teams. A technical disagreement that escalates beyond reason is usually a proxy for a trust, communication, or status conflict underneath. Technical debt that nobody’s fixing isn’t usually a resources problem — it’s an ownership problem. An architecture debate that never resolves is often about competing visions of the product itself.
The implication for tech leads: don’t jump to the technical solution first. Learn to listen for what’s really being said.
4. The Way You Ask for Feedback Determines the Quality of Feedback You Get
Most leaders ask for feedback poorly. “Do you have any feedback for me?” is a question almost guaranteed to produce a useless response. Fiser offers a much better approach.
Be specific about what you’re working on: “I’ve been trying to improve my delegation skills. What do you think I could do better?” Use a 1-to-10 scaling system to make conversations concrete: “On a scale of 1 to 10, how good do you think I am at running retrospectives? What would make it a 10?” Give people time to prepare — don’t ambush them with feedback requests.
Perhaps most underused: ask for feedback during offboarding. When someone is leaving the team, they’re more reflective and more willing to share honest observations. This is often when you hear things you’ve needed to hear for months.
The counterintuitive truth here is that getting useful feedback requires as much skill as giving it. Most leaders never develop this skill because they assume the initiative and honesty need to come from the other person. They don’t.
5. Giving Only Positive Feedback Erodes Your Credibility — Just as Much as Giving None
Many tech leads avoid constructive feedback because they fear damaging relationships. The book makes an equally strong case for the opposite problem: tech leads who give only positive feedback also lose credibility.
People know they aren’t perfect. When their tech lead never highlights areas for improvement, one of two things happens: the team member assumes the tech lead isn’t paying close attention, or they suspect the positive feedback isn’t genuine. Over time, they stop trusting the praise entirely.
Fiser is also clear that the “feedback sandwich” — positive, constructive, positive — is overrated. It dilutes the message and often comes across as formulaic. Better to develop the skill of giving specific, timely, honest feedback regardless of valence, and let each piece stand on its own.
The practical fix: track your own feedback patterns. If you’re only giving constructive feedback, set an intentional reminder to acknowledge what’s working. If you’re only giving praise, push yourself toward one difficult but necessary conversation.
6. One-on-Ones Are Only as Good as Your Listening — and Most Leaders Aren’t Actually Listening
One-on-ones are a core leadership tool, but Fiser identifies something most books on the topic miss: the biggest failure mode isn’t lack of structure or consistency (though those matter). It’s dominating the conversation.
Tech leads — especially those who were high performers as individual contributors — have a habit of filling silence with their own insights, experiences, and advice. When a team member shares a challenge, the leader launches into a story about how they handled something similar. It feels like relatability. To the team member, it feels like the conversation was hijacked.
Fiser’s advice: embrace silence. Count to 39 in your head after someone finishes speaking. Most of the time, they’ll continue — and what comes next is usually more honest than what they said first. After each one-on-one, ask yourself: “Did I walk away understanding more about them than they learned about me?” If not, rebalance.
7. Delegation Is a Leadership Skill, Not a Time-Saving Tactic — and Most Tech Leads Do It Wrong
The book dedicates an entire chapter to delegation and makes a sharp distinction: most tech leads delegate to offload work. Effective tech leads delegate to develop people.
This means delegation should feel slightly uncomfortable for the person receiving it — it should stretch them. It means you don’t delegate and then micromanage. It means you accept that the work will be done differently than you would do it, and that’s often fine.
One of Fiser’s recurring reframes: instead of “I’ll handle this,” your default should become “Who could grow by handling this?” The first question scales you. The second question scales the team. Only the second one is sustainable long-term.
8. Your First Priority When Starting in a New Tech Lead Role Is to Listen, Not to Prove Yourself
Whether you’re taking over an existing team or building a new one, the instinct of new tech leads is often to demonstrate competence early — implement changes, fix obvious problems, show the team you know what you’re doing.
Fiser’s advice runs counter to this: spend your first weeks building relationships and gathering information. Form allies who can give you honest context about team dynamics. Resist the urge to “rock the boat” before you understand why the boat is shaped the way it is.
Ironically, the tech leads who try hardest to establish authority quickly are often the ones who struggle most with it. Authority in a leadership role isn’t claimed — it’s granted over time through trust, consistency, and follow-through.
9. Integrating AI Into Your Team Is Now a Leadership Skill — and It Starts With Your Own Workflow
One of the book’s most timely sections (co-written with Birgitta Böckeler, a Thoughtworks distinguished engineer) addresses AI’s role in software delivery with unusual clarity and realism.
The framing isn’t “AI will replace developers” or “AI is overhyped.” It’s more useful than either: embracing AI thoughtfully is a leadership competency. Your team will look to you for guidance on when to trust AI outputs, when to push back, and how to build a culture that experiments responsibly rather than either refusing to engage or blindly trusting.
The practical recommendation: start with your own workflow. Use AI for release notes, summarizing architecture decision records, turning rough notes into onboarding guides. Develop your own judgment about its limitations before you try to shape your team’s relationship with it.
What This Book Gets Right That Most Leadership Books Miss
Leveling Up as a Tech Lead is specific in a way that most leadership books aren’t. It doesn’t offer a generic leadership philosophy and then gesture vaguely toward engineering contexts. It addresses the actual situations tech leads face: how to handle the transition when your peer becomes your report, how to give feedback about code quality without triggering defensiveness, how to run one-on-ones with introverts, how to communicate delays to stakeholders who don’t understand technical complexity.
The book’s central challenge to its reader: stop thinking of the tech lead role as “senior engineer with extra meetings.” Start thinking of it as a genuinely different job — one where your success is measured by what your team achieves, not what you personally build.
That shift in frame is harder than it sounds. But it’s the one that determines whether you’ll thrive in the role or quietly exhaust yourself trying to be two people at once.
What aspect of the tech lead role do you find hardest to let go of?