team hierarchy

[Ryan Foley]

Hi

I am thinking about re-doing how our team is run/ organized. All we have right now is one captain (me) and 2 sub teams (mechanical/ electrical). It's worked decently until now, it gets hectic a lot, but next year we will probably be an offiial team, so we were wanting to get better organized so that our first year back wont be a nightmare.


What is the hierarchy of leadership on your team (captain, lead mechanical, lead electrical, etc)?


what sub-teams do you have (constructions, PR etc)?


and lastly, do you have any suggestions on how to organize a small team (15 or so) as far as captains, sub team leaders, and sub teams?


Thanks a bunch

::edit::
whoops, probably should have put this thread in the "Team Organization" forum. Sorry about that.

[Jeff Waegelin]

Don't have too much organization. My team had way too much organization this past year. We had 3 captains, with 3 sub groups (Build, Tech, PR), and it was too much. The three sub-groups were a good idea, but you don't want to have too many captains, which we did.

[Gope]

The Baxter BombSquad's system is about as perfect as it gets, as far as I'm concerned

Mentor: Team Leader - incharge of all team functions, works with teacher(Head of Electrical or Mechanical Team)

Mentor: Design Leader - incharge of robot, makes all final design desisions in a tie vote

Teacher: School Sponsor - incharge of school releated events(head of Chairmans Award Team)

Mentor: Drive Team Leader - responsible for training and selectoin of student drive team members, makes all final scouting and picking desicions in a tie vote

Mechanical Team: responsible for all the goodies of the robot

Electrical Team: responsible for all electrical components and programming of robot

Drive Team: drivers and human players, must spend hours and hours practicing and training

Chairmans Award Team: responsible for chairmans award stuff and for organizing PR, often asks for assistance of students from other groups

This setup, with each team having an Offical adult leader and an unofficial studnet leader works almost flawlessly

[Ken Patton]

Foley-

Jeff is right, there is such a thing as too much organization. My opinion is that you should build the organization around the goals that your team has set - don't build the organization before setting the goals.

If people are getting hung up on their job title it can sometimes be a problem - maybe "responsibility" is a better way to think of it than "title."

One idea that I think is very important is to CLEARLY define what responsibilities people have, and DON'T make two people jointly responsible for something. If one person is responsible, they don't need to have a meeting/discussion/argument to make a decision (unless, of course, they are schizophrenic, but thats an entirely different problem ).

hth,
Ken

[Dave_222]

Not much organization here we have a president (Bad Brad) a vice pres (me) and secretary/treasurer (non CD poster) and students just kinda do what ever they feel comfortable with. I am pit crew and mechanical but only because that is what i felt like doing one day and got hooked on it. we donut actually have a structure but once the students get into their groove they kind of stay there.

[Ryan Dognaux]

Originally posted by Gope
The Baxter BombSquad's system is about as perfect as it gets, as far as I'm concerned

Where's the animation section?

[piotrm]

i dont really have any hierarchy suggestions as i do not concern myself with such things but here is a link to see team 190's "hierarchy" : http://users.wpi.edu/~first/dyn.cgi?node=org you can click on each of the positions there to see a description of what they do; note that a lot of the positions that are there are invisible since they have some correletion to specific robot features which we thought might be "sensetive information"

good luck

[tatsak42]

We had two main leaders... and then drive leader, electrical leader, animation leader, chairman's leader... what else... yeah, a leader for every subgroup, but we had a probelm of it all not being coordinated, until very late. So we're reorganizing our team

[Rob Colatutto]

