Googlyness — L7 Behavioral Reference

S Five product teams each ran their own ML inference stack. Costs were doubling year-over-year and reliability varied wildly — but consolidating threatened each team's autonomy. Two SVPs sponsored the teams, with directly opposed positions: one wanted a central platform, the other wanted to keep things federated.

T I had no direct authority over any of the teams. I was a staff engineer in the platform org. I needed to drive consolidation that would save roughly $30M a year, without making it a top-down mandate — which would have triggered active resistance from the federated camp.

A Three things, in sequence. First, I spent two weeks doing nothing but interviewing engineers across the five teams — not pitching anything, just listening. The shared pain wasn't infrastructure cost (the org's pain); it was model deployment latency (the engineers' pain). That re-framing was the entire game. Second, I wrote a proposal that addressed both: a federated platform with central deployment infra but team-owned model logic, governed by measurable latency SLOs. I made the autonomy concern explicit in the doc and showed exactly how it was preserved. Third, I built a working prototype with one volunteer team and shipped a 40% latency improvement in six weeks. At that point the other teams asked to join. The proposal stopped being a proposal and became their roadmap.

R By Q4, all five teams had migrated. Costs dropped 38% YoY. The previously skeptical SVP publicly endorsed the design at the all-hands. The thing I was proudest of: the engineers who had been most resistant ended up on the design council and shipped the next iteration.

S Leadership had committed to migrating our entire data platform to a new open-source stack within nine months — a decision announced at company all-hands. I was four months in. My evaluation strongly suggested the migration would actually take 24 months and create 18 months of degraded performance for our top ten customers.

T I needed to surface this without being the new person who walked in and said "you're wrong." The CTO had personally championed the plan.

A I built a red-team analysis with three options: aggressive migration (the announced plan); incremental migration with feature-parity gates; and parallel-stack with selective workload migration. I presented to the CTO 1:1 first — not in a forum where he'd be defensive. I led with what I agreed with: the strategic direction was right; the timeline was the issue. I had a concrete cost-benefit on the parallel-stack option showing a three-month delay versus 0% customer impact. The CTO took it to the next leadership offsite. They adopted the third option. Crucially, in my followup writeup I attributed the decision to him, not me. I wasn't trying to win; I was trying to ship.

R We migrated 80% of workloads in fourteen months with zero customer-impacting incidents. The remaining 20% — the long tail — moved over the following year, exactly as planned. I later learned the CTO had had similar private concerns but no one had ever given him a credible alternative to anchor on.

S Our VP had decided to onboard a strategic partner whose stack required us to expose internal APIs that bypassed our standard auth layer. I believed this was a security regression and that the "temporary" special-case auth would become permanent.

T I was the on-call security engineering lead. The deal was already drafted. The VP needed sign-off from our org by Friday.

A I wrote a one-page risk doc — not a thirty-page review — and asked for a 30-minute meeting. I went in with three asks ranked: kill the deal; keep it but add a hard six-month sunset on the special path; or keep it but isolate the partner on a separate environment. I led with "here's what I'd do if I were you, and here's why," not "don't do this." He pushed back on option one for business reasons that turned out to be valid — reasons I hadn't fully understood going in. We landed on option two with a written sunset commitment in the partnership SOW. I sent a one-paragraph confirmation note immediately for the written record.

R The sunset hit on schedule six months later and we built the clean integration. More importantly, the VP started looping me in earlier on similar deals. I was wrong about the threat magnitude — we never saw an exploit attempt — but right about the structural risk that special cases ossify.

S A director two levels above me had committed externally to a Q1 launch on an ML feature. I believed there was a fundamental evaluation gap — we were measuring against a benchmark that didn't reflect production traffic distribution.

T Pulling the launch would be embarrassing for him and visible to his manager. I had to surface the issue without making it a blame conversation.

A I refused to be the person who said "I told you so" afterwards. Privately, I built a counterfactual analysis using thirty days of replayed production traffic. It showed the model would underperform the existing system on the top three traffic slices by 12–18%. I sent it to him with the subject line "Optional pre-read; I'd value 15 min before launch." He read it, agreed, and we delayed by six weeks. He took ownership of the delay externally. I deliberately did not take credit; in my one-on-one with my own manager I emphasized his decision-making, not my analysis.

R The launch went well six weeks later, beating the prior baseline by 8%. The director publicly attributed the catch to "rigorous evaluation discipline on the team" — the right framing, in my view. He has since made the approach a standard pre-launch checklist used across the org.

S Three years ago I was lead architect on a real-time pipeline rewrite. The existing system was Kafka plus Storm. I led a decision to migrate to Flink because of its state-management benefits on paper.

T I was the most senior engineer in the room. The team trusted my read on it.

A I significantly underweighted operational maturity. Flink had cleaner abstractions, but our SREs had near-zero runtime experience with it. I optimistically assumed we'd build expertise during the migration. We didn't. We hit subtle state-corruption issues in production at scale that we had no muscle memory to debug. The launch slipped five months and we had two P0 incidents that affected customers.

R Direct impact: roughly $2M in delayed revenue from a B2B contract dependent on the pipeline; a trust hit with our top customer; team morale at a multi-year low. I wrote the postmortem myself and was the sole author of the "what went wrong" section. Three things I've permanently changed: bias toward boring tech we already operate, unless there's a 5x-or-better reason — and "cleaner abstraction" isn't 5x; ask SREs about ops experience before the design doc is written, not at sign-off; build explicit on-call simulation into any platform migration.

S I'd promoted an engineer to TL of a 12-person team. He had top technical chops and I had pattern-matched his communication style to my own. Within four months, two senior engineers had asked to transfer out.

T I needed to figure out whether to coach, transition, or partner him with a stronger lead.

A I delayed too long. I told myself it was a "ramp issue." I ran 1:1s and the team kept saying "fine" — partly because I was his manager and the room wasn't safe. It took an exit interview from the second departing senior to make me see clearly: he wasn't ramp-blocked, he was a poor fit for a leadership role at this scale. I had been protecting my own decision rather than the team. Within a week of that exit interview I had a direct conversation with him, offered a senior IC role with no comp impact, and we co-recruited a new TL together. He accepted — and is one of the best senior ICs in the org today.

R We retained him; we lost one senior we shouldn't have. Two principles I locked in: skip-level 1:1s are not optional (I now run them quarterly with everyone two levels down); when my gut says a promotion isn't working, I trust the gut at week 8, not week 24.

S Engineer M was a senior, three years on the team when I joined. Technically excellent — she'd written the indexing core every query in our system touched. But two consecutive promo cycles for staff had not landed. Her manager had effectively given up.

T I read M's design docs end-to-end and found one common thread: they were technically brilliant and politically tone-deaf. She wrote "option A is correct" rather than "option A optimizes for X; option B optimizes for Y; here's why we should pick X." She wasn't bringing other people along; she was issuing verdicts. Promo committees were reading her as a brilliant individual, not a force-multiplier.

A Three things over six months. First, I pair-doc'd one design with her. I narrated my edits aloud: "I'd add this paragraph to make the dissenting position visible because the reader who disagrees with us needs to feel heard, otherwise they spend the meeting in defensive mode." Concrete, mechanical, copyable — not advice, but a template. Second, I asked her to run a cross-team architecture guild — quarterly tech talks to engineers outside our org. This forced her to articulate trade-offs to people with different priors. After three talks she was a different communicator. Third, I connected her with a director two levels up who needed someone to drive a cross-team architecture review — not as a favor, but because she was the right person for it once she could communicate.

R She made staff the next cycle. Two cycles later she was a principal. She has since taken two of her own engineers from senior to staff — the multiplier compounding.

S Engineer R was an L4 hired into a team where his manager kept assigning him toil — on-call rotation cleanup, flake fixes — for over a year. He was technically strong but losing motivation; I'd watched him at lunch get progressively quieter.

T I wasn't his manager. But I was the senior engineer his manager respected.

A I had a direct 1:1 with the manager. I named it: "You are going to lose R within three months and I think you should know that." I had specific evidence. In our last design review R had shown up with an unsolicited 8-page improvement to our caching layer that was better than anything I had proposed. He was operating below his level by a wide margin. The manager pushed back — "someone has to do the toil work." I countered: that's a structural problem to solve, not a person to assign. I offered to take responsibility for restructuring how toil was distributed — rotating monthly across the whole team — in exchange for R getting the cache project full-time.

R Within three months R had shipped a refactor that reduced p99 latency 40%. Promoted to L5 the next cycle. He's now an L6 staff engineer leading the data plane.

S A critical inference service showed 5x latency degradation on a Friday at 4pm. Customer impact was visible. We had three theories: an ML model regression from a deploy 30 minutes prior; GPU thermal throttling in one rack; or a downstream KV store issue. The on-call had been chasing the thermal theory for an hour.

T I'd been called in as senior incident commander. We had ~30 minutes before US-East peak load.

A I made a forced choice. With incomplete information, I had to pick the highest expected-value action. I rolled back the model deploy unilaterally. Reasoning: it was the most recent change, so the Bayesian prior favored it; the rollback was reversible in five minutes; the other two theories would be slower to fix even if they were the actual cause; and rolling back "unnecessarily" had low cost — minor reputational only. I told the team explicitly: I'm going to do the cheap reversible action first, even at 60% confidence it's not the cause.

R Latency recovered in four minutes. The postmortem found that it was the model deploy — an edge case in the new tokenizer. But more importantly, the incident codified a principle I'd been informally applying. We named it "cheap rollback first" and made it explicit in the IC playbook. MTTR across the org dropped roughly 30% over 18 months.

S Mid-2023, my org had committed to building an internal LLM platform. Two months in, OpenAI released function calling and the GPT-4 API made several of our intended platform capabilities effectively commoditized.

T The team was 14 engineers, four months of sunk effort. The director was uncertain. I was the tech lead.

A I led a two-week kill-or-pivot analysis. I refused to do this in a single meeting because I didn't trust my own first instinct. We built a 2×2 matrix: build vs use external API, crossed with text-only vs multimodal. I deliberately went and talked to eight product teams about real workflows — not asking "do you want our platform" but "what's actually in your way." What I found: the value wasn't in the LLM itself; it was in the data pipelines, the evaluation infrastructure, and the policy layer surrounding the model. So we pivoted: from "build our own LLM serving" to "build the eval, prompt-versioning, and policy infra around external models."

R Twelve months later that platform was the centerpiece of every LLM-using product in the company — saving roughly $20M+ in compute we'd otherwise have spent on the wrong layer. The team kept ~80% of its engineers, who pivoted with us — partly because I was honest that the change meant the original plan was no longer right.

S In 2022 we were preparing a flagship launch tied to a CEO keynote — date non-negotiable. Four weeks out, our user research showed onboarding was confusing 30%+ of new users; they were dropping off at step 4.

T I was engineering lead for the consumer surface. PM and Marketing wanted to ship as-is and "iterate post-launch."

A I refused the binary frame. I proposed three options to the launch committee: ship as-is (confirmed risk); delay (off the table); or ship with a constrained launch — small geographic rollout, 5% of intended traffic — using the remaining four weeks to polish the keynote-friendly subset, with the broader rollout four weeks after the keynote. I built option three with the team in 48 hours as a working prototype. Critically, I framed this as protecting the keynote, not delaying the launch. Marketing got the demo they needed; users got a polished surface; we got data from the 5% before broader rollout.

R The 5% rollout showed onboarding completion at 71% — against 60% projected from the prior version. Broader rollout five weeks later hit 78%, significantly above target. The CEO referenced the launch on two subsequent earnings calls. The team adopted "staged launch with measurable user thresholds" as default.

S Q4 2021. We had agreed to ship a feature for an enterprise customer worth $15M ARR. Six weeks in, we discovered the planned implementation would expose customer data to a third-party processor in a way not explicitly covered by their contract. Legal said "covered." I read it as "technically covered, materially not what they expect."

T The account team wanted to ship. My engineering manager said "not our call."

A I stopped the ship. I called the customer's tech contact directly — not to escalate, but to verify my read. I asked: "When you signed this, did you assume X data would touch processor Y?" He said "absolutely not." I went to our VP with the customer's exact quote. We changed the implementation, added three weeks, informed the customer of the issue and our fix proactively.

R We delivered late. The customer renewed the following year for $22M and cited "how you handled the data thing" as the top reason.

S My peer staff engineer ran a critical platform. Technically excellent — but she had developed a pattern of dismissive code reviews. Engineers were avoiding submitting PRs to her. I'd watched two engineers route PRs through me to avoid hers.

T I noticed the pattern for two months and told myself it was "her style." Then I realized I was the kind of peer who saw the problem and let it grow. Silence was endorsement.

A I asked for thirty minutes over coffee. I didn't sandwich it. I said: "I want to share something hard. I think you don't see it. Two engineers in the past month routed PRs through me explicitly to avoid your review. I have specific PRs in mind. I want to share them with you because I think you'd want to know." I had four specific PRs and six specific comments she'd left, with my read of why each landed as dismissive. She got defensive in the moment. I let her. I said: "You don't have to agree with me. I wanted you to have the data."

R Two weeks later she came back and said she'd reviewed her own comments and seen what I meant. She privately apologized to two of the engineers. Within six months her reviews had a noticeably different tone. She thanked me later — said no one else had ever told her.

S My skip-level director had a habit of asking technical questions in design reviews that came across as gotchas — even when his intent was genuine curiosity. Junior engineers visibly shut down. After one review where a strong L4 left visibly demoralized, I knew I had to say something.

T I asked for time on his calendar. I deliberately didn't tell my manager — making it a coalition would have made it political.

A I went in and said: "I want to share an observation. It's possible you're aware of it. After Tuesday's review, [engineer name] told me they walked out feeling that the room had decided they weren't competent. I've thought through the meeting and I think I understand the pattern. Can I show you what I see?" I had specific moments: tone, timing, the way questions were phrased. I framed every observation as how it landed, not what you intended. He was quiet through it. He said "thank you, I need to think about this." I said "no rush."

R Two weeks later I got a 4-paragraph email — the most thoughtful thing I'd ever read from him. He'd watched the meeting recording. Acknowledged the pattern. Asked if I'd flag him privately when I saw it again. I did, twice. Both times he course-corrected within the same meeting.

S Late 2021, I was principal engineer on our search team. Our core ranking infrastructure was eight years old. It worked, but every team that touched it lost ~3 weeks per new feature on infrastructure friction. I also saw the LLM wave coming and knew the existing infra wouldn't accommodate dense retrieval at all.

T I didn't propose a rewrite — the trap junior staff engineers fall into. I proposed a three-year vision: Search Platform 2024 — serving 10x more diverse queries with one-third the maintenance burden.

A A 20-page doc with three layers: an end state describing the architecture in 2024; a migration path with explicit milestones every six months and rollback gates; and — critically — a section called What We Won't Do with explicit anti-goals like "we will not consolidate ranking and retrieval into a single service" even though it was tempting. I didn't ship the doc cold. I spent four weeks doing review pre-meetings with each of the seven team leads who'd be impacted. I changed the doc eleven times. The version that ultimately circulated had seven names on it as co-authors — including two people who'd initially been opposed.

R The vision survived contact with reality unevenly. Year one: shipped the embedding-ready retrieval layer five weeks ahead of plan. Year two: had to delay the consolidation milestone by six months when GPT-4 changed our latency-budget assumptions. We rewrote the milestone publicly — we didn't pretend it was on track. Year three: the original anti-goal of "don't consolidate ranking and retrieval" became wrong because of how dense retrieval evolved. We reversed it explicitly with a doc that referenced the original anti-goal and explained why it had to change.

S Eighteen months ago I led a vision for how our company would adopt LLMs internally for engineering productivity. Starting state: 200 engineers, no internal AI tooling, individuals using ChatGPT off-channel with no enterprise license. Real risks: data exfiltration, IP exposure, no shared learning of what was working.

T I needed a 2-year strategy, but more importantly, one that wouldn't die in security review.

A I wrote a 12-page doc: AI-Augmented Engineering — what 2025 looks like. Three concrete goals: by Q3 2024, every engineer has a sanctioned, observability-enabled AI coding setup; by Q1 2025, 30% of all PRs have AI assistance acknowledged in commit metadata; by Q3 2025, we know — with data — which engineering tasks AI accelerates and which it slows down, broken down by team and seniority. Critical move: I co-authored with the CISO from week one. I knew the vision would die in security review otherwise.

R I was wrong about one major thing. I'd assumed senior engineers would adopt fastest. The data showed the opposite — junior engineers adopted 3x faster. I wrote a follow-up post titled What I got wrong about AI adoption and it became the most-read internal post that quarter. Senior engineers actually started adopting faster after that post — because I'd publicly admitted my error, the social cost of admitting they'd been hesitant dropped.

S I joined a 22-person platform team in late 2022. Team state: four attritions in the prior six months including two senior engineers; team had missed three of four quarterly OKRs; the previous lead had been let go.

T I needed to stabilize without restructuring on bad information.

A First 30 days: I changed nothing structural. I held 1:1s with all 22 engineers, plus eight stakeholder partners outside the team. I asked one question: "What's the thing you want me to know that I won't hear from anyone else?" I took notes longhand. I shared no opinions. What I learned that I hadn't expected: the team's biggest pain wasn't OKRs missed — it was that the prior leader had been calling individual contributors at midnight asking for status. The trauma was specific. Two senior engineers who'd left had been the team's institutional knowledge; the remaining team couldn't see the competence gap because they'd never owned those areas. Stakeholder partners had stopped giving feedback because they'd "given up."

Day 31–60: I framed and shared. I wrote a State of the Team doc that named these things explicitly. I named the midnight-calls thing — privately first, with HR's awareness — and committed to a no-contact-after-7pm policy except for live incidents. I named the competence gap and announced we'd hire two senior engineers with a specific scope, not a generic backfill. I rebuilt stakeholder feedback by holding a quarterly "what we got wrong" session with our top three partners.

Day 61–90: one structural change. I split the team into two pods — one focused on stabilization, one on new investment. I framed this not as efficiency but as protecting the people doing recovery work from feeling like they're missing out on the new shiny thing.

R Twelve months later: zero attrition since I joined; 4 of 4 OKRs hit in second half of 2023; promoted three engineers to senior. The team's most-cited Glint result was the no-7pm-contact policy — not a strategy, a boundary.

S A different scenario: I joined a team three days into a sustained customer-facing incident. There was no "first 30 days of listening" available.

T I had to stabilize and learn the team simultaneously.

A I adapted the principle. I split my time deliberately: 60% on the active incident as a working IC alongside the team (which let me see who was strong, who was stuck, who collaborated, in real time); 40% on shadowing the existing leadership and 1:1s with the people I wasn't directly working with on the incident. I didn't make any structural calls until day 21, after the incident had stabilized. Then I spent days 22–45 doing the listening I'd have done in week one in a calmer arrival.

R Incident closed on day 14. Two engineers I'd initially flagged as "underperforming" from the incident I later realized had been blocked by tooling and not capability — both were promoted within a year.

I'll answer this in three parts: why Google, why this team, what I'd uniquely bring.

Why Google. Two-thirds of my career has been at the layer where systems and ML/AI converge — search, recommendations, real-time inference. There are roughly four organizations on Earth where that work happens at the scale I want to operate, and Google is the only one whose stated mission still resonates with what I want to spend the next ten years on. Specifically: I care about products that make information genuinely accessible, not products that monopolize attention. Search is the rare product where mission and business model align.

Why this team. I read your team's recent paper on [specific paper / launch / architectural choice]. The thing that struck me was [specific decision — e.g., pushing more retrieval work into the leaf rather than the root, or treating multimodal as a first-class signal]. That's the kind of decision I'd want to be in the room for. I've made similar decisions twice in my career; both times I was the most senior person in the room. At Google L7, I wouldn't be — and that's the point. I want to be in environments where I'm genuinely calibrated against people equally good at this.

What I'd bring. I have specific operational experience that I think is rare. I've taken two ML platforms from "research demo with 10 internal users" to "production system with millions of QPS." I've seen the failure modes that show up at the 1M–10M QPS scale that don't appear in textbooks. I've also built evaluation infrastructure that makes ML quality regressions visible — most teams I've worked with had "ship to prod and watch metrics" as their evaluation strategy, and I've changed that on three teams now.

What I'd be honest about. I have less Google-specific cultural fluency than someone who's spent their career here. I'd need to lean on the team to learn it — first 60 days I'd treat as listening. I'd bring strong opinions, but I wouldn't drive structural changes in the first quarter.

Why Google. I think the most important software products of the next decade are the ones that change how people think and work, not the ones that change how people consume content. Google has a product surface — Workspace — that quietly touches more knowledge workers than any other product on Earth. Most people building AI products are racing to add features. The harder, more durable problem is integrating AI into existing workflows in a way that doesn't break the trust people have in those tools. That's the work I want to do.

Why this team. Specifically I've been watching what's shipped with [specific feature, e.g., Smart Compose evolution into agentic drafts in Docs]. There's a product judgment in there that I admire: small, conservative changes to a surface that 3 billion people use. That's harder than building a flashy demo — and far more impactful at scale.

What I'd bring. I've led product-engineering organizations through three large AI integrations in legacy products. The pattern I've learned: the failure mode is not the model; it's the user's loss of control of an interface they've trusted for years. I've built explicit "trust budgets" into rollout planning — how much per-week change a user will tolerate before churn. I'd bring that frame and the eval discipline behind it.

What I'd be honest about. I've operated at hundreds-of-millions scale, not billions. The leap is real and I'd need calibration time. I'd expect the first quarter to teach me more than I teach.