In partnership with
I’m grateful you’re here. If you enjoy this newsletter, please tell your friends and colleagues and become a paid subscriber.
There's a kind of friction that shows up in healthy companies: your team is doing fine on paper, but you're spending real hours absorbing someone else's gaps. Maybe another team isn't holding up their side of shared reliability. SLOs slip, alerts are noisy or missing, and your engineers end up doing triage work that isn't really yours to own. Or a partner team takes forever to make an important decision, and your roadmap sits in a holding pattern while you're still accountable for dates.
The instinct in those moments is often to stay quiet. You don't want to be difficult. You don't want to look like you're throwing another team under the bus. You tell yourself it's temporary, or that raising it will make things awkward in the next cross-functional meeting.
Sometimes that's true. A lot of the time, silence just encodes the problem into "how we work here," and your team pays for it on nights and weekends.
You can speak up without picking a fight. Chances are you're not the only one seeing the issue, and putting words to it can help your peers, too. The goal is to name a joint dependency with enough specificity that it can actually get fixed.
A thank you from this week’s sponsor:
Become An AI Expert In Just 5 Minutes
If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.
This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.
Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.
When you're deciding whether to escalate something cross-team, you can run a few checks first.
1. Is this a pattern, or a one-off rough patch?
Everyone has a bad sprint or gets so bogged down with incident work that they get off their day-to-day track. The bar for a conversation is repeatability: the same class of issue keeps showing up, and it's predictable enough that your team has started routing around it. Concrete examples with dates or tickets are what make the conversation grounded. If you can't gather those yet, spend another cycle collecting them before you go in.
2. Can I describe the impact without turning it into a character judgment?
The move that lands is specific and boring: here's what we observed, what it cost us in time or risk, and what we need from a shared systems perspective. Accusing people of not caring or moving slowly puts them on defense before you've said anything useful.
3. What's the smallest forum where this can get solved?
Sometimes the right first step is a peer conversation with their EM or tech lead. Sometimes it's a working group that already owns the surface area. Sometimes you need your manager in the loop because the dependency spans priorities and you don't have the authority to reprioritize their roadmap. I like to keep my manager informed, but I explicitly state when I don't need him to step in. Either way, I want to land with someone who can change behavior and commit to a next step, and I keep the forum as small as that allows.
4. What do I want them to commit to, and by when?
Orgs rarely change course on vague discomfort alone. Bring a concrete ask: an owner for the SLO work, a decision deadline, a joint runbook, a weekly checkpoint until metrics stabilize. If you walk in with shared context and a proposed next step, you're much harder to dismiss as "complaining."
I've watched teams burn months being "easy to work with" while quietly becoming the cleanup crew for someone else's operational debt. I've also watched one direct, well-framed conversation reset expectations in a week. In those cases, what mattered most was whether the person speaking could separate the problem from the people and tie it to an outcome both sides were supposed to care about.
Protecting your team's capacity starts with a clear read on whether the issue is real, recurring, and owned by someone who can fix it. You can do that work without waiting for anyone to hand you permission. When that's true, naming the problem is part of the job, even when the conversation is uncomfortable.