Like many others here, I work a day job in engineering and volunteer as a Coach.
One thing I have noticed often at my work and sometimes in robotics bothers me. It shows up in tense troubleshooting situations, especially ones where an individual’s identity is connected to the design in question. This is that a defensive attitude that opposes suggested solutions can hinder problem solving discussions. This phenomenon where suggestions are immediately shot down without a preferred resolution or alternative suggestion in its place is very detrimental to the problem solving process.
My question is for the many experienced coaches here on this forum. How do you establish and foster a culture in which this phenomenon can be eliminated?
Divorce identity from designs and decisions. This has to materialize in language at every level.
Keep focus on the positive.
“We should reinforce our intake” is waaay better than “James’ intake broke again, I have to fix it for him.”
Clearly identify a brainstorming period. Every idea is recorded, nothing is rejected. We call this ‘making room for the good ideas.’ Later these can be sorted into a priority list and gone through in a sane order.
To directly confront ‘that’s impossible’ claims ask: “what evidence would change your mind?” / “How would you prove it anyway?” Often this results in a good next step.
Folks who are not being productive are asked to leave. On 95 our handbook outlines behavior expectations in these cases, and people who do not adhere to them might go take a break. At my day job we have a mission statement to point to with the same results.
Remind everyone that the machine’s current behavior is completely explicable and it is incumbent upon the group to be open to any possibility that could explain or contribute to what has been observed.
A top-down view I have, and is mixed in with what @JamesCH95 wrote, is that there should be an established method for idea sharing and design selection. If someone goes through that process and this situation pops up, I’d facilitate a big team discussion where people “show their work”. Of course, being mindful to keep emotions in check.
As for a quote that may be useful…
Hamlet works with “There is nothing either good or bad, but thinking makes it so.” Meaning, perspective is everything. Put yourself in someone else’s position. Yadda yadda yadda.
But I prefer Shaq, “Don’t fake the funk on a nasty dunk.” Which I’ve always taken to mean “your work should speak for itself, leaving no room for question.”
This is a really important thing to teach students. We’ve had several times in the past where we abandoned designs that some students had worked on for a long time and it can lead to a lot of negative feelings. Reinforcing the sentiment that your work is not you is a great lesson to learn from these situations, and helps a lot later in life.
It is hugely valuable to identify and abandon dead-ends instead of wasting money and opportunity resources chasing them. That is to say a negative answer is still a valid and useful answer to get.
(You know this of course, this is how I try to explain it to my students)
From the get go establish that we are a team and working towards a solution. Solutions very rarely are in their own little box and all sorts of details get incorporated. It is important to underscore that dead ends and half baked ideas can contribute too. 1000 ways not to make a light bulb and all that
The idea doesn’t belong to anyone, we can give credit to those who came up with the “spark”, but often we are rapid fire modifing, changing, tweaking etc. It is important to recognize people that pushed an idea along, but at the end of the day the implementation is built on a thousand small lessons learned (see point 1).
This is often attempted by our coaches when it comes time to select the “winning” design. “There are lots of good ideas and we can only do one of them.” I’ve seen three responses from students - acceptance, pout a little, go off with a like-minded teammate and build theirs to prove others wrong.
Are teams building such complex robots that this is a recurring issue? I’d say at least 90% of our issues are as plain as day.
The SparkMax wasn’t well secured, it fell out, and we drove over it, unbussing the CAN.
We hit the wall full speed with the intake deployed, see the broken chain and the sprocket missing teeth.
and so on.
It wasn’t a conscious decision, but for as far back as I can remember, most of our senior designers have also been on drive team, which means they aren’t on pit crew. And thus they don’t get to hang around the pit. They go elsewhere to work with the strategy lead to do match prep. Our pit crew tends to be manufacturing subteam members. Since they’ve built parts all over the robot, I’d guess they don’t have the attachment to any particular mechanism.
This dynamic tends to be much less common with mechanical issues, where the problem tends to be readily visually apparent. In my experience it’s much more frequently an electrical/software problem, where issues can be fairly “invisible.”
I’ve most commonly seen this dynamic arise when it comes to problems where the root cause ambiguously lies at the intersection of two disciplines. It could be a code issue that this motor isn’t moving…or the wiring could be bad. It could be a vision problem that the shooter aim is inconsistent…or the shooter could not be rigid enough. The groups responsible for each aspect will be convinced that their work is infallible because they understand it, and assume that the problem must lie elsewhere. And it escalates when someone with a very limited understanding of another discipline makes ill-informed speculation about what the issue could be. Problems aren’t always just brought up as a generalized “electrical has a problem, fix it!”, but as a more specific “we think the wires must be leaking electrons, fix it!” Which generates the reflexive “that’s not possible” reaction from people who understand electronics and know that obviously leaky wires aren’t a real thing. In a lot of these situations, people are correct to say that the specific proposed problem “isn’t possible,” but aren’t able to communicate that effectively in a way which doesn’t just perpetuate the cycle by throwing an equally improbable root cause back at the other subteam, nor consider broadening their view of the problem to look at root causes that are possible and within their area of expertise.
Breaking down rigid disciplinary boundaries like this within the team, and getting all members to have some working knowledge of other disciplines that go into the robot so that they can at least “speak their language” when collaborating on troubleshooting, or developing a better understanding of what kinds of problems could come up in other elements of the robot, is one of the most helpful ways to avoid this dynamic.
Strict segregation by discipline is something that’s kind of accepted as a necessary evil in a lot of workplaces due to the required differing educational/professional backgrounds, and I feel like some teams unnecessarily force that dynamic into FRC team structure when it isn’t necessarily the best fit for the situation. The best professionals are those who take active effort to understand the areas they work in parallel with rather than developing an “us vs them” mentality, and we should aim to help our students become those types of people. Plus, giving students more flexible/floaty roles where they develop multidisciplinary experience can help expose them to more and help them make more informed decisions about what they want to pursue in their future education and careers.
One of my favorite responses to a “that’s not possible” is the Explanation of Facts.
“That’s not possible!” “But it’s happening…” “But it’s not possible!” “Let’s go take a look, then.”
Then go through the issue as it’s happening, examine the action(s), and figure out mutually if the “that’s not possible” is justified by the facts, or is, in fact, highly possible because of some other thing… and then FIX the problem.
Maybe I’m overanalyzing the title here, but I’ve had that reaction probably 1000 times in my career. Not once did that mean I was resisting fixing it, just expressing my personal astonishment that something that is theoretically impossible is happening.
It took a while to realize that the theoretical is often wrong and that’s why I use my current name here (and other places).
Anyway, the point is, communication is hard. The same words can mean many different things. Depends on, well, a lot of things.