<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mohit Ranka</title><link>https://www.mohitranka.com/</link><description>Engineering leader. Writing on data platforms, developer tooling, reliability, and leadership.</description><atom:link href="https://www.mohitranka.com/rss.xml" rel="self"/><lastBuildDate>Tue, 21 Jul 2026 10:00:00 +0530</lastBuildDate><item><title>The line manager role is disappearing faster than you think</title><link>https://www.mohitranka.com/blog/line-manager-role-is-disappearing/</link><description>&lt;p&gt;The line manager role is disappearing faster than most career plans assume. Meta has already moved toward one senior manager for roughly every fifty developers. That is not a distant forecast. It is an operating choice already in the market. If you lead engineers — or want to — the useful question …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Tue, 21 Jul 2026 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2026-07-21:/blog/line-manager-role-is-disappearing/</guid><category>Blog</category><category>engineering-leadership</category><category>management</category><category>product</category></item><item><title>Near-real-time is a product promise, not a Kafka cluster</title><link>https://www.mohitranka.com/blog/near-real-time-is-a-product-promise/</link><description>&lt;p&gt;“Near-real-time” is often used as a synonym for “we bought a streaming stack.” On GTM data platforms, that confusion is expensive. The product promise is about &lt;strong&gt;whether a decision-maker can trust a number in time&lt;/strong&gt; — not whether an event log is busy. At LinkedIn, the Enterprise Data Platform (EDP) was …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Thu, 16 Jul 2026 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2026-07-16:/blog/near-real-time-is-a-product-promise/</guid><category>Blog</category><category>data-platforms</category><category>distributed-systems</category><category>reliability</category></item><item><title>The platform team’s real job is interfaces</title><link>https://www.mohitranka.com/blog/platform-teams-real-job-is-interfaces/</link><description>&lt;p&gt;At LinkedIn, the Enterprise Data Platform (EDP) was meant to be the centralized way GTM teams managed and consumed datasets. On paper, that is a clear platform charter. In practice, a platform is only real when its &lt;strong&gt;interfaces get adopted&lt;/strong&gt; — including by teams that already have a path that “works …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Thu, 13 Nov 2025 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2025-11-13:/blog/platform-teams-real-job-is-interfaces/</guid><category>Blog</category><category>engineering-leadership</category><category>platforms</category><category>developer-tooling</category></item><item><title>When I still choose a relational database</title><link>https://www.mohitranka.com/blog/when-i-still-choose-a-relational-database/</link><description>&lt;p&gt;In 2013 I wrote &lt;a href="https://www.mohitranka.com/blog/rdbms-vs-nosql/"&gt;RDBMS vs. NOSQL?&lt;/a&gt; as a pushback against fashion. The fashion changed costumes — document stores, wide-column, NewSQL, "Postgres is fine," "everything in the lakehouse" — but the underlying mistake did not: &lt;strong&gt;picking a datastore from a blog post instead of from access patterns and failure modes.&lt;/strong&gt;&lt;/p&gt;
&lt;figure class="post-figure"&gt;
  &lt;img src="https://www.mohitranka.com/images/blog/when-i-still-choose-a-relational-database.jpg" alt="Illustration of an ordered data table foundation beside scattered documents" loading="lazy" width="1200" height="675"&gt;
  &lt;figcaption&gt;
    &lt;span class="fig-caption"&gt;A relational …&lt;/span&gt;&lt;/figcaption&gt;&lt;/figure&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Thu, 13 Mar 2025 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2025-03-13:/blog/when-i-still-choose-a-relational-database/</guid><category>Blog</category><category>data-platforms</category><category>databases</category><category>architecture</category></item><item><title>Freshness SLOs: the metric product teams actually feel</title><link>https://www.mohitranka.com/blog/freshness-slos-the-metric-product-teams-feel/</link><description>&lt;p&gt;API latency SLOs changed how we run services. GTM data work taught me the sibling idea the hard way: product teams do not experience your job-success chart. They experience a dashboard that is late, wrong, or disagrees with another “official” number. At LinkedIn, BI teams on Power BI and Tableau …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Thu, 11 Jul 2024 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2024-07-11:/blog/freshness-slos-the-metric-product-teams-feel/</guid><category>Blog</category><category>data-platforms</category><category>reliability</category><category>observability</category></item><item><title>Saying no as a platform EM without becoming the villain</title><link>https://www.mohitranka.com/blog/saying-no-as-a-platform-em/</link><description>&lt;p&gt;Platform engineering managers do not run out of good ideas. They run out of capacity to say yes to every reasonable request without wrecking the shared system. The skill is not blunt refusal. It is &lt;strong&gt;no with a path&lt;/strong&gt; — specific enough that partners can actually execute, firm enough that your …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Wed, 08 Nov 2023 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2023-11-08:/blog/saying-no-as-a-platform-em/</guid><category>Blog</category><category>engineering-leadership</category><category>platforms</category><category>management</category></item><item><title>Identity systems fail socially before they fail cryptographically</title><link>https://www.mohitranka.com/blog/identity-systems-fail-socially/</link><description>&lt;p&gt;When people talk about identity and SSO, they reach for algorithms: token lifetimes, key rotation, SAML vs OIDC, session fixation. Those details matter. In systems I have built and operated, the outages and near-misses that hurt most started earlier — as &lt;strong&gt;social and product failures&lt;/strong&gt; wearing security clothing.&lt;/p&gt;
