When I was a management consultant, I built a revenue projection model for nearly every project. After I completed a model, I wold submit it to my managers and partners. Every time, they seemed to have an intuition of the range of possibilities; and within a few seconds of reviewing, they were able to come back with immediate feedback. Sometimes, the feedback would be directional, "It seems higher than I expect. Please adjust x, y, z assumption." This feedback was actionable and constructive, however, I did not need to think further about it, meaning my learning stopped there. Conversely, the most helpful feedback is when my managers deconstruct my revenue model with me, which then allows me to rebuild it even better than before.
As managers, we will receive ideas and deliverables from our team members, giving us the opportunity to provide feedback. There are many ways to give feedback, but deconstructing the idea together will lead to the greatest personal development from the team member. Deconstructing an idea involves requesting for the team member's underlying logic, distinguishing correct and incorrect pieces, and then suggesting that the team member rebuilds the idea given our discussion.
Request Logic
Even if we feel strongly for or against an idea, we need to request the team member to provide their underlying logic rather than give a straight answer. Although this may take more time than providing the answer outright, this additional time provides the team member the opportunity to build more logical connections between their activities and goals. This additional time builds their morale by demonstrating that we care about their rationale, in addition to the final output.
Furthermore, understanding the team members logic in their decision making will help us understand how they came to a certain conclusion or recommendation. If the team member does not clearly outline the rationale behind their idea, we need to reframe the logic request at different levels of specificity, starting with broad goals (e.g., what is the overall goal we are looking to achieve) and then progressing towards specific pieces (e.g., what's the reasoning behind X component).
Going back to the revenue model example, requesting logic would involve requesting for the rationale behind the calculation methodologies and overarching assumptions utilized to build the model. If projecting revenues for a retail store chain, this might involve the growth of number of locations on publicly announced plans, then estimating same store growth rates based on historic growth rates.
Distinguish Components
Once we have a grasp of their logic, we can distinguish which components should be maintained and which components need improvement, and also understand the underlying reasons as to why a component falls in a certain category. So if one idea is partially correct, we need to be able to explain which components are correct. If components are missing, we should be able to explain the logic to guide our teammates to find the absent components.
After we have distinguished the components, we can share the underlying reasons, but not the actual distinction, for maintaining or improving ideas. The level of detail in our explanation maps back to how much do we want our teammates to leap. A thorough explanation will elicit a lower leap (e.g., fewer decisions) needed by our team, whereas as an incomplete explanation would lead to a higher leap (e.g., more decisions). By supplying the underlying reasons, this give our teammates the ability to connect the dots on their own, which is how deconstructing ideas can create learning opportunities.
In our retail store revenue model example, there were two primary components - number of stores and revenue growth per store. The underlying reasoning was the basis (i.e., the company announcement that they would open 20 stores next year). However, we believe this is inaccurate because we know they do not have sufficient resources, and cannot take loans, to finance the expansions. We can then share the following with our teammate to distinguish the components, "Store expansions often cost $X per store and their current cash on hand and projected cash flows put them at $2X next year.
Suggest Rebuild
Based on the supplied rationale in the previous deconstruction step, our teammate(s) should not have a clearer picture of the goal and structure that needs to be built. We can not suggest, not tell, to our teammates that we can not rebuild (e.g., try again). We are suggesting because we are solely supplying the logic.
After we suggest the team member to rebuild towards the objective with the provided underlying reasons for maintaining or improving, we need to validate their understanding by asking them to rephrase their understanding and/or providing their plan for next steps. If they have not grasped the deconstructed idea completely, we need to supply additional underlying logic and ask them to rephrase again. We should repeat this loop until the team member understands the problem and next steps completely.
Based on the distinguished point we provided, the team member should then be able to tie that the retail chain only has enough resources to open 2 stores next year and realize the company's 20 store plan is overstated unless a large influx of cash arrives. She or he can then rebuild the model with the adjusted information. Through this process of rebuilding through deconstruction, the team member will have realized the assumptions that need to be checked. Providing an answer of "those projections seem to high" will not guide the team member through the same learning opportunities.
Closing Remarks
Deconstructing ideas constructively is about asking our team members to explain their logic. At which point, we can further clarify the underlying reasons that would suggest certain components need to be improved. Finally, as we suggest the team member to rebuild, we can validate their understanding and grasp of the previous concepts by hearing their ideas. By deconstructing their idea, rather than providing an alternative solution (e.g., the correct idea in our mind), and then reconstructing it, the team member will develop a sense of ownership over the idea. When the team members feel like they own the idea, they will be more open to learning.
Managers opposed to this methodology will argue that it takes too much time. If we are planning for short term results, feeding answers to our team members will certainly be a faster route. However, if we are aiming for long term success by elevating our entire team, deconstructing ideas constructively will ensure we are creating learning opportunities for our teammates.
If you enjoyed this piece, check out my other pieces on feedback:
Providing Tough Feedback with High EQ: Similar to this article, discusses how managers can give feedback by breaking apart ideas and inciting discovery (i.e., encourage our team members to continue learning)
Harvesting Feedback to Accelerate Professionally: Discusses how everyone needs to continuously collect feedback to improve, even chasing other team members and managers down if necessary
Processing Non-Constructive Feedback: Discusses how individuals can make turn non-constructive feedback into constructive ideas
