Nailing the basics: How to collaborate cross-functionally
Amplify your impact by managing dependencies and working well with others — whether in-person or remote
👋 Hi, it’s Torsten. After a long vacation in Taiwan and Japan, I’m back! And I have lots of epic posts in the works for the next weeks; subscribe below to make sure you don’t miss them!
Usually, every week or two, I share actionable advice to help you grow your career and business, based on operating experience at companies like Uber, Meta and Rippling.
If you enjoyed the post, consider sharing it with a friend or colleague 📩; it would mean a lot to me. If you didn’t like it, feel free to send me hate mail.
Being a lone wolf isn’t really a viable strategy in any organization.
I have seen many smart, capable people get passed over for promotions because they weren’t able to work well with others or couldn’t keep cross-functional projects on track. Some were even managed out.
And it makes sense: Almost everything we do at work requires collaboration, regardless of your role.
Marketing needs support from Data Science and input from Design, and needs to coordinate growth plans with Sales
Data Science needs to gather business requirements, relies on Data Engineering for pipeline work, and needs to partner with stakeholders for implementation
And so on.
Collaboration is already critical at the IC level, but it becomes table stakes once you’re a manager. And as with many similar topics, it’s more complex than it might seem at first glance.
That’s what the “Nailing the basics” series is all about: Helping high performers get to the next level by going really deep and providing tactical advice on deceptively simple topics.
As a reminder, this is part 4 in the series; check out the first 3 posts if you haven’t yet:
Part 1:
Part 2:
Part 3:
In this post, we’re going to cover:
How to identify and manage cross-functional dependencies
8 tactical tips to make collaboration successful
How to become a person people want to work with
Let’s dive in.
Part 1: Identifying and managing cross-functional dependencies
The first — and arguably most important — step is to be intentional about collaboration.
If you just “let it happen”, it will often end in chaos. To avoid this, you need to make an effort to figure out 1) when you need input from others or 2) when your work affects others.
Then, you need to manage that dependency in a structured way.
Figuring out where your work intersects with other teams
There are several ways you can identify these dependencies:
Understanding what’s up- and downstream of your team’s work
If you’ve ever worked at a large company, you’ll be able to relate to this:
When I worked at Uber, I was in charge of managing the supply / demand balance in many of our US markets. To do that, we were using several internal tools to analyze data, automate processes etc.
One day, we got an all-company email that one of these tools was going to be deprecated. This caused widespread panic; dozens of core workflows were leveraging this tool, and there was no viable alternative available.
When we followed up with the team owning the tool, it turned out that they had no detailed knowledge of how people were using it. They had assumed all major use cases were covered by other tools, but hadn’t actually confirmed that.
This, to me, is one of the key symptoms of dysfunctional collaboration between teams (or the complete lack of any collaboration).
If you don’t know how your work fits into the bigger picture — i.e., which teams’ work you’re relying on, and who is leveraging your output — now is the time to find out.
And since context like this often gets lost when people switch teams or leave the company, consider taking a few minutes to document it once you do.
Scoping projects
In cases like the example above, one team is consistently producing or maintaining something that another team needs. But that’s not always the case; many times, cross-functional dependencies come up as part of one-off projects.
In these cases, it’s crucial to scope the project as early as possible to identify what you need from others.
That doesn’t mean you actually have to start working on the project right then and there; you just need to figure out who you need to reach out to so you can do it early.
If you don’t, you risk causing an unnecessary fire drill for another team.
Reviewing other teams’ priorities
Make it a habit to read other teams’ planning decks or roadmap documents to see if there is any overlap or dependencies.
You’d be surprised how often teams commit to doing something that they can’t deliver without your (or your team’s) help, without reaching out first.
Similarly, you might find that another team is working on something similar to what you’re doing and you should join forces or at least coordinate your approach.
This is a valuable exercise even as an IC. Your manager will not always be on top of these things, and it shows that you see the big picture and think strategically (which will come handy during promo time).
Build in public
If you wanted to get married in Germany before 1998, you had to publicly announce that in advance so people could voice any concerns.
Why? Because back in the day, it was difficult for the church or authorities to know whether there were any reasons you shouldn’t be allowed to get married (e.g. because you were already married elsewhere). Crowdsourcing this information was easier.
It’s the same at work. It’s hard to identify every single person that your projects affect, so the easiest way to surface potential issues is by making your work public.
Some ways you can do this:
💬 Share your project roadmap on Slack
🎤 Present during all hands meetings
📅 Bring up your current priorities in meetings with people from other teams
Instead of you having to do all the legwork, people will now come to you.
Managing dependencies
Once you know that your work is an input to other people’s work or vice versa, you need to manage that dependency to avoid bottlenecks.
The more complex and important the project is, the more you should rely on formal structure and process.
Step 1: Create a workback plan
You don’t have to create a detailed GANTT chart in Excel, but you need to clearly document what needs to happen by when, and who is responsible.
To do this, you work backwards from the final deadline:
🪝 Who is on the hook for the final deliverable?
🙏 What do they need from others to put that together?
You then keep repeating this until you get to a point where there are no more upstream dependencies (i.e. the work can be done without input from others).
Here’s an example of what that looks like in practice:
Sales needs to deliver their headcount plan and quota roll-up to Finance
To do that, they need Marketing to provide a Leads forecast
Marketing, in turn, needs Data Science to forecast certain metrics like website traffic
That means for Sales to be able to meet their deadline, two other teams need to deliver.
To make sure that happens, you need to work backwards and agree on dates for when Marketing and Data Science will complete their work.
If you expect there to be controversial points (e.g. the Marketing forecast might be too low for the Sales plan to work out), schedule early review meetings ahead of the actual deadline so that there is time to make changes, if necessary.
Step 2: Avoid bad surprises
Set clear expectations
The most common failure mode I’ve seen in cross-functional projects comes from misaligned expectations: One team delivers what they think the other team needs only to realize it’s not exactly what they were looking for.
The core of the issue is that people use terms like “analysis” or “forecast” as if they were standardized. For example, if someone says they’ll give you a “marketing forecast for France”, what do you think you’ll get?
A spreadsheet of monthly Leads in aggregate?
A daily CSV with Qualified Opportunities split by marketing channel?
Something else entirely?
The only foolproof way to avoid this is to write down the exact specs of what will be delivered. This can feel like micromanagement, but nobody wins if you’re talking past each other.
Maximum transparency
The second most common issue is that people align on what needs to be done once in advance and then don’t talk to each other again until the deadline.
If you’re waiting for an important deliverable from another team, set yourself a reminder a week or two before it’s due and check in with them
If you’re on the hook for something, give regular proactive updates to your stakeholders. If something comes up, flag this early so there’s time to find alternative solutions
What not to do:
❌ “Sorry, I wasn’t able to finish this by today. There was an issue with the data pipeline, and Data Eng took a week to fix it, and then we couldn’t get feedback from our Director in time, and also…”
Explanations like the one above are common, but not helpful. You might feel the need to explain what happened, but that’s irrelevant at this point.
Instead, flag the issue as soon as it comes up and focus on what can be done:
✅ “There is an unexpected issue with the data pipeline which will delay the project. However, to keep the original timeline, we can switch to another data source. We won’t be able to do the analysis on the country-level, but everything else can be done in time. Does that work?”
Part 2: Making collaboration successful
Similar to effective communication, there are many small tweaks you can make to how you work with others that make a big difference.
Especially if you’re working remotely (or with people across different offices), it’s important to address things that could cause friction or confusion.
Here are 8 concrete things you can do:
Tip #1: Make your time zone and working hours visible
It sucks when you quickly need an answer from someone only to realize they are already offline because they are three hours ahead. Similarly, you don’t want to get 7PM meeting invites on a Friday.
To avoid this, set your calendar to your time zone and configure your working hours:
In addition, add your timezone to your Slack name (or whatever tool you’re using) so people know during what times you’ll be responsive:
Tip #2: Be responsive
When I was busy, I used to avoid incoming messages completely; I didn’t feel like I had the time to truly digest the message and answer thoughtfully, so I didn’t respond at all.
However, over time, I realized that there is a middle ground: If you skim the message to see if it’s urgent, acknowledge that you saw it (e.g. by using the 👀 emoji) and jot down a quick reminder to get to it later, you can close the loop for the sender (and get them off your back) without wasting more than a minute of your time.
If you want to set expectations with regards to when you’ll properly respond, you can send a simple “Seen this, will respond by tomorrow morning”. If that doesn’t work for the other person, they’ll let you know.
Note: To be clear, I am not saying you need to check every Slack notification in real-time; focus blocks without distractions are valuable. But when you do see a message, give a quick indication you’re aware instead of ignoring it until you have the full answer ready.
Tip #3: Be hyper-explicit and overcommunicate
You can’t complain somebody missed your point if you buried it in a wall of text. Make sure the important parts are 1) front and center and 2) phrased hyper-explicitly.
Here’s what that looks like in practice:
If you say the above, you’re not going to get a preview in time. The request is not worded strongly enough, and nobody feels responsible for it.
Here’s what to do instead:
Lastly, repeat yourself. It might seem weird at first, but in my experience, if you don’t repeat something at least 2 - 3 times, there’s a high chance people will simply forget about it. So:
Start meetings by recapping recent discussions or upcoming milestones
After meetings, share decisions and action items via Slack
Start messages with reminders like “Since we decided to do XYZ…”
Tip #4: Use screenshots and recordings for things that are complex to explain
Many things are difficult to explain in writing, or it simply takes too long to type it up. In these cases, you can often get the point across quickly by using a screenshot or a screen recording.
For example, let’s say you’re giving someone feedback on a homepage redesign. Instead of describing what you want them to change, just take a screenshot and highlight / annotate the relevant piece:
Tip #5: Get sign-off in writing and document it
If you don’t have proof somebody agreed to something, it didn’t happen. In practice, that means if someone approves something verbally (e.g. in a meeting, or in the hallway), you need to follow up and get confirmation in writing.
And make sure you keep a permanent record of it; I learned that lesson the hard way when I got important approvals via Slack, only to realize the messages were auto-deleted 60 days later.
If you need sign-off from multiple people, you can add a tracker to your proposal:
Tip #6: Don’t gatekeep information
Gatekeeping information doesn’t make you important — it just creates unnecessary friction.
Unless something is highly confidential, it should be shared as openly as possible. It’s already difficult enough to get information to flow through a large organization if you actively want it to, so don’t make it even harder.
This means:
Be overly generous with who you copy on emails
Minimize the use of 1v1s and DMs and discuss important things in public channels
I’m not alone with that opinion. NVIDIA CEO Jensen Huang, for example, actively discourages 1v1 meetings:
Tip #7: Protect what you don’t want other people to touch
If you’re collaborating with others on a spreadsheet, there’s a risk they’ll mess everything up. And you can’t really blame them if you don’t make it clear what’s off-limits.
Even better, just eliminate the risk altogether by locking the cells you don’t want people to edit:
Otherwise, you’ll find yourself having these conversations over and over again:
Tip #8: Use version control intentionally
First things first, unless you’re an investment banker in the 2000s, there’s no excuse to send Excel files via email. Google Sheets / Slides does the trick in 99% of cases.
However, if you’re collaborating with multiple people, it gets difficult to keep track of changes in documents.
Luckily, there is a version history feature in Google and Microsoft 365 tools. Almost nobody uses it (I’d estimate about 1% of spreadsheets I’ve seen have named versions), so it’s a great way to stand out.
To make your (and others’) life easier:
Name important versions in the history
Make a copy of really important ones and create a simple tracker to manage them
Part 3: Be someone people want to work with
Being someone that people want to work with pays off — in fact, I’d argue it’s one of the major drivers of accelerated career trajectories.
Here are some things I’ve seen happen first-hand:
Benefit #1: Skipping the line
If you build a reputation for being easy to work with and helping others out, you can “skip the line” in the future.
For example, you can ping a data scientist that you have strong rapport with directly instead of filing a ticket through the official intake form.
Benefit #2: Access to high-profile projects
Not every project is staffed through your manager. Many of the most impactful opportunities I have gotten (and have seen others get) were the result of executives and managers from other teams approaching me because we had successfully worked together in the past.
But how do you become someone people want on their project or team?
In addition to the tactical tips in the section above, there are a few key traits that make a massive difference:
1. Get work done
A shortage of ideas is rarely the bottleneck in a project; it’s usually execution. If you want to add value to a project team, you need to roll up your sleeves and get things done.
There are two ways you can do this:
📋 Structuring and framing problems: Efficient execution requires clarity, so simple frameworks, decision trees or summaries that boil things down to the essentials will get you noticed
🚀 Executing work independently: An occasional meeting for alignment or a problem-solving session as a group can be helpful, but what people really want is for someone to just raise their hand, take a part of the work stream, and get it done
Volunteering for unpopular work (e.g. reviewing a bunch of support tickets for common themes) can be a great way to build a reputation for being a “doer” early on. With AI, you should be able to get this done fairly quickly, but people will be thankful nonetheless.
This doesn’t mean you should become the go-to person for this kind of stuff, but it helps to show you’re not above doing what needs to get done.
2. Be accountable
It’s almost a cliché at this point, but it’s worth repeating: There are few things as powerful as saying what you’re going to do and by when you’re going to do it, and then doing that.
Besides building trust with your stakeholders, it also makes you more productive.
I’ve found that whenever I am not making progress on a deliverable as much as I want to, simply setting a realistic — but ambitious — deadline and letting a stakeholder know (so that there’s external accountability) gives me the focus and motivation boost to actually do it.
If something comes up that truly makes it impossible to deliver, come up with a mitigation strategy and tell your stakeholders.
The focus shouldn’t be on what happened, but how you’ll deal with it (see below).
3. Always be response-able
Being accountable is easy when things are going well. But when things get challenging, you have a real opportunity to stand out.
Most people give up and blame external factors. While that’s understandable, it’s a defeatist attitude. And the time you’re spending trying to cover your ass and coming up with an explanation for why you couldn’t deliver, you could have spent finding an alternative solution.
The best articulation of this that I’ve seen comes from Fred Kofman’s book “Conscious Business” (which was somewhat required reading at my last job at Rippling). The concept he introduces is “response-ability”.
You might not be responsible for the delay or additional challenges in the project (i.e. it’s not your fault), but you are still able to respond.
“You are not responsible for your circumstances; you are response-able in the face of your circumstances.” - Fred Kofman, Conscious Business
4. Respect other people’s time
Everyone at work is always strapped for time, so the most valuable thing you can do for other people is to respect theirs.
Here are two concrete things you can do:
Making it easy for others to help you
Reaching out to others for help is not a big deal as long as you’re respectful of their time.
Here’s what a bad ask looks like:
❌ “The number of Leads between Sales and Marketing reports doesn’t match. Can you help me understand why?”
This type of ask is simply lazy.
What data source are you looking at?
Are all the numbers different, or just a few? How big is the difference?
What have you already investigated and ruled out?
Without asking a bunch of follow-up questions, nobody can help this person.
Here is what to do instead:
Yes, this is much longer, but it saves a lot of back-and-forth by adding all relevant information, and makes it much more likely you get a response.
Do the heavy lifting
There are many cases where a few minutes of work on your end can save other people a lot of headaches.
For example, when you’re editing a document in Google Docs, the other person will be bombarded with dozens of notifications and highlights.
Important questions or changes get buried in a mountain of small copy tweaks or changed font sizes. But there’s an easy fix: Send a separate message summarizing the important stuff.
5. Celebrate wins and share credit (& never steal it)
When you’re heads-down executing, it’s easy to forget to take a moment every now and then and celebrate wins.
But doing this will do wonders to team morale, and people will remember if you give them a well-deserved shout-out (especially if they are on teams that typically get less visibility, like Data Engineering).
And while it’s important to create visibility for your own work as well, don’t do this at the expense of others. For example, even if you did the majority of the work on something, as long as others were involved, share the credit.
It’s not a zero sum game.
💼 Featured jobs
Ready for your next adventure? Here are some of my favorite open roles, brought to you by BizOps.careers (sorted from early to late stage):
Vannevar Labs: Product Operations Lead | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Remote | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 4+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series B | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: General Catalyst, DFJ Growth
Ghost: Business Operations Associate | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: NY / LA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $85k - $100k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 3+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series C | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Union Square Ventures
dbt Labs: VP, Finance & Strategy | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Remote | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 15+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Sequoia, Google Ventures
Figma: Figma Ventures , Corporate Development & Strategy | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF / NY or remote | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $136k - $288k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 6+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Sequoia, Greylock
OpenAI: Special Projects, GTM | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $265k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 6+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Thrive Capital, Khosla Ventures, Coatue, SoftBank
Anduril: Business Operations Associate | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Costa Mesa, CA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $94k - $141k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 1+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Founders Fund, General Catalyst
Plaid: Business Operations | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $135k - $202k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 5+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Index Ventures, Ribbit Capital
Airbnb: Manager, Strategy & Operations EMEA | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: London / Paris | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 10+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Public
Instacart: Chief of Staff to CTO | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Remote | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $194k - $260k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 8+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Public company
📚 What I enjoyed reading recently
7 Real-World Lessons from Data Leaders at LinkedIn, Dropbox & More by
: A collection of 7 webinars with hands-on advice for leaders (and everyone else) in dataMCP (Model Context Protocol): Simply explained in 5 minutes by
: The hottest topic in AI explained in practical termsOffensive vs. defensive data analysis by
: A reminder to be more proactive in data analytics incl. a list of helpful real-world examples from top companiesThe 13 software engineering laws by
: 13 laws, and why they matter, summarized in one place; a great resource to bookmark for later- and : An insightful discussion with a seasoned operator (early at FB, COO at Quip)
Your tips are so amazing, man. Like a collection of decades of experience in one, single place. You need to make a course on all your tips, Torsten! 😄
This is the content I'm on Substack for! Glad you're back!
I'd love to have a meme game as strong as yours 😅