Our Team at a Hackathon
Earlier this year in March, I was asked by a classmate who was a Statistics PhD student to join a Hackathon team consisting of 4 members in total. I was surprised that he would ask me, considering I had just added the major for my undergraduate degree and my knowledge in the subject was very limited. During our initial dinner with the members of the team, I learned that everyone else but me were graduate students majoring in Statistics. I asked Peter, our group leader, his reason for including me in this project that required a lot of expertise in data analysis. He said, since this project includes a presentation component and he had seen me give a presentation before that I would be a great add to the team, and my skillset would complement the others'. In his words, I dealt with the front-end stuff and the others were in charge of the back-end stuff.
I wasn't entirely sure what he meant by that but I took a leap of faith and agreed to his invitation to the Hackathon which I hoped would add to my experience for the new major. The Hackathon was a weekend-long competition where groups of 3 to 4 students would try to finish a data analysis related project, in this case, providing a forecast for four company's stocks and ultimately choose one of them to invest in. Immediately after the reveal of the topic, Peter divided all of our tasks immediately. George, a Statistics graduate student from Purdue was in charge of mining data from websites because of his expertise in data mining. Jake, a PhD in Statistics who had experience in being a TA in various Statistics courses was in charge of analyzing the data and explaining his findings to me which I would include in the final presentation. I was asked to find out some important background information of each of these company, including what they do, their reputation (news articles mostly), and finally the powerpoint because of my experience in design and presenting. Last but not least, Peter, who was also a PhD in Statistics who had worked with Jake before, was the overseer of the entire project and was helping George with data mining, Jake with data mining and me with producing a presentation that is comprehensive enough for a non-data science professional to understand our findings.
I would say our group structure was a combination of One Boss and Circle Network, because Peter was in charge of everything and the rest of us three worked like George (back end) -> Jake -> Me (front end). This structure, in my opinion, worked exceedingly well because it maximized our individual expertise. Like the B&D textbook mentioned, "teams of diverse individuals, ...., sparked major breakthroughs. Well-organized small teams have the ability to produce results that often elude the grasp of large organizations." I could not agree more. If our team had been bigger, the individual responsibility would be more ambiguous and team members with similar responsibilities would be more likely to pass the buck to another teammate. Because of the clear divide between our tasks, we worked almost like an assembly line from back end to front end, and Peter was there to answer any question we had that made the entire process very smooth.
We ultimately won the Hackathon. If it wasn't for the efficiency of our team structure, we would have more difficulty in achieving it. In Katzenbach and Smith's words, we were a team with complementary skills (programming, mathematics, design, and presentation skills) who were commited to a common purpose (finding the best company to invest in). Peter was also especially good at translating that common purpose into specific, measurable performance goals. He made sure that the data George mined were relevant and clean enough for analysis, the mathematical models Jake used produced the right results and the presentation I made was aesthetically pleasing and clear to a non-technical audience. Through participating in this Hackathon, I had truly understood the power of a small but very efficient team and the joy of winning the competition was immensely rewarding.
It would have helped me at the outset to have you explain what a Hackathon is. I hadn't heard the term before. This is what Wikipedia says the term means. Perhaps data science types have appropriated the term, which was already in use by programmers. In any event, I got the impression that all the work had to be done rather quickly. Was that true in your competition?
ReplyDeleteIt sounded like Peter had a good eye for selecting teammates. But he also must have been persuasive in some way to get George and Jake to join the team. Did either of them tell you why they willingly became part of this effort? It is my belief that the first ingredient of good teams is that every team member wants to be on the team. Then the second ingredient is that each is competent in the area assigned to them, coupled with a willingness to learn enough about the other areas of the project that they can fully understand how their piece fits in.
Having had this good experience, does it impact your future plans? Might you go on to a graduate degree in statistics as a consequence?
Now let me ask what might sound a weird question. Suppose your team performed just as it did but that there was another team in the competition better than yours, so you came in second rather than winning it all. Would that have mattered in determining the effectiveness of the team? The thing is, you can't control at all how good the other teams were. Might we put too much credence in winning as the measure of whether a team is effective?
a
DeleteMy apologies, I should have explained to you what a Hackathon is. It is usually a several-day long competition among teams of programmers, hence it is the combination of the words "hack" and "marathon". Our specific Hackathon started on Friday night and ended that Sunday morning.
DeletePeter selected George as a member of the team because not only is Geroge Peter's cousin, but they have also been in the same Statistics department over the pass few years. As of Jake, he and Peter are doctoral students and have worked on some papers together. They were all relatively good friends with each other. I had known Peter since last summer through the introduction of our mutual friend, Sheryl, and he had been kind of a mentor to me since then. Because of how Peter had already known all of us for a while and had observed our strengths and weaknesses rather closely, he was able to assemble a team of people who would possibly work well at a data-science related Hackathon.
My most important reason for participating in that Hackathon was to gain experience in Statistics . I thought that the entire process was a great learning experience especially because I was going to work with people who were much more experienced than I was. As for George, he was a first year graduate student and was also looking for experience . Jack and Peter, in their words, thought the Hackathon would be a "fun break" in the middle of their doctoral degree, the prize of the competition seemed attractive enough, and Jack genuinely enjoyed teaching Statistics related things and thought he would give us great guidance. Although all of our motivations differ, we all wanted to participate and wanted to win the first place's prize -- iPads. I remember listening to Jack trying to motivate us by reminding us we could have free iPads if we won the competition, at 3 am in the morning on that Sunday while we were typing away at our laptops. The combination of our expertise, our individual motivations and all wanting to win the grand prize contributed to how hard everyone was working over the weekend.
Having had this experience did not necessarily impact my future plans because it was on the right path of what I already wanted -- getting a full-time job related to Statistics/Data Science. Participating in the Hackathon put me closer to that, because it had lead me to an interview for an internship which I ended up going that same summer.
The effectiveness of our team definitely would not have diminished if we had not won. Winning, however, at least was an indication that our team was a good team. However, there are many other ways that our team was a good team without comparing ourselves to others like having a clear divide of our tasks since the reveal of the topic, how all of us were very motivated and worked hard through out the entire weekend, etc.