Your Team's Hierarchal Structure & Methods of Organization

FIRST General Forum
21

On 1710, we use a system under a CEO.

Our system starts at the CEO. Under the CEO there is 5 other leaders. These are the CFO, CIO, COO, PRO (Public Relations Officer), and the Awards Coordinator. Under each of those leaders there are several sub groups. For example under CFO there is fundraising and sponsorships. I can post a list later of all the sub groups. In these sub groups there is a leader and then usually 1 or 2 other members. Each team member that is not a leader is usually in 2 or 3 sub groups.

As far as motivation goes, on each member’s application to be on the team, they mark their top three choices for sub groups that all year, for example fundraising. Then they also mark their top three for build season, for example mechanical. The leaders then get together and put everyone where they need to go. A majority of the time, everyone gets put into their first choice and if not, it is usually the second choice. It is rare you get someone who doesn’t get put into their top two choices. This helps with motivation because the team member chose where they wanted to go.

22

First off, I’d like to continue and thank you all for your highly appreciated input. Thanks!

Now, I’ve raised all the issues mentioned here at our meeting today, which discussed our new hierarchal structure. The structure presented (by me, thanks to all of you) has been open-handedly accepted by all team members. However, this year being our rookie one and all that, the thing that did not go as smoothly was how to incorporate next year’s younger students (reminder: this year, it has been only us, 11th grade working on the project).

The team pretty much split into two different sides, each with its own rightful agenda:

  • The ones who put the team before themselves. They think that in order to create a stable, continuous team, we, as its makers, have to sacrifice our roles for the greater good of the team. According to them, this can be accomplished by giving the younger students at question a direct experience of how things run. To do that, they propose that we, as the experienced fellas, should step down from our duties and pass it on to the younger students at question. Each of us won’t have any practical duty, but instead, will supervise and “mentor” the younger student, who will be doing all the practical work and making the decisions.

Pro:
Allows for the team to run in a continuous manner, even after we are gone, as those who are subject to run the team next year(s) will be prepared thanks to the direct experience they are given.

Con:
Does not allow the team to reach its “maximum”, as experienced personnel won’t be in a decision-making position, but will only be considered as “advisers”.

  • The ones who put themselves before the team. They think that in order to achieve the maximum out of the team (competitively), the experienced fellas (us) should retain their positions, simply because we are more experienced. In order for the team to run after we are gone, they suggest that the younger students will earn their experience in an indirect manner. The younger students at hand will be hierarchically under the experienced ones, and won’t have the final say in any decision whatsoever.

Now, the way I see it, our team is going to go through hard times with this decision as we’re pretty much split. This question will affect both ours and the team’s future in an irreversible manner.

On the one hand, sacrificing ourselves for the team is the appropriate thing to do as we would like to have our creation exist even after we’re gone.
On the other hand, we would all like to squeeze the maximum out of our team and achieve even better awards and recognition next year. However, doing so will hurt the team once we are gone, as there would be no one experienced enough to actually do anything.

Eventually, all teams, organizations, institutes and even states reach the same situation we’re currently in - aspiration conflict. One side aspires to achieve this, and the other aspires to achieve that. The real question at hand is how to settle things between the two, and that’s where I’m currently clueless.

Gah… we’re all so frustrated over this. Hope someone could help out with some insight or better yet, previous experience in this sort of thing.

Thanks in advance,
Assaf

23

Let me tell you about my senior year:

I was the only draftsmen on 1766 and the head engineer. It was clear, if I just left the team then there was going to be a struggle the following year. I didn’t want this and as part of leaving my mark on history, I found an apprentice. She was an extremely hard worker and had lots of natural skill. I might have been a bit short with her at times, but she respected me and appreciated the chance to learn. I did everything I normally would, she did a few things without me. But everything I did do, she was there. She became one of the best draftsmen our team has seen, took over my role in its entirety and even does a little extra. Our team accomplished more that year because of this choice, then we would have otherwise. Needless to say, they did not need me the following year at all. I came back a few times, helped out on a few minor things, but she had everything under control.

Now, I tell you this story to allow you to see a bit of a compromise. Perhaps you could partner each new person with an old person. Try to match personalities, dedication, and possible skills as much as possible. If you do the apprentice thing the team will not suffer the following year, it will flourish. Also, having a student follow you around isn’t really a hindrance. If they ask a question you don’t have time to answer(like build season) make a note and return to it after build season.

I know, I’m probably overly optimistic of this idea because the one time I’ve seen it used, it was a complete success. Anyone care to state any downsides to this system?

24

Assaf, I am really glad that your team is able to see the importance in teaching your future team. Many overlook this goal.

As Molten suggested, don’t just take a step back and be advisors to the new kids. Have them work alongside you. Show them every single thing that you’re doing and that your mentors are doing. Let them take a crack at the simple things. When they see you doing something that is beyond them, THAT is what motivates them to work harder next year.

The best thing you can do is also run training sessions during the summer and during the months before build season. Teach the kids the knowledge they need to keep up with you during build. That way you won’t feel like your team isn’t reaching its max potential and you can also get the new kids involved at the same level you are at. Definitly try the “apprentice” system. It is what creates a steady rate of success and growth in the best teams.

Hope this helps.
-Akash

P.S.- Congrats on a very exciting rookie season! I started following your team after I saw you were finalists at Technion and I was thoroughly impressed in Atlanta at how well you kept up with the “big boy” teams.

25

The apprentice system seems to work for us. During the Lunacy season, team 1318 was comprised of the following:

