iTranslated by AI
8 Things I Keep in Mind When Using Times Channels
I have been using Times channels on Slack for 5 to 6 years now. When watching how others manage their channels, I sometimes think, "Maybe it would be better to do it this way," but since I believe everyone has their own way of using them, I haven't really offered any advice.
However, sharing some tips shouldn't hurt anyone, so I'd like to take this opportunity to share them here.
What is a Times Channel, Again?
Times channels are also known as "fuhou" (minute-by-minute reports). Essentially, if a "daily report" (nippo) involves reporting work on a daily basis, a "minute-by-minute report" (fuhou) or "Times channel" is the idea of reporting the current situation minute by minute.
I believe the benefits of Times channels are as follows:
- Verbalizing the thoughts in your head helps organize your thinking naturally.
- Others can notice what you're currently struggling with (and, if you're lucky, offer support).
- Since past struggles and tasks are recorded, they can be reused as institutional knowledge.
Personally, reading the following blog post was what triggered me to start using Times channels.
On the other hand, I occasionally see negative opinions about Times channels, but perhaps I've just been lucky; in my personal experience, I have never encountered any trouble caused by them.
Basic(?) Rules
Although they aren't often explicitly stated, I think the following are the basic rules for Times channels:
- Regardless of whether the Slack channel is visible to others, do not write anything that hurts or attacks anyone.
- Do not write information that poses a security risk.
- Do not write personal opinions on politics or religion.
- Participation in a Times channel is optional for members and should never be forced.
Things I Keep in Mind
1. Write down your thought process in words so you can retrace it later
I believe a Times channel is not just a place to output useful information, but also a space to pour out, organize, and share your "current" feelings and situation.
For example, I post things like:
- Tasks I'm about to start
- Things I'm currently curious about
- Notes while working
- If I'm stuck on something, the specific point of blockage
- etc.
By writing down your thought process, you can look at your own thinking objectively, which can sometimes lead to unexpected solutions.
Verbalizing not just actions and results, but also the background and internal thoughts leading to those actions, can be helpful when tracing back information later.
2. Don't think, "What will people think if I write this?"
For example, I try to discard feelings like "Will I be seen as ignorant if I write something wrong?" or "Will people think, 'He doesn't even know that?'" and instead just accept that "it's okay not to know."
Especially in a remote environment, if you don't broadcast that you "don't know" something, others can't tell from the outside if you "know but aren't doing it" or if you simply "don't understand," which can lead to unnecessary stress for them. (I'm often like that myself.)
Clearly stating "I don't know" helps remove that stress from those around you and increases the chance of receiving support, making it a win-win for both you and your colleagues.
By the way, when I searched my own Times channel for わからん (I don't know), there were 38 hits (at the 1 year and 6 month mark).
3. Post the commands you execute
I make a point of pasting the commands I've run locally into Slack. The reasons are:
- You can copy and paste them as-is when performing the same task later.
- You might notice operational mistakes when reviewing them later.
- When teaching specific steps to team members, you can simply provide the URL of the relevant thread.
A few months ago, I read the following article and found myself nodding along in complete agreement.
4. Paste error messages as text
When looking into error messages, I try to paste the error message exactly as it is in text format whenever possible.
The reason is to make it searchable when I encounter a similar error message in the future. In some cases, a screenshot might be easier to understand, so I'll post a screenshot then, but I make sure to include the error message as text alongside it.
For text that is too long to fit on one screen, I paste it as a Text snippet rather than a code block.
By doing this, the text can be expanded or collapsed with a click, preventing the flow from becoming difficult to follow due to overly long code blocks.
5. Use GitHub permalinks for source code
When I find a problematic area in the code or take notes while code reading, I make sure to use a GitHub permalink.
If GitHub integration is enabled in Slack, you can view the relevant lines directly within Slack, reducing the effort of switching back and forth between GitHub and Slack.
6. Use links when quoting topics from other channels
When quoting a topic from another channel, or conversely, when mentioning content posted in a Times channel in a different channel, I avoid copy-pasting the text or images. Instead, I provide a link URL to that post or thread to create a path for direct navigation.
This prevents the double effort of having to search for the specific post.
In some cases, I set up reciprocal links so that you can navigate back and forth between related threads.
7. Don't delete content even if you later realize it was wrong
When posting to your Times channel as things come to mind, you might later look back and realize you were mistaken.
At such times, some people might delete the post because they feel embarrassed about having posted something incorrect or because they are uncomfortable with wrong information remaining.
However, personally, I don't overwrite or delete such past mistakes as if they never happened. Instead, I make a separate post mentioning that "it was a mistake."
The reason for this is that there's a possibility of making the same mistake in the future. If I'm about to make a similar mistake again, having a record of what was wrong and why allows me to occasionally find an even better solution later.
8. Be mindful of whether the topic and the place (channel) are appropriate for discussion
Sometimes, a single comment in a Times channel can trigger the need to reconsider the specifications of an application currently under development. When I recognize such a situation, instead of continuing the discussion in the Times channel, I guide the conversation to an appropriate channel where all members are present.
Even if I only realize this after the discussion has finished, I will post a summary of the content and results, along with a URL to follow the flow of the discussion, to the channel where all members participate.
As mentioned in the "Basic Rules," not every member you work with is joined to your Times channel. Also, you should not expect that members who are joined will read every single post.
If a discussion proceeds among only a few people in a channel where only those few are participating, it can lead to realizing later that there are impacts in unexpected places, causing rework. It can also lead to strained relationships due to feelings of exclusion from important decision-making.
Also, as is common with remote work, there are situations that cannot be conveyed well through text communication. In such cases, we may transition to a call using Huddle with audio and screen sharing.
Even in those cases, I make sure to leave a summary of the conversation and any decisions made on Slack so that those who didn't participate in the Huddle can follow what was discussed. This also allows me to look back later and remember the details of the conversation.
Conclusion
I have listed the things I've been doing intentionally while managing Times channels over the past few years.
I started managing Times channels a little before the pandemic, but once the pandemic hit and my work life became centered around remote work, it became a part of my daily life.
In the process of continuing to run my Times channel, I have gradually improved upon what worked and what didn't, leading to the points mentioned above.
I hope this article is helpful to someone.
Discussion