Team Reorganization

[Eugene]

Hi Everyone!

The veteran members on our team decided to do some team reorganization. We came up with a constitution for ourselves (the people at the meeting) and general guidelines for rules which we will use to work with the rest of the team to write our rules. I have looked at most of the white papers dealing with team organization and what struck me was the fact that it seemed that those rules were written by few for many. We believe that in order for the rules to be effective everyone needs to have a say in making them. Most of the work was inspired by The Seven Habits of Highly Effective People- http://www.amazon.com/exec/obidos/AS...092673-9327364 I recommend it for everyone to read.


Here are the things we came up with. Feel free to use them. If you have any concerns or suggestions, please post them. Our team is going to meet soon and we would be very happy to use them.


Leadership Constitution

Our purpose is to improve and apply the knowledge of engineering as well as build strong interpersonal relationships.


１) We exercise self control
２) We do not reject ideas from the beginning
３) We never impose rules on members unless it relates to immediate safety
４) We consider everything in the problem
５) We keep everyone informed
６) If we are going to complain, we will present a solution.
７) We strive to realize the potential of all members
８) We consider all things before making promises
９) Everything that can be done before kickoff should be done before kickoff
１０) We work with people to make self contracts for jobs

Guidelines for Rules and Regulations
Design

• For an idea to be seriously considered it must be documented as accurately as possible by the person
o Must find some relevant prior art
o Detailed (to scale, with measurements)
• Before Production
o Absolute list of materials
o Make exact measurements
o Basic prototype for all ideas.
• Unless the idea is classified a post must be made on Chief Delphi prior to second meeting

Team Meetings
• Designated meetings
• Clear agenda
o List of people who need to be present
• Revision meetings every month
• Work with people to make self contracts for jobs.
• Every meeting was to have an agenda.
• Update meetings
• Do team outings
• All ideas must be written down
• Brainstorming meetings must be taped
• Announce meetings at the end of the day



Competitions
• Mandatory checklist for robot (Before actual competition we go through the process)

As we continue working on reorganizing our team, I will post new material.

Thanks everyone!

Eugene :)

[SarahB]

I really like most of those rules, especially the leadership constitution. I’m not quite sure about some of the rules in the design section, however. It seems like a lot of them would stifle creativity and make it much harder to implement unique and innovative solutions. I understand you don’t want to waste your time with ideas that haven’t been completely thought through, but perhaps you would be better off refining the ideas as a team and then using those rules in the end to determine which designs make it to the final vote. Otherwise, I love your ideas and I’m going to propose implementing some of them at our next team meeting.

[Eugene]

Sarah,

Thank you very much for your support. Despite the effort that we put into those guidelines for rules (We will not enforce those, but rather work with the team to insure that most of the aspects are covered.), they had not been tested. So I really appreciate the fact that you found them sound. (By the way, if you liked them you should really read the book I mentioned before.)

I understand you concern. This rule (“For an idea to be seriously considered it must be documented as accurately as possible by the person.”) is not for the brainstorming period. I still hope that the team will continue to communicate ideas freely. However, in order to put the idea into the next stage, the person who brought up the idea should write it up. I realize that not everyone has the same level of experience, which is why we included the “by the person” clause. If that person is not serious enough about the idea to put it into some tangible form why should we dedicate a meeting to it?

Lastly, there were a few other people who responded that their teams participated in making the rules. I would be really interested in reading those. Please tell me about any problems that you have encountered establishing, implementing and following them.

Thanks!

Eugene

[blueWarrior]

Hi,

My team is also completely reorganizing because last year was our first year and we didnt have too much time to worry about these things.

We changed our team name from RoboBlue Warriors to ArchAngel Robotics.

We too have our own little constitution, except we call it the ArchAngel Doctrine. Its basically a 15 page outline of every aspect of the teams changes. It lists everything from a new team hierarchy, fundraising campaigns, target awards, our mission, how meetings and build sessions will be run etc. At the end of the 2003 FIRST season our team met and compiled a list of everything we want changed and things that went wrong. This doctrine comprises a large chunk of the things we found went wrong.

