Zoe Farooq

Many engineers hesitate to explore leadership roles due to persistent myths that misrepresent what engineering management actually involves. This session challenges common misconceptions—like the need to constantly promote yourself, the belief that only extroverts can lead effectively, or the fear that saying "no" is a sign of weakness. It also tackles concerns about spending all day in meetings or losing technical credibility. By sharing real-world examples and insights, the discussion aims to clarify what engineering leadership truly entails and help engineers assess whether it aligns with their strengths and values. Let's talk about: What assumptions did you have (or do you still have) about what engineering managers actually do day to day? Do you feel like leadership is only for certain types of personalities? Why or why not? Have you ever held back from pursuing a leadership opportunity because you were afraid it would pull you too far from technical work? What do you think “visibility” means in an engineering context—and is it always necessary for career growth? How do you balance saying “yes” to new opportunities with setting boundaries that support your team’s focus and well-being?

Owning and delivering a feature might seem like a standard responsibility for senior engineers and tech leads—but doing it exceptionally well is rarer than you'd think. This roundtable brings together seasoned leaders from Android and Flutter teams to discuss the often-overlooked mistakes that can derail feature development, even for experienced ICs and EMs. From poor documentation and unclear communication to lack of collaboration and hidden decision-making, we'll explore what not to do—and how to do better. Together, we’ll share stories, surface patterns, and identify habits that lead to smoother execution, stronger team dynamics, and better outcomes. What’s one misstep you've seen (or made) when leading a feature that created avoidable friction or confusion? How do you balance speed with documenting decisions and trade-offs—especially when timelines are tight? Have you ever seen (or experienced) communication breakdowns because too much happened in DMs or side chats? How do you promote visibility without slowing down progress? How do you encourage engineers to challenge each other’s solutions without creating tension or hierarchy in the team? What strategies have worked for you to keep large features on track without micromanaging every detail?