![]() |
Incorporating Less Frequently Available Team Members
One issue that most teams must presumably grapple with is that of team members who only show up for a couple of hours a week during build season- those who aren't present often enough to be given a major project, and who won't necessarily know what needs working on when they are in attendance, but who are still valued members of the team, and are sets of hands during crunch times.
What are strategies people have found helpful in involving team members who can't be there as often or for as long as other members of the team? |
Re: Incorporating Less Frequently Available Team Members
I would have them work on side projects that don't take long and are easy to understand. Such as the pit setup, drivers station, T-shirt design, ect.
|
Re: Incorporating Less Frequently Available Team Members
First, make sure to keep them in the loop. If they don't even have a general idea, it should be their own fault.
Second, when they are there, spend 5-10 minutes to bring them up to speed on what happened since the last time they were there before you get them working. Then give them something fairly quick to do--T-shirt design, button design, we need some minor X to do Y (say, a fan bracket), or something else of that nature. Shop cleaning does not count unless that's what they want to do or it really really needs doing, in which case it's clean X portion and then we'll see what else there is to do. Or, the other strategy--have them work remotely, if possible. CAD and programming are best for this, but Chairman's (and other essays) and PR can be done offsite as well. Just make sure that they get their work in on time and interfaced with everyone else's, say via a CVS server or similar substitute. |
Re: Incorporating Less Frequently Available Team Members
My mentality is that if they don't want to participate, its their loss. If they don't like the program they would show up everyday. You can't force anyone to like the program. If it is a legitimate excuse like sports or religious activities or something along those lines, go with Eric's advice. Honestly if they don't want to be there, just straight up tell them to not show up at all. I would believe that they are wasting their time going to the meetings. Time is precious; it should never be wasted. Being able to participate in such programs is a privilege not a right.
|
Re: Incorporating Less Frequently Available Team Members
Quote:
If it's a question of "I don't want to participate", then they probably wouldn't have bothered to show up at all. If they're showing up and not wanting to participate... Well, then you enforce the "don't show up" mentality a little if you have to. |
Re: Incorporating Less Frequently Available Team Members
Quote:
|
Re: Incorporating Less Frequently Available Team Members
Quote:
|
Re: Incorporating Less Frequently Available Team Members
Quote:
For Inspiration and Recognition of Science and Technology. FIRST is about Inspiration and Recognition. If a student does not want to be inspired, then yeah, their problem. But it's not just about STEM. Oh, no. --FRC teams are run like small businesses. I know at least one person majoring in business who spent several years on a team. --A number of former FIRST students have gone into teaching. --FRC students can also go into manufacturing very easily, if they've been working with a team that has that capability. That science and technology knowledge may not seem like it comes in handy for those, but the appreciation of them and the desire to allow those that don't know about how cool they are to find out doesn't go away easily. It's that spark of "I built that!" that can drive someone to do better in their chosen career, STEM or not. If a student does not want to participate, that's what they're missing out on. If a student is being disruptive in addition to not participating, they'd probably get the boot--but if they changed their behavior, they should be allowed to return. If a student does not want to participate, and does not show up at all, that's not really our concern. If a student does want to participate, but has schedule conflicts with other activities, then do not deny them the opportunity for that inspiration. Work with them and with as many of the other scheduling factors as you can (parents, sports coaches, etc.) to find a viable solution that allows them to participate. The initial situation, as described, was that of a student who wanted to participate but could not make it more than a little bit per week. |
Re: Incorporating Less Frequently Available Team Members
Quote:
|
Re: Incorporating Less Frequently Available Team Members
Now back to the original discussion.
I usually keep short/small jobs that I know my frequent members can do within 15 Minutes or less for the in-frequent members, and tend to give harder/longer jobs to the frequent/every day members. examples of a short/small job: -Bumper construction (1 bumper with parts already machined/Drilled) -Assemble wheels -Write up the weekly report for our website (If on Saturday) from our frequent documenters notes -Have them document, take notes, pictures etc. on the days that the in-frequent PR members are in -Design t-shirts/buttons -Assemble buttons -Gear box assembly if you use the regular AM toughboxes -Clean up if i have absolutely nothing else to give them -Assist the frequent members (All Jobs) -Have them work on VEX (Our FRC and VEX team are the same), or our practice bot -Assist me with field construction during the beginning of the build season I do not give them jobs such as: -Chassis construction/assembly -Chairmans award video / paper -Machining and welding (Only the frequent members are trained enough to use our mill, lathe, tig-welder etc.) -Website -Assemble the electrical system of the robot (1 wrong wire could be bad :yikes: ) These are only a few jobs I could think of off the top of my head. I give them he small jobs to keep them on the team, even though they are tied up with other projects, school or sports. Never send them home unless your rooms are filled or they are playing around, this could deter them from even coming at all. |
Re: Incorporating Less Frequently Available Team Members
On it being their loss:
I'm a firm believer that the people who show no interest in the engineering experience initially; the ones who are dragged to meetings by their friends, attracted by promises of free food at the first meetings, or just join on a whim, are those who have the potential to get the most out of the program. You can't force anybody into FIRST. But you can give them a gentle push. And sometimes, that gentle push can have powerful results. On the original topic: I come from a team where, for a number of reasons, intermittent attendance is a HUGE problem. One of the things I've found very helpful is to step up the team's use of Inventor or other CAD software a lot. "Core" members will likely be most involved in the CAD process itself, although others can also work remotely on it. But once it is finished, having printed drawings of most of the robot's parts makes it MUCH easier for people to "jump into" the process. It's much easier to hand someone a piece of paper with a dimensioned drawing on it and say "make this," than hold a conversation like this: You: Hey, you're not doing anything, could you make the arm bracket Them: The what? You: Oh yeah, you weren't here, the prototype broke so we decided we'll need a bracket for extra support. Them: how is it designed? You: well...... *5 minutes of failure to get the design fully conveyed by word* You: Never mind, I'll just do it. Also, if they can't attend design meetings, but still want to help, encourage them to come up with concepts, and run concepts by them, outside of meeting time. Members who can attend can then "represent" them. |
Re: Incorporating Less Frequently Available Team Members
There are 2 types of in-frequents that should be handled differently.
#1. Splitting time with other actitivities, but has a known schedule and is dependable. (Can give you 8 hrs. every Saturday, or can help out Mondays and Wednesdays...) #2. Undependable. Randomly shows up whenever. Type #1 can actually be a really great asset if used properly. many examples have been given above for just such assignments. Keep them involved with the bigger picture as well. The key is these folks get quality assignments that require less continuous support (bumpers, pit display,....) Type #2. You need to convert them to a type #1. Explain to them the importance of knowing when they will be there. On days when they just "show up" give them less desirable assignments. On days when they let you know more than 24 hours in advanced, give them better assignments. If your team is not able to use a predictable 50 man hours (an 8hrs on Saturday person) effectively, then you need to work on your leadership. If the person in question is a random, that is their fault, but your leadership team has the responsibility to let them know what is expected of them. |
Re: Incorporating Less Frequently Available Team Members
There is nothing that prevents you from assigning them to help other team members who are more active. Working with others is one of our goals. By doing so, you may inspire enough to get them to spend more time or take on bigger responsibilities next season.
|
Re: Incorporating Less Frequently Available Team Members
Progress charts work well in these areas. If there is a graphic display in the workshop that shows what has been done, what needs to be done, when it needs to be done, and who to talk to for details on each sub-project, it helps the members be more self-sufficient and raises overall accountability.
|
Re: Incorporating Less Frequently Available Team Members
Quote:
Whether via email blasts or team web page, if your team members can keep current even when they can't be 'in the shop', then they won't have to spend their precious shop time catching up. One could argue this is important enough to merit assigning some team members to be responsible for the maintenance of such information. |
| All times are GMT -5. The time now is 20:19. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi