Collaboration in the Problem Space
Using the CEDAR model for effective one-on-one feedback
There is an inherent bias in software organizations to be solution-focused vs. problem-focused. The reason for this is obvious to me — the fundamental purpose of software is to solve problems (done so by modelling and defining behaviours performed by a computer). Thus, it is no surprise that as individuals and teams, software development professionals focus on solutions vs. problems.
As other technology-oriented, knowledge-based industries take their cue from software companies, this bias is in danger of spreading and quashing our ability to innovate (ironically). This is because a solution-oriented bias fails to interrogate the problem itself. This means asking questions such as:
Is the problem worth solving? If so, why?
Have we identified the root of the problem?
Are we solving the right problem?
While asking such questions can be painful and time-consuming, doing so can bring fresh solutions to the fore that would otherwise not be considered.
Offering suggestions
How often have you given or received the following advice around offering suggestions:
If you see a problem, sketch or draft a solution before bringing it up with your manager or peers.
I know I’ve given this advice before. Asking for the solution, arguably, saves time — I don’t have as much context on or understanding of the problem as the person bringing the problem to me. At first blush, it seems more time-efficient to assess a solution rather then mull on the problem.
Yet therein lies the issue. If each person assesses the problem in isolation and brings forward their individually-ideated solution to their manager, then the manager misses out on the set of possible solutions that can only be uncovered through assessing the problem space as a team. Furthermore, if the manager rewards the best individually-ideated solution, then they are disincentivizing the ideation of solutions as a group, and thus suppressing collaboration in the problem space.
Consequently, I do not give the aforementioned advice anymore. Instead, I encourage both reports and peers to talk about problems with each other — to collaborate on them and thus uncover possible solutions that would be otherwise unreachable. I try to work on being comfortable collaborating in the problem space, whether it’s one-on-one or as part of a team.
In that process, I’ve come across a few techniques that I’ve found useful. I will scope this post to one approach in particular that is suited to providing feedback in one-on-ones.
One-on-one feedback
Traditionally, feedback is split into two groups. Positive feedback is essentially given when there is an outcome attributed to an individual that is desirable to the business. The intended outcome of positive feedback is for that person to continue the behaviours that have led to that outcome. “Keep up the good work,” essentially.
Negative feedback, on the other hand, is the opposite. There is an undesirable business outcome that we have attributed to the individual. As managers, we feel it is our job to both attribute the outcome to an individual, as well as determine the course of action to mitigate its future occurrence. In other words, we feel solely responsible for both identifying the problem and most of the solution space.
Most conventional recommendations on providing feedback centre around how to deliver the feedback. Few question the responsibility of the manager. What if they got it wrong? What if more than one person is responsible for the undesirable outcomes? What if there are alternate courses of action to address them? In reality, all are common in knowledge-based industries such as software development. Increasingly, business value is achieved as a team that works together, even when it comes down to individual tasks (pair programming in software, for example).
Nevertheless, as managers we are stuck with the inescapable reality that we are ultimately responsible for the performance of our reports. Thus, problems will arise that are undeniably connected to our reports, and we need a way to collaborate with our reports on them. Enter the CEDAR feedback model.
CEDAR Feedback Model
CEDAR is very effective at providing feedback in a non-directive manner — directive feedback means that the feedback receiver is being told that to do (or what not to do).
The tendency to come to the table with solutions (as opposed to collaborate on the problem) means that leaders tend to gravitate towards directive feedback approaches such as start-stop-continue. While directive feedback models such as this can be very efficient at feedback delivery, it propagates the issue at hand: failing to collaborate in the problem space.
Non-directive feedback is difficult, time-consuming, and counter-intuitive. Consequently, models such as CEDAR can be effective at achieving and sustaining a non-directive approach that gives adequate attention to the problem space.
Here is a summary of the approach:
Context: Set the context of the feedback. What led you to bring up the issue? Why is it an important problem to you and the company?
Examples: Give concrete examples of activities that you believe to have caused the issue. Explain how they relate to the receiver of the feedback.
Diagnosis: Ask the receiver of the feedback to diagnose the problem and its causes. Is there a root cause? Are there contributing factors? Make sure that at this stage, the feedback receiver is doing as much of the talking as possible, and limit yourself to asking questions.
Action: Establish next actions with the feedback receiver. It’s important that they drive the synthesis of the actions, with you providing feedback on the actions as needed. Oftentimes, it may involve you having actions of your own.
Review: Follow-up on the actions that both you and the feedback receiver have committed to. Primarily, check-in if they need support, but also to close the feedback loop — have the actions have been followed through with? If not, why not?
The above is only my summarized interpretation of CEDAR. I highly recommend reading this article by Anna Wildman (the creator of the model) for a more comprehensive overview.
Applying CEDAR
Let’s walk through an example of how CEDAR can apply:
Context:
Manager: “The tickets you have been working on have been taking longer than expected. This is contributing to the planned release falling behind schedule.”Examples:
Manager: “Of the last eight tickets that you’ve worked on, these five have taken longer than what you had initially estimated.”Diagnosis:
Report: ”I think I could be better at estimating. However a lot of time I have no idea about what’s involved so it’s more of a wild-ass guess. Then, when another team member looks at my PR they point something out that balloons the scope, and it’s back to the drawing board.”Actions:
Manager: “What can we do to improve estimate reliability and accuracy? Or at least, find out when it’s off sooner?”
Report: “I suppose I can pair program with my teammates more, especially on the larger tickets. That way, the hidden scope is revealed earlier than the PR stage”
Manager: “Why are you not estimating together, as a team?”
Report: “I don’t know. I guess that’s just how we do it? I can bring the question up at the next retro.”
Manager: “Great idea!”Review:
Manager: “How did the retro go?”
Report: “It went well! I brought up my missed estimates and ballooning scope, and a few of my other teammates were in the same boat. As an experiment we will try to estimate as a group, and we have agreed to always start off the larger tickets as a pair as opposed to solo on them”
Manager: “Great! Keep me in the loop on the experiment, and let me know if there’s any way I can support.”
In this example, solving the problem at hand involved more than just the report. Their manager encouraged them to bring it up with their team, which in turn yielded a potential process improvement.
Conversely, we can imagine how using an approach involving directive feedback could go. The report would agree to “getting better at estimating”, but may be left figuring out how to do so on their own. Critically, they may never realize that it’s a problem that they in fact cannot solve on their own, and may never think of leveraging their team to solve it.
Wrap-up
Collaboration in the problem space may slow us down in the near term, but can lead to more prudent courses of action in the long term. One-on-ones are just one forum where this can happen. In a subsequent post, I’ll be describing other times where this type of collaboration can happen, as well as other techniques or models that can be applied.
In the meantime, I’m interested to learn about how you encourage collaboration in the problem space. In particular, if you use an alternate to the CEDAR model, I’d love to hear about it!