How to Deliver Complex Cross-Functional Projects

Problem

Working on a larger initiative that spans multiple groups is never easy. We have to navigate a complex landscape of contradicting, or at least competing objectives. Getting such an initiative off the ground takes a lot of effort.

As the project goal may not always be in line with the department specific objective, you will need to convince people to include the project in their plan. You will get a lot of nods and a lot of verbal support but they will be reluctant to support you when you ask for a concrete commitment at the end. Also, it is not unusual to have some teams aligned with you but others not; once they realize the support from the other team is not there, they will reconsider their own commitment.

Actions taken

First, I would meet with the teams we had been able to align with. We would meet with their architects or senior technical people, explain the problem to them, and then together explore a solution. We would approach it somewhat hypothetically; given the infinite resources and infinite time, we would ask them how they would do it. Then, with limitations of reality as a guide, we would contrast their approach with the actual available time frame, and together propose a solution which is feasible.

When presenting your proposal for the first time in a large meeting, people might be taken by surprise and push back. I would rather talk to my engineering counterparts before the "big" meeting and ask my PM to do likewise. That would help me better understand whether they will be interested and, at the same time, what they might expect for the meeting. The final decision won’t be reached in the first meeting and may require additional lateral conversations to happen. After multiple rounds of these big meetings, we might reach an agreement.

There will be teams where we fail to achieve an agreement. We will attempt to understand their reasons, inquire about how we can support them, and work on a contribution model if they lack the resources, etc. If we need a disagree & commit, we will escalate with the leadership team.

For example, we can use the open source contribution model to allow some of our developers to learn a partner team’s codebase and contribute. We would need the partner team’s help with onboarding, reviews, and general guidance.

Typically, we would work with their architects to create a short-term solution that solves most of the use cases and aligns their roadmap for a long-term solution. We would make a joint commitment to make it better and improve the nuances after the project was shipped, a win-win for all the teams.

Lessons learned

• Identify and address dependencies early. Be aware of the things within and outside of your control and focus on the external factors first.
• Don't assume plans are set in stone always, especially if you're working on a project that spans many quarters. Communicate changes and new findings regularly and with other teams. People tend to forget about their commitment, so you have to remind them mindfully. Perhaps, as things change on both sides, you will have to enforce the commitment more strongly.
• Help approvers make decisions by helping them recognize the trade-offs, and explain the factors that are involved in the decision -- such as time, scope and the resources. Our company uses a formal framework for making decisions called DACI (https://www.atlassian.com/team-playbook/plays/daci) that describes how decisions are made and documented.
• Maintain clear communication and let the leadership team know what's going on. If you have an executive sponsor, keep them informed of progress and challenges, ask for specific feedback, and seek resources.