Forem: sta

MRM (Mention Response Mode)

sta — Thu, 25 Dec 2025 00:14:59 +0000

Summary

When we receive mentions, they come with "reply tasks" and the stress of "waiting for progress."
The latter, the stress, is something we can't ignore, so we've developed a technique to alleviate it.
That technique is MRM (Mention Response Mode).
- You define a mode (how quickly you'll respond to mentions) and make it clear which mode you are in.
- This clarifies "by when you should respond," which reduces stress. It also allows you to measure how many mentions you handle or fail to handle in each mode, making adjustments easier.

Background

The overwhelm of mentions

We probably use Slack, and many of us are likely overwhelmed by a flurry of mentions. Isn't that true for you as well?

Mentions accumulate stress more than we expect and decrease productivity

If you have 10 mentions you haven't responded to yet, would you say you have 10 tasks of "replying"?

The answer is No.

It's a greater burden than merely having 10 reply tasks. Consciously or unconsciously, you're likely making constant judgments like the following:

Oh, I need to get back to this soon. I'll do it later, later…
This person is still not making much sense, right? It's okay to ignore it, right?
This is important, but the message was broad, and I think someone else will pick it up, so I'll have to pass!

And, with the number of judgment calls made but still tasks that haven't been replied to, you end up with anxiety about progress or outcomes. You bear not only the tasks but also the anxiety. In clearer terms, it's stress.

These are, of course, a "weakening effect" itself, and the more you bear, the more drained you become. Can you really be productive in such a state?

We need techniques to reduce mention-induced stress

While reducing mentions themselves might be difficult, we can reduce the stress associated with them.

I have been researching techniques for this purpose, and today I'd like to introduce a completed one.

Mention Response Mode

Mention Response Mode (MRM) refers to determining by when you respond to mentions.

How It Works

You define response patterns as modes. Here are some examples:

Lv5: Immediate Mode
- Respond as soon as possible.
- (You're probably chatting synchronously with one or more people.)
Lv4: One Hour Mode
- Respond within 60 minutes.
- (You might be glued to the chat tool.)
Lv3: Half-Day Mode
- Respond within half a day.
Lv2: Few Days Mode
- Respond within a few days.
Lv1: Random Mode
- You may respond immediately, or it may take a few days; you might even not respond.

Then, you declare this mode. You can advertise it like a chat status, or even create a calendar for modes.

Benefits

The benefit of MRM is that it reduces stress related to mentions.

This is because "by when you will respond" is made explicit. Both the sender and the receiver can consider the Response Time specified by the mode, making it straightforward.

Of course, there's the possibility you might not respond as the mode dictates, but that's an issue of capacity or practice, which means each person can handle adjustments. Actually, with MRM, you can quantitatively grasp handling capacity, making improvement easier.

Furthermore, since MRM serves as a common language, it makes communication more flexible. For instance, you can adjust by saying, "It seems like Lv3 would be better, so please use Lv3 tomorrow."

The Schedule is Not Just About Appointments - On Scheduled Domains

sta — Tue, 23 Dec 2025 20:48:20 +0000

Summary

Scheduling is difficult because it is often thought of as handling only "appointments"
In reality, there are things other than "appointments." For example:
- Working hours
- Modes (how you spend your time)
- Personal tasks (personal tasks you'd rather not show to others)
Solution:
- Handle each domain separately with one sheet each, like appointment schedules, working hour schedules, etc.
- This allows for independence and clarity for each domain and enables advanced integration
- However, since there is no existing software solution, creating your own is necessary

Background

The Reality of Scheduling ≒ Handling Appointments

Take a look at your calendar, whether it's Google Calendar, Outlook, or any other. Alternatively, check the schedules of your team members.

Calendars are convenient but also difficult to view and use. Ideally, you'd prefer to avoid them, but that's not an option. Not just managers, but even on-the-ground engineers, likely including yourself, are constantly maintaining your calendar and struggling to coordinate with others'.

Why are calendars so troublesome?

The simple answer is that we recognize the concept of a schedule as handling only appointments. However, there are indeed other aspects than just appointments.

Beyond Appointments

What are these aspects other than appointments?

For example, "working hours." In group schedulers, you can set this in the configuration screen. When set to 9:00-17:30, it indicates these are working hours, and times outside this range are grayed out, marking them as non-working hours.

If this "working hours" concept wasn't distinguished from "appointments," then likely you'd create recurring appointments to indicate working hours, or maybe separate appointments to show non-working hours. This would be cumbersome for maintenance and annoying in display.

By extracting matters like this outside of "appointments" and handling them differently, such problems can be avoided.

Schedule as a Class, Appointments and Working Hours as Instances

On a more abstract level, there are multiple ways to implement the concept of a schedule. We've already mentioned "appointments" and "working hours," but there are others too.

In object-oriented terms, the schedule is like a class, while appointments and working hours are like instances.

This article discusses, based on this viewpoint, the existence of appointments and working hours, and how they should be uniformly handled.

Scheduled Domain

Define the Terms

Firstly, Schedule refers to a data structure that defines what fills which parts of the 24-hour day frame.

Next, Scheduled Domain or simply Domain refers to the type of data written into the schedule.

This allows for detailed schedule operation.

Examples of Domains

Let's look at examples of domains.

1: Appointments
2: Working hours
3: Modes
4: Tasks

Appointments and working hours have already been explained.

Modes refer to ways to spend your time. Typically, there are the following five:

Free mode: Available. Can switch to other modes as needed
Meeting mode: Mainly in meetings. Adjustable even with scheduled appointments
Constrained mode: Engaged in events, etc. No room for adjustment
Work mode: Primarily doing personal tasks. Not accepting meetings, but will check chats
Focus mode: Engaged in personal tasks. No meetings, no chat, and notifications are off

Tasks refer to personal tasks. These are not tasks agreed upon within the team, but how you personally interpret them. Or simply personal errands. The characteristic is that they can't be shown to others. Here are some examples:

Prepare a presentation to explain to the obtuse manager why a document-oriented DB is better than RDB. Schedule preparation and material creation
Reconsider the collaboration method between A and B, who don't get along
Write a resume to look for a new job, for which you'll sift through and organize information on past work

Handle Schedule as One Domain Per Sheet

Now for the main topic.

To effectively handle schedules, use a one domain per sheet approach.

So, taking the above four domains as examples, handle them with four sheets as follows:

A schedule that handles only appointments: Appointment Schedule
A schedule that handles only working hours: Work Schedule
A schedule that handles only modes: Mode Schedule
A schedule that handles only personal tasks: Personal Task Schedule

With this method, we gain the following benefits:

Schedules are separated by domain and functionally simple, making them easy to maintain and read
Overlaying schedules allows for advanced integration
- It becomes easier to define automation
- For instance, "Automatically decline schedule adjustments during focus mode"
  - if a schedule adjustment comes during focus mode, then reject that request

Operate Scheduled Domains

Unfortunately, there is currently no calendar or group scheduler adopting the concept of scheduled domains. This could be because this concept is newly developed by me.

For personal use, with Google Calendar, handling "one domain per sheet" is somewhat feasible.

However, the essence of scheduled domains lies in the integration between schedules. A dedicated scheduling software will likely have to be developed on your own.

If You Want to Embrace Asynchronous Work, Shift from Meeting-Driven to Task-Driven

sta — Mon, 22 Dec 2025 20:45:54 +0000

Summary

Traditional work is meeting-driven
- It involves holding discussions and reaching conclusions in a "spontaneous" manner during meetings
- It's easy because you just follow the schedule (even a child can do it)
Meeting-driven approaches don't allow for asynchronous work, necessitating a new model
- Adopt a task-driven approach
- View all work and actions as tasks, manage them through a system, and update the task pages
You might already be familiar with this format through GitHub Issues

Background

We Seek Asynchronous Work but Fail to Implement It Due to Meeting-Driven Culture

As engineers, we understand the marvels of asynchronous work. It's delightful to work seamlessly in one's preferred environment without interruptions, office noise, or commotion. Occasional meetings or gatherings can replenish solitude or enable thorough discussions.

However, despite knowing this, it seldom works smoothly, and many organizations are reverting to in-office work. Even those claiming to support remote work often depend on online meetings.

Why can't we escape synchronous work? The blame lies with the work model. It's because we're meeting-driven.

A New Model is Needed

Meeting-driven work refers to the reliance on meetings to conduct business.

It has two main features:

1: In order to resolve matters during meetings, communication, discussions, and decision-making are done spontaneously
2: Work is conducted passively, following meetings scheduled in the calendar

It's akin to a school timetable. You merely attend according to the schedule and follow the facilitator or mood of each meeting. Even a child can do this. It's an extremely easy way to work.

But since this approach depends on meetings, it can't accommodate asynchronous work. We must fundamentally change our mindset.

Task-Driven Approach

A task-driven approach views all work as tasks, manages them through a system, and aims to close them.

Key features include:

View all work (including activities and actions) as tasks
Tasks are managed in a system, allowing individuals to access these tasks (indicated by a workspace) asynchronously
- Ticket-based formats like GitHub Issues are straightforward
Tasks have "statuses" and are completed when they're closed

As engineers, you're likely already familiar with GitHub Issues, making this concept relatable. In a broad sense, it's akin to turning everything into an Issue.

Skills Needed for Task-Driven Work

Traditional meeting-driven work required communication skills, especially the "social skills" to coordinate meetings and interact quickly during them.

Task-driven work is different. What's important are task management skills. Specifically, the ability to engage with dozens (possibly hundreds) of tasks and manage them well through self-management and reading and writing skills for documenting tasks (indicated by a workspace).

Before/After

Let's see how a manager's day changes from meeting-driven to task-driven.

Before

Here's a morning schedule for Manager M:

9:00– Check chat, email, and other notifications
9:30– Daily meeting for Project P1
10:00– 1-on-1 with A
10:30– Meeting 1
11:00– Meeting 2
11:30– Work

This schedule is meeting-driven, with four meetings between 9:30 and 11:30. Each meeting has a 30-minute window for spontaneous discussion and decision-making.

Of course, since meetings are scheduled commitments, they must be adhered to. While easy by sticking to the timetable, the work is inflexible and entails considerable effort in arranging and holding meetings.

After

Consider the following example:

9:30– Daily meeting for Project P1

Suppose the agenda of this daily meeting is:

Sharing what was done yesterday and what will be done today (10 minutes):
- With A, B, C, and D
Discussion (20 minutes):
- Someone raises a topic, and it is debated. This is repeated.

In a task-driven approach, it might look like this:

Task: "Post today's plans"
Task: "Post opinions on Topic 1"
Task: "Reach a conclusion on Topic 1"
Task: "Post opinions on Topic 2"
Task: "Reach a conclusion on Topic 2"
...

These tasks are managed in a system. You might use GitHub Issues or, as described in QWINCS, wikis or notes. Any system that splits tasks into separate pages, operates smoothly, and incorporates concepts of open and closed statuses will suffice. You might even use creative representations like adding checkmarks to titles.

Once tasks are on the system, they only need to be updated asynchronously. If a reminder is necessary, simply send a mention.

Can Work be Accomplished in the After Scenario?

Ans: Yes, it can.

If you think it can't, it's likely you're still very meeting-driven.

As mentioned before, task-driven work requires skills in self-management and documentation. You need to be adept enough to easily handle the After mentioned above. These have often been underestimated soft skills, and shortcomings in even engineers, managers, or senior engineers are common.

That's why I initiated Soft Skills Engineering.

Minimum Main Member Principle

sta — Sun, 21 Dec 2025 21:04:25 +0000

Summary

Sensitive to performance and pay-as-you-go cloud costs, but not to communication costs
However, communication is complex and difficult to reduce
- That's why I wanted a straightforward principle
Created the Minimum Main Member Principle
- Introduces its basis and main patterns

Background

Sensitive to Performance and Cloud Costs, but Not to Communication Costs

As engineers, we are likely sensitive to performance. Additionally, we are probably sensitive to pay-as-you-go cloud costs such as API usage fees and infrastructure operation. (Another aspect is technical debt, but it's more dependent on the individual and the project, so we'll skip it here.)

There is another aspect that cannot be ignored. Communication costs. Unfortunately, this seems to be as underrated as, if not more than, technical debt. Here, I pose a question.

Can you secure more than three hours a day to focus on work or discussions alone, without interruptions?

If you answer Yes, or even No but "Yes about once every two days," you're fine. In other cases, you're probably incurring too much communication cost.

Need for a Principle to Reduce Communication Costs

As you can easily imagine, improving communication is very complex and difficult (that's why I started Soft Skills Engineering).

To move towards improvement, especially reduction, it would be good to have a simple and understandable principle. So I created one.

Minimum Main Member Principle

Minimum Main Member Principle is a principle that suggests keeping the main members to a minimum.

Main refers to someone who both "undertakes the primary work" and "has decision-making authority"
- In culturally challenging cases, either one will suffice
Minimum means as few as possible, but at most four including yourself

I initially intended to call it Minimum Core Member, but I chose Main to stick with the 3M acronym.

Why is the 3M Principle Necessary?

To prevent the bloating of communication costs.

Ideally, one person would suffice, but having only one person can lead to biases and uneven capabilities and authority. However, more people mean more time-consuming communication. Many of you might have experienced being overwhelmed by meetings, document creation, or onboarding and mentoring.

A more relatable example is writing novels, blog posts, or other documents. It's a challenging task even alone, so imagine doing it with two people. What about three or four? Just thinking about it is daunting. While the logical world of software is less creative yet still creative, a style where one person creates and others review is essential.

Thus, having slightly more than one person but as few as possible is the best balance.

Main Patterns of the 3M Principle

Teams that adhere to the 3M Principle follow several patterns.

Seek the optimal pattern yourself. We'll introduce some here.

1: Worker and Reviewer

Worker: Creates
Reviewer: Reviews what's created

This is the simplest and most straightforward pattern, but it's unclear who does what after a review (post-review).

Typically, the reviewer is the superior and handles the post-review. However, just like the advisory process in teal organizations (where the superior advises but does not have decision-making power), the style can be left to the worker. Yet, post-review requires exercising influence, and often, influence cannot be exerted without authority, making it difficult for the worker.

2: Engineering, Design, Management

Engineer: Creates
Designer: Handles UI, UX, and other visuals
Manager: Manages

This is a role-based distribution. Since it's difficult for one person to handle more than two fields (if possible, one can become independent), each role is assigned to one person.

Each role is challenging. Engineers require full-stack knowledge, including front-end, back-end, and SRE. Designers need to learn engineering tools like GitHub and CSS (otherwise, the 3M burden on engineers becomes too great, leading to a breakdown). Managers must handle both project management and product management—yes, each role is challenging, isn't it?

If you adopt this pattern, it would be better to limit it to a PoC level rather than a full-fledged project.

3: Worker, Helper, Advisor

Worker: Performs actual work
Helper: Directly supports the Worker, including management but not limited to it
Advisor: Conducts research and examination for improving or transforming the Worker, and coordinates with the Helper

This is a pattern I call the Worker Triangle.

The most important role is the working Worker, who is given the utmost respect. However, since the Worker can't cover everything alone, a Helper is placed. Simply put, the Worker handles direct tasks, while the Helper handles indirect tasks. Traditionally, everyone handles both direct and indirect tasks, but here it's more about entrusting only the capable Worker with these tasks, with the Helper taking care of the indirect ones.

Next, since improvement or transformation can't happen with just these two, one more role is placed. This is the Advisor. As the name suggests, they provide advice, but it's directed to the Helper, not the Worker. This is because the Worker is specialized in direct tasks, being less focused on improvement or transformation (like engineers disliking soft skills). However, nothing can be done without it, so it's channeled through the Helper.

 Worker <--> Helper <--> Advisor

Thus, the Helper is often the most important. They need to understand the Worker's circumstances and communicate them to the Advisor, as well as grasp the Advisor's advanced offerings and convey them to the Worker. In this sense, the Helper might even be called a Translator.

Effective Facilitation Techniques: Speaker Queue and Speaker Stack

sta — Sat, 20 Dec 2025 23:20:13 +0000

Background: Meeting Facilitation is Challenging

Even engineers have meetings. These discussions or reviews can become quite heated and cover topics not only related to software development but often also organizational development.

However, we engineers are not facilitators. The quality of a meeting depends on facilitation, but we lack the necessary skills. As a result, meeting quality becomes inconsistent, leading to the following issues:

Selecting "compatible members" to reduce quality inconsistencies → This increases hiring and onboarding costs.
Conducting discussions exclusively with managers and senior engineers → This incurs communication costs to convey information to the on-site engineers.

Solution: Using Queues and Stacks

While meeting quality is not determined solely by facilitation, let's focus on facilitation here.

When facilitation can be systematized, it becomes more stable. We introduce two methods: Speaker Queue and Speaker Stack.

By controlling speaking rights using queues and stacks, facilitation becomes more stable. Additionally, since there's visible management, it becomes easier to quantify the quality of the meeting.

Speaker Queue and Speaker Stack

This is a system where speaking turns are managed via queues and stacks.

Basics

When speaking, follow these steps:

Step 1: Push a button (your name enters the queue)
Step 2: The facilitator simply picks a name from the queue and gives that person the right to speak

Queuing is a classic approach in system architecture, and the same principle applies here. By using a queue for speaking rights, you can ensure FIFO processing, providing a stable experience for all participants.

Using Stacks As Well

In practice, both queues and stacks are used. A stack serves for "interruptions," processed as LIFO, and handled as a priority until it is empty. When a queue alone cannot handle the complexity of a meeting, a stack allows for interruptions.

Advanced Techniques

As mentioned, the basic form is 1-Stack 1-Queue, but other patterns are also possible.

Although this diverges from the topic of facilitation, I previously wrote HQRST is Recommended for Lightweight Task Management - DEV Community. This covers individual task management using combinations of multiple data structures, and the same idea can be applied here.

For example, you can operate with a 2-Stack 1-Queue system:

Priority 1: Stack for asking about unknown terms
Priority 2: General interruptions
Priority 10: General speaking

This approach allows for facilitation of typical meeting challenges such as "There's a term I don't understand" or "It's not a conducive atmosphere to ask immediately."

"Career Ladder is an Inverted Triangle" Bias

sta — Fri, 19 Dec 2025 05:01:06 +0000

Summary

There is a deeply ingrained bias as follows:
- The higher you climb the career ladder, the more you can do. You solve undefined problems.
- The lower you go on the career ladder, the less you can do. You solve specific, instructed problems.
- In other words, there is a bias that the height of the ladder corresponds to the level of abstraction.
Let's discard this bias:
- Even among those who aren't in high positions, there are people capable of solving abstract problems.
- Conversely, just because someone is in a high position doesn't mean they can solve these problems.
However, to exert influence, a higher position is necessary.
- Related article: Influence sucks - DEV Community

Background

Career Ladder and Abstraction Are Proportionate

As you ascend the ladder, meaning your position rises, you begin to handle more abstract problems. You also deal with ambiguous issues like people and organizations, making soft skills more crucial. Conversely, when you're lower on the ladder, you consistently tackle specific, instructed problems. You only need to address technical and "hard" problems, making soft skills unnecessary or even unwelcome.

I call this bias the Inverted Triangle Career Ladder. The higher you go on the ladder, the broader it becomes, while it is very narrow at the lower levels.

Career Ladder and the Ability to Handle Abstraction Are Unrelated

However, being higher on the ladder does not necessarily mean you have a high ability to handle abstraction. Conversely, engineers who haven't been promoted or have only been promoted once may have the capability to address abstract problems.

So, let go of this bias and enhance the agility and flexibility of your organization!

Successful Operation Without the Bias

If we were to discard the Inverted Triangle Career Ladder bias, how would it change the roles in our organizations and projects? More specifically, what operations would be successful?

1: Distinguish Exploration, Performance, and Influence

First, distinguish the following three points:

Exploration
Performance
Influence

Exploration refers to solving abstract problems (through examination). It's not as visible as project work, and new approaches are required. I call this Transject. As a method, I've previously explained Creative Thinking.

Performance refers to abilities and deliverables. For instance, there's an engineer who can compare the usage methods and properties of the OpenAI API, summarize them in a document, actually try them in compliance with the company's governance, and share the results of the examination and testing as knowledge. This person clearly possesses investigation, prototyping, documentation, and sharing skills. There are deliverables, too, indicating performance.

Finally, Influence refers to improving metrics directly. Note the difference from performance. Exerting influence requires considerable authority, which is the responsibility of those in managerial positions or higher. Therefore, it's practically a dereliction of duty to assign influence responsibilities to engineers without the authority (the only exception is delegating tasks whose outcomes are certain to produce influence). I've also emphasized this point in Influence sucks.

2: Permit Exploration

Once you can distinguish the three elements above, the next step is to allow exploration work to be conducted by anyone at any level, including the front lines.

This might be confusing, so let me explain with a Before/After scenario. Let's simplify the career ladder to lv1 Field, lv2 Manager or Individual Contributor, lv3 Senior Engineer, and lv4 Executive Level.

Here's an overview of which levels handle each element. Before represents conventional bias, and After is our proposed approach.

	Before	After
Exploration	Lv3~	Lv1~
Performance	Lv1, Lv2	Lv1, Lv2, Lv3
Influence	Lv1~	Lv2~

The specific changes are as follows:

First, ensure Lv1 doesn't have influence responsibilities.
Next, make exploration possible from Lv1.
Consequently, some Lv3 responsibilities will become available, potentially allowing for performance duties.

Previously, exploration was only conducted by Lv3 or higher, but now it can be done starting at Lv1. However, as stated earlier, Lv1 doesn't have the authority to produce direct influence, so Lv2 or higher should handle that responsibility.

3: Connect Exploration and Influence

Even if you've enabled Lv1 to engage in exploration, it holds no meaning unless the results translate into business impact. This part, of course, falls under influence responsibilities and must be taken up by Lv2 or higher, who have the authority to exert influence.

This means that Lv2 or higher must receive the results of Lv1's exploration to exert influence.

When proposing such a concept, you may receive opinions accusing it of irresponsibility, but that's precisely the bias. It's impossible for Lv1 to exert influence. Nevertheless, Lv1 can explore and think of ways to capitalize on its results. It's a matter of role division.

Conclusion

The height of a career ladder does not correlate with the ability to handle abstract problems. However, applying the results of exploring abstract problems requires influence, and influence necessitates height.

Therefore, it's actually possible to collaborate as follows:

Exploration of abstract problems can be entrusted to field-level engineers who excel at it.
Because influence using the results cannot be exerted at the field level, it must be passed on to someone with authority to execute.

If you're relatively high on the ladder yet struggling with abstract problems, try discarding this bias. There might be a team member capable of dealing with abstract issues. Collaborate effectively.

The Seven Lists Principle for Creating Tools for Soft Skills

sta — Thu, 18 Dec 2025 21:10:10 +0000

Summary

To effectively leverage soft skills, soft tools are necessary.
- These are tools like templates and checklists.
- They are not hard tools like hardware or software.
- Soft skills are not simple enough to be covered by hard tools alone (though engineers might prefer hard tools).
Creating soft tools is challenging, so here are seven perspectives to get started:
- This is the Seven Lists Principle, consisting of the following seven:

               Task    Span
     Trigger                  Question
            Check        Label
                   Fill

Background

Tools for Soft Skills Are Challenging

In today's digital age, there is a tendency to see software creation as the ultimate solution. However, only a small portion of phenomena can be translated into software. If software were enough, there would be no need for the term soft skills.

However, discussions about soft skills tend to become abstract. For engineers, they are "non-technical" and "not concrete," creating a double disadvantage. Just seeing the title can trigger an allergic reaction.

So what should we do? Create "immediately usable forms of something" like templates and checklists. We refer to these as tools.

If this sounds unclear, think of actual tools like software and hardware as hard tools, and operational, language-based deliverables like templates and checklists as soft tools. Soft tools are necessary to utilize soft skills.

How to Create Tools?

So, how do we create these soft tools?

In essence, one must create things like templates and checklists, but even when told this, it's hard to find a starting point.

Therefore, we introduce some perspectives for getting started.

The Seven Lists Principle

The Seven Lists Principle is a guideline suggesting that it's useful to categorize soft tools into seven types.

               Task    Span
     Trigger                  Question
            Check        Label
                   Fill

When creating a soft tool, first think about which of these seven categories it should fall into. Even if it doesn't fit perfectly, you might find a hint.

While the word "list" is used, it doesn't have to be a list. It can be a matrix, map, or framework—anything else works. The name or visualization method is not important. "List" is merely used here to mean a collection of elements.

Let's go through the details of each.

1: Task List

What is it?
- A list of instructions.
Reader's Expectation
- Expect readers to follow it.
Examples
- SOPs and other procedure manuals fall under this category.

2: Span List

What is it?
- A list of time-based units (things with a temporal length).
- Elements can also be placed within the time units (classification function).
Reader's Expectation
- Expect readers to understand the overview and current status of the time periods.
Examples
- Roadmaps, schedules, WBS.

3: Trigger List

What is it?
- A miscellaneous list of things that might spark ideas.
Reader's Expectation
- Expect it to assist in idea generation.
- Each item can be used or not, and interpreted freely.
Examples
- GTD® Trigger List, Osborne's Checklist, SCAMPER method.

4: Question List

What is it?
- A list of questions, particularly open questions.
Reader's Expectation
- Expect readers to answer them one by one.
- By answering, they can gain insights, especially confronting their "own will" and making decisions.
Examples
- Interviews and surveys in general.

5: Check List

What is it?
- A list of items answerable with Yes/No.
Reader's Expectation
- Expect the determination of whether specified items are Yes or No.
Examples
- Omitted

6: Label List

What is it?
- A list of classification items (labels) to assign to a subject.
- Readers select labels from this list and assign them to the subject.
- There are one-label-per-subject (category method) or n-labels-per-subject (tag method).
Reader's Expectation
- Expect them to use the specified classification items.
Examples
- GitHub Issues labels, tags used in document systems.

7: Fill List

What is it?
- A list of blanks for the reader to fill in.
- It's essentially a template.
Reader's Expectation
- Expect them to fill in the blanks.
Examples
- Templates in general.

Introduction to Creative Thinking

sta — Thu, 18 Dec 2025 03:19:12 +0000

Summary

The Current State of Creative Thinking
- An uncharted genre where individuals define and interpret as they like
- None captures its essence
What is Creative Thinking
- The only approach that can contend with Open-Ended Situations
- No management whatsoever; exploration instead
Approach to Creative Thinking
- Neither communication nor documentation, but "spreadication"
- "Solo work" over teamwork
- "Shield and purge" to absolutely protect the act of exploration

Background

Era of Innovation Demand

Today's world is referred to as VUCA, a period of great change without definite answers. Additionally, as noted by terms like DEIB, our own standards and demands have risen. For developers, approaches like DevEx and DevRel that emphasize respect, consideration, and customer-centricity are gaining importance.

To survive such times, innovation is essential.

It's not necessary to change society itself, but we must at least alter ourselves and our surroundings. We need the power and structures to do this sustainably. This isn't about solving immediate technical problems—what I call "hard work." Rather, it's about exploration until we discover the hard work, requiring a completely different strategy.

Creativity and Open-Ended Situations

Let's define a situation where there's no clear answer and no direction in sight as an Open-Ended Situation (OES). As the name suggests, it is wide open with no building or point that can be called a goal. Rather, you must decide what the goal is.

Therefore, creativity is inherently required in OES.

Misguided Approaches to Creative Thinking

Despite attempts to make creativity replicable through what is called creative thinking, existing methods seem misguided.

For example, take the following explanations:

Brainstorming is key
Ideas generated in brainstorming need validation
Advance your marketing channels, etc.

No, that's completely off. Creation is exploration. It is the activity before you start planning or working, without any tangible outcome. The only product is text expressed in words. Comparing it to generative AI, it's akin to creating prompts.

Creation requires deep dives and high, distant leaps, and anything related to work—planning, management, tasks—becomes an obstacle. You must eliminate everything and focus solely on thinking and articulation. Creative thinking must be designed for this purpose.

Therefore, I took a stand. Let me teach you what creative thinking truly is.

Creative Thinking

Overview

Creative Thinking is a method to maximize encounters with innovation.

The aim is to break through Open-Ended Situations and serves as the activity before any actual work begins.

The essence of creative thinking is exploration, engaging in thought and articulation until things start to "become visible." Ignoring all constraints, focusing solely on the theme, or even straying from the theme for detours, you explore and explore until you find that "Eureka!" moment. You're only as good as your persistence in finding it.

True to its name "creation," it necessitates deep dives and high leaps, eliminating anything that obstructs the process. You don't plan, manage, or assign tasks. You don't hide your own lack of persistence or loneliness behind the guise of teamwork or communication.

Making Creatives' Practices Replicable

Currently, it appears that only a few creatives possess creative thinking.

Engineers, managers, and business leaders seemingly apply this in merely 1% of cases. This is because these people simply follow orders from higher ups or trends around them. It's not creation but merely work. There's just a difference in execution capabilities, performance, and interpretation. They are merely high-performers or smart individuals, not creators.

When I think of creators, I envision Japan's manga, novels, or illustrations. Japan is at the forefront, home to prodigious talents engaged in over twelve hours of creative work for years. Having grown up in this samurai nation, I aim to transform exploration from a genius-level activity to a method with reproducibility.

The Three Elements of Creative Thinking

I've organized the concepts and methods of creative thinking into three elements.

1: Spreadication

Neither communication nor documentation, it's Spreadication. Spreadication is the activity of organizing ideas through divergence, convergence, and distillation.

Let's compare.

Communication happens in a one-on-one exchange:

A <---> B

While N-to-M is possible, as with computer multitasking actually being a rapid switch between single tasks, communication at its smallest unit is one-on-one. It merely becomes complex and compounded.

Next, documentation is about creating a document as a medium of exchange:

           C
           |
           v
A ---> Document <--- B

This enables asynchronous interaction, not immediate listening and speaking, but writing and reading, allowing complex information to be fully communicated.

Finally, in spreadication, you create a workspace for individual exploration:

                         c
                         |
        +----------------|---+
     A----->             |   |
        |                v   |
        |     Workspace      |
        |                    |
        |                 <------B
        +--------------------+

Within the workspace resides a wealth of ideas and information. Each individual freely expands upon them and actively utilizes others' contributions.

2: Solo Work

Solo Work is the antithesis of teamwork, involving individual activity.

During solo work, you do not:

Engage in synchronous communication, including meetings or small talk
Follow plans, create them, manage budgets and actuals, track progress, etc.
Execute tasks, persist until deadlines or quantitative assurances are secured
Conform to specific ways of working

Without communication with others, without plans or deadlines, you dictate your way of working. However, solo work is lonely. It's meaningless if you slack off, so exploration must be pursued. You must continuously explore an Open-Ended Situation on your own without clear answers, visible conclusions, or guidance from anyone.

There are exceptions:

The timeframe (scope) for exploration is given
- For instance, "Let's do this for just two weeks"
Reading others' writings and expanding or commenting on them is permissible

That's it. It's essentially solitary, hence the name solo.

Why choose solo? Because it eliminates all distractions. Only by reducing interruptions to zero and deeply immersing oneself can one reach creation. There is no escaping solitude.

3: Shield and Purge

Shield and Purge refers to protecting solo work (shielding) and removing obstacles to solo work (purging).

As you can easily imagine, maintaining solo work while continuing spreadication is not easy. You must be meticulously committed, akin to the levels of strict security or governance that come to mind.

There is a term, CPPF—children, partners, pets, and friends—suggesting creators should diligently eliminate these distractions. Whether this is right depends on personal and situational factors, but for creators, such measures aren't unreasonable. In creative thinking, you must not stray from this essence. Instead, to sustain it, both shielding and purging are emphasized.

Conclusion

We have introduced the concepts and three essential elements of creative thinking.

To contend with Open-Ended Situations, we must engage in the rigorous activities that creators undertake. This is not the realm of geniuses, but a method that can be made reproducible. I believe this and am developing methods and concepts as a Soft Skills Engineer.

Engineers, in particular, because you are engineers, I urge you to put this into practice!

Deep Contribution and Wide Contribution

sta — Wed, 17 Dec 2025 08:35:42 +0000

Summary

Deep contribution refers to project work.
Wide contribution refers to transject work.
In today's world, there is a supremacy of "deep contribution," which tends to lead to a shortage of talent as it requires a high level of human resources.
- To mitigate this, it is beneficial to shift to a paradigm of wide contribution.

Background

The Reality that Work ≒ Project Work and Role ≒ Framework

It seems that a shortage of human resources is being called out in almost all organizations. This is naturally because there is little flexibility in how "work" is perceived.

Here are some examples:

When we talk about work, it almost always refers to project work in the modern context.
- Members need a comprehensive ability to adapt to projects and teams.
- Without this, individuals are not considered valuable assets, even if they are skilled.
When we talk about roles, it refers to the framework model these days.
- A framework is created in advance, and people who fit into this framework are sought.
- Job descriptions vary widely, but they merely change the material or color of the framework, while the "framework" of position or role names remains static.

In short, only those who have comprehensive abilities and fit the framework can pass through, which makes finding such individuals quite difficult.

Engineers Are No Exception

We engineers are no exception.

Especially managers and senior engineers are responsible for human resource management and acquisition, so this issue is certainly their concern as well. Of course, because of the curse of comprehensive ability and the framework, it is hard to find talented people, leading to struggles. Therefore, they often have to look at the long term and focus on nurturing talent. This also involves communication costs. It's almost like being a teacher. They justify it to themselves by saying things like "it's necessary" or "nurturing can be enjoyable." It's quite challenging.

It's Time to Change the Paradigm

The culture mentioned above is what I call the approach of Deep Contribution. Projects fall precisely into this category, where one dives into a specific scope and strives to achieve the intended outcomes, doing whatever it takes until success is achieved.

However, relying solely on this approach has its limitations. It is time to introduce another, fresher paradigm!

Deep Contribution and Wide Contribution

Deep Contribution refers to project work. As the name suggests, it involves diving deeply within a specific scope and working tirelessly until the desired outcome is achieved. If not initially possible, it means persevering until it becomes possible, going deeper and deeper.

On the other hand, Wide Contribution refers to non-project, cross-support roles. You do not belong to any particular project and work on a best-effort basis, but in return, the influence range is vast. For example, an individual engineer, not in an executive position, regularly delivers blog posts to several thousand employees within the company and responds to queries from all employees.

Let's compare it with numbers:

Deep contribution delivers a value of 100 to a single project.
Wide contribution provides a value of 1 to 100 projects.

Examples of Wide Contribution

While we refer to deep contribution as projects, wide contributions have a name, too: Transject. I have already written an article with specific examples, so please take a look at it.

👉️ Project vs Transject - DEV Community

Wide Contribution Alleviates Human Resource Shortage

The reason is that it advances the structuring of organizations and work.

The approach of solely focusing on deep contribution, that is, project supremacy, is akin to a monolithic code in programming terms. It's hastily written code that prioritizes speed over cleanliness, making it unsightly and difficult to maintain. The technical debt is unbearable. Therefore, it requires overall excellent talent who can withstand this mess.

Now, what happens when wide contribution is recognized, and wide contributors are increased?

Standing up wide contributors:

It's equivalent to intentionally reviewing existing work and organizational structures, verbalizing, modeling, and determining what to extract and restructure. This is similar to turning common data into variables or modularizing common processes into functions.
It also equates to developing, organizing, and delivering ideas and methods that become convenient when understood and adopted. This, too, is akin to introducing linters, formatters, or type systems.

In any case, while it may require more effort in the short term, in the mid to long term, it leads to further structuring. As engineers, you surely understand the advantage of structuring.

Communication As A Task: A Mindset for Successful Asynchronous Work

sta — Tue, 16 Dec 2025 20:57:31 +0000

Background

It's Needless to Say Asynchronous Work is Valuable

As engineers, we require concentration, but the tools, methods, and procedures needed for that concentration vary from person to person. A single environment like an office has its limitations.

Moreover, before being engineers, we are human beings, and as humans, we want to minimize life's burdens. For instance, getting exhausted from commuting is ludicrous. Even if it's a 30-minute one-way commute, with preparation, settling in, and context-switching, it's effectively equivalent to about 1 hour one way. That's 2 hours round trip. Imagine what could be done in those 2 hours.

To ensure each individual's concentration and care for their well-being, remote work is essential. This necessitates asynchronous work.

The Reality of a Shift Back to Office Presence

Even giants like GAFAM and MATANA are still advocating for a return to the office. It's obvious that productivity can result from being in a physical office. Confining people by time and place is exploitative, and it's no surprise that exploiting can yield results. Much like an oppressive regime of a king, you can achieve outcomes by forcing slaves to overwork.

Even without such force, most people inexplicably prefer to gather. Certainly, gatherings are lively, fun, and socially satisfying, but that's all. While it might work for some, it is not favorable in terms of concentration and stress load. It's not something that should be forced on everyone.

Why does this imposition still run rampant? Simply put, people who prefer this collective way of working are in power. Furthermore, as organizations grow, inefficiencies and sabotage structurally increase, leading to using office attendance as a loyalty test.

Seemingly Full Remote But...

In many organizations that might seem fully remote or close to it, there are cases where they are consistently engaged in online meetings. This is no different from being at the office.

Office work binds both time and place, while online meetings bind only time. The binding exists either way. To achieve focus and care, the binding must be reduced. It is also necessary to reduce online meetings.

Thus, asynchronous work means working remotely without relying on online meetings.

A Perspective to Establish Asynchronous Work

In my years of advocating, I've realized that many don't grasp the prerequisites for establishing asynchronous work.

This time, I'll articulate what these prerequisites are. We'll consider communication as a task.

Communication As A Task

Communication As A Task is a concept where communication is seen as a task. It is abbreviated as CaaT.

In asynchronous work, communication naturally becomes asynchronous communication. Many people dislike asynchronous communication simply because they do not understand the underlying concepts.

Asynchronous communication should be perceived as a task.

A task has the concept of being open and closed. It begins when opened and ends when closed. This means that all opportunities for communication and the topics covered therein are handled as tasks. Bringing everything to a point where completing a task means it's finished provides clarity.

Example

Suppose Manager M and Engineer E have a 45-minute 1-on-1 meeting. The topics are as follows:

1: Icebreaker
2: E's career
3: Topics 1 and 2 concerning Project P
4: The poor compatibility and handling of members M1 and M2 in P
5: Closing

So how would this look under CaaT? It would be as follows:

Task 1: "Icebreaker", conclude in 3 minutes
Task 2: "About E's career"
Task 3: "Topic 1 concerning Project P"
Task 4: "Topic 2 concerning Project P"
Task 5: "Compatibility and handling of members M1 and M2 in P"
Task 6: "Closing", conclude in 2 minutes

As you can see, everything becomes a task. We then think about completing all six tasks.

The icebreaker and closing should be time-bound. They automatically end after the specified time.
The other tasks can be regular. Once either or both agree to close, it's over.

Of course, it's not necessary to conduct these six tasks as a meeting. They can be done asynchronously. If using Slack, create a channel with both E and M and open six threads. If using GitHub Issues, open six issues.

In fact, if it's asynchronous, you might not need an icebreaker or closing, so four would suffice. Or, if you want small talk, open a dedicated thread or issue for ongoing discussion.

This is the approach. Consider the communication topics as tasks with opening and closing.

Does It Seem Bland?

Many may find CaaT to be "bland" or "lacking in humanity."

Admittedly, that's true, but is it necessarily an issue? We are engineers, and this is work—not playtime with friends. We're not students anymore; we should have professional consciousness.

Certainly, as humans, some social interaction is necessary, but a dedicated opportunity can address that. Meeting weekly, monthly, or even at a lower frequency could suffice. Many organizations conduct retreats.

I call this Communication Time and recommend securing social time as "part of work hours without working." Whether it's Minecraft, board games, or just chatting—it doesn't matter. You can do it regularly or spontaneously adjust as you like. An example of the latter is GitLab's Coffee Chat, where anyone can request a 1-on-1 with anyone at any time.

What You Want is Knowledge

sta — Tue, 16 Dec 2025 20:28:44 +0000

Summary

What You Want isn't just a personal life hack in the self-improvement genre.
- In fact, writing it down collectively with multiple people has many benefits.
- It contains information valuable enough to be called knowledge.
The method is simple; you just need to provide a space where multiple people can write together.
- For instance, tools like Cosense, GitHub Issues, and Miro

Background

"What you want to do" and "What you want" are important

"I won't miss what I want to do or what I want" is one of the soft skills, I believe. Although missing these won't cause immediate harm, securing them can lead to learning and richness in the mid to long term.

Some examples of tools (especially lists) that fulfill this are as follows:

List of Things You Want to Do
- A simple list where you write down what you want to do
- Creating such a list can help make it clear what you should do next
GTD®'s Someday List
- A place to store "things you might want to do someday," even if you're not committed to doing them, and it's okay to discard them if necessary
Bucket List
- A list where you write down "things you want to do before you die"
- Often, you aim to fill it with 100 items as a way to gamify your life

What You Want

Let's refer to this genre as What You Want, abbreviated as wyw.

Engineers tend to underestimate wyw

In my opinion, engineers tend to underestimate wyw. The same goes for engineers in the field, engineering managers, and even senior engineers.

This is because wyw appears to resemble self-improvement or life hack endeavors, which engineers often dislike. While this is partially true, it's more than that. It's something that is particularly useful for engineers.

In this article, I will demonstrate the value of wyw. Specifically, I will introduce a method for sharing wyw among multiple people.

What You Want Log

A What You Want Log is a collection of wyw. It's accumulated collectively by several people. Think of it as the wyw version of a product backlog where tasks are typically stored.

Anyone can write anything in a wyw log, but be sure to define the scope of what can be written. A clear example is "things you want to do related to this project."

Incidentally, I often set the scope much broader. It may include personal wants or things to do, or discussions about personal career growth. This approach tends to foster more conversations.

Benefits of the wyw Log

Conversations among members flourish
- Increases asynchronous interactions
- Even in synchronous conversations, using wyw as a topic can make discussions more engaging
Serendipity occurs
Hidden needs of the members become clear
Offers practice for those not used to writing comments or creating issues
- Surprisingly, many people need practice, such as junior engineers, newcomers from other industries, and seniors just beginning to learn asynchronous communication
Provides practice in "verbalizing," which is necessary for prompt engineering
- Even as engineers, not everyone is adept at verbalizing. In scenarios involving soft skills like communication or management, verbalizing "context about oneself" is often required, which many find challenging. Casual initiatives like this can help in practicing it.

How to Do It

Simply use some tool to allow multiple people to write at any time.

Example 1: Cosense

https://scrapbox.io

Cosense is a Japanese-produced simultaneous editing wiki that can operate thousands of pages with ease and without needing Slack. It's also appealing because it can be customized using JavaScript.

Create a "wyw workspace" including all members, and have them collectively write wyw. It's enjoyable as you can link pages, embed images or videos easily, and hype things up.

There's already an example: /wanna. It's a Japanese community, but multiple people are already writing wyw. I'm also participating. It's fun to see others' wyw, get advice, and of course, write my own. Through wyw, you can get to know others and reflect on yourself.

Example 2: GitHub Issues

Create a repository for wyw and handle 1-issue per 1-wyw.

It's important to ensure writing is as casual as possible, so try to keep the following in mind:

Either no labels or templates, or keep them simple
Don't manage it. For instance, even if there are duplicate postings, don't worry about it. No need for maintainers to sort them.

As wyw accumulates, you can create various mechanisms using APIs. You can create a Reader or a feature that randomly displays content. It might also be interesting to integrate by sending this week's entries to a Slack channel.

Example 3: Miro

Create a wyw board in Miro and write on it using sticky notes. Also, if you come up with more wyw upon seeing others' sticky notes, keep writing them down. It's like brainstorming asynchronously.

One thing to note is not to organize. Even if it's cluttered or there are duplicates, focus solely on writing sticky notes for wyw. The more sticky notes accumulate and things get cluttered, the more interesting it becomes.

wyw is Knowledge

I consider the wyw accumulated by multiple people in this manner to be knowledge. This is because it includes individual personalities, needs, and advice from the members.

It might also be useful to input it into a generative AI for dialogue or analysis. Since the wyw is derived from the members themselves, the information suggested from it will be both attractive and practical.

RAIS (Regular Asynchronous Information Sharing)

sta — Mon, 15 Dec 2025 20:41:11 +0000

Summary

Information is held by managers, but they tend to hoard it
If you want to run organizations or projects more smoothly, you should share information regularly
To do this, sharing information "regularly" and "asynchronously" is effective

Background

Information is held by managers

I read Will Larson's "Staff Engineer" book (the Japanese edition with expanded interviews for Japanese readers). In one of its supplementary chapters, it states that organizational information is designed to revolve around managers, and I found this to be very true.

Organizations like GitLab that share all information asynchronously and via a SSoT (Single Source of Truth) are rare. Usually, confidential meetings are held among higher-ups, and decisions are passed down to middle or ground-level workers as needed. The reliance on meetings—primitive methods—inevitably makes communication word of mouth, which is a structural issue.

The key players in this structure are the managers, or you might call them middle managers. They are key because they connect the executive level with the operations level. In decision-making processes not involving executives, they virtually act as kings. Unless they release information, the ground-level workers cannot access it.

Managers tend to hoard information

Not every manager, but most do tend to hoard information or sometimes don't share it at all.

This is also a structural issue, leading to the belief that information sharing is equivalent to conveying it in meetings. Meetings entail costs. If there are 5 members, are you going to set up a meeting with all 5 people every single time?

Managers often claim, "I'm open because I answer when asked," but that is far from openness. Openness is achieved only when information is available to anyone, at any time, without having to ask.

About This Article

This article will teach managers, including engineering managers, how to release information.

By adopting this approach, as a manager, you'll be able to share information regularly without burden, gaining trust from your team members. In turn, members will be able to act based on the shared information, making projects easier to manage. While the effort of sharing regularly may initially seem burdensome, it is undoubtedly worth it.

Regular Asynchronous Information Sharing

Regular Asynchronous Information Sharing (RAIS) is about sharing information regularly but asynchronously, as the name suggests. We'll abbreviate it as RAIS.

Examples of RAIS

Once a week, share the summaries of decisions made in management meetings via chat
Once a week, distribute summaries of meetings held among managers or senior engineers via a mailing list
Daily, write an overview and summary of meetings attended that day in a wiki, and also share the URL in chat

How to Implement RAIS

Simply define the parameters and put them into practice.

There are 3 parameters:

Frequency
Content to share
Audience

Let's delve into each.

1: Frequency

When it comes to frequency, there are options like daily, weekly, or monthly.

I refer to it as DWMY. You organize your notes daily and then use that organization for the weekly review. Then use weekly notes for the monthly report, and similarly, use the monthly summaries for the annual review. By building it up this way, the workload becomes manageable.

Consider the alternative: if you were to compile a monthly report without doing daily or weekly reviews, you'd be looking at summarizing 30 days of information all at once. That's overwhelming. However, with DWMY, you only need to review 4-5 items from your weekly summaries.

2: Content to Share

Essentially, it's everything you've gathered from meetings. Think of it as subtracting from that total.

It's hard to determine what will be useful to whom, so instead of filtering based on your own judgment, aim to divulge information as broadly as possible.

For creating content, DWMY is recommended. Especially on a daily basis—summarizing what you learned from meetings daily. Even just a 5-minute slot to jot down bullet points is enough. Don't stress if you can't document every meeting.

For example, if you attended 7 meetings in a day, ideally, you'd have a list like this:

- Meeting 1
    - Summary
    - Summary
    - ...
- Meeting 2
    - ...
- ...

Perhaps you can't disclose meetings 4 and 5 due to privacy concerns—which is fine (sharing confidential meeting details is problematic). A few lines are totally acceptable.

For sharing content, weekly is a good balance. However, it's easier to create a weekly summary if you have daily tasks to work with. Some may find it easier to compile retrospectives weekly. Tailor the operations to your preference. It's something you are doing, so do it in a way that suits you best.

3: Audience

Share where the team naturally communicates. This is likely in a chat tool like Slack, but some projects may use mailing lists.

If it's hard to write in chat, feel free to use a wiki, notes, or a repository (Markdown), but don't forget to circulate the URL to the channels where communication flows.