I’m an engineer, but never really dug into how AI works. I use it every day, yet I feel so far away from the tech. A few weeks ago, I finally dove really deep to understand AI from the bottom up. Understanding its internals has helped make me far better at using it.

And I want to share those learnings with you.

This new series is called Unpacking AI.

A five-part series

This deep dive is a five-part series:

1. The Hardware Behind AI. Transistors, semiconductors, and fabricators. Learn about the big players (TSMC, Nvidia, ASML). The memory-compute bottleneck. And all the acronyms you always wondered about (TPU, ASIC, FPGA, CUDA, etc.)

2. Data & Model Architecture. Learn about what models are made of. We’ll cover the paper that started it all (”Attention is All You Need”), plus talk about transformers and diffusion models. And of course, we’ll cover how training data is prepared for these models (what sources? how is the data decontaminated and filtered?)

3. Training. The mechanics of teaching a model. How does pretraining work? What goes into it (backpropagation, optimizers, loss functions)? What scaling laws should we understand before we kick off an expensive training run (up to hundreds of millions $)?

4. Post-Training & Alignment. How does one guide a model once it’s been taught? How do we apply safety? How do we benchmark and know the model got better? How do we evaluate a model’s performance?

5. Inference, Serving and Agents. This might be the most familiar topic, since it’s closest to you as an AI user. How does a model output its token and serve the result to you (SSE)? How do systems stay fair and fast? What tools are available (MCP, RAG, tool use) and how do agents work?

Over the course of this series, I expect the syllabus to change as I learn more about AI. For sections with several acronyms, I also list their definition at the top of the section. I also welcome questions in the comments! This will help me improve this series.

Quick note: As much as I love using AI, this article and future ones will be written by hand, with light editing by AI. After all, we’re all too sick and tired of reading AI slop. Some images, however, will be generated by AI.

Transistors and Their Importance

To understand Artificial Intelligence, we first have to go to the core of it.

AI runs off GPU chips. These chips are made from transistors which are manufactured using EUV machines.

Let’s break each of these down, starting with a transistor.

A transistor is a semiconductor device that controls the flow of electricity. It uses a small electrical signal at one terminal to control a much larger current. It either (1) boosts a signal, or (2) decides whether a current can pass. In other words, it acts as either an amplifier or switch.

A semiconductor, most commonly silicon, is a material that conducts electricity only under certain conditions. Its conductivity can be modified by adding impurities.

Who designs these chips? Nvidia and AMD are the biggest players when it comes to designing chips. Not far behind are Google, Amazon and now Meta when it comes to chip design. However, these companies operate as “fabless” designers. That means they only build the architecture, while outsourcing the physical production to foundries, which can cost up to $20B to build and maintain.

Who then makes these transistors? TSMC (Taiwan Semiconductor Manufacturing Company) does. But they require special machines, called extreme ultraviolet (EUV) machines, and a process called lithography, which is the act of printing on chips. There are other foundries like Samsung and Intel, but they are not as advanced as TSMC, which currently holds 70% of the global foundry revenue.

Who makes these EUV machines? These are currently only being manufactured by ASML (Advanced Semiconductor Materials Lithography), a Dutch company that has a monopoly foothold in the EUV machine industry. China is fast catching up, but is still roughly 5 years behind.

Fun fact: there are no major competitors to ASML today. It took them 30 years to reach the stage they’re in today. They’ve integrated thousands of suppliers together to build a generator that fires 50,000 droplets per second. They also own the major company Cymer that makes these EUV sources. These light sources are so short (as short as 13.5nm) that there is no natural source for it.

OK, now we know what a transistor is and how it’s made. Now we can understand GPUs (graphics processing units). A single GPU contains billions of transistors, which are packed onto a die (a raw block of silicon) manufactured with various fabrication technologies.

We’ll now get into these different types of fabrication technologies.

Die Shrinks: Going from 10,000nm -> 2nm in 5 decades

Let’s take a quick history detour of die shrinks.

Why do we need a die to be smaller? Smaller features mean more transistors per square millimeter. This allows manufacturers like TSMC to pack more into each chip and build more capable chips. More cores, more cache and more tensor units. However, one point to note is that by building features smaller, this leads to more defects per wafer. As such, it isn’t necessarily cheaper to produce.

What’s the history of these dies and die shrinks? It’s complicated, but I’ll try to explain in a couple of paragraphs. The first microprocessor, the Intel 4004, was launched in 1971, at a 10µm process line width. This means that the gate length (distance between drain and source electrodes) was at 10µm. Which in turn means that electrons have to travel across this 10,000nm whenever a transistor switches on. A shorter gate = faster speed.

At that point in time (1971), this chip was designed for a Japanese calculator company, Busicom. However, once Intel realized that this was much more useful for the mass market, Intel repurchased the marketing and technology rights from Busicom.

A few years earlier, Gordon Moore made the observation you’ve heard of as Moore’s Law: that the number of transistors on a chip would keep doubling at low cost roughly every two years.

Over the next few decades, we went from 600nm → 250nm → 180nm → 130nm → 45nm. In the early 2000s, manufacturers hit a wall. There was no way to take the next jump and shorten gate length. However, a TSMC engineer named Burn-Jeng Lin had a breakthrough: adding water between the lens and the wafer. This was a huge bet by ASML in 2003-04, which was at that time a smaller European challenger behind Nikon and Canon. They went all in on immersion and won.

Nikon and Canon stuck to their guns on 157nm dry lithography, but by then it was too late. ASML had a huge head start. Canon essentially exited leading-edge lithography, and while Nikon did eventually build immersion tools, it never recovered its lead, and later sat out EUV entirely.

Today, your iPhones run on 3nm chips. GPUs today all use TSMC’s 5/4/3 nm variants. The state of development is currently at 2nm, and there’s targets to hit 1.6nm (TSMC’s “A16”) around late 2026–2027, with 1.4nm later and true 1nm not expected until the back half of the decade.

Unfortunately, one sad fact is that these numbers no longer mean gate lengths. They’re used more for marketing. The thing that actually improves is transistor density, measured in MTr/mm² (millions of transistors per square millimeter), and even that isn’t measured consistently across foundries.

The Shift from CPU to GPU

Let’s talk a bit about how GPUs got famous in the first place. It all started with the CPU.

CPUs have been in place since 1971, since the first microprocessor. However, when games like Quake were introduced in the 1990s, they lagged pretty badly while trying to render graphics. I remember my own computer grinding to a halt whenever I played intense games (DotA, anyone?).

Graphics accelerator cards were the answer. Instead of having a few sophisticated cores, you’d have thousands of dumb cores running in parallel. Each individual core is super weak, but when combined together in a GPU, the throughput is gigantic. These were great for games, since rendering a 4K image meant computing colors of 8M pixels independently. NVIDIA wasn’t the first to build these cards (other companies called 3dfx and ATI did), but they did coin the term GPU with the GeForce 256 in 1999.

Fast forward to 2006, Jensen Huang, CEO of NVIDIA made a huge bet. That Moore’s Law is slowing. Single-threaded CPU performance was not optimized for the long run. He wanted to build a programming platform for scientific computing on graphics cards. This bet was targeted at scientists who wanted access to supercomputers. At that point of time, these supercomputers were multi-million dollar machines only owned by government labs and a few corporations.

This bet was called CUDA (Compute Unified Device Architecture). This allowed the CPU to offload parallelized computing tasks from the CPU to the GPU. This ended up being their moat. The ecosystem (PyTorch, TensorFlow, which we will cover in later chapters) ended up being built CUDA-first. Silicon and networking was also specialized around this architecture.

The first hint of AI leveraging GPUs came about in 2012. Three University of Toronto researchers, Alex Krizhevsky, Ilya Sutskever and Geoffrey Hinton submitted a neural network called AlexNet. (You might start to know these names!) This was trained on two NVIDIA GTX 580 gaming GPUs in Alex’s bedroom.

This proved that GPUs were feasible to train deep neural networks for the first time. These neural networks, which were mostly based on matrix multiplication, were able to be achieved in someone’s bedroom. If the same neural net were to be trained on a CPU, it would have taken centuries.

If we were to compare a CPU (left) to a GPU (right):

Structure of an NVIDIA GPU

Now let’s take a look at a GPU.

Fair warning: it starts to get very technical from here on out. I will try my best to break it down.

The first is an overall view of the Blackwell GPUs (launched Q4 2024). This is not the latest chip architecture: Rubin R100 was recently announced and plans to ship in a few months. I could not seem to find a good infographic on R100, unfortunately, so let me know if you do.

Nevertheless, let’s examine the Blackwell Ultras, since this does give us a good sense of how it works end-to-end.

Here in Blackwell, we have 2 dies that have been welded together with a custom interconnect called NV-HBI. An interconnect is basically a physical wire linking two things together. In this case, NV-HBI is an ultra-low latency, proprietary die-to-die interconnect that powers 10 TB/s.

Now, let’s think of each die as a city. Each city contains:

1. 4 Graphics Processing Clusters (GPCs)

   A GPC is a district within the city. Think of it as a district housing a group of factories that share some local infrastructure to pass numbers around. Within a GPC, there are 20 SMs, which means that there are 80 SMs per die, and 160 SMs total across both dies. That’s a lot of compute power!

2. GigaThread Engine + MIG Control

   This is the city-level dispatcher. Its job is simple. It receives work from the CPU (through the PCIe Gen 6) and farms it out to the GPCs. The “MIG” part stands for Multi-Instance GPU, which lets the chip be sliced into up to 7 logical GPUs.

   Each of these GPUs looks isolated to different tenants, which is important for hyperscalers (e.g. AWS, Google Cloud) to run multiple customers on one physical chip.

3. L2 Cache

   We have 50MB of shared SRAM (static random-access memory) in each L2 cache. Remember, SRAM is expensive, fast to access RAM. This cache allows any SM to read what the other SM wrote.

   L0 and L1 caches are within the SM, which we’ll cover in the next section.

