Promoting Interdepartmental Teamwork for More Efficient Problem-Solving
13 June, 2022
Solving Problems in Silos
Successful companies aim to build autonomous teams that are self-sufficient and take ownership of their problems. But is there such a thing as too much autonomy? Are excessively autonomous teams missing out on the benefits of inter-team collaboration?
While having teams solve their own problems is the desired behavior, a lack of communication can lead to them missing out on valuable external input. Sometimes these inputs can lead to faster, better solutions.
Cultivating Teamwork in Problem-Solving
Complex problems should be communicated within the department. Trying to solve a challenge entirely within a team—when there are other qualified people available for help—can be unnecessarily time-consuming.
Here’s our system for fostering interdepartmental collaboration for problem-solving:
Step 1: Publishing a problem statement. When a team believes that additional help would be useful, they share a problem statement with the entire department. This consists of a short description of the problem and the requirements for the solution. Teams can present these in our regular IT workshops that are open to all our engineers. We ask, who wants to contribute? Who has relevant knowledge and experience in such problems?
Step 2: Collaborating via confluence papers. We create a confluence page for the problem, where anyone can contribute their thoughts and ideas on potential solutions. People can also upvote an existing solution. Anyone who writes or votes is added as a contributor.
Step 3: Sifting through the proposals. We hold a kickoff meeting where we invite all the contributors, discuss the proposals, and agree on a maximum number of three solutions.
Step 4: Deciding on the best solution. We form a work group for each proposal. The groups evaluate the different tools that we have at our disposal and examine ways to execute the given solution. Afterward, they present their findings and we collectively decide on a solution.
Step 5: Executing the solution. Lastly, one of our product development teams will take ownership of implementing a proof of concept for the chosen solution– with the help of the former workgroup– into our product. At that stage, the process returns to our regular workflow.
It Helps to Share Your Problems
- Bringing up problems to the wider team is a great opportunity to extract insight from a large number of people. People often overlook the breadth of knowledge within their department. Individuals with seemingly irrelevant titles can unexpectedly come up with the best solutions. Perhaps they had past experience in that area, or they have a personal interest that is unknown to you.
- Collectively trying to solve a problem is a great way to intrinsically motivate people; ultimately, it always brings good results.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Learn about 10 rules from the wisdom of these long-living residents from Ogimi, a small village in Okinawa, Japan. You could interpret the rules as the lifestyle habits that enable the senior residents of Ogami to live long and enjoy their ikigai.
CEO at Quantum Vision Consulting
3 ways leaders can cultivate relationships that lead to better products.
SVP Global Customer Experience at Salesforce
Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.
Senior Director of Engineering at SupportLogic
Discover the daily struggles, challenges, and moments of delight encountered when delivering banking products around the world. I will share my story candidly and honestly, without filter as much as I am allowed, and offer insights into my approach while providing retrospectives of the results.
Director of CX at FLF PRODUCT DESIGN
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero