Define

In this section, we explain how we at Amazon adopted the **DMAIC process**—a structured Six Sigma methodology—to bring clarity and control to our increasingly complex operations. This approach helped us stay focused on what drives business performance, even as we scaled globally and diversified our offerings.

### Key Takeaways:

- **We turned to Six Sigma to manage complexity**: As Amazon grew from a book retailer into a multi-product, international company, we needed a structured way to measure, monitor, and improve our processes. Six Sigma’s DMAIC framework offered exactly that.
- **DMAIC became our operational foundation**: The five steps—**Define, Measure, Analyze, Improve, Control**—allowed us to break down complex systems into manageable parts, identify input metrics, and drive improvements with precision.
- **We embraced Donald Wheeler’s philosophy**: Following his principle that understanding variation is key to improvement, we focused on how changing inputs affects outputs, aligning our culture around continuous improvement.
- **We built clarity into invisible systems**: Since much of Amazon’s operations (software, fulfillment, logistics) were either virtual or distant, we created standard definitions and measurements to make the system’s performance tangible and actionable.
- **We aligned every part of our system to inputs**: From product selection and pricing to software reliability and delivery speed, we learned that managing the inputs across all departments ultimately shaped our outputs like revenue and customer satisfaction.

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/>

Become An Engineer Influencer [Part 4] - Strategy #2: Social Media is a Sales Funnel

Master The DSA Interview [Part 16] - Alternate Approaches

The beautiful (and sometimes frustrating) thing about software engineering is that almost every technical problem has a ton of possible solutions. This lesson teaches you:

- Why being able to come up with alternate approaches is so important as a software engineer at the top level
- How to have a proper discussion with your interviewer about alternate approaches
- What a great alternate approach discussion looks like, discussed with an in-depth example

