Our battle bot (the black) in action
I've adapted this article from the written report that I turned in to the ELC committe for the BYU Engineering Leadership Certificate.
My second leadership experience took place at BYU during the fall semester of 2023. I led a team of 4, including me, in the Ant Annihilation tournament hosted by the Experiential Learning Center in the ECEn department and the Combat Robotics club. The experience was defined by two principal stages: the building stage and the competition day. Starting in September, the hosts started the teams out building their robots. Every Thursday night, we had a “build night” where we would brainstorm, design, discuss, and build as a team. This continued until the 3rd of December when the competition day itself was held. Then, teams compete in a double elimination tournament. The building phase comprised the vast majority of the leadership experience. For me, this was the most rewarding and interesting part. I'm not a very competitive person but I loved learning more about electronics and RF communications during this phase. In order to ensure safety and fairness, the robotic competition adhered to the SPARC robotic competition rules, specifically the rules of the ant weight class. This meant that only plastic parts were allowed with the exception of axles and fasteners. In addition, the robot could not weigh more than a pound. Our team was created simply out of happenstance with none of us knowing the others before. I (Ben Duncan) and Ty Bielozer are Computer Engineering students, me being a senior and Ty being a freshman. Zachary Freelove and Peter Brown are both mechanical engineering freshmen. We split our team into two: an electrical/software team and a mechanical team. We started out the building phase with gusto in planning, scheming, and conniving. We opted for a pin, or barrel, robot with a wedge-shaped body and our own RF controller modules. Despite our thorough efforts to create a consistent RF transmitter/receiver pair, we eventually scrapped it and used a manufactured transmitter/receiver pair.
In my leadership experience proposal and my midterm evaluation, I identified strengths and weaknesses in relation to exceptional problem solving. I identified my determination and persistence as the strength that I wanted to work on. I chose starting projects early as my weakness.
During the project, I was very happy to do my part of the project and found my determination to be a great help in facing the challenges of the project. However, I found it strained due to the difficulty of the project. I needed to pace myself better. To my surprise, I've learned over the years that determinism can be strengthened with healthy energy management, setting a pace, and accomplishing my tasks in smart ways. I was reminded of these principles during this project. I found that I was overworked as the semester went by simply because there were many tasks that needed to be done but only I knew how to do them. Specifically, Ty and I chose to make our own transmitter/receiver pair instead of purchasing them. Our goal behind this decision was to have a greater learning experience than otherwise. But I underestimated the amount of work needed to design and produce it. In addition, Ty had little to no experience with PCB design, circuit design, and programming. This meant that the vast majority of the work rested on my shoulders. It was too much. I learned about the importance of two things: knowing the capacity of me and my teammates, making sure to provide proper rest and recovery; and knowing the extent of the challenge at hand. If I understood Ty's abilities, I would've been able to problem solve with him better. In addition, if I had better understood the problem at hand, I would've known that it was too much for me to do alone. We should've outsourced the transmitter/receiver in order to have a more manageable workload. This experience helped me to know that simply attacking a challenge with determination is good but not the best. It's best to pace oneself and approach the problem in a careful, deliberate, and thoughtful way.
At the beginning of the building phase, my team and I started early to understand the requirements of the robot we were going to build. We discussed various possibilities and options for the weapons and drive systems. We really nailed the start of the project. I was really proud of this. However, I found it more difficult to keep such organization and scheduling as the semester went on. For example, because I was enrolled in capstone at the time, I lead our team on the development cycle discussed in the curriculum. The cycle uses the following steps: shrink your focus, try different concepts, evaluate the results, and preserve the outcome. I love the idea of this development cycle and believe it to be very useful for any project. In our second meeting, our goal was to have the basic concept of a robot decided: the weapon system, the drive system, and the general shape of the robot, executing the development cycle. However, we spent too much time in the “try different concepts” stage of the development cycle. Because of this, we had a difficult time deciding on an actual concept by the end of our decision time. I had to quickly get a vote on which robot concept we would go for. Happily, we all agreed on which concept to go forward with. As the semester went on, we paid less and less attention to this development cycle and the schedule that we had created. Our project suffered because of this. This experience helped me to increase my problem solving skills in a leadership capacity because I better understand how to effectively implement a development process. It's crucial to have a schedule and to adhere to it so long as it is beneficial to the development of the project. In this instance, I could've done a better job by keeping us on track, reminding us of the goals that we had set, and the expectations that we had one for another for the entirety of the project.
Though I made good progress in both the strength and weakness that I identified for exceptional problem solving, I found that new areas of improvement were brought to my attention. This is one the greatest qualities of improvement that I've come to appreciate. As I get better, I understand better how to get better. It's amazing!
For effective teamwork, I identified my strength as finding the best solution with peers and my weakness as speaking my mind in difficult circumstances. I recognize that these are heavily tied to communication. In fact, I've decided to write about “speaking my mind” in the Clear Oral and Written Communication section. As I was thinking about the experience, I found that “speaking my mind” was very closely related to the “speaking boldly” that I had listed on my communication weakness. Because of this, I'd prefer to write once about them both in that section. I know this goes somewhat against the rubric for this paper but I hope that you'll make this case an exception. However, I would like to talk about the difference in skill levels between teammates and how it affected our ability to work together.
Throughout the project period, I found great solutions with my peers in discussions and research. When making a design decision, we would consult each other and give suggestions and advice on the matter. For instance, we made a lot of great decisions at the beginning of the project which gave us a general overview of the tasks ahead. Because of this, we were able to work in parallel. This was a great strength for us. However, one of the biggest lessons I learned from this experience is knocking out the task that the majority of other tasks are dependent on. We worked in parallel but many times, in a project, there are tasks that must be completed before other tasks. It's important to finish the most important task in order to get to the next task. In our case, we had a mechanical task that was dependent on an electrical task. The electrical task was figuring out which components were going to be used on the robot such as the receiver, motor controllers, the motor, power switch, and the motors. If the mechanical team didn't know what needed to go into the robot, they couldn't properly design the chassis. This happened to us. I didn't realize the importance of this task until later in the semester. I had focused so much on the design of the transmitter that I had neglected the design of the receiver and the other electrical components in the robot. As such, the mechanical team couldn't fully design a chassis and this delayed their work. In the future, I think that an activity map would be very useful in choosing what tasks to do first. An activity map shows the needed tasks as well as their dependencies on other tasks. With this tool, one can easily see what tasks need to be done before others as well as if one could mark a task as optional or not. This area of effective teamwork was somewhat new to me and now seems obvious. However, I believe that it's very important to the success of a project.
our project required a skill level that only I had obtained from classes. More specifically, the transmitter/receiver that Ty and I had decided to build required at least a skilled Sophomores or Juniors education to complete. For that reason, I was stuck designing, prototyping, and building it. Ty was able to help out with some of the soldering and the user experience but other than that, I was stuck working on it myself, similar to what I stated in the Exceptional Problem Solving section. I know that we would have ideally known what was required for us to be able to work efficiently together but that was something that we didn't know at first. In addition to me misunderstanding Ty's abilities, we also underestimated the time and effort required to complete our project. Being able to balance a workload between coworkers is very important to effective teamwork, I've found.
Effective teamwork is greatly tied to communication between team members. I found again that I discover new ways to improve when I seek to better my current strengths. I can increase my ability to implement the great solutions that my teammates and I find together.
In clear oral and written communication, I identified coordination as a strength of mine and being bold in communication as a weakness. By being bold, I mean to be able to address difficult conversations. I've combined this weakness with the “speaking my mind” from the Effective Teamwork section. In addition, I'd like to discuss delegation as well as interfaces as additional topics for communication.
Overall, the general coordination and interfacing between team members was great. We chose to use a simple sms group chat for talking supported by a Google drive where we kept important files and links to facilitate the development process. I'm very glad that we used a communication platform that was easy for everyone to use. I was tempted to use something such as Slack, Teams, or Discord but, after some thought, we decided that it was too much effort. I've learned the importance of getting everyone's opinions on the method of communication in order to facilitate it as much as possible.
Despite my efforts to communicate well, I struggled to have critical conversations with my teammates and provide enough structure to them. For example, I didn't mind taking the initiative with my own subteam (Ty and I) because I understood well what I was doing, was eager to do it, and had the ability to initiate a collaborative environment with Ty. The other subteam (Peter and Zach) were freshmen and didn't have very good initiative to work together and collaborate. I discovered this later in the semester as we drew nearer to the competition date. At first, they worked somewhat fine with each other but struggled to listen and discuss. Later on, they seemed to have given up working with each other and began to implement their own designs without consulting the other. Once I realized this was happening, I struggled to think about how I could get them to work together effectively. I found one of them to be approachable but timid and the other to be unpredictable and somewhat brazen. I was afraid of discouraging, offending, or upsetting them. Because of this fear, I hesitated too long. This was detrimental to our timeline as it set us back a couple of weeks. In addition, I'm not very satisfied with how things turned out. One of them ended up implementing the entirety of the robot chassis while the other's work was scrapped. I wish that things had gone differently. If there was an opportunity to do it over again, I would've sat down with them both and talked out more frankly the goals we had, what needed to be done to get there, and asked them what they were going to do about it. This experience was a great opportunity of learning and growth for my ability to have such crucial conversations.
In addition to the crucial conversations, I found many lessons to learn in my ability to delegate work. As I stated before, I found myself overworked and stressed with this project. Much of this was due the fact that I was the most experienced team member whereas my teammates were still learning many of the skills needed. However, there was a good portion of my burnout that could be attributed to delegation. I thought that if I simply said what certain teammates were in charge of, they would take charge of it and accomplish it. However, now I understand that there is much value in clearly noting what expectations, goals, schedules, and deadlines are needed to accomplish the task. In addition, it's capital to give responsibility to the people in a very transparent manner. This is an area in which I can improve. I believe that if I knew these things beforehand, I would've had much better results in delegating work to my teammates.
While I was reflecting on how we could've communicated better as a team, I thought about one of the practices that we had discussed in capstone. That's the practice of defining and communicating interfaces between systems. In our project, we had two main systems: the electrical system and the mechanical system. These systems interface via motors, part mounts, and the shape of the electrical parts. While building out the internals of each of these systems, it's very important to have the interfaces in order to design effectively. Above, I discussed how the mechanical team would've been able to work more effectively if they had known what electrical components were going to go into the body of the robot. If we had defined interfaces, they wouldn't have needed to know so much about the robot. I believe that our interface definitions could've simply come from the parts that we chose. Although this is a simple thing, I believe that I could increase my clear and oral written communication abilities as a leader by implementing such a strategy.
To me, communication of expectations, goals, responsibilities, and plans are critical to the proper execution of a project and one of the greatest roles of a leader. This is becoming more evident to me with every experience. I'm very happy that I was able to improve so much and understand how I can do better in this area during the past semester.
Deciding what I'd like to improve for the future is a difficult choice for me. I find a myriad of possibilities and opportunities to develop my leadership abilities. If I were to choose two, however, I would choose being able to have critical conversations and being able to keep my team on a schedule. Each of these are capital for the success of any project and I believe that I could improve drastically with these skills. I still find it hard to have those critical conversations but I am improving. Keeping myself and others on schedule will help me to be more efficient in working toward my goals. Although I don't see any immediate opportunities for leadership in my plans, I know I will have such opportunities in the future. In addition, I find that I can apply these same practices with my own self discipline in my life. It's very possible for me to set clear expectations, goals, plans, and schedules and then practice doing them in my own life. Another possibility for leadership will be as a father in my family. This one will come with different challenges and learning experiences than being the leader of a small engineering team. Crucial conversations and scheduling/deadlines will be important for managing family finances, chores, activities, etc… There's a lot of opportunities for development in my future. Overall, I'm grateful for the lessons that I've learned in this experience. There's always room for improvement and that makes me excited.