Cross-Team Project Management at InVision
InVision currently has over 20 engineering teams focused on building and operating a piece of the InVision platform. To scale this model, each team operates much like a small startup – with their own product manager, designer, engineering manager, and engineers. With minimal coordination outside their team, they ship features quickly.
But as we mature the product, some changes affect more than a single team. New architectural foundations, integrations, or UX design work often impact large areas of the product and require coordination to ensure consistency and an on-time delivery.
Growing from a team of 3 to over 100 distributed engineers in a very short time, we didn’t have much experience managing cross-team or cross-department projects outside an in-office environment. Without some best practices, we often experienced delays due to redundant effort, rework, and confusion on who is responsible for what. Here’s what we’ve learned so far, and we’re still learning.
One Project Lead
After you’ve identified the need to escalate a project to a cross-team initiative, the first task is to identify a single Project Lead. This doesn’t need to be a new individual dedicated to the role, and in many cases, it’s more desirable to choose an individual who has the most vested interest in the success of the project. Typically, for us, this means the engineering manager of the team with the biggest part to play or who is the prime mover of the project.
Start A Project Plan Document
The first duty of the Project Lead is to start or identify a document to serve as the project plan. This document acts as the central source-of-truth for the initiative, and should be the main portal for all other documents or resources on the project.
Define The Goal
Working with the lead Product Manager on the initiative, the Project Lead sets out the goals of the project. What does success look like? What’s our definition of done – the moment when this initiative is marked complete?
The goals and metrics for success should be captured and documented in your project plan document.
Roles & Responsibilities
The Project Lead must identify up front every team that may have a part to play in the success of the project. This includes teams outside the immediate department, such as the platform, analytics, support, or marketing teams.
Each team involved should designate a primary point-of-contact for their team on the project. This is often the engineering manager or lead engineer handling the work on the team. They are the individual responsible for reporting status of their work and disseminating information to their respective teams.
Regardless of title, the Project Lead is empowered to direct the actions of the other team managers as it relates to the initiative. They often do this by providing and documenting clarity on the roles and responsibilities of each team.
Communication, communication, communication
With the project underway, the Project Lead must adopt a mantra of “avoid surprises”. No team involved in the project should be left out of the loop. The project is far more likely to succeed when everyone involved is informed and motivated.
While not every team involved needs to have a say in making the necessary decisions, we can’t stress enough the importance of every team knowing those decisions as soon as possible after they’ve been made.
Pro Tip: If you use Slack, the Reacji Channeler is a great integration for tagging and funneling :gavel: decisions to the teams that need to know.
Daily Stand-ups
Daily stand-ups for a cross-team project may seem like a lot of overhead, but stand-ups serve as an important checkpoint in ensuring the project stays on-track. So have them!
Take running notes in a document.
Ensure the lead from every team is present, and when unable to make it, they should send a representative to standup. As a last resort, when no one is available to attend, they should drop their standup notes into the document ahead of time.
Task Tracking
We use JIRA at InVision, and every team has its own JIRA project. Because of this, a single view of individual team efforts across a cross-team initiative requires some additional setup.
To do this, we implement a standard JIRA label for the project and set up a filter or board that displays all the tickets across each team. This can also be accomplished with a Confluence page.
Documentation
Document sprawl is a problem for any widespread initiative. In almost every case to date, a cross-team project starts on a single team and involves more teams as it approaches implementation. As a result, there are often many discovery and ideation documents floating around – and many of them contain out-of-date decisions. A single team working from outdated information is a serious schedule killer.
The Project Lead must prioritize the centralization of the project’s documents. Rigorously deprecate out-of-date documents as they’re discovered. Putting all project documents into a folder or project space is a great first step, but the project plan should link out to all auxiliary documents that remain relevant.
Dependencies & Blockers
Every cross-team initiative has dependencies – by definition. Determining the dependencies up-front is often the most difficult aspect of a cross-team initiative, and no one person or team can discover them all. Each team involved is responsible for harvesting their dependencies and reporting them in daily stand-ups.
I wonder if anyone’s ever run CS classes in pairs, where one class has to write libraries for another class to use.
Because that’s life.
– @dakami
The Project Lead must document and track the dependencies and blockers across the project, but it’s not the Project Lead’s responsibility to identify or resolve dependencies.
Meeting and Discussion Facilitation
The Project Lead should identify when it’s necessary to schedule an ad-hoc meeting to discuss a topic.
In the event of disagreement, after listening to each team’s input, the Project Lead is empowered to make a decision to move the project forward.
But it’s also the Project Lead’s responsibility to recognize when a decision requires executive sponsorship or approval.
Milestones
The Project Lead should establish interim milestone dates to keep everyone tracking to the overall schedule. The daily stand-ups should be used to keep everyone accountable to these important dates.
Schedule
The Project Lead keeps the overall schedule up-to-date.
A best practice is to separate the status and schedule reporting of a cross-team project from any projects for which a single team alone is responsible.
Reporting Status and Risks
Lastly, the Project Lead is responsible for reporting the project’s status to leadership.
This should include an assessment on how well the project is tracking against the target date, the quality of the work, the dependencies, and any risks that may affect our ability to hit that date. Risks could be resource constraints, scope changes, technical limitations, etc.
The mantra of “avoid surprises” applies not only to the teams doing the work, but executive leadership as well.
Retrospective
More than any other project, with all its moving parts, a cross-team initiative requires a retrospective to review what went well and what could be improved for next time. Be sure to include all the major stakeholders across each team. Retrospectives can sometimes be difficult to schedule, and while not preferred, it’s possible to hold them in an asynchronous manner using a collaborative document.
Conclusion
By their very nature, cross-team initiatives require more coordination to increase the likelihood of success.
Follow these best practices and your next cross-team initiative will suffer from far less confusion, uncertainty, and doubt:
- Designate a single Project Lead
- Keep a single document for the project plan
- Set out the definition of success ahead of time
- Designate a primary point-of-contact for each team involved
- Document the roles and responsibilities of each team
- Ensure every team involved knows decisions as soon as possible
- Have daily stand-ups and take notes
- Use a JIRA label or other mechanism to track the work across teams
- Prioritize the centralization and cleanup of the project’s documents
- Ensure each team is harvesting their dependencies
- Empower the Project Lead to make decisions
- Establish interim milestone dates
- Separate the schedule, status, and risk reporting of a cross-team project from other projects
- Have a retrospective