This year what we had done was, elect 3 equal team leaders who had experiance of at least one year (ended up being myself, Frank, and Dan) and basically let them decide who would head what. We also elected a secretary (well, I don't remember there ever being more than 1 person wanting the job). Then the 4 of us were the 'executive counsil' which was overseed by the 2 adult leaders to make sure we didn't become too much of a dictatorship.
Team leaders just always end up being the drive team because we pick them by:
1. work done this season/last season
2. experiance driving
3. do they know the game inside and out
4. can they cooperate with the rest of the team
In previous years we had also done individual group leaders such as, mechanical, electrical, design, autocad, animation, programming, and secretarial... But as has been said, thats a little too much organization on a small team like the one I was on. For a small team, 10-20 people, 1 president and then 2 vice presidents, one for mechanical and one for electrical/programming, and then a secretary that also oversees PR and funding should be more than enough.

[Beth Sweet]

In our team, we have a team leader, who basically stands up at meetings and tells us what needs to get done. After that, we break off into our subgroups. Subgroups during the build season are the Engineering team-builds robot, the Chairmans team-chairmans submission and tv program, and the Animation team-does the animation. During the competition season, the subgroups mix members up a bit more, and we have the Drive Team-drives the robot, the Pit Crew-fixes the robot, the Scouting team-scouts other teams w/ these wonderful scouting sheets (thanks Ursula) and the PR team-button collectors and miscellaneous other promo stuff. For a small team, i would say that the best idea would to get one mentor who is in charge but doesnt think that he/she is the only one w/ right ideas (aka, open to all ideas and suggestions, more of a peer but w/ slightly more say) and then divide off into the smaller groups. Make sure that u have enough ppl to take care of the robot, and from there, go into the other groups. A drive team is also an essential.

[Kristina]

http://www.chiefdelphi.com/forums/sh...t=manageme nt

Whew...that took a while to dig out of the archives but I knew I answered this question before. More answers there, including how team 691 is structured. Hope it helps.

Ah yes, if anyone needs help on the management side, don't hesitate to IM or PM me. It's easier to do it individually depending on your situations. Between setting up the structure on 691, 4 years of student gov, and essentially majoring in this (political science and more so in public policy) this is my little contribution of how I can help since I'm scientifically inept.

::edit:: fixed above link and found these in the correction process...

Good thread on different teams subcommittees

Lots of management advice, including my take on committees

[sanddrag]

Kristy,
Link doesn't work.

[Madison]

Now, keep in mind that this isn't something that's ever been put into real practice, but it's a system of organization and training that I tried to develop for some of the teams I've worked with.

The impetus was the need to expedite the process of design and construction by working hard during the pre-season. It means training new and old team members in a variety of disciplines ahead of time so that they can be relied upon during the intense build period to take on real responsibility for the project. It also has a system of accountability built in so that people are expected to do what they say they'll do.

In short, it's as egalitarian system as I can imagine. There is a small handful of elected officials that are the point-people for the team. They handle things like tracking attendance, performance, and skills-based training seminars. Additionally, they would call upon other team members, mentors and teachers with other skills-based ability to be trainers. Outside of those individuals, this system eliminates sub-groups and sub-team leaders. There is no longer a need for an electrical group or a mechanical group or a public relations group.

In short, the pre-season -- from August/September through Thanksgiving -- is the training period. During that time, the team will run a series of seminars and lectures about varied subjects pertinent to FIRST teams. This might include PBasic Programming Skills, Inventor Workflow, Drawing Annotation, Design Philosophy, Sponsor Relations, etc. Additionally, there would be classes in Tool Safety and FIRST Philosophy, and these classes would be required for maintaining membership on the team.

At the start of the pre-season, each potential team member is issued a Team ID. This could be something they can keep as a souvenir of their involvement and should be nice. It might have the team name and logo, and the student's name and photo. Along the bottom of the card would be a series of small boxes, each labeled with a two letter abbreviation. For example, again, there'd be "PR" for Public Relations or "IN" for Inventor Workflow.

Students would be required to attend the two mandatory classes, and then they'd be asked to sign up for a minimum of three other programs during the pre-season. After successfully completing those programs and passing a perfomance evaluation, the students' cards would be punched for the appropriate skills.

I know that I've sometimes been overwhelmed by trying to remember the talents and abilities of 70 or 80 kids. This system should make it easier to quickly identify who's capable of completing a certain task.

During each day of the build season, the team leaders would be charged with developing a schedule of what needs to be accomplished during that day and over the following days. This might include a brief description of the projects at hand, the skills required for each, and the allotted time frame for their completion.

As the remaining students come in to the meeting each day, they'll be able to look over the daily tasks and see what is expected to be done and what needs to be accomplished. Then, they'd simply take their ID and insert it into a pocket for the project they'll be working on.

I think that this provides a simple way of making sure that students are capable of competing the projects we assign them to, and it also holds them accountable for doing the things they say they'll do. At the end of the day, or upon their departure, each student checks out and brings a team leader up to date on what they accomplished.

This should also prevent more students than are necessary working on certain projects and neglecting others. Again, from personal experience, students tend to want to be involved in the biggest project there is and they don't ever realize how important the little things can be.

I'm sure this system can be improved and streamlined considerably, and, as I said, it's just an idea. It's never been practiced, so I can't really say how well it works or what effects it has on team productivity.

[Jeff Waegelin]

It's an interesting idea, M. It might be a little too much for a small team, but I could see how a larger team could benefit from things like your punch-card system. My only concern is, is it too much organization, yet too little at the same time? It seems like there's a lot of stuff to keep track of, yet without a defined structure. It could very well be a better system, though. Until somebody puts int into practice, that remains to be seen. I have my doubts, but I'd be willing to give it a try. At the very least, it's a fresh, new approach.

[Madison]

Originally posted by Jeff Waegelin
It's an interesting idea, M. It might be a little too much for a small team, but I could see how a larger team could benefit from things like your punch-card system. My only concern is, is it too much organization, yet too little at the same time? It seems like there's a lot of stuff to keep track of, yet without a defined structure. It could very well be a better system, though. Until somebody puts int into practice, that remains to be seen. I have my doubts, but I'd be willing to give it a try. At the very least, it's a fresh, new approach.

For someone with better organizational skills than me, it might be redundant and unnecessary. I know from my experiences that I tend to take on more work and responsibility for the team and its robot than I probably should, and I think the people I've worked with would agree. This would help me and people like me to back off a bit and turn things over to the students more while still ensuring that they were gaining knowledge of meaningful skills that they can use in college and at work.

It was an idea for a way I could delegate work to people other than me when I couldn't just say, "You, do this." It also helps that the students are deciding on their own what level of work they're comfortable with. There's no need to worry about saddling a student with more work than they can handle or are comfortable with, and it means that I won't get upset with them if they don't complete the assignments that I give them.

The responsibility for getting things done lies squarely on their shoulders instead of their teachers and mentors.

It's really a whole new of doing things for me. After a season of being responsible for the entire design of every aspect of a robot, with very few checks on me, I got back to thinking about what benefits this could have.

Of course, if you have a team of unmotivated students who aren't willing to own up to their responsibilities, this entire system could also be a spectacular disaster.