Skip to main content

Organizational structure

Who owns what

In my experience RoboTeam Twente functions and 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 created more segregations between different fields and slowing down organic communications then what would be optimal.

The way the team is divided into roles directly shapes how information should move. Where responsibilities are unclear or unowned, decisions get made in conversation and then lost, because no one is accountable for recording them. This page sets out how RoboTeam Twente is structured and, more importantly, who owns what, so that every recurring type of decision has a clear home.

This is not a description of how things happen to work. It is the organizationalstructure chartthe team and how information flows, it exists to remove the ambiguity that wascaused createdinformation 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 yearparts of 2025-2026:
Organizational_Chart_Transparent.png
(yesthe Irobot knowthat cross departments. The clearest example: GNSS, multiple teams were working on while it hashad 2already mechanicalbeen sectionsdecided oops)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 use 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 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. But within my investigations it was not quite possible to integrate the software department throughout the other STEM subsystems due to their broad work week by week.

Org chart.png

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 ].
Back to top