31 students, of which
15 were seniors
3 were juniors
13 were sophomores, and
0 freshmen (Issaquah SD has a separate 9th grade campus)

This year especially, we were going to lose alot of experience and talent. To minimize the effects of brain drain and to help the team flourish going forward, a goal had been set such that all tasks, no matter how major or minor, were assigned as an “experienced person paired with a less-experienced person”. We’ve found that by going this route, tribal knowledge can be effectively handed down.

When the season ended, elections were held, and the new officers began to take on their future roles.

It’s always exciting to see the next generation of leaders step up to the challenge.

26

Haha, wow. Such an excellent feedback within so little time. Big thank-you to all three of you, this input has been extremely appreciated.

I’ve suggested the apprentice system as a compromise, presenting its varied aspects and how they deal with each side’s aspiration for the new recruits’ involvement.

This seems promising, and will more than likely sort out the differences and prevent us from having to deal with this in the future.

Thank you all so much. :slight_smile:

27

I’m going to grab another example from personal experience…

My Boy Scout troop had a system where each Senior Patrol Leader and Patrol Leader were elected by the whole troop and their patrols, respectively, then chose their own assistants. A few years ago, the system changed (the SPL was away for quite a while, and the ASPL, his assistant, had to lead the troop with no experience). Now, the ASPL is elected, while the SPL is the previous ASPL. The patrols still elect their patrol leaders, who choose their assistants.

You really want the leaders to be passing on their skills to the younger members, not by advising, but by grabbing a few younger members and saying, “Come, I will show you how to do this so that you can show the ones who will follow you.” As the new members get better, the older members can lead them farther, and start to be more advisors than doers.

28

I hope this answers the original question of the thread…

Attached is our team’s proposed hierarchy for next year. This year we had about 20-25 students, next year we are hoping for 25-35. This structure is flexible enough to accommodate either number of students, as people can be involved in more than one area, and are encouraged to do so.

The groups marked with a * are simply a responsibility and don’t have to have people working on them year round.
The arrow between Design and Game Strategy is there to show that these groups will be working very closely at the beginning of the year in deciding the functions of our robot.

Some might wonder why Programming is under Strategy. Our reasoning for this is that the programmers need to work closely with the Drive Team to design the OI, and they must be well aware of the strategy in order to effectively program our robot (one example would be autonomous this year…our programmers had out countless field diagrams and rule books trying to decide the best route).

We are also changing the naming scheme of the ‘teams’. For instance, Build Team is no longer Build Team, but Build Group. This is because we felt that people were losing the view of the larger picture (our Team as a whole), and were too focused on their particular role (for instance, Mechanical).
Their will be a leader for Build, Strategy, Safety (the Safety Captain), Public Relations and Animation (if we get enough students interested), as well as some sub-group leaders (ie. for Mechanical, Documentation, Scouting, Promotion, and Team Spirit).

I hope this might give some of you some ideas for your team structure and, as always, I am open to suggestions on how to improve this hierarchy and any questions you might have.

Hierarchy v3.pdf (300 KB)


Hierarchy v3.pdf (300 KB)

29

Team 1675 implemented an apprentice system that ended up working very well. In the teams second year we had to rebuild the team because most of the members graduated. At that time a freshman on our team started to learn about welding. The third year we had a mentor, who was a tool and die maker that took the student and taught him how to weld. The fourth year the student was good enough at welding to help teach workshops on how to weld to incoming students with the mentors’ guidance. That year a freshman became interested in welding. The students’ final year on our team, he was able to mentor the younger, interested student with only some help from the adult mentor.

This is just one example but we used this system quite a bit on our team. It doesn’t mean the seniors have to step down and step back, it just means that they have to become teachers as well. Doing that will also help you transition from a student to a college mentor smoothly.

Personally, going into my final year on the team, I looked at what I had done with the team, and what would happen if I left without any transition, and was terrified that the Team, the younger students, my partners in crime, would have a really hard time next year. So I stepped back, so they could step forward, and have their turn.

Team 1675 is a smaller team, and our break down turned into having Co-Captains (one in charge of the mechanical side of the team and the other in charge of the rest) and Heads that were responsible for Build, Design, Programming, and Logistics. Our team was fully student run and in 2007-2009 the system worked well. Students could over lap areas and do other things but the main goal of this system was to help with communication and make sure everything was getting done properly.

I hope this helps.

30

That is actually a very sensible hierarchy. Some of the things can be done once and revisited once or twice a year, as noted, while others take more time. I like how the mentors and school liaison tie in without being completely separate, and it’s in a professional format.

31

Our team doesn’t really have one student that is the overall captain, we have a committee structure that works very well for us. Each committee has a chairperson and when we have meetings we split into our groups after a general meeting. Occasionally, we have meetings for only our committee heads and mentors (sometimes not even mentors) to make decisions for our team. Committee heads are also encouraged to run their own meetings in school, at the library or where ever it need be. Our team coach picks who is in charge of what and then we take charge of our little piece while communicating with the other committee chairs. Each chair is pretty much equal power. However, we have a large team, (over 50 members!) so we can delegate more.

Robotics doesn’t really end for our team so we have what we call Year- Round Committees, Build Season Committees and Competition Structure.

Year-Round committees are like Web Dev, Digital Animation, Media etc. things that can always be worked on.

Build Season Committees are kind of obvious like Robot Design, Programming and Award Submissions.

Competition Structure is split into Technical (Pit Crew, Programmers, Drive Team) and Non-Technical (Scouting and Spirit).

Sorry about the long boring post! But if you would like specifics (yes, this is very general) PM me and I’ll be glad to let you know more!

32