Establishing Task Forces to Tackle Cross-team Challenges

At Smartly.io our engineering organization consists of autonomous teams that fully own their domain and the codebase they work on. Clearly defined areas of responsibility are vital for teams to be able to focus and prioritize their work effectively – but of course, there are always some projects that require multiple teams to cooperate. This article is about one of those projects and how we solved the challenges of cross-team work.

Setting up a cross-team task force

In early 2020 we planned to implement Pinterest Shopping Ads, a product for eCommerce sites that are looking to automate their Pinterest advertising. Pinterest Shopping Ads require synchronising the advertiser’s product catalog with Pinterest. With the way our teams were organized, this project would span across two domains run by the Pinterest team and the feeds team. The Pinterest team owns our tooling for advertising operations on the Pinterest platform, while the feeds team owns all feed management and processing services on our platform.

Working alone, we saw that either of our two teams would lack huge chunks of the context necessary to pull this off efficiently. Our chosen approach was to form a temporary task force consisting of members from both of these key teams – think of it like a highly focused virtual team building a minimum viable product.

Ingredients for successful cross-team projects

The idea is to get the discovery phase and initial implementation done as quickly as possible before finally disbanding the task force and returning back to the typical team activities. Here’s how we did it:

Prioritizing task force work

The point of the task force was to bring the contextual knowledge of the two teams together to enable smooth progress on a large cross-team project. That shared context is lost if members of one or both of the teams are pulled away.

To crystallize the focus of the task force, the members were exempt from their usual team routines. While they did have their daily stand-up, it was in the scope of the task force itself, not with their individual teams.

Activating discovery mode

A project spanning the domains of multiple teams will most certainly involve plenty of discovery work, as there’s likely a vision of the end goal but not necessarily a detailed project plan. Deep diving into the codebase will probably unearth a host of unknowns and previous architectural decisions that may need to be reworked to pull the project off. This discovery work benefits from having members of involved teams working together to reduce lag in round-trips of communication.

Assigning leadership and following progress

As with any project, it’s good to have someone whose responsibility it is to facilitate the planning and the communication with stakeholders. This temporary task force was no different: lacking an “official” team lead, one of the members in the task force took up these responsibilities alongside their development work.

Of course, the task force’s progress doesn’t just concern the project at hand, as the availability of engineers affects their own teams’ plans in the near future, too. To support individual teams’ planning, it is good to have frequent checkups on the progress of the project together with the project team and their own team leads. Periodically check if the project is really progressing towards the goals initially set for it. If not, is there something that can be changed to unblock the progress? What still needs to be done to consider the project completed?

Disbanding the task force

The time will come when the task force has reached their goal, and what happens after should be carefully considered even before the project. Should the task force be disbanded and the members returned to their own teams? Or should there be an entirely new and permanent team formed around the project’s scope? I would argue that it depends largely on how easily the responsibilities can be shared in the future.

In our case, it seemed rather clear that the task force could be disbanded and the responsibilities split among the already existing teams. The Pinterest-focused team would take up the responsibilities around campaign creation and reporting whereas the feeds/catalogs-oriented team would continue to watch over catalog management.

Running a retro

Having a retrospective after the project helps clear out many of the questions related to future roles and responsibilities. What’s more, these retrospectives also offer a forum for sharing and learning to become better at running these cross-team task forces. The retrospective should involve the task force team and the project stakeholders, such as team leads and PMs from the members’ own teams. Some good topics to discuss during the retrospective include:

• The project itself - What went well and what could have been improved in the planning and execution of the project?
• Communication - Was the progress clearly communicated and the teams kept properly up to date?
• What now? - How should ownership of the project be distributed from hereon? Are there clear responsibilities for existing teams? 

Key takeaways

• Allow the task force to have their complete attention on the cross-team project throughout its duration, but at the same time, aim to keep the project scope as short as possible.
• Assign one member to act as a virtual team lead to facilitate the work and handle communication with stakeholders.
• Set clear goals and milestones for the task force and remember that the project can’t span indefinitely.
• Organize a retrospective after the project. It’s a great medium for discovering what could be done better for the next project.
• Think about which team will eventually own the different end results of the cross-team project. The task force might be temporary but the new additions to your product are there to stay and someone needs to maintain them!