4. 8 HBM3E (High-Bandwidth Memory) stacks

   Surrounding the dies, we have these High-Bandwidth Memory (HBM) stacks. In order to build them, we stack DRAM (dynamic random-access memory), with 4 stacks per die.

   These DRAMs are connected by Through-Silicon Vias (TSVs), microscopic vertical wires drilled through the silicon, connected by an interposer which is a thin slab of silicon that sits beneath the GPU die and HBM stacks.

The ‘E’ in HBM3E stands for extended – a refresh of the HBM3. Only three companies in the world make the HBM: SK Hynix (~55% share), Micron and Samsung (~20% each). And the latest version, HBM4, is being sampled and is ramping up for NVIDIA’s Rubin.

On SRAM vs DRAM: SRAM uses 6 transistors per bit and holds its value as long as it’s powered on. It’s expensive since it’s bulky, but much faster. DRAM uses 1 transistor + 1 capacitor, but the whole array refreshes thousands of times per second. As such, SRAM lives on the GPU die which is closer to the GPC, and faster but more expensive. On the other hand, DRAM lives off the die. Both are however volatile, and data is lost once power gets cut. We’ll dive into this deeper during the memory-compute wall.

Last but not least, we have the I/O paths surrounding the image:

• NVLink v5 (1.8 TB/s) → connects to other GPUs via NVSwitch

• PCIe Gen 6 (256 GB/s) → connects to the host system

• NVLink-C2C (900 GB/s) → connects to a paired CPU coherently (e.g. for “superchips” like Grace+Blackwell combo).

Within a Streaming Multiprocessor

Now within a Graphical Processing Cluster (GPC), there are 20 Streaming Multiprocessors (SM). These SMs are the cores that people mention when they say a GPU has thousands of cores.

A Streaming Multiprocessor usually has the following:

• Small register file (fast storage)

• On-chip cache (shared memory between threads)

• Functional units that do math (CUDA cores, tensor cores, etc.)

Within an SM, the unit of execution is a warp. 32 threads that execute the same instruction simultaneously. A warp scheduler picks a ready warp every clock cycle and issues an instruction. A dispatch unit routes it to the right functional unit to do the math.

An interesting note: this way of routing instructions on an NVIDIA GPU is also known as SIMT (Single Instruction, Multiple Threads).

Let’s take a look at a concrete example - the Blackwell Ultra SM from above.

Each SM is split into 4 partitions, which are all done in parallel. Remember we mentioned that Blackwell Ultra has 160 of these SMs, so this means 640 partitions in total.

Diving into each part, from top to bottom:

1. L1 Instruction Cache
   This contains the recent instructions that are shared across all 4 partitions. If there’s an L0 miss, it hits the L1 Cache.

2. L0 Instruction Cache
   This is a super fast cache that sits next to the Warp Scheduler. When the warp scheduler needs the next instruction (aka what to do, be it a matmul or a different operation), it pulls from this.

3. Warp Scheduler
   This is the shift manager, where upon every clock cycle, it picks a warp (32 threads) and issues an instruction. Remember, this is a GPU here, so all 32 threads in the warp execute the same instruction simultaneously on different data.

4. Dispatch Unit
   The dispatch unit next to the Warp Scheduler helps to find the right execution unit. Now, there’s going to be different execution units for different purposes. A CUDA core is used for scalar operations (e.g. a multiply-add operation like 3 x 2 + 1), a Tensor Core is used for a matrix multiplication, and an SFU is used for transcendental functions (exponential, logarithmic, trigonometric, etc.).

5. Register File (64KB)
   This is the fastest possible storage. Registers are sitting physically adjacent to the execution units. And working values are kept here. This is used especially to tune performance. Keep note of this, as we will return to this when we talk about the memory-compute bottleneck.

6. CUDA Cores
   This is where work happens. Each partition contains an assortment of execution units here. FP32 refers to 32-bit floating point math, INT32 is for integer math, and FP64 is for scientific computing.

A key point to note here: every time a clock cycle happens, a CUDA core handles roughly one scalar operation (e.g. multiply-add) per cycle. This becomes important as we look to Tensor Cores.

7. Tensor Cores
   Remember how AlexNet was introduced in 2012? Everyone wanted to train neural networks after that happened. However, CUDA cores were limited to one multiply-add per clock. This is because they were for scalar arithmetic. Given that neural networks are matrix multiplications, there needed to be a different type of core. Which is how the Tensor Core was born.

   At GTC 2017 (Nvidia’s conference), the Volta V100 was launched, and the Tensor Core was introduced. It specialized in 4x4 matrix multiplication (matmul). That’s 64 multiply-adds per clock, already a 64x improvement! With each V100 SM handling 8 Tensor Cores, that was an insane amount of matmul work it could perform, roughly 125 TFLOPs.

   By the time Blackwell arrived, new floating points FP6 and FP4 were supported with adaptive precision selection. In layman’s terms, it was extremely powerful at 15 petaflops (10¹⁵) per second. This means 15 quadrillion (15 * 1015) floating operations per second.

   Again, this is all NVIDIA. We’ll take a look at other architectures like Google down the road. CUDA cores and Tensor Cores don’t exist outside of NVIDIA.

Gleaning over the next two: SFU - These Special Function Units help to take care of transcendental operations (sine, cosine, exponential, logarithm, softmax, math functions that cannot be represented by basic algebra). And LD/ST Units, which are in charge of moving data between registers and larger memory tiers.

8. Tensor Memory (TMEM) — 256 KB

New in Blackwell. A dedicated SRAM pool that is reserved exclusively for tensor (multi-dimensional scalar/vectors) operations. Used to stash work in progress instead of forcing data back to L1 Cache.

9. L1 Data Cache / Shared Memory — 256 KB (configurable)

Shared workshop SRAM that all 4 partitions can access.

Blackwell by the numbers

When you add it all up, a single Blackwell Ultra SM contains:

• 4 partitions

• 128 CUDA cores (32 × 4 partitions)

• 64 INT32 units, 64 FP64 units

• 4 fifth-generation Tensor Cores (1 per partition)

• 256 KB total register file (64 KB × 4 partitions)

• 256 KB Tensor Memory (new)

• 256 KB L1 / shared memory

• 4 Texture units

• 4 Warp Schedulers, 4 Dispatch Units

• L0 instruction caches per partition, shared L1 instruction cache for the whole SM

• LD/ST units, SFUs across all partitions

Multiply by 160 SMs on the full chip and you get the scale:

• ~20,480 FP32 CUDA cores total

• ~10,240 INT32, ~10,240 FP64

• 640 fifth-generation Tensor Cores

• ~15 PFLOPS of FP4 compute (!!)

• ~40 MB of TMEM across the chip (a new tier of on-die SRAM)

• ~40 MB of L1/shared memory

• ~100 MB of L2 cache (shared between the two dies, fully coherent)

Now that’s a lot! No wonder it costs around $30-40k for each GPU, as compared to a $700 consumer CPU or $10k datacenter CPU like the Xeon Platinum.

NVIDIA vs Google vs Others

Now let’s take a break from numbers and dissecting chips.

Let’s go back to learning history and understand who else is in this space. There are three other major players. AMD, Google and Amazon.

AMD sells chips called Instinct. Google rents TPUs, or Tensor Processing Units. And Amazon also rents their chips called Trainium/Inferentia, which are separate chips for training and inference.

There’s also Groq and Cerebras which are newer companies, formed in 2015/2016. You might have heard of Cerebras as the “first AI-era IPO”, and Groq as a company started by a former TPU engineer that has signed a non-exclusive licensing agreement with NVIDIA in 2025.

I won’t cover them here in this section in detail, but it’s worth checking them out. Groq bets on inference using a new LPU (Language Processing Unit), and Cerebras is making one huge chip to reduce interconnect tax.

Let’s put these four (NVIDIA, AMD, Google and Amazon) into a table and measure them up.

Anthropic is another interesting customer, because it’s serving Claude across both Google and AWS clouds. And of course, as of three weeks ago, Anthropic announced a deal with SpaceX to use all the compute capacity at xAI’s Colossus 1 in Memphis (300MW worth). This is spread across at least three silicon types now - AWS, Google Cloud and NVIDIA (the Colossus GPUs, from what was xAI).

Most of the history revolves around NVIDIA and Google. NVIDIA started at around 2006 with CUDA, and then Google started their TPU journey around 2013, before bringing them public around 2018.

NVIDIA

We’ll talk about launches within NVIDIA, since each of these are important and have interesting bets.

The italicized codenames refer to GPU architecture codenames.

• 2006: Launches Tesla with the CUDA architecture. This is the year where Jensen bet that parallel, individually weaker compute is going to be more important than large CPUs.

• 2010: Fermi improved the IEEE-754 floating point format, teaching computers how to do decimal/math operations. ECC memory was also a milestone here where this memory could detect single corrupt bits that could ruin the entire job.

• 2012: Kepler. CUDA core counts jumped to 1500. This was the year AlexNet was trained on two GTX 580s as well.

• 2017: Volta (V100). Each of these chips now has the first letter of their chip’s name, as well as 100, which means the most performant chips.

• 2020: Ampere (A100). 8-GPU server configurations were standardized here. New low-precision formats BF16 and TF32 were added here. Smaller numbers means each number takes less space, so you can move twice as many bytes per second when you halve the precision. Bandwidth increases. For neural networks, these were helpful.

• 2022: Hopper (H100): Named after Grace Hopper. FP8 native compute arrived via the Transformer Engine which made 8-bit training viable. A dedicated unit for bulk data movement called the Tensor Memory Accelerator (TMA) was also introduced.

• 2024: Blackwell (B200). These are dual dies that we talked about, and chips are now optimized for FP4 (4-bit floating point numerals).

• 2026: Rubin (R100) ← We are now here! A new 3rd gen transformer engine was introduced at GTC, NVIDIA’s yearly conference in March.

Google TPUs

Google’s TPU is built around a giant systolic matrix engine called MXU (Matrix Multiply Unit). The reason it’s called systolic is because it pumps data through the chip in rhythm, similar to the systole of a human heartbeat.

