Talking to Yourself is a Distributed Work Superpower

Asking a Question.png

With more people working from home over the last year, there’s a lot of adjustments that folks are making to accommodate a new way of working. When I started working at Truss two and a bit years ago, I had to adjust my own way of working; one of the habits I picked up that has turned out to be a not-so-secret superpower has been remarkably simple: talking to myself on Slack.

The summer after I started at Truss, I got put on a project as an infra lead, one where we were trying out a number of new approaches to building out our infrastructure and really the first time I had built out a greenfield infrastructure (mostly AWS resources and a CI/CD pipeline) from scratch. That meant I was working on a lot of stuff I mostly understood but where I was running into a lot of rough edges.

As I and the other engineers on the project started building things out, when I got stuck or when I was faced with a decision I wasn’t sure about, I started making threads in Slack on our #infrasec channel where I would put the problem I was trying to solve in the first message, then my thoughts on whatever it was in the thread. Putting my thoughts in the thread when I had the question prevented the situation where I ask the question, don’t get a response for three hours, and then forget half the context I had when I originally asked.

After a while, I realized that these threads were also working great for me as just a way to rubber duck problems. As the project continued, it wasn’t unusual for me to start these threads and talk myself into a decision or figure out the problem. I would start making these threads specifically to rubber duck problems, and in the message starting the thread, I say I wasn’t necessarily looking for feedback, but if people were interested I’d be happy for them to weigh in:

Kicking off a thread

There was another effect though -- more junior engineers or even folks from other practices would mention in the thread that they learned a lot from watching me talk something through, or seeing the discussions between myself and other senior engineers. I realized that this wasn’t just a great tool for me, it was something that helped the entire practice or the entire company. This isn’t entirely a surprise -- at Truss, we try to have most of our conversations in public anyway for this very reason -- but the extra step of having conversations with yourself as a teaching tool was new. 

Now I regularly start up these threads even when I think I know what I want to do, just because seeing that thought process will both help other engineers and will give people the opportunity to point out issues I might not have thought of. Plus, it displays a degree of vulnerability that I think gives other engineers the space to realize that we don’t have all the answers and that it’s okay to show you don’t have them. It lets them realize that asking for help isn’t a sign of weakness.

In order to get the most benefit out of this, I think there’s a few things you have to do:

  • You have to do it in active, public channels. If I was doing this in #chas-brainstorming, it wouldn’t be nearly as effective. I don’t know about you, but I’m already trying to watch a lot of Slack channels, and most other people -- especially senior folks -- usually are too. They probably won’t watch a channel that doesn’t get much traffic (in comparison) and a lot of folks won’t even know it exists. By doing it in #infrasec, it’s in a known, visible area where everyone (at least everyone interested in the practice) will see it.

  • That being said, because you are doing it in a public channel, you need to do it in a thread so that it doesn’t suck up all the oxygen in the channel. The first message needs to be reasonably short and give details on what you want to talk about, so folks know if they want to look or not. Everything else goes in the thread.

  • Make it clear if you’re just rubber ducking or if you’re really stuck and need feedback -- that can communicate to other folks how to prioritize looking at the message.


It’s worth saying that this practice isn’t a replacement for writing documentation, no matter how long your Slack conversations are retained, but when you do document your decisions in ADRs or other places, you’ve got the full context of the discussion laid out to add to your documentation. Aside from that, though, it’s a great way to provoke informal discussion, demystify the decision-making process, and help people understand the rough edges of your practice.