Dive deeper into real system design here: [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

How To Be An Effective Tech Lead [Part 9] - It's All About The Team

The best tech leads are selfless, not selfish. But what exactly does that mean? This lesson teaches you:

- The proper mindset to have as a tech **lead**
- A simple mental model to understand your overall goal as a tech leader
- How to divide up work as a tech lead
- What sort of tasks you should take on within a project as a tech lead

Nail Your Promotion As A Software Engineer [Part 27] - Writing Your Packet

You have gone through the entire performance review cycle and done a ton of amazing work. So how do you now capture all the great things you've done so you have a great shot at promotion? This lesson teaches you:

- How to make writing your self-review/promotion packet easy (hint: it requires following the advice of this course)
- When to start writing your performance review materials
- How to work with your engineering manager to optimize the quality of your promotion packet

Grow From Junior To Mid-Level Engineer [Part 16] - Show Your Work

It's not enough to do the work - You also need to do the work to get full credit for it. This lesson teaches you:

- The 2 big components behind showing your work properly
- The differences between junior engineers and mid-level engineers when it comes to showing their work
- How mid-level engineers give far more effective status updates compared to junior engineers, explained with an in-depth example

Learn how to write an excellent project update post here: ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

[Part 2] Software Engineer Onboarding: Learn the Workflow

To make the hard work easier, learn the workflow and process first.

**A big mistake new engineers make**: they dive in directly to a project and start landing code/landing impact. You goal is be curious about the testing and deployment procedures, along with the workflows and processes. One way to do this is to deliberately pick the simplest possible bugs and code changes to make, so you can exercise the workflow. 

- [Use Code Review Feedback For Hypergrowth](https://www.jointaro.com/lesson/aBRgdYpUfnUpoyWG4qZC/use-code-review-feedback-for-hypergrowth-meta-prodigy-engineer-story/)
- [How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/how-to-write-better-code-faster-as-a-software-engineer-11192022/)

This is part 2 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go to part 3 of the masterclass here](https://www.jointaro.com/lesson/7l4Nr4hQf8Pv8zfGZwh4/part-3-software-engineer-onboarding-understand-tactical-decisions/)
- [Go back to part 1 of the masterclass here.](https://www.jointaro.com/lesson/IYZRmwp33E3TBeFQFr9c/part-1-software-engineer-onboarding-embrace-your-lack-of-knowledge/)

[Part 4] Software Engineer Onboarding: Understand Strategic Decisions

Learn the business to make good strategic decisions.

By the time you're a month or more into your job, you should start execution on your projects, but you should continue gathering context about your team and company. You should document key decision points in your work, and reflect on who is involved, how long various steps take, and the level of detail various stakeholders ask for.

------

This is part 4 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go back to part 1 of the masterclass here](https://www.jointaro.com/lesson/IYZRmwp33E3TBeFQFr9c/part-1-software-engineer-onboarding-embrace-your-lack-of-knowledge/)
- Connect with Daniel Tomko on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Check out the [Formation.dev discount](https://www.jointaro.com/perks/) for Taro Premium members
- [How To Figure Out If A Team Is Important To A Company](https://www.jointaro.com/lesson/9OwPRwFFSMvEoVj6Zt5Q/how-to-figure-out-if-a-team-is-important-to-a-company/)
- [How To Find A Good Team With Career Growth Opportunities](https://www.jointaro.com/lesson/UGIUC9zaGccK0tOarBri/how-to-find-a-good-team-with-career-growth-opportunities/)
- [This Is How You Get Feedback - Making The Process Smooth](https://www.jointaro.com/lesson/aGuxjGbFjYb34ofhRxjs/this-is-how-you-get-feedback-making-the-process-smooth/)

The Five Pillars of Business

In this first module, we explore the essence of individual contributor roles through the lens of core business functions. This sets the stage for understanding how management fits into the bigger picture.

- We break down IC roles across the **five pillars of business** (from Josh Kaufman): value creation, marketing, sales, value delivery, and finance—clarifying how each function contributes.
- The **essence of software engineering** is to create value by building software that solves problems for customers.
- Marketing professionals focus on **raising awareness** of that value, while salespeople focus on **exchanging value**, usually closing deals.
- Roles in value delivery, like customer support or DevOps, ensure that users receive and benefit from the value created.
- Finance professionals ensure **business sustainability**, tracking what’s working financially and what isn’t.
- This clarity of purpose—knowing what success looks like—is often **missing in management**, which leads us to part two: defining the true essence of a manager’s role.

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)

What To Do If Your Manager Pings You Too Much

Receiving tons of interruptive messages or "can you take a quick look at this?" pings is something that every successful engineer must deal with.

The underlying cause of getting pinged too much by your manager is generally an indication that you're not effectively guarding your time.

A few options to consider:

- Understand the demands on your manager. Why do they feel the need to ping you so much? Do they not understand what you're doing, or perhaps they're facing a ton of pressure from their manager about high-pri bugs?
- Document how you're spending your time, and how that is making it harder for you to do the higher priority work.
- When you talk to your manager about the issue, bring up a proposed solution along with calling out the problem.

Related resources:

- ["How does one effectively handle pressure especially when the stakes are high?"](https://www.jointaro.com/question/Bxle0iRRpQXJV88KTpn4/how-does-one-effectively-handle-pressure-especially-when-the-stakes-are-high/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

[Become A Go-To Person 8/18] Other Ways To Develop Exptertise

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

Negotiation Course: Recognize The Information Asymmetry

First, let's make clear a harsh truth of the world: Companies are economically incentivized to pay you as little as possible, even if you think they're generous.

**You don’t get what you deserve, you get what you ask for.** Many candidates are unaware how high compensation can go, and therefore never ask about it. This leads to them being underpaid, and the information asymmetry is used to benefit the company.

Recruiters and companies talk to candidates every week or even every day. On the other hand, you probably only talk to a few companies every few years. So recruiters have way more information about what you’re likely making and what you may expect.

Come Up With 500k+ User Project Ideas [Part 6] - Your Idea Is Worthless (For Now)

While the idea behind a side project or any tech product is extremely important, ideas as a whole are usually placed on a pedestal they don't deserve. This lesson teaches you:

- Why ideas are initially worthless
- What truly makes a side project valuable (hint: it's not that much about the idea)
- Why you shouldn't build out the vision of that random MBA you just met for 0 pay and 10% equity

Negotiation Course: Negotiating With An Exploding Offer

An exploding offer is an offer that must be accepted within a time limit (potentially as short as a few hours), otherwise it will expire.

**Exploding offers are often fake** and you can take longer than the supposed deadline. However, you should protect yourself in the small chance that the explosion is real by having backup options.

If you face an exploding offer, the first step is to understand where the urgency is coming from:

> What’s the timing constraint? I’ve dedicated 3 weeks interviewing here and enjoyed meeting the team, but I'm curious why there's such an urgency at this point in the process?

A few options for how to request more time: 

- **(less effective)** Explain that you’re still collecting data and wrapping up the process so you’d like another week. Something like: "*I’m in the last round with the company so I’m confident I can get back to you by Monday.*"
- **(more effective)** Ask for more information. "*One thing I heard in the interview is that many of the mobile developers have transitioned to work on dev infra, which is interesting for me. Could I chat with someone who does made that transition?*" 
  - In a similar way, you can also request to chat with folks in the management chain, e.g. the director or VP.
  - When Rahul was at Meta, he’d do calls with people who got offers coming from Pinterest

Worst case scenario, you have to renege or quit shortly after joining. You should avoid this if possible (there is potential reputational damage), but we'll talk about this scenario in the next video.

Negotiation Course: How To Practice Negotiation Skills

Just like anything else, practice makes perfect. But conceptually understanding negotiation and practicing negotiation is very, very different.

Be aware of the difference in the incentives and working model between a job negotiation (once every 2 years) and your operational model on the job (every day).

- One (the job) is built on shared understanding, sharing vulnerability. There's a clear incentive to make life more comfortable for people around you.
- One (the negotiation) is **not** built on shared understanding. The person who wins is the person who can tolerate discomfort.

The upshot of all this is that negotiation is extremely important but you don’t get to practice much. Verbalize the advice and practice in conversation with a friend or family member.

Break Into Tech And Become A Software Engineer [Part 10] - Why It's Better To Share

In this lesson, Brian explains the value of building in public as a tool for personal accountability, skill development, and community building.

This lesson covers:

- How building in public holds you accountable to your goals and helps you communicate more effectively, a key skill for software development
- The importance of using public sharing to connect with like-minded people and build a supportive community
- Why building in public improves your discoverability and can lead to networking, job opportunities, and genuine collaboration

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Become A Debugging Master [Part 9] - Understand The End-To-End Flow

Most engineers waste time guessing at random fixes instead of methodically understanding the flow of what’s actually happening. Here are the core points from the lesson:

- Before you fix a bug, deeply understand the end-to-end flow, the intended behavior, and where reality deviates
- Avoid “blind fixes”—randomly adding things like null checks without fully identifying the root cause leads to fragile software
- Break down the system into smaller steps, narrow down the problem area through a process of elimination, and ask better questions based on where things fail
- Understand which components are involved, how they communicate, and what data formats they expect to quickly spot mismatches or errors
- Strong debuggers act like detectives: they map out the flow precisely, isolate the problem, and only fix after gaining clarity on why things broke

DSA Interview Step #1: Clarify The Problem

- The first step for any data structures and algorithms (DSA) problem is to *clarify the problem*. This means understanding exactly what the input and expected output are.
  - A common failure mode for candidates is that they will jump straight into coding, not doing this step. This leads to them wasting a lot of time writing code that isn't actually relevant.
- Often times in an interview, you will get a purposefully ambiguous problem - This happens with Big Tech a lot. The goal is get signal on the candidate's communication abilities.
- Clarifying the problem can help you *a lot* as it's very possible that the problem's scope is much more limited than you initially thought.

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [[Taro Top 10] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)

Grow From Senior To Staff Engineer [Part 19] - Code Machine

As a software engineer, one of your most powerful tools to land more impact is to write more code. While many engineers write less code as they grow to staff, there is 1 large exception. This lesson teaches you:

- What the code machine staff engineer archetype is
- Why the code machine archetype is quite rare and usually not supported
- How to become a code machine

As this lesson talks about, code machines have both a stunning degree of velocity and quality. Level up your code quality here: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

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.