• 2013: Internal TPUs get developed. Silicons are spent mostly on a systolic matrix engine.

Each of these have different execution models:

• CPU → SIMD (single instruction, multiple data)

• GPU → SIMT (single instruction, multiple threads)

• TPU → Systolic

Of course, this might seem great for neural networks. However, remember that we are only looking at one thing that TPUs excel at, matmul. They’ve been heavily optimized for these matrix multiplication operations.

As good as these systolic arrays are for matmul, they are unsurprisingly weaker at others. They don’t do well at branching heavy logic, sparse workloads, and irregular control flows when it comes to GPUs. For instance, softmax, a very important function in neural networks, can run slower in a TPU than a GPU.

As such, Google added other separate specialized hardware blocks within TPUs called VPUs (Vector Processing Units), and Compilers to help with these other operations.

Alright, let’s finish the history of TPU.

• 2017: TPU v1 paper goes public, and proved that GPU was not the only way for ML going forward.

• 2018: v3. MXU is scaled up with liquid cooling. Starts opening to Google Cloud customers.

• 2021: v4. SparseCore (specialized engine for data dependent embeddings) and Optical Circuit Switching also launches.

• 2023: v5e and v5p both get launched. v5p is especially interesting since trillion-parameter training is finally launched with a 3D torus shape.

• 2024: Trillium (v6e). 4x the multiply-accumulate count with a smaller HBM on each chip. The goal here was to optimize for inference throughput and cost efficiency with less dependencies on chip memory.

• 2025: Ironwood (v7). 64x more chips in one domain.

• 2026: TPU 8t and 8i. This time, it follows AWS’s lead by separating training and inference chips, and leans on Broadcom and MediaTek to help implement these chips with TSMC.

If you are interested in diving deeper into TPUs, this is a really good guide.

AWS Trainium / Inferentia

In 2019, AWS realized that they were too dependent on NVIDIA, and for a hyperscaler their size, this wasn’t the best position to be in.

Given that Google had proved that hyperscalers could build ASICs, they started to build their own chips, starting with Inferentia (for inference). Inference means that the model applies its learned knowledge to return predictions and reply to user queries.

• 2019: Inferentia enters the market, marketed as “good enough for a cheaper price”.

• 2021: Trainium adds a new training chip.

• 2024: Trainium2 launches with 30-40% better price performance, with Anthropic as the main customer.

• 2025-2026: Trainium3 ships and processes over 50% of Bedrock’s token throughput. Provides up to 2.52 PetaFLOPs of FP8 compute.

Brief Segue into Floating Points & Numeral Formats

Traditional computing standardized around the FP32 (32-bit floating point) standard.

This was great for scientific computing and simulations. However, over time, research showed that neural networks could tolerate lower precision. Throughput also scaled like crazy with the reduction of bits. For instance a H100 chip can deliver 67 TFLOPs at FP32 and 3958 TFLOPs at FP8.

This kicked off a round of increasingly specialized numerical formats:

• FP32 → traditional scientific computing

• FP16 → early deep learning acceleration

• BF16 → wider exponent range for more stable training

• TF32 → NVIDIA’s Tensor Core optimized training format

• FP8 / FP4 → ultra-low precision formats optimized for modern large-scale inference.

This is how they look, in terms of bit length.

We’re currently at FP8 / FP4 with NVIDIA’s Rubin and Google’s TPU, continuously learning how low the number of bits an AI workload can tolerate. The art of performing this lossy compression is called quantization, where we are trying to reduce the memory footprint in order to increase inference speeds.

Interconnects

Before we jump into the final section, which I think is the most interesting problem of this piece, we need to talk about interconnects.

Why does it even matter? As GPU chips compute gradients during matmul operations, they need to share their gradients with each other. TPUs might have solved some of these problems with systolic operations, but that happens only within a chip.

To share these gradients, they use interconnects.

NVIDIA has a full interconnect stack strategy. We talked about most of these in the prior section.

• Within the chip: NV-HBI (NVIDIA’s High Bandwidth Interface) runs at 10 TB/s between the two dies.

• Chip-to-chip: NVLink 6 runs at 3.6TB/s for the Rubin series. Throughput roughly doubles every generation.

• Rack-to-rack: NVLink Switches enable dense communication.

• Server-to-server: InfiniBand owns this layer, which is built by Mellanox and acquired by NVIDIA in 2020. While InfiniBand still leads in terms of performance, Ethernet has been gaining rapid adoption by all the hyperscalers.

Whereas Google on the other hand takes a bit of a different approach (take note of their torus topology and OCS tech):

• Within the chip: No need for an interconnect

• Chip-to-chip: Inter-chip Interconnect (ICI): Runs at 9.6 terabytes / second. It uses a 3D torus topology which is a 3D lattice that loops back to itself. This is a lot cheaper at scale and given its twisted shape, every chip is connected to many others.

  • Optical Circuit Switching (OCS) is also a key innovation here that we mentioned earlier. At provision time, the interconnect topology can be rewired to match the workload.

Since we are on the topic of interconnects, it’s also important to look at what else is happening across the landscape. The two previously mentioned companies, Cerebras and Groq both specialize in their own ways. For Cerebras, they don’t believe in an interconnect. They’ve built one gigantic chip. Groq still uses interconnects, but avoids dynamic interconnect behavior. The compiler is the brain and schedules when/where data goes.

Furthermore, there’s also new technologies that are being developed:

• NVLink Fusion: Allowing third-party chips to plug into NVLink. Developed by NVIDIA.

• Ultra Ethernet: Open standard built by AMD, Microsoft, Meta. This competes with InfiniBand and NVLink. This is starting to take off.

• Optical I/O: Photonic chiplets and interposers that route signals as light instead of copper traces. Today signals leave chips electrically and need to be converted to light and then back. If we remove that conversion, the energy savings is massive. Ayar Labs and Lightmatter are two companies that are tackling this space.

Now that we understand interconnects better, we’ll talk about the biggest problem that GPUs have faced for a while: the memory-bandwidth.

The Biggest Issue: Memory Bandwidth

While GPU floating-point ops (aka compute) have been scaling exponentially every few years, memory bandwidth has not kept up. Memory Bandwidth = the speed at which data travels between the GPU chip and memory banks. This is now too slow.

So what? Well, this leads to underutilized compute on the GPU (meaning that you’re not getting the most of what you’re paying for). Let’s take a look at how this hasn’t kept up.

Rooflines and Arithmetic Intensity

Before we dive in further, we need to know what rooflines are. Roofline models help us understand whether an algorithm is memory bound or compute bound.

Let’s take a fictitious example. Say your chip is a kitchen. Your chef is your compute (e.g. GPU cluster). It can perform 1000 TFLOP/s (teraflops) of knife work. The runner who ferries ingredients to and from the kitchen is your memory bandwidth, where it has 2TB/s of legs sprinting to the pantry (HBM) and back.

Is your kitchen limited by chef speed or runner speed? To do that, we need to calculate the peak compute: 1000 TFLOP/s ÷ 2 TB/s = 500 operations per byte fetched. This means that recipes that do more than 500 things with each byte (e.g. ingredient) are bottlenecked by the chef. Less than that, and it’s bottlenecked by the runner.

Here’s a real example with a graph. A chip that can do 1000 TFLop/s of compute and pull 2TB/s from memory (bandwidth), the arithmetic intensity is calculated as 1,000 ÷ 2 = 500 FLOPs per byte. This means that if your algorithm’s Arithmetic Intensity is below 500, you’re bandwidth bound (limited by how fast you can move tensors). If its Arithmetic Intensity is above 500, you’re compute bound. I’ll refrain from turning Arithmetic Intensity into an acronym, well... because it’s also AI.

Now we have two algorithms, Algo 1 and Algo 2.

Algo 1: Matrix × one vector: Multiply a 10,000 x 10,000 matrix by a vector of 10,000 length.

• Math done: 2 × 10,000 × 10,000 = 200 million FLOPs

  • Each output entry is a dot product of length 10,000 (one multiply + one add per pair), and the output has 10,000 entries.

• Data read: 10,000 × 10,000 × 2 bytes = 200 MB

• Arithmetic Intensity = 200M ÷ 200M = 1 FLOP/byte

1 is way below the ridge of 500, so it’s bandwidth-bound. Each number you load gets used exactly once, so there’s no way to climb. Actual speed ≈ 1 × 2 TB/s = 2 TFLOP/s. This is just 0.2% of the chip’s peak. This means that the chip is mostly sitting idle waiting for memory. What a waste!

Algo 2: Matrix × matrix. Multiply a 10,000 x 10,000 matrix by another.

• Math done: 2 × 10,000 × 10,000 × 10,000 = 2 trillion FLOPs

  • Each output entry is a dot product of length 10,000 (one multiply + one add per pair), and the output has 10,000 × 10,000 entries.

• Data read: 2 × 200 MB = 400 MB

• Arithmetic Intensity = 2T ÷ 400M = 5,000 FLOPs/byte

Now, 5,000 is well past the ridge of 500, so it’s compute-bound and runs at the peak compute full 1,000 TFLOP/s. It’s the same matrix, but now every number you load gets reused thousands of times, so memory keeps up easily and the chip stays busy.

Solving Memory Bandwidth

All the above architecture that we studied helps to address this memory bandwidth issue: large amounts of SRAM, L1-2 caches, quantization (remember the floating point stuff?) provides fewer bytes to move and cheaper compute, interconnects (NVLink, etc.), and moving memory as close to compute as possible.

However, the most direct method to solve memory bandwidth is the bus itself. By making memory faster. Enter HBM (High-Bandwidth Memory). Co-developed by AMD and SK Hynix starting in 2008, and first shipping in 2015, HBM uses the same DRAM chips that have powered servers for decades. Except, it’s now just rearranged.

Instead of laying chips flat on a motherboard, you stack 8 or 12 of them vertically into a single tower, drill thousands of microscopic wires (called TSVs, or through-silicon vias) straight up through the stack, and place the whole thing on a silicon interposer right next to the GPU.

