The power of Rubber Ducking – Pair blogg # 6
In case you haven’t read about my pair-blogging idea before, a short summary from the first post:
”A while back I asked on Twitter for people who would be up for pair-blogging. The idea was that we agree on a topic and a date and then we each write a post about that topic. We publish on the same date and promote each other’s posts.”
Eager to get back on writing and armed with a concept that served me well before – I took to Twitter again. First to agree was Benjamin Bischoff who suggested the topic “The power of rubber ducking”. This is the first topic that feels like a stretch with my current role – but I love a challenge to let’s go!
Make sure to check out Benjamin’s post as well!
The Power of Rubber Ducking – Engineering Manager Edition
Rubber Ducking, or rubber duck debugging, is a very simple concept that is actually hiding a lot of power. In its original form it is simply the act of explaining your code problem to a rubber duck. Forcing ourselves to explain the code, line by line, to an inanimate object, we often start seeing inconsistencies between what we are trying to do and what we are actually telling the code to do. And hey presto – the problem is “magically” solved without any external support.
Starting out with that perspective, my initial thought when the topic was suggested was “I can’t write about this. I don’t write code any more!”. However, after thinking about it for a while I decided there are certainly angles I can take that are relevant to the role I have today – Engineering Manager.
I will cover my thoughts around three of them in this post:
1. Rubber Ducking as a general problem solving mechanism
2. Rubber Ducking using other people
3. Manager-as-a-rubber-duck service™
Rubber Ducking as a general problem solving mechanism
While the concept originated from software development, the concept applies to any problem you want to solve. Explaining our problem out loud often unlocks something in us and allows us to find the solution on our own. We start seeing where expectations and reality differ, or we come up with solutions while breaking it down. While the idea of doing this to a rubber duck might be silly to people outside of engineering, it is actually a really good thing to try. As long as the problem is something you should be able to figure out using logic – breaking it down into pieces and stepping through each piece is a great way of making ourselves unstuck.
Since this method has the great advantage of not having to interrupt anyone else, you don’t have to wait for the rubber duck to have time to meet you (unless you have a very popular rubber duck with several clients) – it is a very cost effective method. But it’s not the only way!
Rubber Ducking using other people
Something that might be a bit less unusual to people outside of software development, while still being closely related to the same concept, is using another person as a rubber duck. I think most of us have experienced explaining a complex problem we are faced with to someone else, with the purpose of getting help, and halfway through the explanation we figure it out ourselves. Same concept. This effect can be especially powerful when the other person is someone with no knowledge about the topic at hand. This might sound counterintuitive but when we have to explain something (complex) to someone we know have little understanding of the area, we need to be extremely crisp and clear in our explanation. And when removing all the clutter (and potentially adding some abstraction or simplification) it becomes easier to see the flaws.
On the other hand, when explaining to someone with more skills than us, we might need to explain other things, such as:
– What we have tried
– What we have ruled out
– What possible options we see
Which in its own way helps us break down the problem.
Contrary to rubber ducks, other people have the benefit of being able to add new perspectives or might actually have the answer. Just in case the rubber ducking in itself didn’t solve the problem.
The third perspective I came to think of is the fact that I often act as a rubber duck to my reports and peers. Often when people come to me with problems, I am not the one to solve it for them. I might ask open questions, I might ask questions like the list in the previous paragraph, I might challenge assumptions. But honestly, a lot of times my biggest power tool is friendly silence and encouraging nods. I rarely actively plan to use it but I’ve noticed that the more comfortable I’ve become in the coaching part of my manager role, the more easily I default to this style of leading conversations. With some reports (and colleagues) it works great, they flourish and grow in their problem solving skills with me just holding the space and allowing them to be the experts. Often in those conversations, it is enough to just actively listen, help with summarizing or possibly inject a thoughtful question to keep the conversation (monologue?) going. With others, this is a style that takes some getting used to. One aspect of growing as a manager has been to learn to adapt and become more aware of when I need to shift to a more active participation, maybe even stepping into leading or driving the process of solving the problem at hand. Since this is something I defaulted to naturally when moving from being the specialist to being the manager, I have fought hard to unlearn this approach and I think it will take me years and years to get to a point when I can seamlessly switch between the two.
One of the challenges I face with my writing is that I struggle so hard to let my blog posts be just that: blog posts. I tend to want them to be Proper Articles™ and due to that – they tend to become bloated and take a lot of stress and energy to finish. These pair blogs are one way for me to push myself beyond that and learn to Embrace Good Enough™. I reached out to a friend to share the struggle and shared the first draft. I didn’t ask for help writing, I didn’t ask for thoughts on the topic. I just shared that I was struggling with my perfectionism and how to wrap things up. Thank you Samuel for this gem of a comment, which is just what I needed from my Rubber Duck today:
“What you could wrap up with is how you used rubber-ducking to actually finish that blog post you’re writing. Because I think you did. You reached out to a trusted person to reflect back. You didn’t even share a lot of what you think about, what you have in mind, you just shared that you struggle with it.That can be a great mechanism to overcome challenges (I try to do it more consciously with a lot of stuff)”