Five tips to help lead large cross-functional collaborations

Large cross-functional projects can be difficult to steer. To help mitigate common pain points, consider these pro tips.

Leading large cross-functional projects can be intimidating for recently turned senior individual contributors (ICs) who are on the leadership track. 

These large projects are known to span over several workstreams and require many people, involving complex milestones and timelines. Being the sole accountable point of contact chasing a deadline can therefore be tough. To successfully steer cross-functional collaborations, engineering leaders should not only be responsible for architecting and coding a product well, but communicating effectively, making informed decisions, and rallying a team forward.  

Lessons from managing large projects

The first few large projects that I led lasted anywhere between 12 weeks and six months. These undertakings were a massive learning experience because, initially, I was like a babe in the woods – I had no idea what I was walking into.  

However, in my most recent and largest cross-functional project I led three teams, eight engineers, two designers, two product managers, one data engineer, and one data scientist. Even though I knew that everything might not go according to plan, it was interesting to discover new points of failure with each increasingly complex project. From the get-go, the team couldn’t converge on the user interface (UI) design which impeded progress.

We didn’t understand certain parts of the system we were building on top of and had to pivot to new and more thorough approaches to meet our target timelines. Additionally, our initial A/B test setup had to be restructured since we had underestimated how long it would take to build certain parts of the project.

These sorts of never-seen-before situations and roadblocks will always arise in large efforts. Learnings garnered can be treated as a common denominator across several projects and will eventually help to push forward these cross-functional collaborations. 

Here are some lessons I learnt along the way:

1. Know the unknowns

Proactively seek out the unknowns. Is it a dependency on an external application programming interface (API)? Is it the feasibility to build a certain part of your system? Is the level of effort to build on a certain platform unclear? By frontloading unknowns and systems you’re not familiar with, you mitigate being caught off guard when executing the project.

Pro tip: As the main point of contact, you will be thanked for creating documentation for this. Creating some type of record with a list of unknowns will not only serve the purpose of your current effort but will continue to live on as learnings for future ones as well.

2. Set sustainable timelines and scope

Large projects need to have clearly defined goals and time frames for completion: either the timelines should depend on the scope of the project, or the scope should be pruned based on your timelines. 

When creating timelines, make sure you’re not too attached to them. They should be sustainable; allow enough flexibility so that your team isn’t scrambling and gasping for breath by the end of it. 

Pro tip: When I was starting off as a software engineer, my earliest mentor said, “Be smart with your time estimates for any work you do. If you estimate something to take x weeks, in reality, it is likely to take 3x weeks.” As a result of their advice, I rely heavily on Gantt charts, using spreadsheets to stay on top of timelines. There are plenty of other project management tools available that can also help you with setting and tracking timelines.

3. Maintain changelogs

Changelogs don’t get talked about as much as they should. You’re probably thinking “great, more documentation”, just like I did at some point. But I’ve learnt the hard way that things change over the course of a project, so having a paper trail of decisions is important.

These choices don’t alter the fate of the project, but they might mean a significant change in the amount of work required. Any changes or decisions made should be logged for easy reference. Just had a quick chat with your PM about a new topline metric? Add it to the changelog. The designer just told you they were going to change some parts of the product flow? Record it in the changelog. Have the engineers just reported a possible blocker that might extend your deadline? Changelog it!

Pro tip: Whether you are going to publish changelogs periodically, or let your team and stakeholders know where to look them up, is totally up to you. But having this reference point is imperative. Documents and spreadsheets can be your friends when you’re trying to track dates, decisions, or tl;drs.

4. Keep stakeholders in the loop

And by that, I mean every single stakeholder. There is a varying level of information required by different stakeholders and partners in a large effort. Some partners might want a milestone update, some might want a weekly update, and some daily. Establish a cadence for your communication, and follow through.

Pro tip: When working on long-running efforts, publishing brief progress reports periodically can help keep anxious stakeholders calm, generating interest, and creating excitement about your project. 

5. Create a knowledge repository

This is a personal favourite and probably the most important thing to do when getting organized. As the main point of contact, you are going to be asked several questions about different aspects of the same project by different people. Engineers will want to be reminded of designs, designers will want to understand whether or not everyone’s converged on a product decision, and product managers will want to know if you are tracking any previous, relevant user research. Key stakeholders will want to know what your progress is looking like. 

Context switching to answer all of the above might leave you extremely exhausted and ready to pack up and go home. Creating a go-to space which has all the answers is definitely going to make your life easier. You can think of it as building your own FAQ resource.

Pro tip: There are many ways to implement this, and it depends on the nature of your collaboration. Having a shareable folder with commonly referenced documents and spreadsheets, or a single document which serves as a starting point (or FAQ page) for anyone looking for relevant information can be helpful. 

Final thoughts

Recently turned senior ICs will probably already know what it takes to architect a complex system and push a great product out of the door. I hope that over and above those skills, some of these organizational ideas will help you streamline your efforts and even serve as a foundation for coming up with your own system.