Suresh G

Recently, we witnessed a major production incident at work, one that got me thinking about how we respond in critical moments. The issue happened right after a deployment and the team's initial reaction was to rush for a hotfix. This was driven by the intent to fix the problem quickly. But the result was the opposite: mitigation got delayed, and the impact lasted longer. This was a good reminder that in a high-pressure situation, technical leadership is about prioritisation i.e. restoring stability first, fixing the code later. When an issue is deployment-induced, rollback (if feasible) is almost always the fastest mitigation path. It requires confidence in the process, not in the individual change and is often quicker and safer than fixing things under pressure. Strong engineering cultures build this discipline: - Detect early, rollback fast - Investigate once stability is restored - Learn and strengthen safeguards after the fact In incidents, leadership often shows up not in writing code, but in creating clarity so the team can focus on mitigation, not motion. Would love to hear how others approach similar situations! #LeadershipInTech #EngineeringCulture #IncidentManagement #Postmortem #TechLeadership #OperationalExcellence

32

Operational leverage matters more than people admit. If your team is busy firefighting infrastructure, they aren't solving business problems. True scale requires self-healing systems and minimal manual intervention—a massive organizational unlock. This is exactly what will be unpacked in the session. Thanks Confluent team for partnering in this amazing feat 🙌 Rubal Sahni Rohit N. Diksha Munjal

17

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

At Paddle, we're setting a new standard for developer-first infrastructure. Our API-first transformation with Paddle Billing has delivered significant wins, and our partnership with Postman is a testament to our engineering excellence. Here's a look at the outcomes: - 50% faster onboarding: We've reduced the time to first call by half. - 4x growth in engagement: Our API discoverability has quadrupled. - Shortened sales cycles: An improved developer experience is accelerating sales. Our API-first approach has also greatly improved internal collaboration, with shared workspaces and clear documentation providing instant context for our teams. Read the full Postman case study here: https://lnkd.in/g3K4bvHu

37

Reposting with some thoughts and a potential interview question. Girish T V and Manikandan Thangarathnam: this one fits beautifully with the “science” theme of your post, and is directly inspired by a recent LinkedIn discussion: https://lnkd.in/gwmGJbzt Why does Uber initially show “Uber Go – 1 min”, but after booking, it switches to something like 15 min? We’ve received this feedback often — how would you improve this system? Here’s how I’d evaluate a candidate’s thinking around it: 1️⃣ Bonus Point 1: Do they first question whether the problem is valid? Are there data points beyond anecdotal LinkedIn posts to confirm it? 2️⃣ Bonus Point 2: Do we have a metric for the error gap between upfront ETA and actual arrival? 3️⃣ Bonus Point 3: Do they ask, “What is the current approach?” Improvement starts by understanding what already exists — not reinventing it from scratch.

4

Most systems fail not because they get answers wrong, but because they answer too early. Last week, Santosh Jaiswal articulated this cleanly in his post on “When answering is NOT the right answer.” It resonated because I’ve been working on a framework where UNKNOWNs are not defects to eliminate, but deliberate design artifacts. First-class citizens. https://lnkd.in/gpGW8A73 In complex systems, architecture once made ignorance explicit. We spent time defining what we knew, what we didn’t, and what we were intentionally deferring. In today’s sprint-driven execution model, that step is usually skipped. We build partial truths, demo something that “works,” then pay for it in rework because the boundaries were never declared. AI workflows behave the same way. Give them an incomplete picture and they will still complete it—plausibly, confidently, and often prematurely. The alternative is structural honesty. Partition the problem into phases. Each phase explicitly declares what it will not solve. UNKNOWNs are scoped, tracked, and deferred by design. If you know what not to fill now, you avoid rework later. This pairs naturally with Venkat Pillay’s “Needs” framing: what is required now versus later, driven by evidence rather than optimism. Combined, you get phased architecture where exclusions are explicit and progression is data-backed. AI doesn’t invent answers; it preserves your explicit structure. This is where human cognition becomes more relevant, not less. AI operates inside a defined problem space. Human curiosity defines the space itself. It decides which UNKNOWNs are worth preserving, which assumptions are premature, and which questions should not yet be answered. That requires intent and judgment. Models do not do that. At CloudFrame, this is how we use AI. Translation, analysis, migration—AI excels. For boundary-setting, sequencing, and confronting unknown unknowns, automation stops. Architecture resumes. In an age of powerful automation, the scarce skill is not producing answers; It is knowing when not to.

21

1 Comment

Thanks to Anurag Aggarwal and Ravi Kiran Achalla for encouraging the development of this idea from my earlier post. In response to your inquiry about whether trust architecture guardrails could be integrated directly into application code, I took your feedback to heart and have built a solution. I am excited to announce the release of llm-trust-guard on npm. This TypeScript package provides deterministic guard checks for LLM/agent workflows, addressing concerns such as prompt injection, encoding attacks, memory poisoning, tool-chain validation, trust boundary checks, and more. It also includes integrations for Express, LangChain, and OpenAI wrappers. This release continues the direction I’ve been pursuing: - Architecture-level validation: https://lnkd.in/gdCe5nKj - Code-level guardrail enforcement: https://lnkd.in/gPw7xUuw #AIEngineering #LLMOps #AIGovernance #AgenticAI #TrustArchitecture

27

7 Comments

Came across this Spark learning resource by Vinod K C and really liked how clearly and practically the concepts are explained. Great resource for anyone looking to get stronger with Spark fundamentals and internals https://lnkd.in/gciM7YFr

181

8 Comments