While writing it I made sure and stressed the use of pragmatic theory and rationalism. Teams tend to get excited and add extra things that will actually slow, or in the worst case receed the teams development. Our doctrine is much more complex and rational then I had originally imagined.

Suggestion: the hardest part of reorganizing a team is putting the outlines in place and reinforcing them. In this doctrine we list exactly the steps and dates that these changes wwould occur. It starts at the beginning of the school year (in 13 days) when our team will have our first recruiting session. The students will have to submit a digital registration form and from that point we, the team leaders, can review, accept and decline anyones entrance into the team. This ensures we get the top students who we know will help the team succeed. Once the students are in place I plan to print off copies of our ArchAngl Doctrine.

I outlined and organized the doctrine so that particular aspects of development are kept within each team division. So under the media and marketing team division you would find the complete plan of our fundraising, jursey design etc. This allows students to know exactly what the team is targeting for. The students are given a copy and one is always stored in the robotics room at the school for reference. A copy is always available at team meetings for reference.

A major part of these changes is reinforced and kept track of by teachers and the use of an action register system.

Once we have our second meeting and the students know what is expected we begin growth and expansion of a team.

So basically not only have we listed the key components of our team but we have completely documented every aspect and plan for its growth and have applied ideas that will ensure it will succeed.

We have also referred to other important online references developed by teams and have summarized all their hints and tricks into one system.

Hope this helps and best of luck with your team next year.

[Eugene]

David,

Could you please post the unclassified parts of your ArchAngel Doctrine? This could really help my team as well as a bunch of other teams.

Nice website by the way : )

Eugene

[Matt Krass]

Originally posted by blueWarrior

It starts at the beginning of the school year (in 13 days) when our team will have our first recruiting session. The students will have to submit a digital registration form and from that point we, the team leaders, can review, accept and decline anyones entrance into the team. This ensures we get the top students who we know will help the team succeed.

