Ask Me Anything (AMA) with a Senior Eng Director - Sanjay Siddhanti

[**Sanjay Siddhanti**](https://www.linkedin.com/in/sanjaysiddhanti/) is a Senior Director of Engineering at AKASA. After graduating from Stanford, he previously held engineering roles at Counsyl, Karius, and Flatiron Health.

Sanjay's background:

I'm the Senior Director of Engineering at AKASA. I joined AKASA in 2019 as one of the first employees when we were a seed-stage startup. I originally joined AKASA as an individual contributor, and quickly switched over to management. I built much of the company's early technology as an IC and later as a tech lead / manager. I also started and managed multiple engineering teams at the company, including Platform Engineering, now an org with 20 engineers.

Happy to answer questions about:

- How engineering leaders think about the role of Senior, Staff, and Principal ICs.
- How and why to transition from IC to management
- The differences between an Engineering Manager vs Engineering Director
- How to hire and retain great talent
- How to succeed in a startup environment.

Ethan Evans' Career Path: Startup Manager to Amazon VP

[Ethan Evans](https://www.linkedin.com/in/ethanevansvp/) is a retired Amazon VP. He shared his career journey starting out during the dot-com boom of the 1990s, quickly ascending as a manager at a string of startups.

**Early Career and Management Path:**

- Ethan started in management early, taking on a TPM role for a small project due to the team's need.
- He was drawn to leadership because the project lacked organization, focus, and communication.
- Ethan was supported by managers and encouraged to continue in the role. He progressed through several startups, growing in each one and reaching VP level by the third.

**Joining Amazon:**

- Ethan was a "fake" startup VP before going getting downleveled as a manager at Amazon, and it took years for him to return to a true VP role, managing a team of 800 people.
- The startup he was at was failing, and Amazon offered more compensation despite being giving a worse title.
- He initially managed a team of six at Amazon, which eventually grew to 800. 

Ethan credits his rapid ascent to:

- Seeing problems and proactively solving them.
- Taking initiative and asking for more responsibility.
- Curiosity and motivation to understand the bigger picture.

More to explore: 

- [\[Taro Top 10\] Software Engineer To Engineering Manager (IC -&gt; M Track)](https://www.jointaro.com/playlist/oz0mnJvHHgM8NfVF7rgp/)
- [What's the difference between Big Tech and startups in terms of learning and growth?](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)
- [How much am I hurting my career by staying at a startup? (Pressure to work for big tech)](https://www.jointaro.com/question/dqCvmYhI9WE0k33orZEP/how-much-am-i-hurting-my-career-by-staying-at-a-startup-pressure-to-work-for-big-tech/)

Demystifying LLM Benchmarks -- How To Compare Large Language Models?

In the recent launch of Google's Large Language Model (LLM) Gemini, Google claimed that "Gemini beats human level performance on MMLU" but you might be wondering:

- What are the different evaulation criteria? Massive Multitask Language Understanding (**MMLU**)? General Language Understanding Evaluation (**GLUE**)? **HumanEval**?
- How can we know which model is good at coding tasks?
- What is considered "human-level performance"?
- How do they actually get the results for these benchmarks?

In this talk, Sai breaks down all the benchmarks you need to know to be better informed when papers claim to beat benchmarks.

The next paper reading session is on January 8 at 5pm: [**https://www.jointaro.com/event/paper-reading-group-4-mistral-7b/**](https://www.jointaro.com/event/paper-reading-group-4-mistral-7b/)

**Your host:**

[**Sai Shreyas Bhavanasi**](https://www.linkedin.com/in/b-sai/) has worked in Computer Vision and Reinforcement Learning and published 2 first-author papers. He has also worked as an MLE and Data Analyst.

How To Build A Fulfilling Career Path For Your Engineers

We’ve all been there – you want to be there for your team, but you end up pushing back 1:1 meetings because there’s a lot on your plate. Or your team member wants to practice a particular framework but you don’t have any upcoming work that would let them do that. Or you’re heading into a career development conversation and trying to figure out how to share some tough feedback.

At the same time, a regular piece of feedback from individual contributors is that they’d like their managers to provide more support for their career development..

So what’s an engineering manager to do? How can we help our teams build fulfilling careers while juggling their asks with all the other work on our plate? And how do we balance their development areas with completing the work that needs to be done? Doing this well will not only help our team’s satisfaction and morale, but also support our own progress in our organization – but it’s easier said than done.

This talk provides concrete tips to help you do better in supporting your team on their career development journey. We’ll talk about strategies to:

- The bedrock for a fulfilling career (awareness)
- Make time for 1:1s – even when things get busy!
- Focus 1:1’s on growth & development (not work)
- Balance between improving weaknesses versus cultivating strengths

This is a talk Rahul gave at the [Tech Leaders Chat](https://www.meetup.com/tech-leader-chats/events/293719388/) hosted by [Multitudes](https://www.multitudes.co/).

The Cardinal Sin Of Management: Micromanaging

This segment outlines why micromanagement is a hallmark of poor engineering leadership and how effective managers empower their teams instead of controlling them. It offers a comprehensive look at how hands-off, trust-based leadership enables better team performance and growth.

- **Micromanagement is a red flag**: Hovering over engineers’ work or constantly asking for status updates wastes time, erodes trust, and stifles ownership.
- **Effective managers lead through trust and empowerment**: Autonomy allows engineers to make decisions and own outcomes, with structured check-ins (e.g., weekly or bi-weekly) to stay aligned.
- **Staying out of technical weeds is critical**: A manager's role should focus on people, not code reviews, engineering meetings, or day-to-day task assignments—those should be handled by tech leads or the engineers themselves.
- **Micromanagement creates systemic risks**: It builds dependency, slows down team velocity, and makes the manager a single point of failure. If the manager leaves, the team may lack the tools or confidence to function independently.
- **Lack of trust leads to poor career growth**: Engineers under micromanagement are less likely to take initiative or learn leadership skills, hindering their path to promotion and long-term development.

How To Navigate Your Stock Options

This section of the video explores **what to do with startup stock options**—both while employed and after leaving a company. It emphasizes evaluating offer quality upfront and making strategic decisions about exercising options based on company outlook and personal risk tolerance.

- **Understand the offer**: When joining a startup, it's important to know both the **strike price** (cost to buy shares) and the **fair market value (FMV)** of the shares. A significant gap between these numbers indicates more potential upside.
- **Don’t exercise too early**: While employed, it's typically better to wait before exercising options. Exercising early ties up personal capital and carries risk if the company performs poorly or fails before a liquidity event.
- **Exception for early-stage employees**: If the cost to exercise is very low (e.g., a few hundred dollars), it may make sense to do so early to start the **long-term capital gains clock** for better tax treatment.
- **After leaving the company**: Most startups require options to be exercised within **90 days of departure**. If there's confidence in the company’s future, it may be worth exercising all or part of the options—otherwise, it might be best to walk away.
- **Weigh risk vs. return**: Exercising options is a personal investment decision. If the company is struggling or unlikely to succeed, even favorable strike prices can result in total losses.

Assembling The Feedback "Avengers" For Your Promotion Case

The “Do No Harm” Principle In Coding

In this segment, we discuss the principle of **"Do No Harm"**—a foundational mindset for writing safe, reliable code. While it's great to break large features into smaller diffs, it's essential that each individual diff **stands alone** as non-destructive and does not degrade the product or infrastructure if applied independently.

### Key Takeaways:

- **We ensure every diff is safe in isolation**: Even in stacked diffs, each change must not break functionality or expose incomplete features. Every diff should be self-contained and ideally improve (or at least preserve) the integrity of the codebase.
- **We avoid relying on future diffs to patch behavior**: It's risky to land an unstable or unfinished diff assuming a follow-up will fix it. If that follow-up is delayed or rolled back (e.g., due to a production issue), the earlier diff could introduce bugs or break the app.
- **We use feature gates wisely and early**: When launching features behind flags, we gate the feature at the very beginning—not in later diffs—to avoid exposing half-baked functionality in production.
- **We’re cautious with shared infrastructure**: If a diff touches a shared module or critical system, we proactively reach out to other teams to confirm our changes won’t unintentionally break their workflows or apps.
- **We understand our code lives in a larger system**: Like parts of a giant elephant, changes in one place can affect parts we can’t see. Practicing empathy and caution helps us prevent cascading issues in complex, multi-team environments.

The “Do No Harm” principle reminds us that good engineering isn’t just about adding features—it’s about protecting trust, stability, and the broader system our code lives in.

A Simple Trick To Make Your Meetings More Efficient

What can you do before a meeting to empower it to achieve more outcomes?

You write down an agenda for your upcoming meeting, and you realize that it is incredibly rich and complex. What else can you do to level up the meeting?

Preparing and sharing an agenda before meetings—especially manager one-on-ones—leads to more thoughtful discussions and better outcomes.

- **Pre-fill the meeting agenda early**: Add discussion topics at least a day in advance to give others time to prepare.
- **Proactively notify participants**: Ping the other attendees to let them know the agenda is ready and encourage them to review it before the meeting.
- **Avoid putting others on the spot**: Sharing discussion points beforehand prevents “deer in the headlights” moments where participants may not be ready to respond thoughtfully.
- **Encourage richer conversation**: When participants have time to reflect, meetings become more action-oriented and less reactive.

What's Changing With AI-Assisted Coding Interviews?

In this lesson we talk about the rise of AI-assisted coding interviews and how they are changing the technical interview landscape.

- **Understand the new AI-assisted coding interview format:** Learn how modern interviews place you in a lightweight codebase (not a blank file) with existing helper functions, tests, and to-dos—plus an integrated AI chat panel that can access and assist with your code.
- **Navigate increased problem complexity:** Explore how today’s interviews include more substantial starter code, realistic product requirements (e.g., time zones), and sometimes more advanced algorithms and data structures—reflecting real engineering work.
- **Collaborate effectively with AI while staying in control:** Discover best practices for using the built-in AI strategically, communicating your thinking clearly, and maintaining ownership of the solution in a rapidly evolving interview landscape.

Why Team Selection Is So Critical

We open by explaining that choosing the right company or team is one of the highest-leverage decisions we can make in our software engineering careers.

Here are the core points from the lesson:

- We use the “bus on a highway” analogy to show that company choice determines how far we can go; our personal effort only determines where we sit on that bus.
- Even if we perform exceptionally, joining a stagnant or declining company limits our long-term trajectory, while joining a fast-moving, hyper-growth company can accelerate our career dramatically.
- Real-world examples like Marin Software versus Google illustrate how picking the right “bus” can either stall or amplify career outcomes, independent of our individual contributions.

The Path To Career Success

Before diving into the pros and cons of Big Tech, we introduce two foundational career frameworks that offer different approaches to growth. These models help structure decision-making as one considers roles at large tech companies.

- **Explore vs. Exploit (David Epstein’s “Range”)**: In the early career stages, it’s valuable to gather a wide range of experiences—trying different roles or disciplines—to discover personal strengths and interests. This sampling period can lead to deeper, more informed commitments later.
- **Cultivate Passion through Skill (Cal Newport’s “So Good They Can’t Ignore You”)**: Rather than waiting to find a passion, pick a field and become excellent at it. Passion often emerges through mastery and impact in a chosen domain.
- Both frameworks offer valid paths and should be selected based on personal goals and life stage. The talk later connects these frameworks to the realities of working in Big Tech.

Control

In this final phase, we ensure that the gains achieved through improvements don’t erode over time. Control is about sustaining operational excellence, detecting deviations early, and building mechanisms—both human and automated—that keep the system performing at its best.

### Key Takeaways:

- **We implement control mechanisms to preserve gains**: Once we achieve desired service levels, we don’t assume they’ll stay that way. We actively maintain them through tools like regular audits, alarms, and ongoing data validation.
- **The Weekly Business Review (WBR) reinforces control**: Our WBR report includes 200–300 metrics. We review only the outliers, but by tracking all key indicators weekly, we maintain vigilance and are able to quickly detect when something goes off-course.
- **We rely on automation for precision and scalability**: From real-time alarms to machine-driven decision-making, we automate wherever possible. These systems are monitored to ensure they perform within tolerance thresholds.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Intro To Input Metrics

In this lesson, we explore what input metrics are, why they matter, and how shifting our focus from outputs to controllable inputs transformed the way we operated at Amazon. We learned—sometimes the hard way—that sustainable success comes not from chasing end results, but from rigorously managing the elements we directly control.

### Key Takeaways:

- **We learned to distinguish between input and output metrics**: Outputs like revenue or share price are lagging indicators and largely outside our direct control. In contrast, input metrics—customer-facing and operational—are controllable levers that drive those outputs.
- **We saw the importance of focusing on controllable inputs**: By investing resources in areas like software, marketing, operations, or process improvements, we influenced outcomes in a predictable and sustainable way. Examples include inventory record accuracy and marketing spend.
- **We realized the limitations of reactive output chasing**: Trying to salvage quarterly financials with last-minute promotions often distracted us from what truly mattered—improving the customer experience.
- **We began managing our business as a system of processes**: We stopped reacting to fire drills and started proactively measuring and optimizing the activities (inputs) that lead to better long-term results.
- **We gained a competitive edge through disciplined input tracking**: While most teams naturally measure outputs, few rigorously track inputs. By doing so, we developed a significant operational advantage that helped Amazon scale sustainably.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Gilad’s Take On Management

In this video, we explore the core responsibility of managers and define what great management truly entails. The speaker provides a clear, actionable definition of management and unpacks each part of it to guide us toward becoming more impactful leaders.

- We learn that **the essence of management is to create a positive and sustainable change in the organization’s performance**, a definition we are encouraged to internalize and apply.
- We embrace the idea that management is a **creative, proactive discipline**, not just a reactive one—our actions should be intentional and forward-looking.
- We are reminded that our impact must be **positive** and **lasting**, focusing on growing people and systems that perform well even in our absence.
- We are taught to focus on **creating deltas**, meaning our value lies in the improvement we drive, not in maintaining the status quo.
- We expand our view beyond just our teams, recognizing that **great managers influence the broader organization**, constantly looking for opportunities to elevate overall performance.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

Explanation Examples

In this extended segment, we see the CLEAR framework applied to real machine learning interview questions. Through examples, we’re shown how to craft strong, structured answers that go far beyond buzzwords or surface knowledge. This approach helps us communicate our understanding with clarity and depth.

- For a question like **"How do decision trees work?"**, we learn to walk through each part of CLEAR: define the concept, link to related ideas (e.g., random forests), provide real-world use cases, weigh pros and cons (e.g., interpretability vs. overfitting), and explain evaluation metrics (e.g., accuracy, RMSE).
- When comparing **CNNs vs. RNNs**, we avoid vague statements and instead explain each model’s core function, typical applications (e.g., image classification vs. time-series forecasting), and evaluation metrics, even including hybrid use cases for extra depth.
- For the common question **"How do you handle class imbalance?"**, we’re shown how to define the issue, link it to broader modeling challenges, provide realistic examples (e.g., fraud detection), explore trade-offs in techniques like resampling and reweighting, and select meaningful metrics like precision, recall, and AUC-ROC.
- We’re reminded that **bad answers often list jargon** without context or reasoning, while **great answers show structured thought**, connect theory to practice, and demonstrate the ability to make sound trade-offs.

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

You stayed calm. They still didn’t trust you.

You said nothing was wrong.\
But they felt something was off.

Here we explore what happens when teams can’t read you—and start reading into you.\
Not because you did anything wrong.\
But because silence always fills itself.

**Want to go deeper?**

- Explore more tools and courses at [**Taha’s Method**](https://www.tahasmethod.com/) — from interview prep to leadership development.

- Follow me on [**LinkedIn**](https://www.linkedin.com/in/tahahussain/) and subscribe to my weekly newsletter, [**The Conscious Leader**](https://tahahussain.substack.com/), for more lessons like these.

- Get 30% off [**Top Tech Leader**](https://bit.ly/tarotopleader) with code **ILOVETARO** (exclusive for Taro members).

You tried to be clear. They heard threat.

The words were fine.\
The logic was solid.\
The delivery? Unclear. At least to them.

This is the story of feedback that missed—badly—and why it had nothing to do with the message.\
You’ll walk into a moment that cost more than expected… and learn why it’s so common.

**Want to go deeper?**

- Explore more tools and courses at [**Taha’s Method**](https://www.tahasmethod.com/) — from interview prep to leadership development.

- Follow me on [**LinkedIn**](https://www.linkedin.com/in/tahahussain/) and subscribe to my weekly newsletter, [**The Conscious Leader**](https://tahahussain.substack.com/), for more lessons like these. 

- **Taro members get 30% off** my flagship course [**Top Tech Leader**](https://bit.ly/tarotopleader)*. Discount available later in the course.*

Become A Debugging Master [Part 13] - Create A Real Fix

Quick fixes are tempting, but true engineering excellence comes from addressing the real problem. Here are the core points from the lesson:

- A surface-level fix, like returning null to avoid an exception, hides the real issue and often leads to worse problems later
- Always stress-test your fix, check nearby features, and invite feedback instead of hoping a band-aid fix is “good enough”
- If you must land a short-term patch, clearly document it and create a task for a proper fix to maintain team trust
- Use the “Five Whys” method to dig deep into the root cause rather than stopping at the first obvious error

Become A Debugging Master [Part 12] - Take Breaks

Sometimes the smartest move when debugging isn’t pushing harder—it’s stepping away. Here are the core points from the lesson:

- Taking breaks is critical to avoid getting trapped in unproductive rabbit holes and to regain a fresh perspective on tough bugs
- If you haven’t made meaningful progress after an hour, switching tasks, taking a walk, or asking for help can prevent burnout and unlock new ideas
- Breaks scientifically boost memory consolidation, accuracy, and problem-solving by giving your brain time to process and connect scattered information
- Studies show staying awake too long severely impairs your mental performance, making rest essential for effective debugging and clear thinking

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.