We don't teach students they can.
We let them prove it.

Students don't learn engineering from being told things. They learn it by doing real engineering work alongside people who are also doing real engineering work, and discovering, in the doing, that they are capable of more than they thought.

That distinction matters. We are not a team where mentors stand back and let students figure it out alone, and we are not a team where mentors do the hard parts and students assemble what was handed to them. The student leads the subsystem. They do the work and they direct the help — sometimes that help is other students on their subteam, sometimes it's a mentor or coach acting as a resource the student pulls in when they need a second pair of hands or a sanity check. The shop on a Saturday looks more like an engineering team than like a classroom.

Every decision we make about how 6328 runs — mentor structure, build cadence, what we open-source, why we keep prototypes around — flows from that single belief. It is also not just a belief. It tracks closely with one of the most-cited findings in educational psychology: Albert Bandura's theory of self-efficacy, published in 1977 and supported by fifty years of subsequent research.

Bandura's thesis is simple and empirically robust: what determines whether someone tries, how hard they try, and whether they persist when it gets hard is not their skill — it is their belief that they are capable of doing the thing. Skills and incentives matter, but a student who doesn't believe she can solve a problem will not engage with it long enough to solve it.

He calls this belief self-efficacy. As he puts it:

“Expectations of personal efficacy determine whether coping behavior will be initiated, how much effort will be expended, and how long it will be sustained in the face of obstacles and aversive experiences.”

And critically, he identifies four ways that self-efficacy is built — ranked by how durable the resulting belief is:

1. Performance accomplishments — actually doing the thing successfully. The most powerful source by a wide margin.
2. Vicarious experience — watching people like you succeed at it. Especially powerful when those people had to work for it, not when they made it look effortless.
3. Verbal persuasion— being told you're capable. Real, but the weakest form because it doesn't come with evidence.
4. Emotional state — how you feel while attempting the task. Anxiety reads as evidence of inability; calm reads as evidence of competence.

Read the original paper: Self-efficacy: Toward a Unifying Theory of Behavioral Change (Bandura, 1977).

We build student efficacy by giving them work that matters and letting them lead it. Not assignments-as-rehearsal — actual subsystems on actual robots that compete in actual matches.

• An alpha bot drives within 48 hours of kickoff. Students operate a real, scoring robot in week one of build season. They are not waiting six weeks to feel like engineers.
• Iteration is normal, not a sign of failure.Our 2025 coral funnel reached version 10 before we were satisfied. Each version answered a question. A first prototype that worked perfectly would have meant we weren't pushing hard enough.
• Quantitative testing turns work into evidence. We fire 25 shots per shooter configuration from a fixed distance against a fixed grid. Students see their own data tell them what improved — they don't take anyone's word for it.
• Students lead their subsystems.A student designs the elevator, drives the CAD, decides the gear ratio, owns the integration. They also lead the help they get on it — recruiting other students, asking a mentor for a second pair of hands, pulling in a coach when they need to pressure-test a decision. The subsystem is the student's. When it works at competition, the student knows they led it. When it doesn't, they own the debug. That sense of authorship is what efficacy is built on.

Bandura is explicit about why this matters more than any other input:

“Successes are more likely to enhance self-efficacy if performances are perceived as resulting from skill than from fortuitous or special external aids. […] Mastery of challenging tasks conveys salient evidence of enhanced competence.”

A robot that scores at competition because the student designed it is the strongest possible message that the student is capable of engineering. There is no substitute.

The second-most powerful efficacy source is watching people like you succeed at the thing you're trying to do. Bandura is also specific about which models work best:

“Diversified modeling, in which the activities observers regard as hazardous are repeatedly shown to be safe by a variety of models, is superior to exposure to the same performances by a single model.”

Two things follow. First, our mentors are visible engineers on the shop floor, not detached supervisors. Bandura is specific that models who visibly work hard for their success build more efficacy than models who make it look effortless — and our mentors are actively prototyping, debugging, throwing out v1 and starting v2, same as the students. The students aren't watching engineers on a poster. They're watching the engineer next to them wrestle with the same kind of problem they're wrestling with, and sometimes ask the student for input on it.

Second, this is why we publish everything we make.

