{ "archive_path": "archive/1764951365.819209", "base_url": "lalitm.com/software-engineering-outside-the-spotlight", "basename": "", "bookmarked_date": "2025-12-05 16:16", "canonical": { "archive_org_path": "https://web.archive.org/web/lalitm.com/software-engineering-outside-the-spotlight", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=lalitm.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "lalitm.com", "downloaded_at": "2025-12-05T16:16:13.270729+00:00", "downloaded_datestr": "2025-12-05 16:16", "extension": "", "hash": "19C7XPY3D4QK3861PK0J", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-05T16:16:51.628776+00:00", "index_texts": null, "output": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:49.188562+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "131.0.6778", "end_ts": "2025-12-05T16:16:29.180664+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:23.521322+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=lalitm.com" ], "cmd_version": "8.10.1", "end_ts": "2025-12-05T16:16:17.129939+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:13.567911+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-05T16:16:17.367614+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:17.198150+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-12-05T16:16:43.809989+00:00", "index_texts": [ "Why I Ignore The Spotlight as a Staff Engineer - Lalit Maganti (https://lalitm.com/main.min.css) (https://lalitm.com/theme.png) (https://lalitm.com/github.svg) (https://lalitm.com/linkedin.svg) (https://lalitm.com/bluesky.svg) (https://lalitm.com/rss.svg) (https://lalitm.com/favicon.ico) (https://lalitm.com/apple-touch-icon.png) (https://lalitm.com/software-engineering-outside-the-spotlight/) (https://lalitm.com/) Lalit Maganti (/page/about/) About (/page/archive/) Archive (/page/about/#subscribe) Subscribe (https://github.com/LalitMaganti) github (https://linkedin.com/in/lalit-maganti-18b73a9a) linkedin (https://bsky.app/profile/lalitm.com) bluesky (https://lalitm.com/index.xml) rss Why I Ignore The Spotlight as a Staff Engineer Dec 4, 2025 Lately I\u2019ve been reading (https://www.seangoedecke.com/) Sean Goedecke\u2019s essays on being a Staff+ engineer. His work (particularly (https://www.seangoedecke.com/the-spotlight/) Software engineering under the spotlight and (https://www.seangoedecke.com/not-your-codebase/) It\u2019s Not Your Codebase ) is razor-sharp and feels painfully familiar to anyone in Big Tech. On paper, I fit the mold he describes: I\u2019m a Senior Staff engineer at Google. Yet, reading his work left me with a lingering sense of unease. At first, I dismissed this as cynicism. After reflecting, however, I realized the problem wasn\u2019t Sean\u2019s writing but my reading. Sean isn\u2019t being bleak; he is accurately describing how to deal with a world where engineers are fungible assets and priorities shift quarterly. But my job looks nothing like that and I know deep down that if I tried to operate in that environment or in the way he described I\u2019d burn out within months . Instead I\u2019ve followed an alternate path, one that optimizes for systems over spotlights , and stewardship over fungibility . We Live in Different Worlds The foundational reason for our diverging paths is that Sean and I operate in entirely different worlds with different laws governing them. From (https://www.seangoedecke.com/about) Sean\u2019s resume , my understanding is that he has primarily worked in product teams 1 building for external customers. Business goals pivot quarterly, and success is measured by revenue or MAU. Optimizing for the \u201cSpotlight\u201d makes complete sense in this environment. Product development at big tech scale is a crowded room: VPs, PMs and UX designers all have strong opinions. To succeed, you have to be agile and ensure you are working specifically on what executives are currently looking at. On the other hand, I\u2019ve spent my entire career much more behind the scenes: in developer tools and infra teams. My team\u2019s customers are thousands of engineers in Android, Chrome, and throughout Google 2 . End users of Google products don\u2019t even know we exist; our focus is on making sure developers have the tools to collect product and performance metrics and debug issues using detailed traces. In this environment, our relationship with leadership is very different. We\u2019re never the \u201chot project everyone wants,\u201d so execs are not fighting to work with us. In fact, my team has historically struggled to hire PMs. The PM career ladder at Google incentivizes splashy external launches so we cannot provide good \u201cpromotion material\u201d for them. Also, our feedback comes directly from engineers. Adding a PM in the middle causes a loss in translation, slowing down a tight, high-bandwidth feedback loop. All of this together means our team operates \u201cbottom-up\u201d: instead of execs telling us \u201cyou should do X\u201d, we figure out what we think will have the most impact to our customers and work on building those features and tools. Execs ensure that we\u2019re actually solving these problems by considering our impact on more product facing teams. Compounding Returns of Stewardship In the product environments Sean describes, where goals pivot quarterly and features are often experimental, speed is the ultimate currency. You need to ship, iterate, and often move on before the market shifts. But in Infrastructure and Developer Experience, context is the currency. Treating engineers as fungible assets destroys context. You might gain fresh eyes, but you lose the implicit knowledge of how systems actually break. Stewardship, staying with a system long-term, unlocks compounding returns that are impossible to achieve on a short rotation. The first is efficiency via pattern matching . When you stay in one domain for years, new requests are rarely truly \u201cnew.\u201d I am not just debugging code; I am debugging the intersection of my tools and hundreds of diverse engineering teams. When a new team comes to me with a \u201cunique\u201d problem, I can often reach back in time: \u201cWe tried this approach in 2021 with the Camera team; here is exactly why it failed, and here is the architecture that actually works\u201d. But the more powerful return is systemic innovation . If you rotate teams every year, you are limited to solving acute bugs that are visible right now . Some problems, however, only reveal their shape over long horizons. Take Bigtrace , a project I recently led; it was a solution that emerged solely because I stuck around long enough to see the shape of the problem: Start of 2023 (Observation): I began noticing a pattern. Teams across Google were collecting terabytes or even petabytes of performance traces, but they were struggling to process them. Engineers were writing brittle, custom pipelines to parse data, often complaining about how slow and painful it was to iterate on their analysis. Most of 2023 (Research): I didn\u2019t jump to build a production system. Instead, I spent the best part of a year prototyping quietly in the background while working on other projects. I gathered feedback from these same engineers who had complained and because I had established long-term relationships, they gave me honest and introspective feedback. I learned what sort of UX, latency and throughput requirements they had and figured out how I could meet them. End of 2023 to Start of 2024 (Execution): We built and launched Bigtrace, a distributed big data query engine for traces. Today, it processes over 2 billion traces a month and is a critical part of the daily workflow for 100+ engineers. If I had followed the advice to \u201coptimize for fungibility\u201d (i.e. if I had switched teams in 2023 to chase a new project) Bigtrace would not exist. Instead, I would have left during the research phase and my successor would have seen the same \u201cnoise\u201d of engineers complaining. But without the historical context to recognize a missing puzzle piece, I think they would have struggled to build something like Bigtrace. The Power of \u201cNo\u201d One of the most seductive arguments for chasing the \u201cSpotlight\u201d is that it guarantees resources and executive attention. But that attention is a double-edged sword. High-visibility projects are often volatile. They come with shifting executive whims, political maneuvering, and often end up in situations where long-term quality is sacrificed for short-term survival. For some engineers, navigating this chaos is a thrill. For those of us who care about system stability, it feels like a trap. The advantage of stewardship is that it generates a different kind of capital: trust . When you have spent years delivering reliable tools, you earn the political capital to say \u201cNo\u201d to the spotlight when it threatens the product. Recently, the spotlight has been on AI. Every team is under pressure to incorporate it. We have been asked repeatedly: \u201cWhy don\u2019t you integrate LLMs into Perfetto?\u201d If I were optimizing for visibility, the answer would be obvious: build an LLM wrapper, demo it to leadership, and claim we are \u201cAI-first.\u201d It would be an easy win for my career. But as a steward of the system, I know that one of Perfetto\u2019s core values is precision . When a kernel developer is debugging a race condition, they need exact timestamps, not a hallucination. Users trust that when we tell them \u201cX is the problem\u201d that it actually is the problem and they\u2019re not going to go chasing their tail for the next week, debugging an issue which doesn\u2019t exist. But it\u2019s important not to take this too far: skepticism shouldn\u2019t become obstructionism. With AI, it\u2019s not \u201cno forever\u201d but \u201cnot until it can be done right\u201d 3 . A spotlight-seeking engineer might view this approach as a missed opportunity; I view it as protecting what makes our product great: user trust. The Alternate Currency of Impact The most common fear engineers have about leaving the \u201cSpotlight\u201d is career stagnation. The logic goes: If I\u2019m not launching flashy features at Google I/O, and my work isn\u2019t on my VP\u2019s top 5 list, how will I ever get promoted to Staff+? It is true that you lose the currency of \u201cExecutive Visibility.\u201d But in infrastructure, you gain two alternate currencies that are just as valuable, and potentially more stable. Shadow Hierarchy In a product organization, you often need to impress your manager\u2019s manager. In an infrastructure organization, you need to impress your customers\u2019 managers . I call this the Shadow Hierarchy. You don\u2019t need your VP to understand the intricacies of your code. You need the Staff+ Engineers in other critical organizations to need your tools. When a Senior Staff Engineer in Pixel tells their VP, \u201cWe literally cannot debug the next Pixel phone without Perfetto\u201d , that statement carries immense weight. It travels up their reporting chain, crosses over at the Director/VP level, and comes back down to your manager. This kind of advocacy is powerful because it is technical, not political. It is hard to fake. When you are a steward of a critical system, your promotion packet is filled with testimonials from the most respected engineers in the company saying, \u201cThis person\u2019s work enabled our success\u201d. Utility Ledger While product teams might be poring over daily active users or revenue, we rely on metrics tracking engineering health : Utility: Every bug fixed using our tools is an engineer finding us useful. It is the purest measure of utility. Criticality: If the Pixel team uses Perfetto to debug a launch-blocking stutter, or Chrome uses it to fix a memory leak, our impact is implicitly tied to their success. Ubiquity: Capturing a significant percentage of the engineering population proves you\u2019ve created a technical \u201clingua franca\u201d. This becomes especially obvious when you see disconnected parts of the company collaborating with each other, using shared Perfetto traces as a \u201creference everyone understands\u201d. Scale: Ingesting petabytes of data or processing billions of traces proves architectural resilience better than any design doc. When you combine Criticality (VIP teams need this) with Utility (bugs are being fixed), you create a promotion case that is immune to executive reorganizations. Archetypes and Agency Staff Archetypes I am far from the first to notice the idea of \u201cthere are multiple ways to be a staff software engineer\u201d. In his book (https://staffeng.com/guides/staff-archetypes/) Staff Engineer , Will Larson categorizes Staff-plus engineers into four distinct archetypes. Sean describes the Solver or the Right Hand : engineers who act as agents of executive will, dropping into fires and moving on once the problem is stabilized. I am describing the Architect or the Tech Lead : roles defined by long-term ownership of a specific domain and deep technical context. The \u201cLuck\u201d Rebuttal I can hear the criticism already: \u201cYou just got lucky finding your team. Most of us don\u2019t have that luxury.\u201d There are two caveats to all my advice in this post. First, the strategy I have employed so far requires a company profitable enough to sustain long-term infrastructure. This path generally does not exist in startups or early growth companies; it is optimized for Big Tech. Second, luck does play a role in landing on a good team. It is very hard to accurately evaluate team and company culture from the outside. But while finding the team might have involved luck, staying there for almost a decade was a choice . And, at least in my experience, my team is not particularly special: I can name five other teams in Android alone 4 . Sure, they might have a director change here or a VP change there, but the core mission and the engineering team remained stable. The reason these teams seem rare is not that they don\u2019t exist, but that they are often ignored. Because they don\u2019t offer the rapid, visible \u201cwins\u201d of a product launch nor are they working on the \u201cshiny cool features\u201d, they attract less competition. If you are motivated by \u201cshipping to billions of users\u201d or seeing your friends and family use something you built, you won\u2019t find that satisfaction here. That is the price of admission. But if you want to build long-term systems and are willing to trade external validation for deep technical ownership, you just need to look behind the curtain. Conclusion The tech industry loves to tell you to move fast. But there is another path. It is a path where leverage comes from depth, patience, and the quiet satisfaction of building the foundation that others stand on. You don\u2019t have to chase the spotlight to have a meaningful, high-impact career at a big company. Sometimes, the most ambitious thing you can do is stay put, dig in, and build something that lasts. To sit with a problem space for years until you understand it well enough to build a Bigtrace. By product team I don\u2019t mean \u201cfrontend team\u201d: even as a backend engineer, you are still working on some part of what is being served directly to end users. \u21a9\ufe0e This is not exhaustive, (https://docs.perfetto.dev) Perfetto is open source and we do also care about external developers but that\u2019s not why we get paid. From the company perspective, time we spent on open source bugs is \u201cwasted\u201d time but we do it because we believe in the mission of open source. I talked about this more in a recent post, (https://lalitm.com/perfetto-oss-company-prio/) On Perfetto, Open Source, and Company Priorities . \u21a9\ufe0e For what it\u2019s worth, LLMs might not even be the best solution to \u201clet\u2019s put AI into Perfetto\u201d: in my opinion there is lots of value with \u201cold school\u201d machine learning techniques like neural networks. A lot of trace analysis is just pattern matching. This is something I\u2019m hoping to explore more in the coming year! \u21a9\ufe0e Android Kernel, Android System Health, Android Runtime, Android Camera HAL, Android Bionic \u21a9\ufe0e (https://lalitm.com/software-engineering-outside-the-spotlight/) # 00:15 / (https://lalitm.com/tags/career) #career (https://lalitm.com/tags/big-tech) #big-tech (https://lalitm.com/tags/software-engineering) #software-engineering If you enjoyed this post, you can (/page/about/#subscribe) subscribe to my weekly roundup of recent posts, or follow via (/index.xml) RSS . (https://lalitm.com/fixits-are-good-for-the-soul/) We stopped roadmap work for a week and fixed 189 bugs \u2192 " ], "output": "htmltotext.txt", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:43.790383+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "2024.10.7", "end_ts": "2025-12-05T16:16:49.143865+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:45.590996+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "2.2.3", "end_ts": "2025-12-05T16:16:43.763556+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:41.172202+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpr0q61idc", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "0.0.11", "end_ts": "2025-12-05T16:16:32.875260+00:00", "index_texts": [ "Lately I\u2019ve been reading Sean Goedecke\u2019s essays on being a Staff+ engineer. His work (particularly Software engineering under the spotlight and It\u2019s Not Your Codebase) is razor-sharp and feels painfully familiar to anyone in Big Tech.On paper, I fit the mold he describes: I\u2019m a Senior Staff engineer at Google. Yet, reading his work left me with a lingering sense of unease. At first, I dismissed this as cynicism. After reflecting, however, I realized the problem wasn\u2019t Sean\u2019s writing but my reading.Sean isn\u2019t being bleak; he is accurately describing how to deal with a world where engineers are fungible assets and priorities shift quarterly. But my job looks nothing like that and I know deep down that if I tried to operate in that environment or in the way he described I\u2019d burn out within months.Instead I\u2019ve followed an alternate path, one that optimizes for systems over spotlights, and stewardship over fungibility.We Live in Different WorldsThe foundational reason for our diverging paths is that Sean and I operate in entirely different worlds with different laws governing them.From Sean\u2019s resume, my understanding is that he has primarily worked in product teams 1 building for external customers. Business goals pivot quarterly, and success is measured by revenue or MAU. Optimizing for the \u201cSpotlight\u201d makes complete sense in this environment. Product development at big tech scale is a crowded room: VPs, PMs and UX designers all have strong opinions. To succeed, you have to be agile and ensure you are working specifically on what executives are currently looking at.On the other hand, I\u2019ve spent my entire career much more behind the scenes: in developer tools and infra teams.My team\u2019s customers are thousands of engineers in Android, Chrome, and throughout Google 2. End users of Google products don\u2019t even know we exist; our focus is on making sure developers have the tools to collect product and performance metrics and debug issues using detailed traces.In this environment, our relationship with leadership is very different. We\u2019re never the \u201chot project everyone wants,\u201d so execs are not fighting to work with us. In fact, my team has historically struggled to hire PMs. The PM career ladder at Google incentivizes splashy external launches so we cannot provide good \u201cpromotion material\u201d for them. Also, our feedback comes directly from engineers. Adding a PM in the middle causes a loss in translation, slowing down a tight, high-bandwidth feedback loop.All of this together means our team operates \u201cbottom-up\u201d: instead of execs telling us \u201cyou should do X\u201d, we figure out what we think will have the most impact to our customers and work on building those features and tools. Execs ensure that we\u2019re actually solving these problems by considering our impact on more product facing teams.Compounding Returns of StewardshipIn the product environments Sean describes, where goals pivot quarterly and features are often experimental, speed is the ultimate currency. You need to ship, iterate, and often move on before the market shifts. But in Infrastructure and Developer Experience, context is the currency.Treating engineers as fungible assets destroys context. You might gain fresh eyes, but you lose the implicit knowledge of how systems actually break. Stewardship, staying with a system long-term, unlocks compounding returns that are impossible to achieve on a short rotation.The first is efficiency via pattern matching. When you stay in one domain for years, new requests are rarely truly \u201cnew.\u201d I am not just debugging code; I am debugging the intersection of my tools and hundreds of diverse engineering teams. When a new team comes to me with a \u201cunique\u201d problem, I can often reach back in time: \u201cWe tried this approach in 2021 with the Camera team; here is exactly why it failed, and here is the architecture that actually works\u201d.But the more powerful return is systemic innovation. If you rotate teams every year, you are limited to solving acute bugs that are visible right now. Some problems, however, only reveal their shape over long horizons.Take Bigtrace, a project I recently led; it was a solution that emerged solely because I stuck around long enough to see the shape of the problem:Start of 2023 (Observation): I began noticing a pattern. Teams across Google were collecting terabytes or even petabytes of performance traces, but they were struggling to process them. Engineers were writing brittle, custom pipelines to parse data, often complaining about how slow and painful it was to iterate on their analysis.Most of 2023 (Research): I didn\u2019t jump to build a production system. Instead, I spent the best part of a year prototyping quietly in the background while working on other projects. I gathered feedback from these same engineers who had complained and because I had established long-term relationships, they gave me honest and introspective feedback. I learned what sort of UX, latency and throughput requirements they had and figured out how I could meet them.End of 2023 to Start of 2024 (Execution): We built and launched Bigtrace, a distributed big data query engine for traces. Today, it processes over 2 billion traces a month and is a critical part of the daily workflow for 100+ engineers.If I had followed the advice to \u201coptimize for fungibility\u201d (i.e. if I had switched teams in 2023 to chase a new project) Bigtrace would not exist.Instead, I would have left during the research phase and my successor would have seen the same \u201cnoise\u201d of engineers complaining. But without the historical context to recognize a missing puzzle piece, I think they would have struggled to build something like Bigtrace.The Power of \u201cNo\u201dOne of the most seductive arguments for chasing the \u201cSpotlight\u201d is that it guarantees resources and executive attention. But that attention is a double-edged sword.High-visibility projects are often volatile. They come with shifting executive whims, political maneuvering, and often end up in situations where long-term quality is sacrificed for short-term survival. For some engineers, navigating this chaos is a thrill. For those of us who care about system stability, it feels like a trap.The advantage of stewardship is that it generates a different kind of capital: trust. When you have spent years delivering reliable tools, you earn the political capital to say \u201cNo\u201d to the spotlight when it threatens the product.Recently, the spotlight has been on AI. Every team is under pressure to incorporate it. We have been asked repeatedly: \u201cWhy don\u2019t you integrate LLMs into Perfetto?\u201d If I were optimizing for visibility, the answer would be obvious: build an LLM wrapper, demo it to leadership, and claim we are \u201cAI-first.\u201d It would be an easy win for my career.But as a steward of the system, I know that one of Perfetto\u2019s core values is precision. When a kernel developer is debugging a race condition, they need exact timestamps, not a hallucination. Users trust that when we tell them \u201cX is the problem\u201d that it actually is the problem and they\u2019re not going to go chasing their tail for the next week, debugging an issue which doesn\u2019t exist.But it\u2019s important not to take this too far: skepticism shouldn\u2019t become obstructionism. With AI, it\u2019s not \u201cno forever\u201d but \u201cnot until it can be done right\u201d 3.A spotlight-seeking engineer might view this approach as a missed opportunity; I view it as protecting what makes our product great: user trust.The Alternate Currency of ImpactThe most common fear engineers have about leaving the \u201cSpotlight\u201d is career stagnation. The logic goes: If I\u2019m not launching flashy features at Google I/O, and my work isn\u2019t on my VP\u2019s top 5 list, how will I ever get promoted to Staff+?It is true that you lose the currency of \u201cExecutive Visibility.\u201d But in infrastructure, you gain two alternate currencies that are just as valuable, and potentially more stable.Shadow HierarchyIn a product organization, you often need to impress your manager\u2019s manager. In an infrastructure organization, you need to impress your customers\u2019 managers.I call this the Shadow Hierarchy. You don\u2019t need your VP to understand the intricacies of your code. You need the Staff+ Engineers in other critical organizations to need your tools.When a Senior Staff Engineer in Pixel tells their VP, \u201cWe literally cannot debug the next Pixel phone without Perfetto\u201d, that statement carries immense weight. It travels up their reporting chain, crosses over at the Director/VP level, and comes back down to your manager.This kind of advocacy is powerful because it is technical, not political. It is hard to fake. When you are a steward of a critical system, your promotion packet is filled with testimonials from the most respected engineers in the company saying, \u201cThis person\u2019s work enabled our success\u201d.Utility LedgerWhile product teams might be poring over daily active users or revenue, we rely on metrics tracking engineering health:Utility: Every bug fixed using our tools is an engineer finding us useful. It is the purest measure of utility.Criticality: If the Pixel team uses Perfetto to debug a launch-blocking stutter, or Chrome uses it to fix a memory leak, our impact is implicitly tied to their success.Ubiquity: Capturing a significant percentage of the engineering population proves you\u2019ve created a technical \u201clingua franca\u201d. This becomes especially obvious when you see disconnected parts of the company collaborating with each other, using shared Perfetto traces as a \u201creference everyone understands\u201d.Scale: Ingesting petabytes of data or processing billions of traces proves architectural resilience better than any design doc.When you combine Criticality (VIP teams need this) with Utility (bugs are being fixed), you create a promotion case that is immune to executive reorganizations.Archetypes and AgencyStaff ArchetypesI am far from the first to notice the idea of \u201cthere are multiple ways to be a staff software engineer\u201d. In his book Staff Engineer, Will Larson categorizes Staff-plus engineers into four distinct archetypes.Sean describes the Solver or the Right Hand: engineers who act as agents of executive will, dropping into fires and moving on once the problem is stabilized. I am describing the Architect or the Tech Lead: roles defined by long-term ownership of a specific domain and deep technical context.The \u201cLuck\u201d RebuttalI can hear the criticism already: \u201cYou just got lucky finding your team. Most of us don\u2019t have that luxury.\u201dThere are two caveats to all my advice in this post. First, the strategy I have employed so far requires a company profitable enough to sustain long-term infrastructure. This path generally does not exist in startups or early growth companies; it is optimized for Big Tech.Second, luck does play a role in landing on a good team. It is very hard to accurately evaluate team and company culture from the outside. But while finding the team might have involved luck, staying there for almost a decade was a choice.And, at least in my experience, my team is not particularly special: I can name five other teams in Android alone 4. Sure, they might have a director change here or a VP change there, but the core mission and the engineering team remained stable.The reason these teams seem rare is not that they don\u2019t exist, but that they are often ignored. Because they don\u2019t offer the rapid, visible \u201cwins\u201d of a product launch nor are they working on the \u201cshiny cool features\u201d, they attract less competition. If you are motivated by \u201cshipping to billions of users\u201d or seeing your friends and family use something you built, you won\u2019t find that satisfaction here. That is the price of admission.But if you want to build long-term systems and are willing to trade external validation for deep technical ownership, you just need to look behind the curtain.ConclusionThe tech industry loves to tell you to move fast. But there is another path. It is a path where leverage comes from depth, patience, and the quiet satisfaction of building the foundation that others stand on.You don\u2019t have to chase the spotlight to have a meaningful, high-impact career at a big company. Sometimes, the most ambitious thing you can do is stay put, dig in, and build something that lasts. To sit with a problem space for years until you understand it well enough to build a Bigtrace.If you enjoyed this post, you can subscribe to my weekly roundup of recent posts, or follow via RSS." ], "output": "readability/", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:30.826057+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://lalitm.com/software-engineering-outside-the-spotlight/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-05T16:16:29.311574+00:00", "index_texts": null, "output": "Why I Ignore The Spotlight as a Staff Engineer - Lalit Maganti", "pwd": "/data/archive/1764951365.819209", "schema": "ArchiveResult", "start_ts": "2025-12-05T16:16:29.288694+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Why I Ignore The Spotlight as a Staff Engineer - Lalit Maganti", "warc": null, "wget": null }, "link_dir": "/data/archive/1764951365.819209", "newest_archive_date": "2025-12-05T16:16:49.188562+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2025-12-05T16:16:13.567911+00:00", "path": "/software-engineering-outside-the-spotlight/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KBQMS6JFF0C5A6E301HBDFSV", "snapshot_id": "8d01c911-3c71-481a-81e6-ba96a2b6bf3b", "sources": [ "/data/sources/1764951365-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1764951365.819209", "title": "Why I Ignore The Spotlight as a Staff Engineer - Lalit Maganti", "url": "https://lalitm.com/software-engineering-outside-the-spotlight/" }