Working in teams is hard. Working in teams on the same item at asynchronous times is even harder. Working in teams on the same item at asynchronous times on a problem that no team member has worked on before is the hardest. That is the conclusion for me of this past week 🙂 .

In all seriousness, I have learned more about working in a team in this course than I have in all of the other courses at OSU combined. I believe that this is largely the result of the fact that a key element of our project (developing a neural net) is something new to the entire team. For almost every other topic/project, the concepts were either: A) fairly straight-forward or B) something that at least one team member had experience with. We are at the stage in our project where we are all attempting to train the neural net. Unfortunately, each and every one of the team members is working on this task at a different time (due to work schedules, geographic locations, etc.). Despite a robust version control system and a continuous integration-like process, it is challenging to figure out which team member has made progress on the neural net and how that progress was made (i.e., through trial and error, more or less, which parameters and alterations improved the outcome?). We are all learning on the fly with this task, and that does not perfectly lend itself to effective version control timelines/processes.

All of this experience has led me to the conclusion that the most effective teams, where effectiveness is measured by output, are likely the teams with the most efficient and refined processes. I currently work at an investment firm where a material portion of my day-to-day work involves numerical computing/optimization projects. This is a new endeavor at my firm, and that is evident with our “bare bones” processes, although this is an area we are continually trying to improve. In our current structure, almost all projects are worked on and completed in a singular developer fashion. Once projects are complete, there is an intensive review process by other team members, but this process naturally avoids the challenges and pitfalls that I am experiencing with my capstone project group. This is by no means a knock on my project group, as it is something we are all struggling with simply due to our inexperience in the area. As the developer group at my firm continues to grow, and as our projects increase in scale and complexity, it is only a matter of time before we begin to go through these same challenges that I am experiencing in this course.

This all leads me to the conclusion of this post…what are the best tricks and approaches to efficient team design and operations? As I work on building out the team at my current firm, and as I entertain potentially other positions, this is going to be a critical piece of consideration as I continue to grow in my career. In other news…the opaque, systemic leverage embedded in the crypto community is going to mean a lot of strong developers will be back on the job market (RIP FTX).