Looking to the Future

One interesting paper, by Xiaoyu Ma and David Patterson, shares more about four new research areas to address these memory and interconnect issues. I’d advise checking out the paper if you have time. They propose four different hardware shifts, and I’ll try my best to dissect them, though the paper does a much better job:

1. High-bandwidth Flash: stack NAND flash instead of DRAM. With HBM, you can only stack so much DRAM before heat and cost accumulates. Flash is cheaper, denser and its capacity keeps doubling. However Flash has its own write-endurance limits, but is useful for data that’s written rarely and read enormously (like model weights!)

2. Processing-near memory (PNM): For datacenter LLM inference, it seems that shards with PNM can be 1000x larger, which would allow these partitions to have a low communication overhead. With processing-in-memory (PIM), arithmetic units inside DRAM means (1) weak compute since these units are fabricated for DRAM and (2) creation of many shards which creates a lot of communication overhead.

3. 3D memory-logic stacking: In 2D solutions, the HBM sits besides the processor. This means that the memory bandwidth is capped by how much edge the logic die has. As the area grows quadratically, the shoreline only grows linearly. With 3D stacking, it runs the entire 2D area of the die, which allows bandwidth to scale with area quadratically instead of with the perimeter. Seems like an interesting proposition.

4. Low-latency interconnect. Build topologies inspired by tori with high connectivity. Reduce work outside of the chip network and process within the network. Optimize chip design that lands small packets directly into SRAM. Improve reliability through local standby spares and accepting good enough results. Again, more details in the paper that I can’t cover in a short paragraph.

   Found this helpful? Subscribe to make sure you don’t miss the rest of the Unpacking AI series.

Five things to remember

Now that was a lengthy piece. If there’s five things I want you to remember:

1. It all comes back to one problem: Memory Bandwidth. We just covered this. Compute has gotten much faster than memory could feed it (see the memory wall picture above). Every acronym in this piece (HBM, SRAM, NVLink, quantization, 3D stacking) is an attempt to shrink the distance between the two.

2. Three companies have a strong dependency chain on each other. Designers like NVIDIA hand a blueprint to TSMC (~70% of all global foundry revenue), which can’t print it without ASML’s EUV machines (a literal monopoly). Each of these three companies forms a strong dependency chain.

3. “nm” is mostly marketing now. We went from 10,000nm to 2nm, and the transistors got faster and denser the whole way. But shrinking the chip was never going to fix the memory gap. If anything it made all that compute capacity harder to feed.

4. NVIDIA and Google answer the same question differently. NVIDIA asks how to make each thread more productive (CUDA, Tensor Cores). Google asks how to keep the whole grid fed (using systolic arrays that reduce trips to memory). Both are interesting strategies and we’ll see how they turn out over the next few years.

5. The roofline tells you which side of the wall you’re on. In order to know if your algorithm is starved for memory, work out its arithmetic intensity: how many operations you do per byte loaded. You’re either compute-bound or memory-bound.

That’s it! You made it to the end of the first part of this series.

Stay tuned for Part Two: Data & Model Architecture in a couple of weeks. In that piece, I plan to cover the paper that started it all (“Attention is All You Need”), plus talk about transformers and diffusion models.

Thanks for making it to the end.

I know this is very different from the pieces I’d normally write, so I’d appreciate feedback and comments. What did you like? What would you like to see? If you’ve enjoyed it, please share and subscribe if you haven’t.

Thank you to Sai and Rahul, who work at NVIDIA and Google, for proofreading this article.

Further Reading

1. horace.io/brrr_intro: Quintessential piece if you want to learn more about memory bandwidth.

2. Mainz on X: A fabulous article on X that I came across. Helped me put things into perspective.

3. The JAX Scaling Book: Comprehensive guide on scaling models.

4. The Roofline Model: Research from Berkeley if you want to learn more about the Roofline models.

But product sense alone won’t get you to Staff. The engineers I’ve seen get promoted understand something most frameworks skip entirely: Business Sense - how the business actually works.

This week, we have sharing more about business sense. Hannah leads AI-powered new bets at DoorDash and is the creator of In the Weeds, a newsletter that helps non-technical professionals build AI fluency and adopt AI-native workflows. Her flagship series, Claude Code for Everything, has helped more than 90,000 people get up and running with Claude Code. If you haven’t checked it out, do so!

Without further ado, here’s Hannah.

Product sense won’t help you if you don’t understand the business

In my experience as a PM, the engineers who deliver the most impact aren’t just good at product thinking. They also deeply understand how the business works - the business model and current business priorities, what the competitive landscape looks like, and which metrics matter at the current point in time. That’s business sense - a skill engineers need now more than ever.

The demand for business sense is already visible in the PM job market. Lenny Rachitsky’s data shows 6,000+ open PM roles globally, with the hiring bar rising and junior roles declining fastest. Companies are hiring aggressively for seasoned product leaders who can both identify the right business problems to solve and bring productized solutions to these problems to market. However, given the pace at which engineers are now able to build and ship product, there is not enough available PM supply to meet the demand for this skillset.

Anthropic, Cursor, and OpenAI already run with higher engineer-to-PM ratios than comparably-sized tech companies did a decade ago. As a result, decisions that used to sit squarely with PMs now need to be able to be made within engineering. As engineers take end-to-end ownership of product development, the ability to identify the most critical problems to solve for the business becomes a key differentiator and a way for engineers to create leverage both for themselves and for the business.

Shreyas Doshi, a product leader formerly at Stripe and Twitter, wrote a widely-read piece arguing that product sense is the defining skill of the AI age. He breaks product sense into five components: empathy, domain knowledge, product thinking, taste, and strategic thinking. But I’d argue engineers need more than just product sense. Engineers need business sense. Product sense is about what to build. Business sense is about why it matters to the business.

Without the why, the what is just good taste without generating leverage for the business. You can have strong product intuition - such as spotting good UX, sensing when a flow feels off, or identifying confusing interaction patterns - without understanding how your company makes money, what the unit economics look like, or who you’re competing against. Strategic thinking, the fifth component in Shreyas’s framework, actually requires deep business sense.

The best engineers I’ve worked with start with the business problem.

What lever are we trying to move and why is this the particular lever we’re targeting out of all potential levers?

What makes these engineers’ inputs unique is that they can spot the highest-leverage directions and the fastest path to get there. They suggest a scrappier version of the idea that ships in a quarter instead of a year or an implementation sequencing that front-loads the work required to derisk a business hypothesis. This unique combination of business sense paired with technical sense is one of the fastest ways to move a business forward, and propels an engineer to be most sought after in today’s market.

Business Sense 101

Every company operates in a constantly changing environment - competitors launch, customer behavior shifts, and operating costs move up or down. The moves that made sense a quarter ago can quietly become the wrong bets today.

Business sense allows you to use the changing business landscape to inform the right product investments to make at a given point in time.

The four components of business sense are:

1. How a company makes money: What generates revenue, how much / what does it take to generate revenue, and does each unit turn a profit?

2. Business model fluency: What kind of business are you in? How does that shape what’s worth building?

3. Market sizing: Is the opportunity big enough to matter?

4. Competitive landscape and right to win: Who else is going after this market and why should your company be the one to win?

How a company makes money: Know what moves the needle

A company’s P&L (profit and loss statement) shows how money flows through the business - revenue in, cost out, and profit left over. Underneath the P&L, unit economics measure revenue and costs per unit of your business. Common units include customers, orders, or transactions. Unit economics also measure the profitability of a unit - whether each unit generates more revenue than it costs to produce or serve.

The metrics you’ll see most often in subscription, marketplace, and transaction-based businesses are:

• CLV (Customer Lifetime Value): The total profit a customer generates over their full relationship with the company - revenue minus the cost to serve them.

• CAC (Customer Acquisition Cost): The cost to acquire one new customer - marketing spend, sales effort, onboarding - divided by new customers acquired.

• Payback period: How long it takes to earn back the CAC from a new customer.

• ARPU (Average Revenue Per User): How much revenue each active user generates in a given period. Useful for comparing segments or tracking monetization over time.

• Churn rate: The percentage of customers who leave in a given period. Churn is often the biggest single input into CLV - a small change in churn can dramatically change lifetime value.

Let’s do an example.

Say you’re on a product team at Instacart debating between two features: one that improves shopper retention and one that increases average basket size. Both have the potential to be great features that delight shoppers and consumers. The question isn’t whether these are good feature ideas but rather which idea is the best investment for Instacart right now. Answering this question requires understanding how Instacart makes money. By sizing out the projected revenue from each feature net of costs, one feature will ultimately come out ahead.

From my experience, there are always more good products that exist than any team has time to build (even on the most AI-pilled teams) and business sense is the skill of picking the one that will actually move the business.

Business model fluency: Your business model shapes what you build

Once you understand how your company makes money, the next layer of business sense is knowing what kind of business you’re in. Different business models create different incentives and constraints, which shape what’s worth building in the first place. The five models you’ll see most often in tech:

Pricing models are conceptually different from business models. Freemium, tiered plans, and usage-based pricing often get called business models but they’re not. A business model answers how does the company fundamentally make money? A pricing model answers how do we charge customers for it?

Spotify is a subscription business with a freemium pricing model for customer acquisition. Slack is a SaaS business with usage-based overages on seats. Strip the pricing mechanics away and the underlying model is unchanged - Spotify still sells recurring access to music, Slack still sells seats with software access.

The business model determines how to measure success for a given feature. A recommendation engine in a SaaS product optimizes for stickiness and reduced churn. The same engine in an advertising business drives time on site. In a marketplace, the same engine drives transaction volume. If you don’t know how your business makes money, you’ll optimize for the wrong outcome.

Market sizing: Identifying opportunities worth investing in

Market sizing is how you figure out if an opportunity merits investment. The basic math: how many customers could we sell this to and how much would they pay? Sizing isn’t only for whole markets.

