※The content of this article is based on the author’s personal experience and views, and does not represent the official views of any organization or specific vendor. Additionally, we do not guarantee that the methods introduced here are effective and safe for all organizations. When actually implementing these methods, please make your judgment based on your company’s situation, contracts, regulations, security policies, etc.

Introduction: The “Alignment” Problem Might Be the Biggest Waste #

When working in an environment like we do at BESTNET, where infrastructure, applications, and storage are all mixed together,
we frequently see scenes like this.

• “What was the decision-making process for this again?”

• “How far along is that ticket?”

• “I don’t understand who designed this or what assumptions they made…”

The feeling that we’re burning more time on “alignment” than actual implementation — doesn’t that resonate?

Then an idea suddenly struck us:

“What if we could link the brains and bodies of related engineers and act as a collective entity?”

This is an idea bordering on science fiction, really.
Of course, physically linking brains via Brain Machine Interface (BMI) is still a long way off in reality.

However, by combining tools, operations, and culture, couldn’t we get closer to a “pseudo-linked state”?
With that in mind, we came up with a “pseudo-BMI team operations model” aimed at teams of 10 people or fewer.

Target Team Conditions #

We’re targeting teams that look something like this:

• Members: 10 or fewer

• Roles: Infrastructure, applications, and storage all mixed together (touching both cloud and on-premises)

• Tools used (example)

  • GitHub

  • Slack

  • Notion

  • Teams / SharePoint (for collaboration with other departments and external parties)

  • Nextcloud (file sharing, etc.)

In short, we’re targeting a **”small full-stack team where everyone touches everything”**.

Concept: Create a Team “Collective Brain” Externally #

In one sentence, the state we want to achieve is:

“Reduce information that exists only in someone’s brain,
and shift it toward the team’s external “brain.”

That’s the idea.

Instead of BMI, we use:

• Tools (GitHub / Slack / Notion / dashboards)

• Protocols (how information flows)

• Culture (how we behave)

And combine them to create a **”pseudo-linked state”**.

Tool Role Division: What Serves as the “Brain” #

First, we assign proper roles to the tools we have on hand.

1. GitHub: The “Central Nervous System” of Tasks, Code, and Decisions #

• Issue / Projects: Task management (infrastructure and applications mixed together is fine)

• PR: Changes to code and configuration

• docs/adr: A “decision log” of architecture (ADR)

The key point is:

Put everything—both infrastructure and applications—into GitHub Issues first

This rule is to unify the entry point for acknowledgment.
“Consolidating the task entry point into GitHub” ensures that everyone is on the same page at the start.

2. Slack: Real-time “Brain Chatter” #

Use Slack as a place to share conversations and “what’s on your mind right now”.

Example: Channel structure

• #dev-general: Development and infrastructure general

• #infra: Network, virtual infrastructure, storage-related

• #alerts: Monitoring and alerts integration

• #daily-sync: Daily “mind sharing” (covered later)

• #random: Random chat

What matters is:

When discussions in Slack produce “decisions,”
make sure to record them in GitHub Issue / ADR / Notion

This extra step is crucial.
“Talk and move on” leads to instant forgetting.

3. Notion: “Long-term Memory” for Design and Knowledge #

In Notion, store knowledge and designs that get reused over and over.

Structure image:

• 📚 Knowledge

  • System list (URL, owner, summary)

  • Common procedures (Runbook)

• 🧠 Architecture

  • Overall architecture

  • Network overview

  • Authentication / authorization overview

• 📝 Meeting Notes

  • Notes for each regular meeting

  • A “Decisions” section at the end of each page

• ✅ Playbooks

  • Procedures for incident response and regular maintenance

“Elevate to Notion” any explanation you’ve given three or more times
—a simple rule of thumb.

4. Teams / SharePoint / Nextcloud: External Interface & Repository #

• Teams: For communication with other departments / customers (external window)

• SharePoint / Nextcloud: Storage for documents and files

Consolidate the internal “engineer brain” into GitHub / Slack / Notion,
and position other tools as “connection points to the external world” for easier organization.

Designing a Pseudo-BMI “Day in the Life” #

Morning: Team “Brain Wave Alignment” (About 15 minutes) #

1. Post to #daily-sync individually #

Format example:

Just this alone makes it possible to see:

• What each person is focused on

• Where bottlenecks might emerge

in text form at a glance.

2. Take a quick look at the dashboard #

Prepare a single dashboard consolidating monitoring, CI, and key metrics,
and have someone (or rotate) glance at it first thing and post anything suspicious to Slack:

“DB latency is trending worse than yesterday. We’ll investigate the cause today while monitoring.”

This alone prevents sharing baseless anxiety.

Daytime: Task Start to Completion #

When Starting a Task #

1. Move the card in GitHub Projects to Doing

2. Write the context you know so far at the top of the Issue:

Leaving a “context packet” like this makes it easier
for anyone to catch up on the situation later.

When Stuck #

• Write in the Issue comment: “What I’ve done so far” and “Where I’m stuck”

• Copy that comment and paste it into #infra or #dev-general:

Sharing both “work logs and thought logs” together
makes it easier for other team members to share “the whole picture in their heads.”

When a Direction is Decided #

• Write the conclusion in the Issue

• For important ones, create one ADR

• Post the ADR link to Slack

By doing this,
“decisions once discussed and agreed upon” stay in the team’s long-term memory.

Before End of Day: Small “Brain Snapshot” (5 minutes) #

What each person needs to do is simple.

• Add a one-line memo to the Doing Issue: “What to do tomorrow”

• If you have time, add a rough summary of “What I did today” to #daily-sync

This makes it easier for yourself and teammates to reconstruct the situation the next morning,
reducing the mental context reload cost.

The “ADR” Mechanism for Not Forgetting Decisions #

The waste in meeting time happens when
**”you’re explaining something you already decided before.”**

What we want to introduce here is ADR (Architecture Decision Record).

• Create a docs/adr directory in each repository

• Record decisions that might cause friction or get forgotten

File example: docs/adr/0001-choose-proxmox-as-hypervisor.md

Once discussions in Slack are finished, someone writes an ADR,
and just posting the link to #dev-general has a big effect.

“Why did we choose this?”
moves from one person’s brain to the team’s external “brain.”

Phased Implementation #

Trying to do everything at once is tough,
so breaking it into phases works better.

Phase 1 (First 2 weeks): Unify the Entry Point #

• Create GitHub Projects,
  and try the rule that all new tasks must become Issues

• Create #daily-sync