Leading a team is no easy feat, especially a robotics team.

Usually there’s not just one lead,

which really helps out to manage everything. Over the course of leading my team, I’ve learned a
few things that make a good team. A good team includes:

- Enthusiastic and Dedicated Leads, should be there most at almost all meetings. Does
not necessarily need to be a greater talker or even all that extraverted, but should be
able to explain themselves. Leads should have enough depth about their chosen
“subject” to cohesively integrate those working with them into the team.
- Member cohesion: little arguing between members. Most teams will argue at some point,
so be ready.
- Every member is considered: for example, the work schedule is designed in such a way
that everyone has the ability to attend. That being said if a member is not able to come
to most meetings, you may want to talk with them about their commitments and if they
have the time to do ftc (solely responding to the example) One of the hardest things is to
tell someone they need to start showing up more, so talk to your teams at the first
meeting so they know this is a possibility.
- Good communication: everyone has to know what’s going on. Oftentimes last year I
would come in and the robot would be in shambles. I didn’t know what to do and ended
up wasting time. Having a service like slack or discord really helps with this.
Communication is part of writing a great notebook anyways. Always make sure people
are on the same page regarding things that have been done, are being done, and need
to be done.
- Understanding of the other members work: for a team to build the best robot they can,
the software members have to have a good understanding of the hardware and vice
versa. As my aerospace teacher once said, “A good engineer has an understanding of
the capabilities of the software” This understanding should evolve, as leads (and
everyone on the team if possible) should try to stay up to date on everything the team is
doing.
- In the case of a team having sister teams, try to minimize inter-team conflict. I’ll be the
first to admit we’ve failed at this at my school.
- Blameless culture: If something goes wrong, time shouldn’t be wasted trying to find who
caused it and blaming people. Instead, the team should work together to resolve the
issue. But make sure to document the issue to avoid repetition
- Member involvement: It’s easy to solve all the issues yourself. Whether it be CAD,
fabrication, or software, more experienced members and especially leaders will do tasks
more efficiently than newer members. The problem with this, however, is that it’s very
unsustainable. If your team is interested in being around for more than one year, you
need to teach your newer members the skills they need to succeed when you graduate,
which means involving them in tasks.

On the other hand, there are also pitfalls teams need to avoid. Many of these are the direct
opposite of the tips on the previous section:
- Bad communication: Last year when I was a rookie, there was no work schedule or good
communication between members. I never knew what was going on, and couldn’t really
contribute anything until communication improved. This can also lead to different
members working towards different goals, leading to conflict. Set work times at the
same time every week really helps with this issue.
- Lack of cooperation: the “divide and conquer” approach to hardware oftentimes doesn’t
work without really good communication. Parts end up conflicting and a redesign is often
necessary. Prototyping is good, but don’t plan to take a prototype and stick onto the
robot. Do some CAD in between if you have time.
- High amounts of conflict: this can be a power struggle, drama, or another source of
conflict. Conflict is extremely unhealthy for a team.
- Members not considered: Sometimes leads will neglect newer members and not teach
them what they need to learn to be successful. This can lead to a once great team falling
to become what is basically a rookie team the next year. This means people need to talk
about what they know and have time to teach.
- A “software will make it work” mentality. I’ve seen too much of this before, when a
hardware member makes a subpar design and instead of improving upon it, just claims
that software will make it work. Oftentimes this does not work.
- A hardware-software disconnect. This is when the hardware team and software team
don’t have an understanding of the capabilities of the other, leading to both requesting
impossible tasks, and when a problem occurs, both hardware and software will blame
each other for the problem, which distracts from actually troubleshooting and fixing the
problem at hand, whether it be a hardware or software problem. A good solution to this
is to make sure you give software time to do things, and more so on new teams or when
attempting something new. Also remember that it is well documented that people
underestimate how long things will take, just a flaw in almost all humans.

Also the notebook, whatever level of work gets put into it, needs to cover all aspects of
the team, and should be told of major decisions so they can document it.
- Bad Organization/Documentation; Some teams do a poor job of documenting and
recording what happens in a meeting. It is important to record any decisions or major
events that happened during a meeting. That way if a team member is unable to make it
to a meeting they can refer back to that documentation to get up to speed with what
happened.
- Time management: Yes, the FTC season is long. It seems like one has so much time to
make the robot and perfect it. You have less time than you think. The “quick change in
design” might take longer than you expect, and you definitely will run into problems
along the way. As a leader, it’s important to maintain a solid pace. On 18513, we took it
slow, meeting only once or twice a week early season because we overestimated how
much time we truly had. Now, with competitions coming up in a couple weeks, we are
meeting every single day in a rush to get ready for upcoming competitions. If we had met
more early season and made an effort to make more progress, we would be in a better
place.
All of these issues can lead to progress coming to a grinding halt, and lead to a stagnation of
everything. Try to avoid these as much as you can.

Main Author:
Sebastian Ochoa - FTC 9527 Captain

Contributors:
David Marcon - FTC 8680
Arjun Oberoi - FTC 9794
Siddhant Mody
Cameron DeMille
Caleb Nomi - FTC 18513 Captain

Notes: please add yourself as a contributor if you make a meaningful edit.