# 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)
[](https://bookstack.roboteamtwente.nl/uploads/images/gallery/2026-07/zNfimage.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)
[](https://bookstack.roboteamtwente.nl/uploads/images/gallery/2026-07/rFaimage.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
- **Owns:** \[ **the interface register between software and embedded — every agreed dependency, in one documented place** \].
- **Why this role exists:** under the current structure, interface changes are communicated ad hoc between two leads, which the interviews link directly to \[ **late integration failures — cite App. 1.5** \]. A single owner means every interface change has one documented point of record.
- **Who fills it:** \[ **not a new hire — reallocated from an existing member's time; state whose and how many hours** \].
#### Financial Manager
- **Owns:** \[ **the interface register between software and embedded — every agreed dependency, in one documented place** \].
- **Why this role exists:** under the current structure, interface changes are communicated ad hoc between two leads, which the interviews link directly to \[ **late integration failures — cite App. 1.5** \]. A single owner means every interface change has one documented point of record.
- **Who fills it:** \[ **not a new hire — reallocated from an existing member's time; state whose and how many hours** \].
#### System Engineer
- **Owns:** \[ **the interface register between software and embedded — every agreed dependency, in one documented place** \].
- **Why this role exists:** under the current structure, interface changes are communicated ad hoc between two leads, which the interviews link directly to \[ **late integration failures — cite App. 1.5** \]. A single owner means every interface change has one documented point of record.
- **Who fills it:** \[ **not a new hire — reallocated from an existing member's time; state whose and how many hours** \].
#### Software Integration Manager
- **Owns:** \[ **the interface register between software and embedded — every agreed dependency, in one documented place** \].
- **Why this role exists:** under the current structure, interface changes are communicated ad hoc between two leads, which the interviews link directly to \[ **late integration failures — cite App. 1.5** \]. A single owner means every interface change has one documented point of record.
- **Who fills it:** \[ **not a new hire — reallocated from an existing member's time; state whose and how many hours** \].
#### Technical Integration Manager
- **Owns:** \[ **the interface register between software and embedded — every agreed dependency, in one documented place** \].
- **Why this role exists:** under the current structure, interface changes are communicated ad hoc between two leads, which the interviews link directly to \[ **late integration failures — cite App. 1.5** \]. A single owner means every interface change has one documented point of record.
- **Who fills it:** \[ **not a new hire — reallocated from an existing member's time; state whose and how many hours** \].
# 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
- **Who writes it:** They could theoretically be written by anyone who attended the GTM, but it makes more sense for it to be the **same person who also takes the minutes** as they have all the context and knowledge to decipher what might be written in them. Preferably this would also be a fixed position with the same person doing this job every time.
- **When it goes out:** within **24 hours** of the GTM starting.
- **Where it goes:** posted to the **\#memos** topic on ZULIP and sent by work email using "**year@roboteamtwente.nl**" e.g. 2026@roboteamtwente.nl
- **Format:** bullet points grouped under department headings, not paragraphs. Feedback was more favorable to bullets, though this wasn't universal check what your team prefers.
- **Writing:** memos can be written by hand or drafted by an LLM and checked afterwards. Note that minutes often contain jokes and RoboTeam-isms that confuse an LLM, so a human always reviews before it goes out.
### 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.
End with a link to the full minutes for anyone who needs the detail.
### Example
> **Memo GTM June 15th**
>
> - **Announcements:**
> - - Office power is still down after a power brick shorted.
> - ERC qualification announcement moved to June 28th.
> - Reveal Event is in 2 weeks (June 30th).
> - Student Team photoshoot is on June 25th (15:00–18:00).
> - - Photos will be used for promotional and international media purposes.
> - Meeting on Tuesday about rover layout and component placement.
> - Anyone wanting hardware on the rover should attend and contact Candela.
> -
> - **PR:**
> - - Several company representatives have confirmed attendance at the Reveal Event
> - - Current plan is to have two speakers per subteam.
> - Preliminary speaker list has been drafted.
> - Rehearsals need to start being planned soon.
> - **Mechanics:**
> - - Erik is working on the rover walls.
> - Ludwig is working on suspension-related tasks.
> - Myrto is assembling the gripper and working on the gearbox.
> - Printing materials will be purchased next week.
> - Beacon and switch components may be printed if time allows.
> - **Electronics:**
> - - Ethernet cabling has been installed in the rover.
> - CubeMars motor drivers arrived and are being soldered.
> - Ernesto is working on the power filtering system.
> - Steering system hardware is available.
> - Nanotec gripper components have still not arrived.
> - Camera USB cables may be too short and need review.
> - Drive system schematic is available.
> - **Control:**
> - - Control and Embedded systems work together on the laptop.
> - Physical testing starts this week.
> - **Embedded:**
> - - Progress has been made on CubeMars integration.
> - - Four of seven motors were initially non-functional.
> - Discussions with Chinese engineers resolved part of the issue.
> - One motor was recovered after flashing new drivers.
> - Remaining motor issues are still under investigation.
> - Arm movement has been demonstrated successfully.
> -
> - **Education:**
> - - Nathalie met with UT contacts regarding education activities.
> - Event planned for next year's recruits.
> - **SSTT:**
> - - Communication with SSTT was discussed.
> - **Events:**
> - - Ludwig has an mBots event tomorrow.
>
> ---
>
> **Action Points**
>
> **Everyone**
>
> - Attend the June 25th photoshoot if requested.
> - Contact Andrei if you find previous mBot cards.
>
> **Candela Cimadevilla Gonzalez**
>
> - Organize and lead the rover-layout meeting on Tuesday.
> - Discuss steering system implementation with Ernesto.
>
> **Myrto Pierrakou**
>
> - Work on the battery container design this weekend.
> - Purchase printing materials next week.
>
> **Zodi Minetti**
>
> - Future Factory cleaning duty.
>
> **Illia Guzerya**
>
> - Office cleaning duty.
>
> **Nikolaos (Nick) Diamantopoulos**
>
> - Office cleaning duty.
>
> ---
>
> **Detailed minutes**
>
> [https://docs.google.com/document/d/1r2FWdeTxTQQddGWUbM6enzlEhyrRN8CbIWs4orOKaxc/edit?tab=t.0#heading=h.gjdgxs](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:
- **By specialization**: software, embedded, mechanical, electrical, control.
- **By subsystem:** drive train, drill, gripper, human relations.
**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:
- **\#announcements**: org-wide notices posted by management
- **\#general:** informal chat, the social overflow that keeps the working channels clean.
- **\#memos:** where every GTM memo is posted (see the Memos page).
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)
### Posting rules
A tool only helps if people use it consistently. The minimum expectations:
- **Technical questions and updates go in the relevant channel/topic, not in DMs or WhatsApp.** So the answer is findable at a later date by whoever needs it next.
- **One topic per piece of work.** Start a new topic rather than reusing an old one for a new issue.
- **Announcements that everyone must see** go in #announcements (makes sense).
- **Memos** are posted to #memos within 24 hours of each GTM.
### Getting set up
- **Hosting:** Zulip is self-hosted at [https://roboteamtwente.zulipchat.com/](https://roboteamtwente.zulipchat.com/). Responsibility for keeping the instance running sits with someone from Software or who is most interested in it.
- **Onboarding:** new members are added and shown the structure during the onboarding week.