How to get past "no" and beat cross-functional friction as a software engineer
And in some cases, prevent "no" before it even happens
📣 Integrate API users 50% faster (Sponsor)
Creating a frictionless API experience for your partners and customers no longer requires an army of engineers.
Speakeasy’s platform makes crafting type-safe, idiomatic SDKs for enterprise APIs easy. That means you can unlock API revenue while keeping your team focused on what matters most: shipping new products. Make SDK generation part of your API’s CI/CD and distribute libraries that users love at a fraction of the cost of maintaining them in-house.
A few weeks ago, one of the most popular posts on this newsletter was published. Chaitali Narla, ex-Google Director who was promoted every 2 years 5 times in a row, shared the 3 career principles that led to her success.
Those principles were:
Use glue work for showing leadership and core work for technical skills
Have grit. Be willing to power through long challenges. View failures as progress.
Beat friction and unblock those around you
Today, we’ll deep dive into practical strategies for (3)—beating friction. Specifically, cross-team friction.
Here are a few examples you might have experienced:
You need to modify code that another team owns and they’re blocking your changes
Your change affected another team’s metric which needs their approval, and they aren’t giving it to you
You and the other team fundamentally disagree, and there’s no clear path forward
All these will be answered for you and more. You’ll learn 5 tactics for powering through these types of issues. Each one will gradually get more harsh, so try to stick with #1 and #2. Only if those don’t work, use the final few.
1) Figure out what they care most about
Before going into these, I want to emphasize that this is the most essential one. It’s the one that’ll result in the least negative consequences in terms of your relationship with the other team. The others, while still collaborative, raise the stakes and potential backlash in the future.
The first step to any disagreement is understanding what the other side cares about. If you know what’s most important to them, then you can tune all your other communication toward that, which increases the chance you’ll have an outcome both of you are happy with.
So just ask! A framework you can use is asking “Why” until you fully understand the situation.
Example: Let’s assume you want to make a change to another team’s API. You want to add a field because you need that data, but they’re giving you a hard time.
Other team: We already have so many fields on this endpoint and don’t want to add anymore.
You: What’s the reason having more would be a problem?
Other team: Because we want to be wary of performance
You: Makes sense! Do you have benchmarking set up?
Other team: No, we haven’t got to that yet, which is why we’re being cautious.
You: What if I ran some ad-hoc benchmarks before and after adding the field and shared them with you?
Other team: Yeah, we’d be ok with that.
There you go! We went from: “We don’t want to add any new fields” → “What we really care about is performance.” Once you know the root problem you can address, you can do what you need while still addressing what they care about.
Now, let’s say you ran some benchmarks, and they came back with bad results. Let’s continue the conversation.
You: Here were the resulting benchmarks: < benchmarks >.
Other team: Ah, that won’t do. We can’t ship with those metrics.
You: What’s the reason these performance metrics are important to you?
Other team: We track how much our performance went up or down in total each quarter. We have limits on how much it can decrease.
You: Oh, so if I made a totally separate optimization that balanced out this metric, that could work?
Other team: Yep, you could do that.
And see, asking “Why” or “What’s the reason” gets you to another potential solution. It expands the pool of opportunities.
Sometimes, those ideas might not come to your head. In that case, you can prime them with questions to help you. Here are the ones I like:
What other options can you think of?
What conditions would need to be met for this to be possible?
Is there anything you can think of that I can do to make this possible?
These get the other team on your side, helping come up with as many options as possible for you to be able to make your change.
If you only remember one thing: Avoid a “Me vs. Them” mentality. Instead, adopt an “Us vs. The Problem” mindset by asking why it’s important to them.
2) Give options
If I asked you if you’d like a hot dog this second, you probably won’t.
But if I asked you, would you rather eat a hot dog, a piece of dirt, or a piece of wood? That hot dog starts to sound a lot more enticing.
You can apply this same trick to get the outcome you want.
Example: I was working on a feature that needed to touch someone else’s code. That piece of code was outdated and wasn’t using the recommended practices that the team should have been by now. I brought up that I needed to modify their code, but I didn’t want to be the owner of migrating their code, since that would be too much unexpected scope for my project.
I went to their Slack and provided 3 options:
Ideal solution: The team migrates to the best practices and I build on top of that version
I’ll hack around the existing code and add mine on top, which might make the code worse in the short term.
I can disable their feature for anyone in my experiment while I gather data
As unfortunate as it is, most teams won’t do option 1, at least right away. However, it would be unreasonable for a team to say no to everything.
In this case, the team was ok with option 2 or option 3 so I could be unblocked and planned to follow up in a couple of sprints on the ideal solution.
Bonus benefit of providing options: Without doing it, people can’t tell whether you’ve considered other approaches. That consideration builds shared empathy which gets you closer to a “yes.”