Why spend time building a team around your initiatives? Your organization has already defined teams and boundaries. Your product, program or service has a team allocated. Why would a leader need teams outside of the organizational constructs?
Team Building for Leaders
Your decisions about building a team or not is critical. If you build a team every time there is dissention or conflict, then you spend too much time on team building. If you miss the signs that a team can attack a problem, then you have unplanned issues cropping up at bad times.
Example - build a small team
Suppose your new product launch has investment and the product team is developing the product as planned. You and your product marketing team have a solid go to market plan. One sales team is raising concerns about sales compensation and transacting sales easily. You decide to form a small team to work on the sales concerns. The team meets weekly to define a process for quick quotes that supports the sales governance process. Additionally the team confirms the sales compensation model. You jointly define a large forecast for sales and a sales overlay team is assigned to the launch. You and the sales team receive executive recognition on the new offer.
Example - no small team
One of your colleagues has a similar offer coming out and chooses to ignore the concerns from sales. When the new service launches, there is no sales team responsible for selling it and the sales forecast is small.
Finishing What You Start
While it is fairly simple to pull a team together to work on a problem, it takes creativity to wrap up a small team successfully. By finishing each project team, you have an opportunity to recognize the work of the team and prime the team members to support you in the future.
Example - team built and concluded
Your new product has a limited User Interface (UI) and connections to the customer can't be configured or charged to customers. You need a small team to define the default number of connections that will satisfy the majority of the customers. Due to cost constraints you can't include extra connections. After 3 meetings the team agrees on the default connections. You write up the decisions on the defaults and put the configuration in the backlog for the next sprint. The entire product team builds on this definition and there are no surprises when released to customers.
Example - team built and not finished
Your IT team has a new billing capability that allows monthly customer invoicing for as-a-service products with a single SKU. Your co-worker, Kirk, realizes a small team is needed to adapt the current product's 100+ SKUs to the single SKU billing model. Kirk brings together the IT team, the SKU experts, the billing team and a transformation team to define and plan for adapting your product to the new capability.
Kirk's small team meetings uncover a lot of good information about the new billing capability and the team takes care of most of the changes needed to adapt your product. Kirk cancels the small team meetings because the changes are nearly done. By abruptly cancelling the team, Kirk overlooked key completion items:
Final written notes on what has been done and what is left to do
Defined a way to validate customer orders can be processed
Acknowledgement from the team that their goal is finished
Process updates so other teams can use the new billing capability
Kirk has trouble getting people to join his next small team because potential team members don't get enough value from their time investment.
Conclusion
Letting go of key initiatives to build a team can feel like a leap of faith. In the end a small team built across multiple organizations can finish projects quickly. The key is knowing when to start a team and how to conclude a team effort.