Mudit Malpani

From Mid-Scale Hustle to Big-Scale Systems — My Leadership Journey When I worked at a mid-sized company — McAfee (formerly Intel Security), life as an engineering leader looked very different. I owned the entire tech stack end-to-end for the Real Protect SDK, which powered both enterprise and consumer security products. Decisions were quick. If I had an idea, we could experiment and roll it out within days. The visibility was immediate — the team saw the impact directly, and customers felt it instantly. But there were trade-offs: scale was limited, resources were stretched, and reliability sometimes gave way to speed. I wore multiple hats — tech lead, architect, and often the “on-call fireman.” Fast forward to today at Amazon. The canvas is massive — whether rolling out Prime membership features or building a multi-tenant portal to enable supply chain services for 1P & 3P sellers. Systems serve millions of users globally, reliability is non-negotiable, and playbooks ensure consistency across teams. I learn from some of the brightest minds, and every design decision forces me to think about scale, latency, and resilience. But here too, there are trade-offs: processes are heavier, decisions take longer, and ownership is often of just one slice of a much bigger puzzle. ⚡ What helped me move faster in this environment: Clarity of priorities → tie every discussion back to business + customer outcomes Cross-team relationships → build trust before you need alignment Document → Decide → Drive → cut endless meetings with written context & trade-offs Bias for small wins → ship incremental value instead of waiting for “big bang” launches Empowering the team → unblock quickly and let them own execution 💡 My takeaway: Mid-scale sharpened my ownership, versatility, and bias for action. Big-scale honed my systems thinking, discipline, and focus on reliability. The best leaders blend both — carrying startup agility into enterprise scale. 👉 If you’ve made the shift between mid and big companies, what was your biggest “surprise learning”? #EngineeringLeadership #TechLeadership #CareerGrowth #EngineeringManagement #ScalingTech #BigTech #StartUpCulture #LeadershipJourney

23

1 Comment

🚀 The Chariot: A Startup Story 1️⃣ The Perfect Start Startup horses pull a single chariot. Everyone joins the harness at the same moment — aligned strength, shared purpose. Founders steady on the reins. Early customers trusting the motion. Stride synced. Weakness covered. Progress effortless. 2️⃣ When the Terrain Shifts Horses slow. Some drop out. A new charioteer may appear, demanding speed. Pressure rises. Motivation dips. Trust cracks. Yet the chariot must move — customers expect it. 3️⃣ The Hidden Cost Slow down → risk collapse. Speed up → risk burnout. The journey reveals everything the starting moment conceals. 4️⃣ The Uncomfortable Truth You can’t evaluate every variable before joining. You don’t know: • how many customers will jump in • how fast their load will grow • when teammates will fall out • when leadership changes mid-journey • how unpredictable the terrain becomes 5️⃣ The Discipline That Keeps You Alive Once harnessed, continuous evaluation becomes mandatory. Never assume the load, the team, or the terrain will stay constant. Alignment is not a one-time act — it’s a recurring adjustment. Prepare for customer load increases early, not when you’re already collapsing under it. 6️⃣ What a Horse Must Understand • Your endurance in real conditions • How much drag you can cover without breaking • How much pressure you can absorb from the driver • The moment the cost of pulling exceeds the value of the journey 7️⃣ The Core Principle Choose wisely when you can. Re-evaluate relentlessly when you must. The beginning is beautiful. The truth appears only in the miles ahead. 🔍 Before — and during — any journey: • Inspect the chariot • Understand the horses beside you • Track customer load as it grows • Watch how charioteers behave under pressure • Study the terrain you’re on, not the one you were promised ❓ What do you look for before — and while — riding the chariot?

15

2 Comments

Sharing some anecdotes about hedging requests in distributed systems When we built the blob storage at LinkedIn, every blob was broken into chunks and streamed to different storage nodes. Each chunk had multiple replicas that were written with a majority quorum. The metadata chunk had the location of all the chunks. A request for a blob would typically issue read request for the chunk and stream it to the client. At scale, we found that the tail latency (99.9th percentile) was 3-5x slower. This typically happens for various reasons - network blips, momentary spike in traffic for a specific node or deployments. One of the quick fix was to send multiple requests for the same chunk to different replicas. This is called hedging requests. The benefit of this approach is that you get the chunk faster from one of the replicas before the other. This dramatically reduced the tail latency and brought it almost on par to the 99th percentile. The downside was that we immediately doubled the request load across all nodes. To alleviate this problem, we sent the second request 10-20 ms later after checking if the first request had not started responding yet. This approach only increased the load by 1.2x while keeping the tail latency comparable to the previous approach. The downside to hedging is that the operations have to be idempotent. Immutable blobs were a good candidate for this. We also had to empirically figure out the right interval to send the second request.

70

9 Comments

On the latest episode of Embracing Erosion I sat down with Suyog Deshpande, Co-Founder & CEO of Webless (a Fluvio Ventures portfolio company). Before starting Webless, Suyog spent years at Amplitude, Salesforce, and Samsara - shaping products and GTM strategy at scale as a product marketing leader. That perspective is now fueling one of the boldest bets in tech: 🏗️ rebuilding the web for LLMs. Instead of optimizing for clicks and SEO, Webless imagines an agentic web -where sites are designed to interact directly with AI models and agents. We dug into: - What an LLM-native web could actually look like - How companies can prepare to be LLM-ready - What metrics will matter beyond pageviews and clicks - Why safety and trust are core to agent-driven experiences - Lessons Suyog brings from “big tech” into this transformation If you’re curious about how discovery, trust, and value exchange will evolve online, this one’s worth your time. Link to the full episode in the comments 👇

9

1 Comment

I recently found myself exploring about an interesting AI system design question: If Sanskrit and English had equal amounts of digital content available to train large language models (LLMs), would Sanskrit be the better language because of its well-defined grammar and logical structure? Sanskrit is often praised for its systematic grammar, explicit case markings, and structured sentence construction, where grammatical roles like subject and object are clearly encoded in word endings rather than inferred from word order. Intuitively, that feels like it should make reasoning easier for AI systems. However, modern LLMs are not rule-based systems that “apply grammar” the way humans learn it — they are statistical models that learn patterns from massive data. English, despite its ambiguities and looser structure, has simpler morphology and fewer surface variations per word, which aligns well with today’s Transformer-based architectures and tokenization methods. Sanskrit’s rich inflections and combinatorial forms, while logically elegant, can increase modeling complexity unless the architecture is designed to leverage that structure explicitly. This leads to a deeper realization: language structure alone doesn’t determine AI capability — architecture design and representation strategy matter just as much. It also raises a bigger question for the future of AI: as we move toward neuro-symbolic and reasoning-focused systems, could structurally explicit languages offer new advantages?

22

2 Comments