Episode 24 52 minutes

Leveling Up as a Tech Lead with Anamari Fisher

Key Takeaways from our conversation with Anamari Fisher

Anamari Fisher

Engineering Leader, Coach, O'Reilly Author of 'Leveling Up as a Tech Lead', EMCC Accredited Coach

Señors @ Scale host Neciu Dan sits down with Anamari Fisher — engineering leader, coach, and O'Reilly author of 'Leveling Up as a Tech Lead' — to explore the first jump into leadership. Anamari shares how she went from software engineer to tech lead and product director, why accountability is the key differentiator from senior engineer, and how to scale your impact through soft skills that actually work in real teams.

🎧 New Señors @ Scale Episode

This week, I spoke with Anamari Fisher, an engineering leader, coach, and O'Reilly author who spent over a decade in tech — from software engineer to tech lead and product director. She's an EMCC accredited coach, has coached hundreds of engineers and trained tech leads across the globe, and previously led teams at Thoughtworks during large-scale transformations like monolith to microservices and cloud migrations. These days she runs AF Level Up in Tech, helping senior engineers and leaders grow confidence, influence, and leadership capability. She recently distilled much of her knowledge in "Leveling Up as a Tech Lead" — a book I heavily recommend.

In this episode, we dive into what actually differentiates a tech lead from a senior engineer, how to help people get out of their shell, why context beats one-size-fits-all in coaching, and how to prepare for (and survive) the first jump into leadership.

⚙️ Main Takeaways

1. Ownership and accountability from small teams shape future leaders

Anamari’s early experience in small companies taught her to carry accountability and see things through — even without all the information up front.

  • The setup: In small teams she had to reach out, rely on people, and get things done without someone constantly checking in.
  • The link to leadership: The only difference when you become a leader is that you have to make sure things happen even when you’re not the one doing them.
  • The lesson: "That's the accountability part that comes with owning something and fully seeing it through and making it happen, regardless if you have all the information from the beginning or not."

2. Three strategies to help people get out of their shell

When engineers sit in their corner and wait for tasks, managers can use three approaches — often in combination.

  • Empower and create space: Use 1:1s to understand motivation, then stop being the default guide. When they ask for answers, redirect: "Maybe you can talk with that person." Put them in situations where they have to figure it out.
  • Tie growth to aspirations: For someone who wants to become senior, make it explicit: "This is part of the requirement." Give them ownership (e.g. an initiative) and support them through it.
  • Use frustration as a motivator: When people feel stuck — salary, growth, no feedback — ask: "Who have you asked? What have you done?" That often triggers them to stop waiting and start acting. It’s not the most efficient, but it works.

3. Context over one-size-fits-all in coaching

Coaching and feedback only work when you adapt to the person’s context, not a fixed process.

  • Why it matters: The surface problem can look the same ("I can’t grow to senior"), but the real reasons differ — confidence, not knowing what to do, or lacking information.
  • The approach: Find the underlying challenge first; that’s where you work. You can’t apply the same process for everyone because it won’t work.
  • The reward: "The part that I enjoy most about coaching is that process of figuring out the underneath struggles and challenges that people have."

4. Intentional growth beats one big jump

Getting out of your comfort zone is necessary for growth, but doing it in small, intentional steps is more effective than a single huge leap.

  • The risk of the big jump: Going from zero to "speak in front of 200 people" can backfire — you prove to yourself "I can’t do this" and retreat.
  • The alternative: Find small steps: e.g. deliver a training for your team before aiming at a big conference. "Intentional growth is about finding the little steps on the way to the big jump."
  • The principle: Constantly push yourself out of your comfort zone in a way that still feels manageable.

5. Collaboration is the soft skill that scales most

When "scale" means expanding your impact — on product, people, or team — collaboration is the most efficient lever, especially for tech people.

  • What it includes: Engaging, asking for help, reaching consensus, healthy challenge, contributing to a common result without constant friction.
  • Why it’s hard: It’s one of the hardest to develop if you’re not comfortable with it, and every new person is a new challenge — it constantly requires leaving your comfort zone.
  • Why it pays off: It speeds up scaling your impact more than any other single soft skill.

6. Tech lead = accountability for the team’s technical deliverables

The main difference between a senior engineer and a tech lead is who carries accountability.

  • The definition: The tech lead is the only one accountable for the technical deliverables of the team. When things go wrong, they’re on the front line.
  • Not the same as doing everything: Accountability doesn’t mean doing it all yourself — it means it’s on you to make sure it happens.
  • The reality: "It's actually one of the hardest things in my trainings with tech leads, to help them understand how this makes their life harder."

7. Learn accountability before you have the title

You can build accountability muscles before becoming a tech lead, and you’ll never feel fully ready for the role.

  • Take ownership: Lead an initiative (e.g. feature lead) with your tech lead or manager; own a process (e.g. tech debt strategy — get team and stakeholder agreement).
  • You’ll never feel fully ready: Confidence is built by doing it. If there’s an opening, go for it; worst case you get direct feedback on what you’re missing.
  • The advice: "Be clear about what you want and where you want to get with the people around you. Start working towards that until someone says yes or no — then you work on the reasons or you find another place where someone says yes."

