One of software’s strong points is that it is innately… well… soft! You know what is quite more rigid, though? The makeup of the organization creating it. People are a lot less malleable to change than code is. Therefore, we often miss out on opportunities. There are times when pulling your sleeves up and shuffling things about is the right thing to do. How do you run task forces without harming those affected?

The Case For Task Forces

While creating a concentrated effort quickly might be easier at young startups than at bigger companies, I’ve seen even those shy away from such work modes. That is because they fear “breaking the quarterly plan,” seeming capricious, or the people involved will like things are too hectic. Thus, important initiatives get shelved for months until the next quarter comes. Sometimes too many people are assigned to tasks just to avoid changing teams. Or, due to trying to fit with the quarterly cadence of the rest of R&D, a team is given too much time to work on something before we are confident of its value.

It is good to be mindful of the pitfalls of haphazard goal shifting, but going too far in the other direction is also wrong. We shouldn’t be treating the process as sacred. Task forces enable agility, let the company validate ideas quickly, and can create the initial momentum needed in order to leverage a new opportunity.

Nevertheless, just because these are useful doesn’t mean you should form a new one every sprint. Task forces should be relatively rare. If you see that the need to create these teams arises every month, perhaps you would do better by creating such a permanent team. Second, the name task force does not imply that those assigned to it have to work crazy hours or with low standards. They should be teams that deliver quickly by minimizing scope, iterating fast, and building up only after the value has been proven. Lastly, the task force members should not be in “limbo” without any management and guidance for too long.

Managing Task Forces

Having helped several VPs form these task forces recently, here is my suggested checklist for doing so at maximal impact.

Have a definition-of-done: An open-ended task force makes no sense, as it essentially becomes a new permanent team. From the get-go, define the purpose of this team and what it is trying to achieve. Focusing on the goal helps keep the scope to a minimum while also setting the right expectations about the task force’s role.

Time has to be minimal: Task forces should rarely take on something longer than a quarter. In healthy organizations, they are used to validate an idea or bring out specific value quickly. Beyond that point, the work should be put on the roadmap and worked on in the appropriate teams.

One-on-ones all around: The employees assigned to the task force are in a bit of an in-between mode. They have the task force manager, who they talk to about the ongoing work, taking PTO, etc. But they should also remain in contact with their “real” manager, from the team they belong to and to whom they will eventually return. The former should have frequent one-on-ones, while the latter can temporarily reduce the cadence. However, if the employee seems to need the time, there’s nothing wrong with sticking to the same schedule.

Extra managerial attention: Complementary to the previous point, the two managers should regularly sync about the employee. The task force leader might notice areas of growth that the manager is already aware of and working on or see something new. The managers should work in lockstep.

Feedback! Ongoing feedback about the work done can be given by the task force leader, but the “real” manager should still do regular feedback and growth coaching. For example, suppose the company’s regular biannual performance reviews occur during the task force’s run. In that case, the manager should provide feedback as usual while also considering what the task force leader communicated in their regular meetings. Don’t allow a good employee to miss out on a bunch of feedback and growth because they’re in a temporary team.

Stay connected: The task force members should remain close to their original team so they won’t feel estranged when they return. They can pop into daily standups once in a while. They should participate in the team’s ceremonies like retrospectives—and maybe even share what they’re up to every once in a while. Of course, if there are any team activities, like offsite or fun days, they should be invited.

If time allows, they should ideally participate in reviewing pull requests and design discussions with their team. This is so that their expertise in the group isn’t lost and keeps them “fresh” and connected. I know this might seem too much to expect from an employee in a team focused on fast delivery. However, help them realize they can cherrypick the level of engagement according to their current availability. Whatever connection you get to maintain during this period is better than nothing.

Use good processes: A task force being ephemeral does not mean that you can throw good craftsmanship and practices out of the window. The teams should maintain the same high standard of quality that you have, along with sound engineering processes. Those processes might be tailored to the needs of the project. For example, sprints might be shorter, or you might choose to transition to something more Kanban-like. As long as everything is managed professionally, it is fine. Otherwise, members might feel like they are in a project that hurts their career progress and might also have a hard time readjusting once the task force disbands.

Equipped with this, consider: Is there an opportunity worthy of a task force in your company right now? Seize it.