System Design
Where your app's memory lives, and why this one choice shapes everything for years Every app remembers things: your account, your messages, your orders, your photos. All of that memory lives in a database. It is the most important box in almost every system diagram, and the choice
System Design
How a click crosses the world and comes back, and why "the app is slow" is usually a traffic problem When you tap a link, it feels instant. Behind that tap, your request finds an address, opens a connection, crosses the planet, gets handled, and comes all the
System Design
How software talks to software, from the first request to a payment that never double-charges Almost nothing you use is a single program. Your banking app is dozens of programs. So is your ride app, your email, the website you bought coffee filters from last night. They are built out
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
News
In this session, Ankur Gupta from LinkedIn talks about automation, changing cloud strategies, its impact on managerial roles, and provides career tips. Note: The opinions expressed are those of the speaker and do not represent the employer or any other companies.
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
TPM Knowledge
Every technical program manager eventually runs into the same uncomfortable fact: you are accountable for outcomes you cannot command. The engineers do not report to you. The architects do not need your sign-off. The executive who set the deadline will not write a line of the code that meets it.
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
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 anyone
TPM Knowledge
You have no authority over them. Trust is the only currency you actually have. A technical program manager runs work through people who do not report to them. No one on the engineering teams has to do what I ask. They have their own managers, their own roadmaps, their own
TPM Knowledge
Centralize the information, decentralize the work When I joined the a major tech company in 2022, reliability worked the way it does at a lot of places that copied the early Google model: a large site reliability engineering organization, with SREs embedded across every product. The split was simple on