8. Expand impact beyond your team (especially as senior)

Seniors and future tech leads should go beyond their immediate team — and in many companies this is already an expectation.

  • Instead of documents: Don’t just receive requirements; go have conversations with adjacent teams. "What’s the problem we’re trying to solve? What are the needs? How can we build a solution together?"
  • Why it matters: Your work often impacts or depends on other teams. Engaging early builds trust and makes you the person others think of when they need a leader.
  • Context-dependent: In bigger companies, expanding impact beyond the team is often an explicit expectation for seniors.

9. Tech leads who stay very hands-on often struggle

Even when the company expects tech leads to code a lot, the ones who succeed usually code less over time.

  • The tension: Strategy, alignment, and people work are still expected. Fulfilling all of that while coding 70% of the time is rarely sustainable.
  • Comfort zone: Staying very hands-on often feels safe and gives quick reward; leadership impact is delayed (months or years).
  • The shift: "The main thing people struggle with when they do this jump is letting go and understanding that there might be five bad days where you feel you haven’t done anything — and then everything comes together."

10. Tech lead as leader; involvement in people growth is non-negotiable

You manage things and lead people — and you can’t be accountable for delivery without being involved in how the team grows and works.

  • The distinction: "You manage things and you lead people" (Grace Hopper). The tech lead must be involved in growing people and their ways of working.
  • Middle ground: Some companies separate "performance review and salary" (e.g. EM) from "mentor, feedback, growth plan" (tech lead). Tech leads can own the latter without the former — and that often works.
  • The role: "It's one of the hardest roles in tech. There's very little information on how to do that jump — that's also why I wrote the book."

11. Measure tech lead impact through the team; define success for yourself

Your success as a tech lead is the team’s success. Define what "successful" means and align it with stakeholders.

  • The rule: You’re only as successful as your team. Measure impact of the team (delivery, timeliness, happiness — context-dependent).
  • Define success for you: "What does successful look like for you?" Many people realize they’re already more successful than they thought once they name it.
  • Align with others: Whatever you define, agree with your manager and stakeholders. "If they don’t agree with it, you might be working for the wrong outcomes."

12. How to know what to learn (juniors and mids)

Three concrete ways to find out what to work on next.

  • Job description: Do a self-assessment against the next level; bring it to your manager. If there’s no JD, go straight to your manager.
  • Manager and stakeholders: They’re there to support growth. Ask: "What do I need to work on?"
  • Specific feedback from the team: Don’t ask "give me feedback." Ask: "Please tell me one thing I need to work on when it comes to [e.g. leadership skills]." Be specific to get useful input — then align with your aspirations.

13. Job hunting: one-to-one connections and paying back

In the current market, getting your foot in the door is the hard part. The most efficient strategy is building real connections over time.

  • What works: One-to-one connections, recommendations, getting a human to look at your CV. Conferences (and speaking) help — people come to you. Engage in community; small, repeated interactions build trust.
  • What doesn’t: Sending messages to everyone. "You have to do the groundwork. It takes time — that’s why people don’t like it."
  • Pay back: "The secret to not make it awkward is to pay back. I do the same for other people. As long as you pay back to the community, the community pays back to you."

14. Tech lead interviews: it’s a match, not a verdict

If the process only tests coding and system design, that says something about the company. Use it to decide if you want the role.

  • Read the process: An interview process that ignores leadership often reflects a very technical culture. Even if you want to show leadership, you might not get to do much of it there.
  • Challenge it: Ask: "You’re interviewing for a tech lead — how does this fit with what we’re discussing?"
  • Match, not judgment: A yes or no is whether needs and offer align at that time. Define what you want (day-to-day, expectations, priorities), then focus on roles that match — and put more effort into fewer, better-fit applications.

15. The secrets in the book: collaboration, 1:1s, delegation

Anamari’s favorite parts of "Leveling Up as a Tech Lead" are the ones that make tech leads successful in practice.

  • Collaboration and relationships: Working with others efficiently and building trust.
  • 1:1s: "A secret to any leader that we keep ignoring these days."
  • Delegation: The best tool to take things off your plate while empowering the team — and to reduce the pressure that makes new tech leads take everything on themselves.

🧠 What I Learned

  • Accountability is the core difference between senior engineer and tech lead — you’re the one on the front line when things go wrong.
  • Three ways to help people get out of their shell: empower (create space to figure it out), tie growth to aspirations, and use frustration as a motivator.
  • Coaching works when you find the underlying challenge; the surface problem often looks the same but the causes differ.
  • Intentional growth in small steps beats one big jump — otherwise you risk proving to yourself "I can’t do this."
  • Collaboration is the soft skill that scales impact most for tech people, and it’s one of the hardest because it constantly pushes you out of your comfort zone.
  • You can learn accountability before the tech lead title by taking ownership of initiatives and processes.
  • You’ll never feel fully ready for the tech lead role; confidence is built by doing it.
  • Seniors should expand impact beyond their team — have conversations with adjacent teams instead of just receiving documents.
  • Tech leads who stay very hands-on often struggle; leadership rewards are delayed, and the role expects strategy and alignment too.
  • You manage things and lead people; tech leads need to be involved in people growth even if they don’t own performance reviews.
  • Your success as a tech lead is the team’s success; define what success means for you and align it with your manager and stakeholders.
  • To know what to learn: job description, manager, and specific feedback from the team ("one thing I need to work on in X").
  • Job hunting: one-to-one connections and groundwork beat mass applications; pay back to the community.
  • Interview process is a match; if it only tests coding for a tech lead role, that reflects the company — and you can focus on roles that fit what you want.