&lt;figure class="post-figure"&gt;
  &lt;img src="https://www.mohitranka.com/images/blog/identity-systems-fail-socially.jpg" alt="Illustration of keys, badges, and people connected in a trust network" loading="lazy" width="1200" height="675"&gt;
  &lt;figcaption&gt;
    &lt;span class="fig-caption"&gt;Identity systems often …&lt;/span&gt;&lt;/figcaption&gt;&lt;/figure&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Wed, 08 Mar 2023 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2023-03-08:/blog/identity-systems-fail-socially/</guid><category>Blog</category><category>identity</category><category>security</category><category>distributed-systems</category></item><item><title>What “led the web launch” taught me about constraints</title><link>https://www.mohitranka.com/blog/web-launch-constraints/</link><description>&lt;p&gt;At Postman, “put the product on the web” was not a greenfield rewrite. It was a constraint problem: a desktop-native API tool used by millions of developers, enterprise pressure for browser access, browser security that blocked the old execution model, and a conference date that would not move. I was …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Wed, 06 Jul 2022 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2022-07-06:/blog/web-launch-constraints/</guid><category>Blog</category><category>engineering-leadership</category><category>product</category><category>developer-tooling</category></item><item><title>Incubating 0→1 beside a mature product</title><link>https://www.mohitranka.com/blog/postman-labs-0-to-1/</link><description>&lt;p&gt;When I was at Postman, the core product was already the default API client for a huge HTTP/HTTPS world — on the order of tens of millions of developers on desktop. That success created a sharp problem: &lt;strong&gt;how do you explore what comes after HTTP without slowing the product everyone …&lt;/strong&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Tue, 15 Jun 2021 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2021-06-15:/blog/postman-labs-0-to-1/</guid><category>Blog</category><category>engineering-leadership</category><category>product</category><category>developer-tooling</category></item><item><title>How I review a distributed design in 45 minutes</title><link>https://www.mohitranka.com/blog/how-i-review-a-distributed-design/</link><description>&lt;p&gt;The most expensive design reviews I have run were not missing a box on a diagram. They were missing a decision. One of them froze delivery on an EDP self-serve portal for about a month while two strong engineers disagreed in public about monolith versus microservices — and ownership quietly collapsed …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Wed, 03 Mar 2021 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2021-03-03:/blog/how-i-review-a-distributed-design/</guid><category>Blog</category><category>distributed-systems</category><category>engineering-leadership</category><category>architecture</category></item><item><title>Introducing on-call without burning the team</title><link>https://www.mohitranka.com/blog/introducing-on-call-without-burnout/</link><description>&lt;p&gt;At Postman, my team owned a large-scale platform surface used by millions of developers. What we did not own — formally — was a &lt;strong&gt;predictable operational response&lt;/strong&gt;. Production issues and public GitHub noise were handled ad hoc. Someone jumped in, or everyone hesitated. Retrospectives lacked a clear accountable role. The system worked …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Tue, 10 Nov 2020 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2020-11-10:/blog/introducing-on-call-without-burnout/</guid><category>Blog</category><category>reliability</category><category>engineering-leadership</category><category>platforms</category></item><item><title>GTM datasets need data contracts</title><link>https://www.mohitranka.com/blog/gtm-datasets-need-data-contracts/</link><description>&lt;p&gt;When a go-to-market dashboard is wrong, nobody says “the warehouse is eventually consistent.” They say the number is wrong — and they stop trusting the platform. On LinkedIn’s Enterprise Data Platform (EDP) work, the failure mode was rarely a missing chart type. It was &lt;strong&gt;informal truth&lt;/strong&gt;: datasets without clear producers …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Wed, 01 Jul 2020 10:00:00 +0530</pubDate><guid>tag:www.mohitranka.com,2020-07-01:/blog/gtm-datasets-need-data-contracts/</guid><category>Blog</category><category>data-platforms</category><category>platforms</category><category>product</category></item><item><title>RDBMS vs. NOSQL?</title><link>https://www.mohitranka.com/blog/rdbms-vs-nosql/</link><description>&lt;blockquote&gt;&lt;p&gt;From our own experience designing and operating a highly available, highly scalable ecommerce platform, we have come to realize that relational databases should only be used when an application really needs the complex query, table join and transaction capabilities of a full-blown relational database. In all other cases, when such …&lt;/p&gt;&lt;/blockquote&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mohit Ranka</dc:creator><pubDate>Sat, 29 Jun 2013 00:16:00 +0530</pubDate><guid>tag:www.mohitranka.com,2013-06-29:/blog/rdbms-vs-nosql/</guid><category>Blog</category><category>data-platforms</category><category>databases</category><category>architecture</category></item></channel></rss>