After 11 years in at a huge corporation, I started mentoring a high school FIRST robotics team and learned more about engineering, teamwork, motivating people, and project management than I had in dozens of corporate trainings.
We had enough students to field two teams of ten students each in the FIRST Technology Challenge. The students named their robots “Syzygy” and “Glitch Machine.” The senior designer on team Syzygy was Tyler. Tyler’s team won the Director’s Award at the Washington State competition and goes on to Nationals in April. The other team, named Glitch Machine, also built a fine robot and competed well. Glitch took 7th place in Washington, then we drove over to Idaho and made it all the way to second place! The students who worked on Glitch were mostly sophomores and they will have 2 more years to build amazing bots!
Core lessons that I learned from the 12 weeks of FIRST Technology Challenge:
- If it’s fun, then you will win
- Let the engineers fail fast, so they will ultimately succeed
Fail fast: when a student suggests a design, even if your superior adult engineering intuition screams at you to just shut him down by saying “that won’t work, what other ideas do you have” you need to let them work through the idea. The corporate culture that I came from had a lot of meetings where people would shut down another persons’ ideas. We would call it triage, or troubleshooting, or brainstorming, but really only a few people ever got their ideas implemented, and I can’t say we built the best stuff we could have with the brilliant people we had in our team. Too many ideas were shut down in the brainstorming phase and too many bad ideas were approved, and never revisited even in the face of failure.
Everyone told Tyler that his design was too complicated. An Archimedes’ screw and a pitching wheel? The mentors warned Tyler that his design was too complex for a 12 week build! It will have too many bugs to win! So he used the Fail Fast method that Team Xbot has promoted for many successful seasons.
The mentors ask open-ended questions, while trying very hard to hold back a tone of skepticism in our voices. We ask the students to draw on the whiteboard, then we ask lots of questions about how the bot will handle different problems, friction, gear ratio, power, blocking by another bot, what materials will be used for that piece? Both the student who is being questions and the other students learn many things from the discussion. How to ask questions without a tone of judgement. We learn that there are many answers, and there isn’t just one right answer, like in the teacher’s edition of the math text-book.
Sometimes the kid will realize it won’t work, otherwise help them prototype so you can both see if it will work or fail. Some kids are not used to failure being a GOOD THING. Ruling out some designs helps us find a design that will work in this situation. Encourage failure! Some kids get really frustrated when they don’t get the right answer right away. Help them with the emotion that parts of their design were good, and let’s think about other ways to throw a ball with a robot. Engineering is solving new problems in new ways. If you were just building something according to instructions, that’s not engineering! That’s construction.
Tyler has been through this brainstorm & prototype process in pervious FIRST competitions, so he was ready to prototype and work out the details of his initial idea.
Tyler drew many sketches on the whiteboard. He was good at top view, front view, and perspective drawings. He went home and built his design out of paper and scotch tape! He came to the next meeting and had to hold up his design, because paper can’t stand up on its own, and showed how the screw would pull balls up to the top of the robot and shoot out the pitching wheel. The mentors still had a ton of questions. What materials would you use for the center part that spins? Would the center spin, or the ramp spin? Does the little 12V motor have the power to overcome that kind of friction?
By letting the engineer run with his idea until it fails, you both learn things, get inspiration for a better design, and he is less likely to harbor resentment. I can’t tell you how many times at Microsoft I heard a developer say “management wouldn’t let me implement my design and now their way isn’t working any better.” In this case Tyler’s design still didn’t show any concrete signs that it really would fail, so he ran with it while many mentors offered tips to simplify parts of the design. The Syzygy team went forward with the Archimedes screw idea.
Glitch on the other hand, did not have one student with an unwavering vision like Tyler. Tyler was 18. Most of the students on Glitch were 15 and had not taken a CAD course, had not taken physics, and had not learned to deal with the frustration of prototypes that fail. We would have to learn these things together. I was excited to help these eager students realize their engineering potential!
The students on the Glitch Machine team had many creative ideas. As we worked through the ideas rapidly, I facilitated the conversation by reminding students to keep their comments positive, or frame their criticisms in the form of a question. In other words, if a student criticised another student’s design by saying “that would tip over” I would remind them to ask a question instead “how will this design effect the weight and balance once it extends that far?” because sometimes the student had an answer, like the weight of the 12V battery is way more than the aluminum arm, so it won’t tip. Other times the question helped the designer refine their proposal and redraw the arm on the whiteboard.
I mentioned the 15 year olds on Glitch had not taken many of the fundamental classes that would help with robotics. It was often difficult to interpret the four lines and the circle they would draw on the board. Often I would hae to ask a lot of questions just to understand what they had drawn.
After a certain amount of whiteboard design, and writing the best ideas into our Engineering Notebook, we started prototyping. Will this design work? The Glitch Machine students loved prototyping with the metal Tetrix parts, and didn’t like prototyping with cardboard and tape. Why? I think the blank slate of a sheet of cardboard is intimidating. Unfortunately we can’t let the kids start cutting up sheets of 0.1″ aluminum or 0.93″ polycarbonate plastic before they’ve refined their design because the materials are too expensive.
Here are some topics I’d like to cover in future blog posts in more detail:
- People are willing to do a certain amount of un-fun necessary tasks, but that has to be balanced with fun, visible progress, and pleasant working relationships.
- The students are more productive when they get to work with people they like. Duh! I wish corporate workgroups paid attention to this fundamental fact of human nature.
- The students are more productive when there is an adult in the room, even if the adult isn’t.
- An internet connection will suck the productivity out of any situation. Thankfully none of the students had the security code for the wireless connection, and we could pull the bright orange network cable from the kids’ computers.
- Encourage every team member to learn to use the hand tools and power tools. Some people are intimidated by a giant bandsaw with a blade tht can cut 0.2″ aluminum. Some people are frustrated when they can’t drill a perfectly centered hole in a sheet of polycarbonate. Get scraps and practice.