Hey CD,
Our dev team is currently made up of 2 programmers and they are getting burnt out. We have a lot of projects that need to get done but they are struggling to get them done with deadlines and team needs as they also lead subteams. This becomes a hinderance to our team’s productivity as we don’t have certain projects (e.g. scouting app) done by a certain time. How do your teams solve for burnout?
For background: We are a smaller team w/ 15 members.
It could be worth seeing what projects you really need. For instance a scouting app could be simpler paper data collection or a google spreadsheet, or you could try to partner with teams at your events. If you can take some of their other responsibilities away (such as subteam leads) then they will not be so stressed.
To add onto this, there are many open source scouting apps you can look at. You can take an open source one and then modify it to fit your needs.
Also, if the programmers aren’t really interested in a project and its just for the greater good of the team, maybe have them take a break on that project for some time.
100% let the programmers drop projects. A lot of the time you can get around fancy software offseason projects without sacrificing too much.
Correct answer. You need to define scope, because too much scope for available programming resources is just as damaging to your team’s season as the mechanical side deciding to go full-send on a custom swerve after Kickoff with no experience.
1293 has scouted on Google Sheets for years in collaboration with partners, can confirm it yields results for minimal inputs.
You’ve really gotta prioritize in situations like this (especially as a smaller team). While many projects are cool and would be useful, you have to pick the most important one (or two, if both are critical, but that’s rarely the case) and save the rest for later, when there’s more available time.
Also, like others have said above, lots of teams have open-source code available for all sorts of projects. Reinventing the wheel is a very unhelpful use of time.
Finally, imo the only super-ultra-critical projects in FRC would be robot code and possibly website stuff. Everything else is a lower priority for times when programmers are more free.
Something that might be beneficial to know:
Is the rest of the team aware these developers are getting burnt out? Are they actively taking steps to deal with this, or is it largely overlooked?
How many of your 15 team members are actually consistently and continually active? Your team may benefit from evaluating its capabilities and reducing the total scope of what it attempts to do.
Typically, around half the team members are really productive.
How many members typically attend the competitions? How many are in the pit crew and not on the drive team? How many people do you have left who actually want to do scouting? If you only have 6, the scouting team members will not be able to take breaks and they will burn out. Since your team is so small, your team should consider collaborating with other teams for scouting.
My team does essentially zero offseason projects except Introduction to Java and WPILib starting in October. I have an opinion of what robotics we might be sacrificing but it’s the students’ choice on what they are willing to sacrifice in their life.
Our programmers program the robot and that’s it. Scouting, web site, whatever are for others and that includes some mentor help if there aren’t enough students on one subteam to support the rest of the team’s norm.
And more specifically I agree with the others - negotiate with the team and programmers what the priorities are and how much the programmers think they can accomplish comfortably (it’s supposed to be fun).
You need to prioritize and work on what’s the most important for your team. Below is our off-season list for a team of 30 active students and 10-15 active mentors. We’re only working on the top 11 projects because we can identify a lead student, lead mechanical mentor and/or systems/programming mentor (depending on the project) with 1-3 additional supporting students. For a team with 2 software students and 15 total you probably shouldn’t be working on more than 3 projects simultaneously or the whole team will get burned out.
We’re a little smaller team and yep this what I figured we sacrifice by not working your offseason project list. Congratulations - you run a fine team.
Seriously though, what everyone else said above is probably right. Just have your programmers focus on getting really good at programming the robot. When your robot works really well and your success is blocked by other factors (like poor scouting data or lack of a neat-o pit display), re-allocate resources to that.
Thanks! I only contribute an idea or two here and there… But, my point for the OP is just lay out your list of work, prioritize it and do the stuff you can realistically resource.
I shared the list because I suspect much smaller teams are trying to as much or more --and its OK to have a stuff that just needs to wait until you can resource it. Doing a few things well is better than many things poorly.
Wasn’t it Finland that as a nation decided to work less and discovered that more was accomplished at work?
I’ll dare stray into motivation and make a pre-emptive strike against those on OP’s team who may try to motivate the programmers.
There is the Give It 110 and then all those 120. From 70% to 120%, Are you giving 120?, Give 120% everyday, Why you should give 120% at work, the list is endless.
I vehemently disagree with 120% Don’t go there! Don’t even try. OP’s programmers are already there. Get them back to 70%!
There’s only two ways to reduce burnout: Give the team less work to do, or put more folks on the team to help get the work done. If people are getting burned out, there’s no magic trick to make them feel better while keeping their workload, pressure, and resources the same.
The suggestion to drop lower-priority projects is a great one. You could also explore splitting out projects to more people - for example, if you have a scouting captain or enthusiastic scout, they might be interested in learning to make a scouting app even if they don’t want to “join the programming team”.
You also mentioned that both your programmers also lead subteams - was that a good decision? Have you explored whether they might want to pass those responsibilities off to someone else?
Finally - it’s only October. Is there any way you could recruit/convince more people to help out with programming? Maybe a rebrand is needed - on my last team, we had 3 people doing CAD and they would get completely burned out, but no one else wanted to “join the CAD team”. So we merged CAD with assembly to form one Mechanical Team, and made sure everyone in Mechanical learned enough CAD to help out with simple tasks like making spacers; and we taught our machinists how to make CAMs. We still didn’t have tons of kids who wanted to “join the CAD team”, but we had a lot more people who were able and willing to help out a little here and there to lighten the load. Maybe there’s a way to do something similar with programming.
Energy Drinks!
TL;DR Say no to projects, let mentors work on non-critical projects if you can, and evaluate if all of your projects are feasible right now.
From my experience in programming both as student and mentor on a smaller team (we have 8 total students this year, 12 last year, and 6 in 2020, programmers being mostly novices and seniors), I’ve found a few things that help. They’re more or less the same as others have said, but they’re worth repeating.
First, Absolutely drop projects if you can’t do them all. Your team needs to sit down and talk about what they want done. Obviously, anything pertaining to game-relevant robot code should probably be the highest priority, but beyond that, what do they want done the most? And “we want all of it” is not an acceptable answer (as much as they’ll try) - there needs to be a concrete priority list by the end of it. For example, if there is a reasonable alternative to one of your projects that already exists, don’t reinvent the wheel! Those projects should be low-priority.
Second, Offload work if you can. My view on FIRST is that the only thing that needs to be exclusively student-led is work on the actual competition robot. If students can do other projects more or less independently, fantastic! But mentors stepping in to take some of the work is perfectly reasonable. For example, I offered to my students last year before competition that if they could come up with an interface, even just a wireframe, I would happily build a scouting website for them. I did this because none of them had any experience with that kind of programming, and I couldn’t seriously expect that to be exclusively their project.
Third, (the extra point that is implied by the other two) A critical skill for programmers is self-awareness. It’s valuable to learn new things, but starting on an important project without any knowledge of how to do it is often doable, but tricky at best, and the quality will rarely be good (speaking from real-life work experience/regrets here). Have your programmers take a look at their own skills, and honestly evaluate themselves as to whether or not they’re capable of taking on the project right now (this analysis requires a certain vulnerability, which I recognize can be hard).
For your example of a scouting app again, probably the easiest way to do it is to build a small website that’s not much more than a simple interface for a DB backend, but is that something your programmers have done before? What about building an actual phone app (as inferred from the word “app” in OP)? Largely the same process, but more confined to a certain framework. Do they have experience with that? Do they want to rewrite it for every game? If not, do they have an idea of how they would make it dynamic for every year? If the answer to any of these questions is “no” or “not really”, then maybe that’s not a project that they should be taking on right now. There’s nothing wrong with not being able to do everything, and it’s important as a programmer to know where your strengths and weaknesses lie. In the meantime, they can learn new skills that they want, instead of what they need for the team. Don’t just let the mechanical teams (who tend to not have a well-calibrated gauge for software complexity), or the idea of “that sounds cool” drive your work load. An informed “This is not reasonable” is a valid response to a project pitch.
Finally, maybe recruit one of the mechanical students to learn programming. Some are quite good at it and interested, they’ve just never given it a fair shake, or they had a bad experience. with 15 students, it’s entirely reasonable to have 3 of them be programmers.
I actually looked at your profile to see if you’re on my team because we were in a very similar situation(2 programmers, small team, lots of burnout) last year, lol. I was one of the programmers.
First, you need to figure out what projects are actually necessary to work on, especially in-season. For example, I would put a scouting app lower on your priority list because you can scout just fine with Google Sheets as long as scouts know what they’re doing. Reducing the number of things on your team’s plate will help them feel less overwhelmed. During the season, they should only be working on robot code and other urgent tasks. Save other projects for off-season.
Second, reduce the effort that the projects take. Reach out to other teams and look at open source stuff online so that your programmers don’t have to do everything themselves. After all, programming is all about finding shortcuts. . .
Lastly, remind your programmers to take care of themselves and to take breaks. Their mental health is a top priority, and there’s no point in all this robotics stuff if you’re so burnt out that you’re not having any fun.
A longer term goal would be to learn how to recruit, train and retain more team members and mentors i.e. increase the team’s capacity to do work.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
