- Separating Deliverables from Effort - How to Eliminate "Tossing Over of the Fence" Mentality
- Separating Deliverables from Effort - An Example in Real Life
- Separating Deliverables from Effort - Keys to Making It Work
- Separating Deliverables from Effort - Why it's Worth It
By separating the notions of delivery and effort, we increase collaboration, improve the quality of deliverables, and effectively diminish the callous attitude of just "tossing deliverables over a fence". Everyone buys-in into the quality and accuracy of whatever is developed because there is the shared sense of participation, vetting, and consensus that comes with this approach.
I wanted to trial this collaboration framework with my team. After consulting with a couple of my colleagues, I pushed forward with a limited test. I asked two of my colleagues to begin working as a tandem, one as a solutioner and the other as the planner, on a shared list of customers. They were given the following guiding principles:
- All effort into serving their customers must be shared between the two of them. That means as a team they are expected to attending all meetings (or at least informed of the outcome of the meetings afterwards) and collaborate on all deliverables.
- The quality of all output is reflective of the team, and not as individuals. That means they're equally responsible for the work they develop together and hold each other accountable for quality and timeliness.
- While collaboration is shared, accountability for deliverables is uniquely assigned. That means the solutioner is ultimately responsible for all solution deliverables, while the planner is responsible for all project planning deliverables.
There was a few weeks of ramp up, where they got up to speed with customer details, and we conducted regular check ins to adjust our tactics to maintain momentum. When the dust settled, we realized the following:
- Reduction in Context Switching - The solutioner was able to trust the planner to take on the project planning deliverables. As a result, he was able to focus more on understanding the pain expressed by his customers instead of constantly context switching between solutioning and project planning
- Improved Empathy - The planner really got the chance to understand why certain decisions were being made because he's now participating in client meetings and can understand customer behaviour first-hand
- Increased Perspective and Opinion Diversity - With two people on the same client meetings and calls, we started to see a difference of opinion when it comes to meeting retrospectives. This forced the team to be more critical on their own analysis and next steps
- Better Risk Management - When one team member needs to take a day off or go on a much deserved holiday, there's no skipping a beat because the other half of the team can always step in knowing full context of everything being done with the customer.
Having gone through a trial, we rolled out the structure to the rest of the team, pairing up solutioners with planners to form 2-person teams. In the end, we used the above guiding principles for the team to operate on. We had some success with this structure, but we also ran into some problems. I was fortunate that the team trusted each other with highly critical feedback so we can tweak and improve on the framework. I'll cover the keys to success in making this type of collaborative framework in the next article.