Does anybody else think this is a bad idea? I don't like the idea of rejecting students before you see what they're really capable of (actually I dislike rejecting students altogether but that's a new post in itself), especially if you're rejecting them electronically. I know my team never would've accepted me as is, I was an idiot, no skills, but I learned and I made our auto code work. We had a very successful season also. You don't need the top students you need the dedicated ones. Two students with no clue but enough dedication to work on something is always better than one expert who doesn't care enough notto leaveit until the last day. You can't find out who's dedicated via forms or a two-minute meeting, the ones who are dedicated are the ones who'll stick around long enough to design, build and test it. Besides what's in a trophy, my season was worth it for me before build was over.

[miketwalker]

Originally posted by Matt Krass
Does anybody else think this is a bad idea? I don't like the idea of rejecting students before you see what they're really capable of (actually I dislike rejecting students altogether but that's a new post in itself), especially if you're rejecting them electronically. I know my team never would've accepted me as is, I was an idiot, no skills, but I learned and I made our auto code work. We had a very successful season also. You don't need the top students you need the dedicated ones. Two students with no clue but enough dedication to work on something is always better than one expert who doesn't care enough notto leaveit until the last day. You can't find out who's dedicated via forms or a two-minute meeting, the ones who are dedicated are the ones who'll stick around long enough to design, build and test it. Besides what's in a trophy, my season was worth it for me before build was over.

For the most part, I agree with Matt.... but at the same time (at least with our team) every year we run very tight with funding. We can't handle more than 25-30 students each year, or else we would have to charge much much more for students to go on trips. As for the meeting, we do that with everyone. We don't really ask what skills they have, as like prerequisites... but more along the lines of "Do you know what you want to learn, and what will you do to try to get there?" If a student is unsure, they'll talk about different areas... and see where that student could fit in. I know we had something like 37 people interested when I joined 2 years ago... but we could only support 25 that year... I know that they did the best job to make it fair, I know that we spent lots of time trying to figure out another way to be able to have them join the team. So with all my rambling... I'm basically saying that some teams have limits, and in that case unfortunatly some people will have to be left out, but what about next year? The student could always try again, or even participate during the build season and maybe be squeezed in, I think that's happened... so it partially depends on the student's dedication, and money issues unfortunatly.

[blueWarrior]

Well when I say reject the people are not notified with a nice letter saying sorry. We post a list of members accepted and those who we thought were not capable would be left out.

I believe this is the best way for my team because our team leaders already know who everyone is, we know the persons capability from last year.

Last year we had some slackers and we want to keep them OFF our team. It also helps to keep the team small. From experience I learned that smaller teams are more effective teams, while larger teams seem to fall all over each other because of their size.

Dont you agree?

[miketwalker]

Originally posted by blueWarrior
Dont you agree?

Ok, in that case, I personally would agree. If I were to be head of a team, in the case you're saying, I agree... unless the student approaches you saying "I'll try harder this year, give me one more chance" then I guess you are going about it the correct way. But if a student says "I will try" then at least you know they will because they've taken the first step and confronted you. As for new people wanting to join the team, you should try to give them a chance on the team too though.

[Matt Krass]

Rejecting is still rejecting. If the slack then you ignore them anddon't let them do anything. There are better ways to deal with slackers than to force every person to automatically know what they're doing. You lose a lot of the potential crop that way.

[PyroPhin]

i think matts point was that you shouldnt reject members outright.. our team nas about 50+ members the first meeting and by the time the trips come around, we have 14 at the most. the team kind of builds itself, the people who want to be there and have the dedication remain while the people who just want to go on a cheap trip leave. with an application system you will loose out on alot of good people simply because they dont live up to the standards that the team members reviewing the application have set.
and, if trips do come around and you have more members than you can afford to bring, just pick the ones that are essential to the teams success and tell the rest to try again next year. it sounds mean but now you have a bunch of people who have a good idea what FIRST is about, how to do stuff and will be an asset to your team in the coming years.

~Pyro

[SarahB]

I think this application system could either work really well or totally screw things up, depending on what is actually in the application. Those of you who are saying what a horrible idea this is are assuming that they’re going to ask only about what skills the students have and whatnot. You haven’t seen this application so you really can’t make that assumption. Maybe they just want to make sure the people they let on the team will have the time to commit to the team and aren’t just joining for a free trip or another extracurricular for their college applications.

[PyroPhin]

i agree, but i lean more towards screwing things up.. honestly, if people are just joining for a free trip or whatnot, you are gonna notice and when the time comes for trips, the mentors or whoever decides things can act accordigly.

personally, id feel that having to fill out an application to a robotics team is really impersonal, and kind of rude. there are many people i have worked with who were downright useless untill you gave them a chance

~Pyro

[SarahB]

Once again, you haven’t seen the application so you really can’t judge if its impersonal or not. You assume that its just basic questions like name, grade, and whatnot. It very well could include much more personal essay type questions about why they want to join the team and what interests them about robotics/engineering. These kinds of questions would not only help narrow down the field to a manageable number, but also help them to get to know their applicants better. You may think its not necessary to weed people out at the beginning based on your own experience, but this team’s situation is different so you really can’t judge. It seems to me like they are dealing with a fairly large applicant pool but very limited resources. They can’t conceivably go through training and practice and planning with such a group, especially when they expect that most of them will drop out or will do nothing and only stay on to get the free trip.

I’m not saying an application process is a great thing and every team should do it, I just don’t think you should attack them for their decision to use one when you know nothing about their team’s situation.

[ZACH P.]

Originally posted by PyroPhin
i agree, but i lean more towards screwing things up.. honestly, if people are just joining for a free trip or whatnot, you are gonna notice and when the time comes for trips, the mentors or whoever decides things can act accordigly.

personally, id feel that having to fill out an application to a robotics team is really impersonal, and kind of rude. there are many people i have worked with who were downright useless untill you gave them a chance

~Pyro

Actually I agree with the point you are raising about a form being impersonal. But I also believe that "screening" the applicants is necessary, and doing so with an interview is the best way to go about it.