The same discipline applies to prioritizing product features on a roadmap and to pitching technical investments like a platform rewrite or an infra migration. Every sizing exercise comes back to the same question: how much return does this investment generate, relative to the alternatives and relative to what the business cares about right now?

The biggest version of sizing is at the market level - should a company invest in this market at all? A famous example is Uber.

In 2009, UberCab’s seed pitch estimated a $4B TAM (Total Addressable Market) based on the existing black car and taxi market. Uber investor Bill Gurley argued this number was off by 75x - when you materially improve an offering (sub-5-minute pickups, cashless payments, suburban coverage), you expand the market rather than just compete in the existing one. He estimated the real TAM at $300B+ after including the potential for car ownership displacement in the evaluation. The question changed from “should we build a luxury dispatch app?” to “should we invest in displacing car ownership?” While the original pitch sized the existing taxi and black car market, the ultimate investment decision sized the expanded market of car ownership displacement.

In practice, you’ll rarely be sizing entire markets. Instead, you’ll more often see sizing applied to product features and technical investments your team is weighing for the product roadmap. At this level, the goal of sizing is to understand which bets are most likely to deliver against the current business priorities.

The sequence matters. Business priorities (set by what’s happening in the landscape) tell you which problems need investment this quarter. Sizing then tells you which candidate solutions are the best bets against those problems.

Imagine you’re on Uber’s product team in 2018 and are getting ready for quarterly planning. Pretend the most pressing business problem is that Uber is losing drivers to Lyft, creating a driver supply shortage. The team brainstorms every way to grow driver supply: a driver-onboarding redesign, faster payouts, referral bonuses, retention incentives, and shift-flexibility features. Each gets sized - how much new supply it adds, at what cost, relative to the alternatives. The features that are sized highest get funded. Features that don’t move driver supply, e.g. rider retention notifications, surge-pricing tweaks, are left behind.

Priority tells you which problem areas matter right now and require investment to solve (and need various shots-on-goal to be sized). Sizing tells you the expected return on a given investment.

Competitive landscape: You need to know how your company wins

Your competitive landscape is the set of companies chasing the same customer dollar you are. Understanding the competitive landscape means you can answer the following questions:

1. Who are our real competitors - direct, indirect, and the alternatives customers use to avoid buying the product at all?

2. What is each competitor actually good at and what are they investing in next?

3. When a customer picks us over them (or them over us), what’s the deciding factor?

4. Where are we winning? Where are we losing ground?

5. What’s our moat - the thing competitors can’t easily copy?

6. Where is the market moving and who’s positioned for where it’s going?

Your competitive landscape is another input into what your team should build. The landscape tells you what kind of problem you’re actually facing - whether you’re losing on price, distribution, a feature gap, or a market shift. That diagnosis determines which investments matter. Without it, product investments land in the wrong place - polishing strengths instead of shoring up where you’re losing or doubling down on today’s position when the market is shifting.

Understanding your moat is one of the most important inputs into product strategy. Your moat is a structural advantage in winning customers or keeping them - the thing competitors can’t easily copy. Good product strategy either reinforces the moat you have or builds new ones. Most companies win on one of five common moats:

Using your moat to shape your product strategy helps your company win. Stripe and Microsoft each won a market by anchoring product strategy to a particular moat. Stripe won based on switching costs and Microsoft Teams won based on distribution.

Switching costs: Stripe. When Stripe launched in 2011, the incumbent payment processors had working products and massive distribution. What they didn’t have was developer experience. Stripe diagnosed developer experience as the unguarded flank. That moat shaped the product strategy: clean APIs, beautiful docs, and integration in hours instead of weeks. Switching costs built up in developer habit. Once a team shipped on Stripe, rewriting an integration for a legacy processor was unthinkable.

Distribution: Microsoft Teams. When Microsoft launched Teams in 2016, Slack was the dominant workplace messaging tool with a genuinely better product. Microsoft played to the moat it already had - distribution. That moat shaped Teams’ product strategy. Teams shipped bundled free with Microsoft 365, which already sat on 345 million existing seats. Product investment doubled down on the moat: deep Office 365 integrations, admin-friendly deployment, and compliance controls that made Teams the default for enterprise IT. By 2020, Teams had 320 million daily active users (DAUs) vs. Slack’s 42 million.

In each case, the moat shaped the product strategy. The product strategy won the market.

How to actually build business sense

You don’t need an MBA, a class, or a certification to build business sense. Try one of these three things this week:

1. Trace your team’s metrics to the P&L. Look at your team’s OKRs or success metrics and follow the thread to a business outcome - revenue, retention, or cost reduction. If you get stuck, ask your PM or an ops partner to help you connect the dots.

2. Attend one business review. Just listen. Jot down any term or metric you don’t recognize, then look it up or ask someone who was in the room. (Sidwyn’s pro-tip: Ask to be invited to leadership review to be a “fly on the wall”, stating that you are just there to learn. More often than not, you’ll be welcome.)

3. Read the financials. If you work at a public company, you’re in luck. A 10-K is the annual report a public company files with the SEC, laying out revenue, costs, risks, and strategy in plain English. Find yours on the investor relations page of the company website or on SEC.gov. At a private company, ask someone in a business-facing role - finance, strategy, ops, or sales - for 30 minutes to walk you through the P&L. In my experience, business partners are happy to give a P&L walkthrough to partner engineering teams.

Pro tip: Drop a 10-K or earnings call transcript into NotebookLM (Google’s AI research assistant) and have it generate a podcast. Listen on your commute - way easier than reading financials at your desk.

Apply the framework to one company

Run this exercise on your own product and company or a company you’re curious about. Answer four questions:

1. How does this company make money?

2. What’s the business model? What are the key levers?

3. How big is the market?

4. Who are the competitors? What’s the right to win?

Want to go deeper?

This article covers the four components of business sense you’ll use in most engineering decisions. If you want to keep going, the resources below are worth reading, organized by topic.

Revenue & financials:

• SEC’s How to Read a 10-K: The SEC’s own walkthrough. Plain English. Start here if you’ve never opened a 10-K.

• Professor Damodaran’s 10-K video: 43-minute video walkthrough of Procter & Gamble’s actual 10-K. If you watch one walkthrough, make it this one.

• Public.com’s earnings call guide: The most beginner-friendly explainer I’ve found. Good for the first earnings call you try to follow along with.

Market sizing:

• Bill Gurley, “How to Miss By a Mile”: The Uber TAM rebuttal. The famous argument that sizing a market correctly can turn a $4B idea into a $300B one.

• Sequoia, “The Market Curve”: A simple quantitative framework with real company examples mapped onto a curve. Cuts through TAM hand-waving.

Competitive landscape:

• Gibson Biddle, “The DHM Model”: “Delight customers in Hard-to-copy, Margin-enhancing ways.” Uses Netflix as a running case study.

• Cascade, “Porter’s Five Forces”: 15-minute read with tech examples throughout. Good if you want the framework without the 15-week MBA version.

Danny sat on dozens of promo committees, particularly for the Senior → Staff jump for ICs. What he saw in those rooms is not what most engineers expect. I personally enjoyed this piece a lot because he uses an analogy to flying a plane. It makes the invisible mechanics of promo committees feel tangible in a way that most career advice doesn't. I hope it's as helpful for you as it was for me.

Without further ado, here’s Danny.

Read more

Last week, he wrote The Adolescence of Technology. In it, he shares his thoughts on the risks of Powerful AI and what it takes for humanity to overcome them. If you have time (~2 hours) this weekend, I strongly suggest giving it a read.

This essay is a follow-up to his previous Machines of Loving Grace, which is also a great read.

Given the length of this latest essay, I’ll summarize the relevant key points here. In the second half of this post, I’ll share my thoughts on what roles & skills are needed for software engineers in a post-AI world.

Powerful AI = Country of Geniuses

First off, Dario talks a lot about the safety of AI. This is in line with why he started Anthropic with six others in the first place. He is most concerned about how AI can get dangerous if left unchecked. He’s also wr…

Read more

If you like shorter-form content, I have also been recently writing more over on Threads and X, on top of LinkedIn, so be sure to follow me there.

Read more

We’re only a few weeks into 2026, but Big Tech already looks shaky. Meta laid off 1,500 people, many of them I’ve personally worked with. Amazon is reportedly cutting up to 30,000 jobs, and Microsoft is letting go of 22,000 folks this month.

If you’ve been impacted by layoffs or expect them, here’s my learnings from going through multiple layoff rounds at Meta.

Read more

Today, I want to share a framework that has completely changed how I run technical reviews —meetings where senior engineers come together to evaluate a decision and align on a direction.

A 1-minute story:

Early on in my career, I scheduled a technical review for a design I had been working on for weeks. I was proud of it, and I wanted feedback from smart people. So I invited eight of them: engineers from adjacent teams, a PM, a tech lead. More eyes, better feedback, right?

The meeting started. I pulled up my document and began walking through it.

People started reading along. Then the questions came. Then the critiques. Someone in the back raised a concern about my approach in section two. Someone else wanted to revisit the problem statement entirely. A third person was still on page one and asking me to slow down.

Given that I only budgeted 30 mins, we quickly ran out of time. And guess what: No decision was made. I left with a pile of conflicting feedback and no idea what to do next.

I was disappointed, both with how the review went and myself for not planning properly. The worst part was feeling that I had wasted the time of eight busy people who probably had better things to do that hour. Should I have sent the doc async instead? Should I have kept the meeting shorter? Should I have invited fewer people?

After trial and error over a decade, I realized the trick to these reviews isn’t whether to write or meet.

The question is how to sequence them.

For any technical decision that matters, you almost always need both. The key is doing them in the right order, with the right structure in between.

Let me walk you through how I think about this.

The Framework: Write First, Meet Second

The best technical reviews that I’ve participated in, both as a presenter and as a reviewer, follow a consistent pattern:

1. Write a focused document: This should lay out the problem, the options, and your recommendation. Keep it to three or four pages. Any longer and people won’t read it. Any shorter and you probably don’t need a meeting at all.

