Another engineering team needs to do some work on your team’s domain. Obviously, they need your cooperation, but you are super busy with your own work.
You can usually choose 1 of 3 paths:
You don’t give them attention, and ask them to do the work the best way they can.
You give them delayed attention. They chase you for PR reviews and consultations, which you end up giving days later.
You prioritize helping them to do great work, on time (sacrificing your own work).
The TLDR:
Good engineering teams focus sideways - they put the needs of other teams (questions, requests for help, consultations) before their own 90% of the time. The ones who only focus upward might succeed in the short term, but nobody likes working with them, and it backfires.
Yes, there are risks (I’ll get to them later), but I REALLY believe in that mindset.
It wasn’t always so - the trigger for me was a painful experience while being on the other side.
A couple of years ago, my team had to work outside our domain. Company priorities change, it happens. But oh man, it can suck.
For me, the hardest part of collaborating with other teams is the chaos. Even with good intentions, requests aren’t tracked, so people rely on ‘Slack nagging’ to get what they need - continuously distracting each other. Work falls through the cracks.
Even OpenAI experienced this before moving to Linear: “If you went and assigned an issue to another team, things would get lost.” Engineers hate janky issue reporting apps, so asking teams to “just open a ticket” makes you more annoying, not more helpful.
To prioritize other teams’ requests, you need visibility into where everything stands. Teams that switch to Linear handle requests faster - not because engineers suddenly care more, but because the tool doesn’t fight them.
And the best part is you don’t need permission or a big migration to start - you can actually run Linear alongside your current tracker with 2-way sync. Become the team everybody loves:
Thanks Linear for supporting today’s article!
….I remember one month in particular:
We had a mid-size feature we needed to release, which was in the ‘meaty’ parts of another team’s codebase. We wanted to consult with them, but their EM mentioned the team was super busy and requested to talk only to him.
He of course was busy too… But asked us to add him as a PR reviewer. He chose option #2 - delayed attention.
We ended up chasing him for 2 weeks(!) for a review of the first PR. In the end, he gave some meaningful comments, but we were so frustrated and pressured that we just merged it and decided to address any misgivings retroactively (which I don’t remember ever happening).
Let’s dive deeper into the 3 options you have:
Option #1 - not giving any attention
Now, with Cursor, it becomes a bit easier to understand existing codebases and other domains.
If you are truly overwhelmed, and the feature the other team works on is low risk or on the ‘sides’ of your domain, it’s a valid option.
If you choose that path, make sure not to block them or change your mind later on! You should basically say: “You have my blessing to complete this feature as you see fit”.
Personally, I don’t like this option because of 2 things:
A lot of context lives in people’s heads. What decisions were made, why, what should you be aware of. Even small amounts of time from engineers on the ‘hosting’ team can help a lot.
There are always complications. Scope increases, requirements change. Even if you thought it was ‘harmless’, by the time you are involved, you have a monster feature written in your codebase. If nobody from your team is involved, the quality of the code (and of the result) will suffer for sure.
Option #2 - giving delayed attention
This one is the most painful. You decided against option 1 (giving them full permissions) and want to be involved, but you don’t do it on time.
They just started their planning, and they have a couple of questions. You answer it 3 days later - they probably moved on with some partial assumptions they’ll now need to adjust.
They finished the technical design and want your feedback. You give it a week later, once they are already starting to implement. They hate you.
They asked you to review some PRs, and it took you a week to do so. Other engineers depend on those PRs, so a PR mess started to accumulate… Lots of time was wasted just addressing and reconciling everything afterward. They hate you even more.
This is the worst option by far.
Think about the cost here. If your team had dropped what they were doing and reviewed the PR within a few hours, what would that have actually cost you? Maybe 2-3 hours of focused work time (at most).
The company paid for it with engineer-weeks of degraded productivity, plus technical debt from messy merges, plus demoralized engineers.
It doesn’t make any sense in my opinion. If you anyway decided to spend the time to participate in the effort, what have you gained by delaying?
It’s very similar to healthy code review practices. There is a reason Google has the following guideline: “If you are not in the middle of a focused task, you should do a code review shortly after it comes in.”
The same principle applies to unblocking other teams, but I would take it even further:
Option #3 - prioritize unblocking other teams
The biggest argument I hear against this approach is: “But what about my own work? My team will get a reputation for never being on time”.
Let’s take an extreme scenario:
It’s the last day of the quarter, and two teams have critical initiatives they want to launch today. You have a single engineer who needs to wrap up their things. The second team finds they need a relatively small change in your domain, but it would take a few hours from that same engineer (they can’t do it themselves).
In reality, it will probably be escalated to a shared manager, and they’ll decide. In my opinion, the default mindset should be to unblock the other team.
Let’s assume both deadlines are nothing more than reputation hits on both teams’ side (if it’s a ‘hard’ deadline, I really hope you would have known in advance...).
If you choose to finish your own task: Your team will make it on time. The other team will be late, and will probably mention your team as the reason…
You choose to help the other team:You will be late. The other team will be on time - and for sure they’ll mention your team saved them.
If it happens multiple times, the reputation you will gain is of a team that is always delayed, but also always helps other teams. It might even help you get additional hires.
This doesn’t even take into account the benefit of other teams being quicker to unblock you when things switch around!
What about setting boundaries?
In an ideal world, teams have some shared planning and know to raise flags in advance, so the team you depend on saves some time to help you at the right moment. Very often it’s not the case. You find out the dependency too late, or the scope of it is bigger than you think.
These are the cases I’m talking about in this article - but teams need to improve.
Some teams and individuals will abuse your team. They’ll not do any ‘prework’ themselves, and expect you to do their work for them. They’ll be lazy, and not try to anticipate their needs in advance.
You cannot treat those people the same - it’s a recipe for being a low-performing team (see the “overgiving” section in this article).
I would err on the side of helping the first time it happens, while explaining what they could have done better. Same the second time. If it continues to repeat - it’s up to you as the EM to step in, set a standard, and even block them if needed.
Final words
There is a wide involvement scale, my point is not to be deeply involved every time. It’s ok to decide to just be available for critical questions, as long as you set the right expectations. But once you have decided that, do it in a timely and helpful manner, putting their needs before your own.
In Give and Take, Adam Grant shared the surprising reality that givers (people who give unconditionally, and who will spend hours helping you without expecting anything back) are the most productive type of people! Even more than matchers (people who will gladly help you, if they know you will help them in the future or helped them in the past) and takers (people who prioritize themselves).
I believe the same concept works for teams.
Discover weekly
Coding at work (after a decade away). by Will Larson. Beautiful article about getting back to coding in 2025, and how to not mess it up.
