Our club has been growing for the past few years, and we’ve seen a lot of good members join our ranks. Unfortunately, we also seem to find that there are people who “join” the club but don’t want to do the work required for each member. We’re looking for a formal way of tracking what everyone does in case we need to launch a “formal investigation” (as our team likes to call it). We’ve juggled the ideas of having individual logbooks or of possibly having a group log book. Anyone have any other possible ideas?
We will generally speaking have the mentors keep an eye on who is puting a good effort in and who is slacking off. If they feel it’s becoming and issue, they inform our coach and he will generally speaking sit down with the kid and let him know he needs to pick up the pace/do a little more work. Usually that’s all it takes and the student is fine after that. If the student continues to be an issue, the coach will decide how to handle it on a case by case basis.
Be careful being overly-specific when deciding on things like this. As your team gets bigger, you’ll find you have more space for people who like doing job “A”, but don’t necessarily want to do B, C, and D.
Looking at it another way, different people commit to different levels of work. Ask yourself it you really want to be exclusionary because everyone doesn’t live up to a certain ideal. You can even make different levels of team membership. Those who do X amount can travel, those who do Y amount can continue participating but can’t travel, etc.
We’ve found numerous reasons why particular individuals may not be able to work at the level of our top or even intermediate level team members. Perhaps they have problems at home, or don’t have time because of outside pressures, etc. Always try to be understanding. For some folks, robotics can be one of the few ‘bright’ points in their lives. Even though they don’t appear to be 100% committed to the team.
Our team employes a Star Chart to keep our students on task.
I don’t know how I feel about this idea. I was one of the kids that just “joined” the team (talking about my experience on 2502) because my best friend was on the team. I didn’t really do anything my first year, but I had a good time. Then I got really hooked on STEM watching 1114 at worlds, and that completely changed my mind on what I wanted to do with my life. I guess my point here is that FRC is about inspiration, not about actually bulding the robot, the robot is just a tool for inspiration. By having a team that shames kids that might just need to get their feet wet before they get hooked is counter productive to FIRST’s mission in my opinion.
So, what’s the end goal here? What are you trying to accomplish by tracking what people do? That will help guide you towards an appropriate level of tracking.
For example, if you want to know who to recognize for different things (either internally at a team banquet or externally in a school yearbook or announcements) then you’ll need much more detailed notes. On the other hand, if you just want attendance hours to determine who travels or letters, you need a lot less detail.
I find detailed work logs to be a little over the top, personally. Different people are going to want to work on different parts of the team - how do you measure work CADing part of the robot against work building it, against work programming it, against work on Chairman’s?
My team does track attendance numbers, on the assumption that if you show up then you’re working (which is mostly true, if your team leadership makes sure it is). Those attendance numbers then go into travel and lettering requirements.
Part of our lettering requirements is for each student to take charge of some sort of project with the team. We don’t really care what it is, so long as it matches their experience level with the team - a senior that’s been on the team for 4 years is going to do something a little more in depth than a freshman. They have to come up with some documentation along the way (project proposal, timeline, checkpoints, and a summary about what they learned) as well. The point here isn’t a detailed work log for every student, it’s to expose them to project management concepts and make them think about how impacts to schedule and scope affect the project - important engineering concepts. And in the end, we want them leaving the team with a portfolio of what they accomplished that they can take to college interviews to proudly display and talk about.
Our team expectations are every member attends 80% of scheduled meeting hours. The calendar/meeting schedule is published a year in advance, and any meetings that are added after the first of September are extra credit hours. Tournaments and travel hours are recorded, but don’t count for or against minimum participation expectations.
Aside from that requirement (which only one student in three years has failed to meet), team culture and attitude towards hard work takes care of the rest. We stress that we aren’t one team of 20 people each contributing 5%, but one team of 20 people each working at their personal best towards a common vision of excellence. There’s a collection of related pep talks that keep us more or less on the right path.
It’s not shaming anybody for a lack of skills, but more a general expectation that everybody do what they are able. There’s ample opportunity to take initiative to either learn something that will be helpful later, or do something that’s helpful now.
To get to the bottom of what’s happening, I think you need to find out why some of your students aren’t doing the work. It’s normal to have a few new people who end up leaving the team because it wasn’t right for them. But it’s a different story for those students who show up and socialize, watch other people, and otherwise don’t participate. That’s usually a sign of poor engagement. It’s a very common problem. There are a lot of reasons it could be happening.
- Students might not be able see opportunity for getting involved at the (lack of) skill level they’re at.
- Students might find the way skills are taught to be incompatible with the way they learn.
- Students aren’t invited to engage in something that they find interesting. (ex: “Bob does all of our programming so you probably won’t do that.”)
- Students might be worried about embarrassing themselves if they suck at doing something new-to-them.
- Students are often still learning how to balance their time commitments so they miss meetings or drop tasks.
- Some students have personal problems that distract them from focusing.
Here are some other questions you might want to look at:
- Does your team have a core group of go-to students that are experts? If so, do these students spend most of their time mentoring new students or do your student experts mostly spend their time getting the legwork done on projects?
- Does your team clearly and precisely communicate their expectations regarding what students should accomplish and in what timeframe?
- Does your team plan its activities as projects with milestones?
- Does your team have a process for monitoring project status?
Watching progress too closely is counterproductive too. Nobody likes to be micromanaged. Accountability is good but not when it’s used to blame or pass judgement. If your team isn’t satisfied with a student’s work, someone on the team needs to get to the bottom of it. It’s much more informal than an investigation. More like a having a private conversation of concern with that student. (“Hey, you don’t seem too interested in doing XYZ. What’s going on?”) The team of course has the right to give the student the choice of working or leaving, whether for the day or permanently. But it’s the team’s job to help that student find a good fit before it comes to that.
It’s also nice if you can find ways to recognize students that go above and beyond. The trick there is to find ways that reward more than time-in or being connected to a resource (ex: getting the team access to money/goods/services/opportunities through family or family-friends). Look for creativity and meaningful efforts. A little recognition can go a long way.
Our team actually just developed our own way to track member contribution. First things first, you want to track attendance. For our team, this is the biggest thing. We’re pretty small, and therefore pretty lax, but we allow 5 unexcused absences and 5 excused absences yearly. If you exceed that, an investigation gets launched. Typically, that will end in being removed from the trip, but it allows the student to explain themselves.
So far, this has worked pretty well for our team, but we’re also putting team leaders in charge of more intense monitoring. This is so we can enforce our “present means involved” policy, i.e. you can be counted absent if you are here, but not working or contributing. We’ll be keeping track of everything through a google spreadsheet/doc, and basically tally up absences. Like I said, there are other teams that feel the need to go way more in-depth due to size and intensity, but we’re content with our little system.
I’m not trying to say you shouldn’t work on solutions to tracking student hours and whatnot, or that you shouldn’t deal with problem kids who are being distracting and not trying, but something feels off about your post. You need to consider the value of the team, to the student, as much or more than the value of the student on the team. Robotics teams aren’t just supposed to be places for high performing, already-motivated students who instantly get robotics principles to shine. Teams are supposed to try and inspire everyone, especially those who hadn’t really considered science and technology beforehand. It’s really important that your system doesn’t leave these people behind, who may be intimidated by their lack of knowledge or still trying to figure out their specialty on the team. Just keep them in mind when you’re working on this - the team is more for them than it is for the kids who were already going to be STEM majors.
Our team has a very lax approach to this. Our general rule is to say when you are coming, and come when you say you are coming. It works well for most of the season, but we ran into a few problems during deciding who gets to skip two days of school for NE DCMP. Given that our team is small, we were able to do this case-by-case, which worked well. For a larger team, not recommended though.
Pretty well this for my team, to figure out whos doing what juat ask around the individual sections no need to really beurocrat it up in my opinion. The captain for each section should have the knowledge of whos good on their section and whos not. Have a meetup of all the captains and just run through the names of each member on the team. You’ll easilly figure out whos doing what where.
Some members of my team spent part of the summer designing a solution to this exact problem. In order to streamline team member accountability and job delegation we developed a team member front-end and a team leader front-end where team leaders put in jobs they need done and they either specify a member to whom the job should be delegated, or they let the system delegate it for them. We made it with an SQL database (to log jobs and team members’ “accounts”) with PHP forms connected to the team website. At the end of the job, both the team member and team leader rate the job based on how much they like it and how well it was done (respectively) and the system learns which categories of jobs are preferred by which people.
This not only allows us to ensure everyone who is present is doing something relevant to the team that also needs to be done, but it is working towards our goal of everyone doing the job they most want to do and it promotes accountability where we can log (based on start and completion times) exactly what kind of effort each team member is putting in. We haven’t used it during the season yet, but beta tests seem promising. If it works well we’ll open-source the code.
We decided to code our own that is custom-tailored to our team’s needs, but there are existing “job management systems” that you can google for that will also probably help if you are interested in managing your team members that way.
Also search for issue tracking systems (Jira is a popular professional one, but there are other open source ones)
It took me a while to find it - from the home page, navigate to “About” and “Travel Requirements”.
We have similar requirements to qualify as an officer (leader) or as a varsity team member (travels to remote competitions and local competitions on school days). We usually have one student and one mentor who keep a centralized log of hours worked, funds raised, etc; I believe they use a spreadsheet on our Google drive. Numbers from the logs are often referred to when it comes time for our end-of-season awards in May.
As to why we track, we have far more students at the school casually interested in being on the robotics team than we have resources (shop and meeting space and mentors are more strained than $$). Early in the season (first two weeks of October this year) we have “tryouts”, which expose prospective members to the various tasks involved in the team, present them a challenge, and meets about 2/3 as densely as during build season. So far, we have had more students “drop out” during tryouts than we have had to “select out” after tryouts. We track service hours separately from build/writing hours, but do not break down work hours any farther.
We just made the switch from paper log to a quickbooks online timesheet.
This lets us create reports on a weekly/monthly/quarterly basis.
Each team member has to log hours they want credit for in an online timesheet. They can do extra or make up hours lost because of things like Cross Country or Marching Band. But they have work on approved projects if it is outside of a normal meeting.
Along with seeing how many hours each member logs we can also see the details of what they worked on.
We as mentors are liking this approach because when the team member enter the real world they will have to log timesheets and document what they spent their time on.
If they forget to log it… they do not get credit for it.