Internal communication systems

RoboTeam Twente is actually quite a large organization with many moving parts, Therefore good structured communication is important.

How to write a management RoboWiki page

Why this page exists

The team has documented its technical work for years: code, designs, test results, build logs. But we have not documented how the team is managed in the same way. Decisions about ownership, communication, and coordination have often lived in people's heads. When those people leave, that knowledge leaves with them.

This page is a first step towards fixing that.

It explains how to write a management page: a page about a role, process, or decision, rather than a technical part of the rover. When you are documenting how the team works, rather than what it builds, use the structure below.

Who you're writing for

Write for the person who joins after you leave and has none of your context. Imagine a new student who cannot ask you any questions and needs to understand the page in ten minutes.

That leads to two important rules.

State the rule, not only an example. Examples are useful because they show what something looks like. But a newcomer also needs to know exactly what they are expected to do. A process page should include both the example or template and the rule for using it. For instance, "use this memo template, write the memo within 24 hours, and post it in #memos." followed by "here is a template of a memo"

The shape of a good page

Every management page should answer three questions, in this order. The order matters: it lets the reader understand the reason for the page before being asked to follow its rules.

1. Why does this exist?
Start with the problem the page is trying to solve, not the mechanics of the solution. When people understand the problem, they are more likely to follow the process — a rule without a reason is much easier to ignore.

2. How does it work?
This is the main content: the rules, structure, or steps. Be specific. Use real channel names, deadlines, links, and responsibilities. "Within 24 hours" is better than "promptly"; "post it in #memos" is better than "share it with the team."

3. What does it look like?
End with something concrete the reader can copy or refer to: a completed example, a template, a diagram, or one real case.

Template

Copy this into a new page and fill it in.

[Page title]: use a plain, searchable title such as "Memos," rather than something like "Communication Protocol v2."

Why this exists: two to four sentences explaining the problem this page solves and what tends to go wrong without it.

What it looks like: a completed example, filled-in template, or diagram the reader can copy.

Links: related pages, source documents, and any tools mentioned.

Organizational structure

Who owns what

RoboTeam Twente should function as two distinct wings. The STEM and non-STEM.

The non-STEM part is headed by the Team Manager/General Manager and is assisted by human relations and external affairs.
From here there are two different ways of thought, an organization of this scale can structure their STEM wing as either by specialization or subsystem which is headed by a Technical Manager/Systems Engineer or both.

In the past we structured according to specialization this entails that you create and work in groups of the same field e.g. Mechanical embedded, electrical, etc.
This wasn't "bad", but it left the gaps between fields unowned, decisions that crossed departments had no clear home and often went unrecorded or unaddressed until it was very late in the process.

The way the team is divided into roles directly shapes how information moves. Where responsibilities are unclear or unowned, decisions get made in conversation and then lost.

This is not a description of how things happen to work. It is a statement of how the team is structured and how information should flow through it, and it exists to remove the ambiguity that caused information to fall between departments.

The current structure (2025-2026 specialization)

image.png

Historically the team is organized by specialization, software, embedded, mechanical, electrical, control, each department led by a lead who reports to the technical manager.

This works for managing people within a department. It does not work for the parts of the robot that cross departments. The clearest example: GNSS, multiple teams were working on while it had already been decided that it would not be used as it did not fit within the scope of the competition. No single role owned that interface, so no one was accountable for documenting the current decisions.

The proposed structure (subsystem)

image.png

The other option is to structure according to subsystems, hereby you divide teams from different specializations in teams according to functionality of the project. For us that would be a Mars rover so below here is an example of what I imagine an effective RoboTeam structure would be. Of course keep in mind the subsystems under the Technical Integration Manager are just a rough outline of the idea, these systems can be broken down as specific or as broad as the size of the organization allows and the scope of that years project calls for. The proposed structure is not "purely" subsystem-based. Technical subsystems (drill, housing, drive, arm) are organized by function under the Technical Integration Manager, while software remains a single department under the Software Integration Manager because its work spans all subsystems simultaneously. This hybrid is deliberate and by having a clear line of communication between the software and technical integration managers it should avoid anything falling between the cracks or for one scope to grow disproportionally to the other.

Explanation of managerial positions

Team Manager

Financial Manager

System Engineer

Software Integration Manager

Technical Integration Manager

Memos, why and how

Why we use memos

A lot happens every week in each department. To keep everyone aligned, we hold one General Team Meeting (GTM) where all departments update each other on progress, blockers, and help they need.

The GTM alone is not enough to keep the team on the same page. Not everyone can attend every week, and because so much is discussed, people forget details by the time they need them. We take detailed minutes at every GTM, but they are long and stored 4 folders deep in the RoboTeam Google drive, which creates enough friction that most people never reopen them.

The memo fixes this. It is a short summary of the important points from the minutes including, decisions, deadlines, and action points sent to every member so the information reaches them instead of waiting in a folder.

The rules

What every memo must contain

Each memo has two parts:

  1. Department updates: one short heading per sub-team/system, a few bullets each.
  2. Action points: grouped by person, so everyone can find their own tasks in one place. Each action point states the task, and a deadline if applicable.

Example

Memo GTM June 15th

Action Points

Everyone

Candela Cimadevilla Gonzalez

Myrto Pierrakou

Zodi Minetti

Illia Guzerya

Nikolaos (Nick) Diamantopoulos

Detailed minutes

https://docs.google.com/document/d/1r2FWdeTxTQQddGWUbM6enzlEhyrRN8CbIWs4orOKaxc/edit?tab=t.0#heading=h.gjdgxs

Internal Communication Software (ZULIP)

Why Zulip

RoboTeam Twente is a large and, it being a student organization, sometimes chaotic team. That makes reliable information transfer between members hard.

Historically, updates and technical questions went through in-person conversation or WhatsApp. This caused recurring problems: messages were missed when a chat got busy, old conversations were almost impossible to search, and the norm on WhatsApp is casual, gifs, stickers, jokes, which is fine socially, but buries anything important. Part-time members returning after a few days away had no way to catch up on what they had missed.

We needed software built for structured work on a complex project. Options include Slack, Discord, and Teams. We chose Zulip because It can be self-hosted, making it effectively free while still professional.

The point of Zulip is not that it replaces WhatsApp. It is that its topic threading lets a member open a single subsystem channel and read that conversation from the top, in order, without combing through unrelated messages. That is the specific property WhatsApp and a daily stand-up cannot provide, and it is why the tool was chosen rather than only a change of habit.

(Keep that paragraph — it's the answer to the exact question your assessor raised about why add a tool rather than a practice. It belongs on the page and in Chapter 4.)

How the channels are structured

The channel structure should mirror the structure of the organization so it feels intuitive. There are two models I imagined:

We used specialization. I would recommend a future team to switch, but a team should pick one they belive would be most effective to tackle to scope of that years project.

Every layout starts with a General section containing:

After the General section, one channel per specialization/subsystem. Within each channel, topics are created per piece of work in progress. e.g. in #embedded, a topic like "CubeMars motor integration". Topics are simple; make a new one rather than derailing an existing thread.

Example layout (specialization based)

image.png

Posting rules

A tool only helps if people use it consistently. The minimum expectations:

Getting set up