💬 Favorite Quotes

"That's the accountability part that comes with owning something and fully seeing it through and making it happen, regardless if you have all the information from the beginning or not."

"Intentional growth is about finding the little steps on the way to the big jump. It's way more risky to just do the jump directly."

"As a tech lead, you're the only person in the team that has the accountability for the technical deliverables of the team. When things go to shit, you're gonna be the first one in the front line."

"You'll never feel fully ready. I never met anyone that said, okay, now I'm gonna jump, I'm truly ready. The confidence gets built up by you doing it."

"You manage things and you lead people."

"Your success as a tech lead depends on the success of your team. Whatever you define as your success criteria, make sure you agree on it with your manager and your stakeholders — if not, you might be working for the wrong outcomes."

"The secret to not make it awkward is to pay back. As long as you pay back to the community, the community is going to pay back to you."

"The interview process when you get a yes or a no is just a match. It's not a matter of judgment — at this point and this time with these requirements, this company has the same needs as the things you're bringing."

🎯 Also in this Episode

  • How Anamari went from informatics in high school to software engineer and then tech lead
  • Balancing university and part-time work (and professors who didn’t support it)
  • Learning C++, Pascal, assembly, Lisp — and why "ugly" tech is still the reality in many companies
  • First jobs in small companies: ownership, support for juniors, and hands-on learning
  • The doer mentality vs. waiting for tasks — and why small-company experience helps
  • Cross-cultural context and coaching (and why The Culture Map matters)
  • Speaking at conferences as a way to build confidence to speak up in meetings
  • Tech lead vs. manager: coding expectations and the range across companies
  • Defining "successful tech lead" for yourself and checking the boxes
  • Job descriptions and self-assessment for growth
  • Why the tech lead role is messy and context-dependent — and why she wrote the book
  • Book recommendations: Crucial Conversations, The Culture Map, The Manager’s Path, continuous delivery (Valentina Servile, classic Continuous Delivery), thrillers (The Silent Patient)
  • Conferences: Live Dev, DevFest Barcelona, and applying in the review season

Resources

More from Anamari:

Book Recommendations:

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 52 minutes on tech lead accountability, soft skills that scale, intentional growth, and making the first jump into leadership.

If you’re a senior engineer eyeing the tech lead role, a new tech lead figuring out the job, or a manager helping people grow, this conversation — and Anamari’s book — are full of practical ideas you can use right away.

Happy building,
Dan

💡 More Recent Takeaways

MicroFrontends at Scale with Florian Rappl
Episode 23

Señors @ Scale host Neciu Dan sits down with Florian Rappl — author of 'The Art of Micro Frontends,' creator of the Piral framework, and Microsoft MVP — to explore how micro frontends are transforming how we build scalable web applications. Florian shares hard-won lessons from over a decade of building distributed systems, from smart home platforms to enterprise portals for some of Germany's largest companies.

Nuxt at Scale with Daniel Roe
Episode 22

Señors @ Scale host Neciu Dan sits down with Daniel Roe, leader of the Nuxt Core team at Vercel, for an in-depth conversation about building and scaling with Nuxt, Vue's most powerful meta-framework. Daniel shares his journey from the Laravel world into Vue and Nuxt, revealing how he went from being a user to becoming the lead maintainer of one of the most important frameworks in the JavaScript ecosystem.

State Management at Scale with Daishi Kato (Author of Zustand)
Episode 21

Señors @ Scale host Neciu Dan sits down with Daishi Kato, the author and maintainer of Zustand, Jotai, and Valtio — three of the most widely used state management libraries in modern React. Daishi has been building modern open source tools for nearly a decade, balancing simplicity with scalability. We dive deep into the philosophy behind each library, how they differ from Redux and MobX, the evolution of the atom concept, and Daishi's latest project: Waku, a framework built around React Server Components.

Domain Driven Design at Scale with Vlad Khononov (O'Reilly and Pearson Author)
Episode 20

Señors @ Scale host Neciu Dan sits down with Vlad Khononov, software architect, keynote speaker, and author of Learning Domain-Driven Design and Balancing Coupling in Software Design. Vlad has spent over two decades helping teams untangle legacy systems, rebuild failing architectures, and bring clarity to messy business domains. This conversation cuts through the hype around DDD and microservices, focusing on the mechanics of bounded contexts, coupling, business alignment, and architectural evolution.

📻 Never Miss New Takeaways

Get notified when new episodes drop. Join our community of senior developers learning from real scaling stories.

💬 Share These Takeaways

Share:

Want More Insights Like This?

Subscribe to Señors @ Scale and never miss conversations with senior engineers sharing their scaling stories.