Our first Leadership Lessons AMA of 2026 kicked off with Anemari Fiser, Engineering Manager, O’Reilly Author & Tech Lead Trainer in the spotlight.
We explored her journey from engineer to leader, the mindset shifts that shaped her path, the hard lessons learned in high-stakes moments, and how she stays credible without living in the code.
🎥 Watch the full conversation below
When did you realise tech leadership was the right path for you?
I was always more motivated by the impact we had as a team than by my individual achievement. I cared about how we made decisions and how we could do better together. At some point I realised the only way to have the kind of impact I wanted was to lead a team.
What was the hardest mindset shift when you moved from engineer to leader?
Letting go of control. As an individual contributor, you feel in control of your work and your results. As a leader, there are so many variables – people, personalities, context – and you can’t control them. I had to learn to rely on my team. And I realised that if I kept over-controlling, I was blocking their growth.
What advice would you give someone stepping into tech leadership for the first time?
Get very clear on expectations. Not what you think is expected of you - what actually is. Talk to your manager. Ask your team what they expect from you. And then align that with how you want to show up. If you don’t set expectations early, you create confusion and disappointment later.
What leadership mistake taught you the most?
I once aligned with my team on a strategy, but in the final conversation with the client I had to go in a different direction. My team felt betrayed. The real mistake wasn’t the decision, it was that I hadn’t been clear upfront about how much decision power we actually had.
I learned to be very straightforward about how decisions will be made from the beginning.
How do you involve quieter engineers in decision-making?
There are a few practical strategies. One is anonymous input. You can use a form, a board, post-its – anything that separates the idea from the person. Often people don’t speak because they’re worried about how their idea will be perceived.
Another approach is using one-on-ones. If there’s a big topic coming up, I’ll gather input individually and then present those ideas in the group without attaching names. That way people feel heard without feeling exposed.
But I want to emphasize something important: don’t assume someone is quiet just because ‘that’s their style.’ You have to understand why. Is it a psychological safety issue? Is it a skill gap? Do they not fully understand the topic? Or did they just have a bad day?
If you only add anonymous tools without diagnosing the root cause, you’re solving the wrong problem. First understand whether it’s an individual issue, a team dynamic issue, or a trust issue. Then act accordingly.
How do you balance technical depth with people leadership?
Balance isn’t static. It’s constant adaptation. You have to understand your team’s context. If you have strong seniors, you might focus more on facilitation and strategy.
If your team lacks experience in an area, you may need to be more hands-on – but that doesn’t mean doing the work for them. It means helping them grow into it.
How do you know if you’re actually a good leader?
Feedback. Your gut feeling isn’t enough. Your success depends on your team’s success. If the impact you think you’re having isn’t reflected in how people experience you, then it doesn’t really matter what you think. The only way to know is to ask.
How much responsibility should a tech lead take for ‘glue work’ like documentation, mentoring, and stakeholder coordination?
Stakeholder coordination is often part of the tech lead role, especially in more traditional companies. But documentation is a team responsibility. Instead of making it a separate task, it should be part of the work itself.
Mentoring isn’t glue work, it’s core leadership. Growing people is part of your job.
And instead of carrying all the glue work yourself, you want shared ownership. You want the team involved and accountable.
How do you balance transparency with shielding your team from difficult stakeholders?
It depends on the context, there’s no single rule.
My default is transparency. I believe sharing context builds trust and helps teams feel included. But I’m intentional about it. When I receive sensitive information, I’ll validate upward and ask, ‘What can I share, and when?’ Sometimes there are legal or strategic constraints, and alignment matters.
If you tend to withhold information, I’d suggest experimenting with small steps. Share a little more and observe the impact. Most leaders are afraid of oversharing, but if transparency isn’t your default, it’s unlikely you’ll suddenly go too far.
The goal is to understand the boundaries, stay aligned with leadership, and then be as transparent as you responsibly can. That’s what builds trust without creating unnecessary risk.
If these themes resonate, you can dive deeper by watching the full Leadership Lessons AMA on demand here.