• Open-source code, CAD, and tooling. Our robot code, AdvantageKit, AdvantageScope, our Onshape models — all publicly available, all year. Other teams use them. Our students see other teams use them. A fifteen-year-old freshman watches her code show up on a robot in another country.
• Detailed build threads on Chief Delphi. Every prototype, every dead end, every successful iteration documented in real time. Students see the shape of the work — including the parts where things went wrong — not a polished retrospective.
• Wiki content drawn from many teams.We don't just document our own approach. Our mechanical wiki cites examples from teams 254, 1678, 1690, 2056, 2910, 3005, 3847, 6800 — and many more. Students see the same problem solved many different ways.
• “Steal from the best, invent the rest.” The phrase belongs to Mike Corsetto at 1678 and we've adopted it. Copying a proven mechanism is not a failure of imagination — it's the rational starting point. Innovation is what you do when there's no proven option to start from.

There is a common worry that publishing everything gives away competitive advantage. The opposite is true: making our work visible raises the ceiling for our own students, because they see their work used and respected by people outside our shop. That social proof is one of the strongest efficacy signals available to a teenager.

Telling a student “you can do this” is real information, but it's the weakest of the four sources because it carries no evidence. Bandura:

“Efficacy expectations induced in this manner are also likely to be weaker than those arising from one's own accomplishments because they do not provide an authentic experiential base for them. In the face of distressing threats and a long history of failure in coping with them, whatever mastery expectations are induced by suggestion can be readily extinguished by disconfirming experiences.”

So 6328 mentors don't lead with reassurance. We lead with structure and shared work that lets students discover capability for themselves. Encouragement happens — it would be heartless not to — but it works because it points at evidence, not because it substitutes for it. “You can do this” lands when the student has already done something similar; otherwise it's noise.

The corollary is about how mentors plug in.When a student is stuck, the response is rarely the answer and rarely a stand-back-and-wait either. It's usually a question, often paired with offering to take a piece of work the student directs us at — running a calculation alongside theirs, prototyping a different geometry on the bench, holding the part while they measure. The student stays the lead on their subsystem and the lead on the help they're receiving. We are a resource they can pull in. A mentor who answers “what RPM should the shooter run at?” takes away the most important learning event of the season. A mentor who says “want me to run the math while you do the test fire?” gives it back, and adds a model the student can watch.

High anxiety reads, internally, as evidence of inability. A student who is afraid to fail will read their own pre-attempt nervousness as a sign they shouldn't try. So we deliberately build a culture in which failing is the expected outcome of a first attempt:

• Version 1 is a learning tool, not the final product. We expect to iterate. We say so out loud. A prototype that doesn't work is not a setback; it's the data the next version is built on.
• Don't get attached to a design.When testing says it doesn't work, the mature response is to extract the lesson and move on. Doubling down on a failing concept because you're emotionally invested is the most common way teams waste a build season.
• Document failures as thoroughly as successes. Knowing what doesn't work is just as valuable as knowing what does. A well-documented failure prevents the next student from rediscovering the same dead end.
• Keep old prototypes around.Don't scrap version 2 the moment version 3 starts. Sometimes version 2's frame plus version 4's rollers is the right answer — and you can only discover that if both still exist.

The ethos is abstract; the practice is specific. A few of the concrete commitments that follow from it:

• Strategy before CAD. Kickoff weekend is for understanding the game and producing a Needs / Wants / Nice-to-Haves list — not for sketching robots. Architecture follows strategy.
• Prototype the things you're least sure about, first.A new mechanism without a precedent gets a rough prototype before any competition CAD. We don't commit to architectures based on assumptions we haven't tested.
• Dev bot at high fidelity, not throwaway.We don't build alpha bots — we build dev bots powder-coated and treated as a first iteration of competition. The students get hardware quality close enough to the final to learn the real integration challenges.
• Keep it simple and reach for software first.If software can solve a problem, don't add a mechanism. Every mechanical system added is a thing that can break. This compounds with consistency: fewer parts, fewer failure modes, more reliable mastery experiences for students.
• Off-season investment. The teaching, the workshops, the wiki, this entire education hub — built and maintained off-season because the off-season is when the foundation is laid. Students spend the first weeks of build season actually building, not learning what a Kraken is.

Most of what 6328 has learned about FRC engineering used to live only in the heads of veteran students and mentors. When they graduated or moved on, the team rediscovered the same lessons each year. This site is the inversion of that — a deliberate, written corpus that future students start from, not catch up to.

Every wiki page, every lesson, every quiz here is part of the same project: making the floor of student capability higher every year. A freshman in 2030 should not have to relearn what we already know about flywheel mass tradeoffs or absolute steering encoder calibration. They should start there and build up.

Bandura's framework gives this work its theoretical grounding, but the simpler way to say it is: we believe our students are capable of remarkable things, and we run the team to make sure they discover that for themselves.