Senior Staff Technical Program Manager, AI Infrastructure at LinkedIn. 15 years across machine learning infrastructure, distributed systems, and reliability engineering.
System Design
If you only ever learn one kind of database deeply, make it this one. The relational database has been the default way to store important data for over forty years, and despite a parade of trendy alternatives, it is still the right answer for the majority of systems being built
System Design
If you have ever looked at a modern system's architecture diagram, you have probably wondered the same thing every newcomer wonders: why are there so many different databases in here? There is a relational database over here, something called a document store over there, a cache, a search
TPM Knowledge
For years, the question “TPM vs PM vs EM” quietly stressed me out. Not in a theoretical way, but in a very real “I have no idea what I actually want to be” way. Not because I was overthinking titles, but because my early career created a lot of mixed
System Design
Here is a question that sounds simple but trips up most people new to software: once an engineer finishes writing code, how does it actually reach the millions of people using the product? It does not just "go live." Between a developer typing the last line of code
TPM Knowledge
A program roadmap is a shared decision about where you are going, not a list of dates. Most program roadmaps are a wall of bars on a timeline. Features down the left, months across the top, colored rectangles in the middle. It looks like a plan. It is really a
TPM Knowledge
Escalate the problem, not the person Escalation is one of the most misunderstood tools a technical program manager has. Done wrong, it reads as an accusation: you went over someone's head, you made them look bad, you imported a fight. Done right, it is the fastest, cleanest way
System Design
How teams know a system is healthy, and how they decide how healthy it needs to be There is an old engineering saying: you cannot fix what you cannot see. A running system is a black box from the outside, millions of things happening per second, and the only way
System Design
The handful of ideas that stop most breaches, explained for people who do not write security code Security has a reputation for being a dark art practiced by specialists, and the deep end truly is. But the great majority of real-world breaches are not exotic. They come from a
System Design
How systems talk without waiting, and how they find things fast So far, most of the talking between parts of a system has been a direct call: one service asks another and waits for the answer. That works, but it has a weakness. The caller is stuck until the answer
System Design
What to do when one machine is no longer enough Every system starts simple enough to run on a single computer. Then it grows, more users, more data, more requests, and that one machine begins to strain. Scaling is the craft of handling that growth, and once you commit to
System Design
Keep the popular stuff close, and everything feels fast Caching is the single most common trick for making a slow system fast, and the idea is something you already do every day. You keep the things you use most within arm's reach: the coffee mug on your desk,
TPM Knowledge
Make every dependency explicit, tracked, and owned Unmanaged dependencies are the number-one cause of preventable program slips. Not technical complexity, not headcount, not changing requirements. Dependencies. And here is the frustrating part: they are also the most predictable risk in any large program. A dependency that slips rarely surprises