2. Add an alignment table at the top where reviewers can signal their stance before the meeting. Something simple: their name, whether they agree or have concerns, and any key questions. This gives you a read on the room before you even walk in.

3. Send it as a pre-read one to two days before the meeting. This timing is important, and I’ll explain why in a moment.

4. Use the meeting to resolve, and not to review. If everyone has read the doc and left comments, you don’t need to present anything. Go straight to the open questions. I typically like to lead in by saying, “Alright, since everyone has had a chance to read this document ahead of time, we will go over a few of these comments in the doc.” Use the time to drive toward a decision.

Just implementing these four steps will already do wonders for your review.

Why Timing Matters

I mentioned that one to two days is the sweet spot for sending out a pre-read. Here’s why.

If you send it too late, people won’t have time to read it. They’ll show up cold, and you’ll end up doing what I did in that first disastrous meeting: reading the doc together in real time, fielding questions as they pop up, running out of time before anything gets decided.

If you send it too early, people will forget. They’ll skim it on Monday, the meeting lands on Friday, and by then they’ve lost all context. You’ll spend the first ten minutes re-orienting everyone anyway. I’ve done this too many times to count.

One to two days gives people enough time to read and comment, without so much time that it falls off their radar. I’ve found this window works well even for busy reviewers. This means your ideal review day should not be Monday or Tuesday, since folks are not going to be remembering what you sent them on Friday.

What Makes This Fail

Even with this framework, things can go wrong. Here are a few failure modes I’ve seen:

The doc is too sparse. Make sure your doc is substantive enough that it invites real feedback. No one wants to be the first to leave a critical comment on something that looks half-baked.

The reviewers are too senior. This one surprised me. If you invite people who are two or three levels above you, they often won’t comment ahead of time. They’ll wait for the meeting to weigh in. The best reviewers are usually plus or minus one level from you. Close enough to the work to engage meaningfully, but senior enough to offer useful perspective. This is what’s worked well for me.

Too many people in the room. The more people you invite, the harder it is to drive toward a decision. Everyone has something to say, and the conversation spirals. Keep the invite list tight. If someone just needs to stay informed, send them the doc afterward. Don’t invite them to the meeting.

Forgetting to recap decisions and action items. After the meeting, you need to make sure you recap the action items from the decision meeting. This doesn’t have to be complicated and can be as simple as this:

TLDR:

That’s it! Here’s the quick summary so you can stop running reviews that waste everyone’s time:

• Write, then meet. To make meaningful decisions, you first need to jot down your ideas on paper. Write first, meet second, and decide together.

• Write a 3-4 page doc with a clear recommendation and add a comment table at the top for reviewers to signal their stance.

• Send it 1-2 days before the meeting. Not too early, not too late. This gives folks enough time to understand what you’re asking them to weigh in on.

• Use the meeting to resolve open questions, not to walk through the doc.

• Watch out for failure modes: docs that are too sparse, reviewers who are too senior, and meetings with too many people, forgetting to recap.

One more thing: this framework applies to bigger decisions, the kind that need multiple reviewers and a formal meeting. For simpler decisions, a quick call or Slack thread is often the right move. Knowing when a decision is “big enough” for this process versus when you should just hop on a quick sync is nuanced, and I’ll write more about that distinction in a future post.

If you enjoyed this, check out the other posts in the Mastering Communication series: Part 1: How to Deliver Value Every Time and Part 2: Make Hard Choices Easy to Understand.

Read more

This first part covers how to deliver value to your audience when communicating. Value in this case means providing useful information or takeaways that allow a concrete action to happen. Examples include a project signoff, strategy alignment, or a ship / no-ship decision.

Why Communicate Value?

I strongly believe that:

1. Your reputation is silently based on how you communicate: People judge you on whether you make their time feel well-spent. They will listen if you communicate value to them. And they will talk about you.

2. Most technical problems masquerade as people problems. I saw this on Hacker News the other week, and highly agree. As you level up, learning how to work with others is key. Communicating the importance of your work to others is how you earn their buy-in.

3. Impact is directly driven by value. Clear communication drives alignment, better decisions and ultimately positive outco…

Read more

I get this question all the time: “How do I get to Staff Engineer quickly? How do I level up fast?” The idea of jumping from junior to staff in a few years sounds exciting (and I did it myself!), but there are also real reasons why you shouldn’t rush.

In today’s job market, promotions are both slower and rarer. Companies have the upper hand now, and employees are staying longer than before. When companies conduct layoffs, their internal talent pool shrinks, and now you’re competing with even stronger candidates (assuming you weren’t laid off).

It’s tough to feel stuck. Some days, I do too. But as I’ve reflected more over the past few years, I’ll share why growing too fast can work against you, and what you can do today if you feel like growth has stalled.

Read more

Here’s a scene revolving around an incident:

Team A’s Engineer: “Your service is failing our checkout APIs and now customers are calling non-stop. It’s your service’s fault and you need to fix it now.”
Engineer from Team B blinks. “What? What’s going on? Why do you think it’s our fault?”

At that moment, everyone in the room can feel it. The air gets heavy. Tension rises quickly, and people start defending themselves. Before either of them knows it, voices are raised and accusations are thrown at each other. No one, especially Engineer A, knows how they even got here.

What’s missing here isn’t good intent. In fact, Engineer A probably had good intentions.

What’s missing is good framing. Framing and setting up this conversation clearly from the start would have turned this from a defensive debate into a productive discussion.

Read more

I’ve been a fan of using the STAR method in interviews, but as an interviewing expert, he shares something even better. The CARL method.

Without further ado, here’s Austen.

Read more

Influence is necessary as you level up and work with more teams and cross-functional partners. It helps you turn your idea into reality. But it's often not clear. If you haven't read the first half, check it out here.

In today's piece, I will outline the last three key tips for you on how I achieve influence.

Here's my six tips, including this week's three:

1. Understand your stakeholders' goals.

2. Build private consensus.

3. Make your case using the SCQA framework.

4. Go big on marketing.

5. Harness consistency.

6. If not today, plan for next time.

Tip 4: Go big on marketing.

If you've gotten alignment from using the SCQA method in Tip 3, it's time to go big on marketing.

To do that, you need to inform the rest of the company of what you're up to.

Post on your internal chats, groups, and emails. I like to get the word out by

1. Announcing a kickoff through meetings, emails and posts

2. Sha…

Read more

You need to refine the idea, discuss it, share it widely, gather stakeholders, and then finally implement it. And wait, you have to share it again. Did I already mention that?

This process is messy, especially when you need others to buy in. In other words, this is also known as influence.

Influence is required as you level up and work with more teams and cross-functional partners. Getting one person on board is simple. Getting everyone to stay consistent and aligned? That’s the real challenge.

There isn’t a perfect playbook for influence, but I’ve spent over a decade refining a method that’s helped me influence top decisions at Meta and Lyft.

Over the next two weeks, I’ll share my six core tips to influence:

1. Understand your stakeholders' goals.

2. Build consensus privately.

3. Make your case using the SCQA framework.

4. Coming next week

5. Coming next week

6. Coming next week

Today's article will cover the first three: understanding stakeholders' goals, building private consensus, and leveraging the Minto Pyramid.

Tip 1: Understand your stakeholders' goals

The first tip to influence: Knowing and understanding your stakeholders.

What are their goals and key objectives? What’s urgent for them? How fast are they trying to achieve these? Aligning with these multiple stakeholders is crucial, especially as seen in these studies.

At the core of this is a key question that you should keep asking yourself: How can I help them?

Dr Robert Cialdini, author of the bestseller Influence, calls this reciprocity. People are obliged to give back to others in the form of a behavior, gift, or service that they have received first. If you want something from others, you have to first give.

Here are four key questions to ask your stakeholders:

1. What is your team's roadmap for this / next half?

2. What are the biggest challenges or blockers you’re facing right now?

3. Which metrics or outcomes are you being measured on?

4. Who else do you need to align with to succeed?

As they answer, listen carefully for collaboration opportunities. Does your project make their work simpler? Can it help them hit a metric they care about? Can you connect something your team is already doing or wants to do with their priorities?

If you find a natural fit, bring it up:

“I've been thinking about Project X. Seems like it might help your team increase revenue, which you referenced as a goal earlier. What do you think? Would you support it?”

Remember: The goal of these questions is to understand your stakeholders better. So when it comes time to pitch your idea, your stakeholders see it as helping them too.

Tip 2: Build consensus privately

This is my favorite tip – but also the most time-consuming. Build consensus privately.

At Toyota, engineers spend 3x more time consulting every stakeholder before they begin implementation. They call this process Nemawashi, or literally "going around the roots" to build consensus.

But why even do this? The idea is simple: get alignment in private before you ever walk into a big review meeting.

By practicing Nemawashi, you create safe spaces. Your stakeholders can voice private concerns or doubts without the pressure of public embarrassment. It's also a chance for both of you to negotiate how the project should be shaped.

But be careful: do not take in everyone's feedback. Not all opinions matter equally. This is where identifying your stakeholders is most important. You don't want this to take forever, nor is it easy to incorporate everyone's feedback. Time-box these 1:1 meetings, 30 minutes or less.

Here’s my usual flow in these private meetings:

1. Introduce what the project is and why I'm advocating for it.

2. Connect it to my previous understanding of their team’s goals.

3. Probe gently to see how they feel.

Some questions to figure out how they feel:

1. What are your thoughts on this project? (See where they land)

2. Any concerns if we go ahead with this, as is? (Hear out their doubts)

3. What would help make this proposal stronger from your perspective? (Gather support and alignment)

If you end up incorporating their feedback, go one step further. In a large review meeting, call it out:

“This idea came from [Stakeholder’s name]."

This does two positive things:

1. It shows social proof that others have vetted this proposal, and

2. It strengthens your relationship with this partner since you gave them credit in front of a large group.

Tip 3: Use the SCQA Method

Once you're done building consensus privately, it's time to bring it to a larger review meeting.

I'm sure you've sat through large reviews where the ask isn't clear. The presenter spends 10 minutes summarizing and presenting diagrams. Everyone’s already super checked out.

Here's a better way: the SCQA method.

It’s a simple way to cut through the noise and make sure your message lands. Invented by Barbara Minto (creator of the Minto Pyramid), the SCQA method is one of the most widely used frameworks for executive communication at consulting and Fortune 500 companies.

The SCQA Method

• Situation – What’s the current context?

• Complication – What’s the challenge, tension, or problem?

• Question – What do we need to solve or decide?

• Answer – What’s the recommendation or next step?

Let's run through an example. Imagine you’re the TL of the monitoring team and you're thinking of using Vendor X's solution.

Instead of saying:

❌ Without SCQA:
“Our system has lots of problems, and engineers are frustrated. But I don't think we've got a good handle on it. We've been throwing so many solutions at the wall, but nothing sticks. Both Vendor X or Y have shown promising solutions too that we should consider.”

Did you catch the proposal? It's hard to grasp what's going on.

Now, let's try applying the SCQA method:

✅ With SCQA:
Our current monitoring system is outdated. (Situation)
Engineers waste hours debugging because of missing alerts, and outages cost us $100k annually. (Complication)
How do we reduce downtime and improve reliability? (Question)
We should adopt Vendor X. It’s reliable, cost-effective (saves us $100k), and our engineers already know how to use it. (Answer)

Notice the difference? In the first version, your ask is not clear. There's no good storytelling, and it's easy to get lost.

In the SCQA version, the audience knows the problem, the decision point, and your recommendation.

Let's practice with a second example. Say you're trying to get your entire team to adopt agile methodology and sprints.

Instead of saying:

❌ “I think what we've been doing isn't too great. We are stuck in endless loops during standups, and development cycles are going on for too long. Has anyone tried this sprint process in their previous company? I heard it might work.

This doesn't show clear thinking or conviction about your proposal. Try this:

✅ We meet often, but we're still missing our ship goals. (Situation)
We're not communicating well, and often not on the same page. Our feedback loops are often too long. (Complication)
How can we shorten our iteration cycle? (Question)
We should try sprints. It's been proven to work well in other companies – leading to increased efficiency and productivity. (Answer)

See how much clearer this is? We're able to organize our thoughts and structure them in a way that makes it easy for the audience to comprehend.

Give it a shot the next time you make an ask, and let me know how it went in the comments.

TLDR:

That's the end of Part 1 of my guide to influence. To summarize the first three steps:

1. Understand your stakeholders' goals: Make sure your project caters to their needs.

2. Build private consensus: Understand concerns before large meetings.

3. Make your case using the SCQA framework: Structure your ask well.

Looking for Part Two of this guide to influence? Click here.

But thinks that’s a mistake.

You might know Deb, former VP at Facebook, ex-CEO of Ancestry, and author of Take Back Your Power. She has built products used by billions, gone on Lenny’s Podcast, on the board of Intuit, and founded the 30,000+ member community Women in Product. Besides being a proud mom of three, she is also open about her struggles with cancer.

Today, she’s here to share more about three topics that will challenge how you think about your own career:

1. Why short-term career thinking will quietly trap you.

2. How family choices shape your career trajectory

3. Why staying silent in key moments isn’t humility

Our discussion took place as a Q&A format. If you’re looking for a summary, I’ve summarized my takeaways at the end.

Without further ado, here’s our interview:

Career Stalls & Tradeoffs

You spent 11 years at Facebook. What’s something you believed early in your Facebook career that you’ve since changed your mind about?

Early in my career, I believed the biggest myth my immigrant parents taught me: put your head down, do great work, and people will reward your brilliance. That’s what school teaches you. Just do the work, get good grades, and move up to the next grade.

But the workplace is nothing like that. People value different skills. Perfect code or great ideas don’t always win. Communication, influence, and relationships matter a lot more than I realized.

Facebook was a shock in that way. You’re surrounded by incredibly talented people, and advancement isn’t just about doing your work well. It’s about making your impact visible. That doesn’t mean being the loudest in the room, but it does mean understanding what the company values and making sure your contributions are aligned and seen.

You mentioned before that you went 6 years without a promotion. Most people would quietly quit or leave. What kept you going? Do you regret staying?

Those six years weren’t me sitting still. I actually had three different jobs across three companies. But I was stalled in my title progression. I didn’t regret it because each move built new skills, and some of the work I did then still impacts my career today.

When my son was born, my career had always been front and center, but suddenly I wanted to be with him more than anything. He’s nineteen now, but back then I remember thinking: Why am I spending so much time away from him? I switched to four days a week and gave up my high-intensity job so I could be there in his early years.

I made deliberate trade-offs. For most of my kids’ entire childhood, I never traveled for work. In fact, I didn’t travel until I had weaned my youngest at age one. I knew that meant certain roles and opportunities were off the table. But that was okay. It was my choice. I had three children during that time. I was also pregnant with my youngest while my father was diagnosed with Stage 4 cancer. He then passed a few months after she was born. So a lot was happening outside of work that mattered more.

I joined Facebook right after maternity leave for my second child, Bethany. I sat my family down and said, “If I do this, I’m going to be working a lot more.” I wanted to give them a heads-up that I was going to be busy. To me, work-life balance is not about hours but being able to be there when they need me.

But for your readers, here’s the hard truth: I wasn’t actively managing my career during that time. I thought my managers at Facebook would see my work and push me forward, but I went through seven managers in 2.5 years. They were all wonderful in their own way, but no one was in my corner long enough to champion me until the 7th manager.

I learned that you have to be the product manager of your own career. You have to set your own milestones, know the promotion criteria, and make sure you’re filling those gaps deliberately.

Looking back at those 6 years, was there anything you would have done differently?

Hindsight is 20/20. When you’re in the moment, you’re just making the best decision with the data you have. I talk about this in my book.

I was born in Queens in New York. If you’ve ever taken the E or F train out toward Queens from Manhattan, you are going north, and then the train makes this sharp right turn. But you don’t feel it because you are on the train. You don’t notice until you look at a map later and realize you’re now 90 degrees from where you started.

Careers are like that. You don’t always feel the shift as it’s happening. Only when you look back do you see how far you’ve turned. Those six years without a promotion were like that for me. I was gathering skills, building experience, and preparing for the next stage, even if I didn’t recognize it at the time. I have no regrets because I have three amazing kids and an amazing life.

Perspectives

You've publicly shared that you recently drew the cancer card. How did your cancer diagnosis shift how you think about work?

This year really made me stop and think. Last year, my mammogram was totally clear. This year, when I went in, they told me there’s something ‘pretty suspicious.’ You hear that phrase enough times, and it’s almost like it becomes inevitable. Suddenly, I’m on this conveyor belt of biopsy, surgery, and radiation. I’m now on Tamoxifen, which reduces the chances of recurrence. Life is short.

And in those moments, none of the things you’ve achieved matter. It doesn’t matter what’s on your LinkedIn, it doesn’t matter what your title is. What matters is: where do you want to spend your time? What brings you joy?

Also, family has always been really important to me. Last year was especially hard. My mom passed away, and just a few months before that, both of my in-laws passed away. I was very close to all of them. We had planned to move in together; my mom had lived with me for over a decade after my dad died, and we had even built a house with a massive in-law unit so my in-laws could live right next door, connected to our home, so we could care for them.

Losing all three of them within nine months was incredibly difficult. It’s a stark reminder that behind every short bio or Wikipedia page, there’s an entire life being lived. With joys, losses, and deeply personal stories that don’t show up in the titles and bullet points.

You have a finite amount of time. I want to spend mine on the people and the work that truly matters to me.

Influence

For introverted engineers, what do you think most quiet or underestimated engineers get wrong when trying to build influence? How do you, as a product lead want them to act?

First, for product managers, communication is the job. It’s literally your job. It’s like saying, ‘I don’t like standing in front of an orchestra,’ when your job is to be the conductor. You picked this role, so you have to own that responsibility.

As an engineer, though, you’re also part of the orchestra. If something is going wrong and you don’t speak up, the whole piece suffers. Imagine the woodwinds are half a beat off! Even if your section is perfect, it’s going to sound bad. And the woodwinds? They’ll feel terrible, because they might not even realize they’re out of sync until it’s too late.

A lot of engineers think, ‘If my work is good, that should be enough.’ But in leadership roles, you have to be able to escalate and raise issues at the right moment. You don’t need to speak all the time. Constant talking isn’t influencing others. But silence in key decision moments is a disservice to your team and yourself.

One trick I suggest for introverts is to deliberately change your ‘meeting persona’ for a while. If you’re usually the quiet one, try being the provocateur for a month. Ask the uncomfortable question. Play devil’s advocate.

It’s not about changing who you are. It’s about breaking how people perceive you. You want to get out of the box. Because influence isn’t just what you know, it’s when and how you show it.”

Fun Questions

Now let’s pivot to some fun questions. What’s the funniest or most ridiculous thing you’ve ever seen listed on FB Marketplace?

“Definitely the raw chicken teddy bear. Someone took raw chicken and shaped it into a teddy bear. The head, arms, everything. It was disturbing and hilarious at the same time.

What’s your go-to comfort food after a brutal day at work?

“Soup. I love ramen, udon, and noodles. I’m a big soup noodle person. So are my kids. But my husband is not a fan. We have been married for 25 years, and there are still some things that we can’t quite get on the same page about.

Thank you, Deb, for sharing! My takeaways:

1. Short-term career thinking is a trap: If you’re managing your career around the next performance review, you’re playing the wrong game. Deb argues for thinking in 2–5 year arcs: What skills will my future self need? What experiences will open the doors I want later? Sometimes that means taking the less glamorous role today so you’re ready for the bigger leap tomorrow.

2. Family choices have clear trade-offs. We can’t pretend that taking time for family, whether it’s having kids, caring for aging parents, or stepping back from travel, doesn’t slow career momentum. Deb is blunt about this: the impact is real. But that doesn’t make it the wrong choice. It just means you need to acknowledge the trade-offs and plan for how you’ll rebuild speed when you’re ready.

3. Speak up, or you might be doing others a disservice. Treat speaking up like playing in an orchestra: you don’t have to play every note, but when your section comes in, you’d better be heard. Speaking up at the right time isn’t self-promotion. It’s advocating for your team, your customers, and the work that matters.

Know anyone who should be featured? Reach out via Substack or email.

Enjoyed this? Let us know in the comments.

Today, he shares more about how the STAR format is powerful but also often misused, especially in interviews.

Without further ado, here’s Prasad.

Read more

Today, I’ll share more about my framework for prioritizing projects. Prioritizing your work is a skill that becomes increasingly important as you advance in a company.

Why? Knowing how to prioritize means:

1. You don't have to lean on your manager as much, which builds greater trust between you and them.

2. As you get more senior and lead large teams and organizations, you need to figure out what to work on. Other engineers depend on the output of your work.

3. You get to have fun while doing so. Being in control of your priorities means you're in control of your destiny. Besides, who likes being told what to do?

Marrying needs & fun

You need two things to prioritize your work:

1. A good understanding of your company

2. A…

Read more

If you know Philip from Facebook, he’s the guy who spent $57,000 buying everyone a cup of coffee for everyone at Facebook across several offices!

In today’s article, Philip talks about how he believes work-life balance is a myth if you want to level up. He was promoted every year in his first 8 years at Microsoft. That’s extremely impressive.

Of course, this intensity isn’t for everyone. I’ll also share the other side of the coin on Philip’s Substack (subscribe if you haven’t!) in a week or two. I’ll share how I find work-life balance while continuing to build my career.

But without further ado, here’s Philip.

Self-help books and countless motivational speakers evangelize the dream that you can have it all: a great family, a 45-hour work week, a head full of luxurious hair, and faster career growth than your peers.

It isn’t true. Anyone saying differently is selling something or leaving out key context.

Ways to Get Ahead

Three components of fast career growth:

1. Luck

2. Talent

3. Grit

We all know lucky people. You can’t orchestrate attending Sergey Brin’s high school and also having your favorite professor in college turn out to be Sergey’s dad. (Both happened to me, though in my case, neither led to fame and fortune.) Since luck is something you can’t control, there’s no need to discuss it deeply, though it helps to acknowledge it as a significant factor in many people’s careers.[1]

Talent is also not within your control. Some people are just flat-out smarter than you. I will never be an NBA player. Lest you think the latter flippantly irrelevant: in presidential races between two candidates, the taller one wins the popular vote 67% of times because they are perceived as stronger leaders. So height turns out to be quite relevant career-wise. But equally uncontrollable as luck.[2]

This leaves grit as the one thing you control when it comes to career velocity.

True Grit

There are many ways to be gritty, like persisting at self-improvement. But for this post, I’ll focus on the centrality of working hard.

If you are just as smart as everyone else, and you work just as hard as everyone else, you’re just as average.

Now average isn’t bad. In fact, average could be stellar, depending on where you work, so I wouldn’t go around pooh-poohing being average. But you probably didn’t start reading this post to learn how to stay average.

Assuming you aren’t exceptionally luckier or more talented than your peers, the only recourse to progressing faster than your peers is to outwork them — with longer hours or more focus and efficacy. Ideally both.

The opposite surely couldn’t be the case, right? Sally is just as smart as Amy, and every bit as lucky, but works far less than Amy while rocketing past Amy career-wise? Yet this is the gospel preached by many: that you can work the same hours as your peers yet blow past them in career velocity without breaking a sweat.

What’s true at the personal level is true at the national level. Americans enjoy greater prosperity than Europeans due largely to longer work hours. Sure, those longer hours come at the cost of leisure time… but if you wanted to read about how to maximize leisure, you’re reading the wrong post.

Be luckier. Be more talented. Or work harder.

Blasphemy!

I can feel comment-submitting fingers already warming up to send screeds on how this post is all wrong. I’ll address some objections up front.

• Work smarter, not harder. So catchy, this phrase. So smugly superior, as if this golden life hack were unknown to most. If you find yourself in a workplace where you don’t have to work harder simply by “working smarter,” you’ve joined the wrong team or company. On every great team I’ve ever been on, it was table stakes that everyone was already working smartly.

• You’ll have lower output beyond 40 hours. People often refer to Ford’s study of factory workers, where per-hour productivity does indeed decrease after 40 hours. But what many may elide is that total productivity continued to go up until 55-60 hours, at which point mistakes would at last decrease total output. I suspect the same trend holds for office workers: beyond 40 hours, total output continues to go up until the point where mistakes start to overwhelm productivity. But I have little doubt most coders working 45 hours produce more, in total, than when working 40 hours.

• You’ll burn out. You might well. Or is it true that “if you choose a job you love, you’ll never work a day in your life?” Everybody has a different threshold of sustainable long-term output. Finding yours is key. But I’ll add this: many times when my direct reports have talked about work-life balance, what they were really saying — implicitly, sometimes unknowingly — was they had lost interest or a sense of purpose in their job.[3]

• You’ll blow relationships. Likely true, depending how unbalanced your life is and how sensitive your friends and partners are. You might also miss opportunities to form new relationships. I’m not saying this is good. I’m saying it’s true.

• You’ll miss out on the better things in life. This is both true and wise. There’s a tradeoff between going faster in your career and deeper in other aspects of your life. It might not be strictly zero-sum (e.g. doing better in career to some degree may improve other aspects of your life), but contrary to all the advertising you’ve seen, you can’t have it all.

Opportunity Costs

Hard work goes a long way.

In college, I was pre-med and scored a 40 on the MCATs (~522 in today’s terms, higher than the median Harvard Medical School student) by reading nine different college textbooks across chemistry, biology, and physics, cover to cover at least two times each. It irked me when friends lauded my intelligence upon hearing my score. I felt they should only attribute the score to my intelligence if they, too, had studied equally hard yet fared worse. As it stood, they misattributed the primary cause of my success to talent, when so much was due to long, laborious hours spent in solitude.

When I first started at Microsoft, I had a sleeping bag in my office. I coded until 11pm nightly and slept until 3am, at which point I’d code until ~6am, then sleep until my first meeting ~10am. This was totally sustainable for me at a time when I had no hobbies and my closest friend also worked similar hours.

I was promoted once a year for my first eight years at Microsoft. This is far from typical, but also not unheard of. Certainly faster than average. Was it due to luck and talent? No doubt. Could I have progressed equally quickly working 45-hour weeks? I can’t imagine how. I literally can’t. I remember learning late-night insights as I debugged things while the janitor vacuumed nearby hallways. I fixed twice as many bugs as a peer who started on my team the same month as I. How could I possibly have progressed as quickly without the advancements I made in those wee hours?

But it all comes at a cost. There are no free lunches. Our family once bought a Nordic chess set my then-seven-year-old son was excited to use. He asked me whether we could play it together, and I said, “Sure!” He then asked me to put it on my calendar, and watched until I had done so. This was a devastating moment of sudden realization for me. Back then at work, I was experiencing what in hindsight may well have been the high point of my entire career: leading the Facebook London engineering office, its first international development outpost. I was Facebook’s first engineer promoted to E9 outside the US. All this, at the cost of my second-grade son making sure he had a reserved spot on my calendar prior to me heading off to work that morning.

Was it worth it? Could I have worked a lot less in my earlier career and have eventually gotten to the same ladder level? Quite possibly. Would I have had more time to spend with family and friends, and perhaps even have developed some hobbies, had I worked less? Most definitely.

I’m no apologist for e/acc’ing your career by working long hours. But I’m not going to blow sunshine and sell you some fantasy where you’re no smarter or luckier than your peers, and you work no harder, yet you break the career velocity sound barrier through positive manifestation and three simple tips.

If you want atypically fast career growth, you need to put in the hours. Only you can answer whether the sacrifices are worth it. And there will be sacrifices, whether intentional or not.

But no shortcuts.

How might you organize your weeks & time for all this work? I’ll post a follow-up article which you’ll receive by subscribing here.

Notes

[1] Yes, you can “make your own luck,” if by that you mean seizing opportunities when they avail themselves and putting yourself in places where you’re more likely to be lucky. I don’t call that behavior “luck” anymore; perhaps a better descriptor is “orchestrating your career to maximize chances you’ll have better opportunities.” When I here use the word “luck,” I mean the kind of chance happening you couldn’t possibly control.
[2] Yes, I could have done human growth hormones earlier in life, or tibial lengthening now. But you miss the broader point if that’s what you’re thinking. There are tons of natural characteristics I have zero control over.
[3] Fireside True Story™ time: Tim was an avid cyclist on my Microsoft team. He loved cycling so much, in fact, he asked in our 1:1 to go to 32 hours a week, explaining that he wanted time to pursue his lifelong passion. I supported this. Tim later joined Google, which in 2004 definitely had worse work-life balance than Microsoft. This surprised me, so I asked Tim how things were going with his cycling when I ran into him six months later. “Biking? I’ve got zero time — I don’t do it at all. I love my job at Google!” This, from a man that swore to me his lifelong passion was being sacrificed at the altar of Microsoft profits.

Thank you Philip for sharing your insights. If you haven’t subscribed to his Substack, do so here! We’ll be sharing my take on WLB on Molochinations as a follow-up article.

Today, I'll share with you my tips on handling disagreements in the workplace.

When I was a junior engineer, my PM yelled at me for failing to inform him about an experiment. We disagreed on what happened, and this escalated quickly into a heated public discussion.

Was I in the wrong? Were they in the wrong? I was so caught up in standing my ground. Now, I realize how little that matters.

I've since reflected on that episode from a decade ago and learned how to handle disagreements much better. Let's dive in.

Read more

They don't just stay one step ahead — they think ten steps ahead.

Instead of reacting to problems as they arise, they anticipate what's coming next. As a result, clarity follows. They leverage proactiveness to showcase their leadership and ownership skills, eventually leading to recognition and promotions.

I want to share and break down that skill with you today: Thinking Ten Steps Ahead.

Read more