diff --git a/content/post/managing-a-team.md b/content/post/managing-a-team.md new file mode 100644 index 0000000..a2aa587 --- /dev/null +++ b/content/post/managing-a-team.md @@ -0,0 +1,106 @@ +--- +title: "Lessons Learned: Managing a Team" +date: 2017-12-26T15:42:56-05:00 +draft: false +--- + +This semester at George Mason, I was enrolled in a class simply titled "Software Engineering." +I didn't pay it much thought at the time, my job title is Software Engineer. How hard could a class +be that is about going to work every day and topics such as the software development lifecycle +or different process models. Simple, I practice this on a daily basis. Scrum? No problem. Standups? +Yeah every morning. Agile? I live it! Needless to say, I had a big head going into this class, +but the experienced humbled me, and taught me that there is much more to learn to this field +than mere engineering. + +The class was centered around a team project. The point of this project was that you and 4 other +strangers were to bring a large-ish (because Java but I won't get into that) project from the +initial user specification to completion. On it's face, the specification was very simple. We were +to design a system that peformed operations on data based on messages that were passed to it +from a front-end interface. Easy, what a CRUD-dy spec. See what I did there? It gets interesting +though. + +After giving out the specification, our professor announced that she would be dividing us into +teams, based on experience. Everyone was to take the same online survey designed to order us +in terms of real-life industry experience and the teams would be created from this ordering. +With nearly 4 years of professional development under my belt, I knew I would be closer to the top +of this ordering, but I figured that everyone in the class would at least have internship experience. +To get this far in computer science (junior level class), you have to have a decent amount of +drive, and the people with that drive are typically trying to start their career as well. With that +thought in mind, I thought whatever team I was placed on would be able to hit the ground running +and have all of us actively contributing from day 1. + +False, everything I thought was false. + +Being the most experienced developer (at least for large projects, i.e. work) in the class, I was +placed with 3 other students who had next-to-no experience in anything other than hacking together +homework assignments on their Windows laptops. + +Now, I love to teach, and figured that while we were all working side-by-side on this semester long +project I could disseminate what I know to my future colleagues. Any way I can help them be better +off in the job market will make me happy. I prepared quick walkthroughs on using Git, how to resolve +merge conflicts, what workflow we would employ in version control, all meticulously selected +to better my new teammates. + +Then, the professor announced: "Each team must vote on who will manage the group for the entire +semester." + +Everyone unanimously voted for me on my team, leaving me no choice but to enter the world of +management. + +Now I found myself in a different paradigm, I could no longer see to it that code was completed in +a way that I enjoyed, I just had to plan to hit our project deadlines and milestones. +I couldn't be a part of the detailed work taking place on the repository and +at first it killed me, but it taught me a lot about people, and my own soft skills. I wanted to +share some anecdotes, and lessons I learned from being a manager for 3 months. + +## Lessons learned + +1. Prevent knowledge "Silos." + +We had a member of our group, who I shall call Kevin. Kevin was a genius student when it came to +computer science theory. However, Kevin was very very quiet. He would sit during our meetings +and not talk at all, but his stream of ideas would flow on Slack at 2 AM when we were all asleep. +Kevin had a habit of taking things from the more junior members of the team and fixing them +when the juniors would get stuck. When Kevin did this, it encouraged the juniors +to write buggy code and just depend on Kevin to fix it. He would never provide an explanation as to +what was fixed though, and just submit pull requests without detail. + +To fix this problem, I had Kevin peer program with the junior members of the team whenever he found +issues. This did 2 things for my team. It build Kevin's interpersonal skills, and it built the +junior programmer's coding skills. I was very happy at the end of the year to see the junior +programmer asking Kevin for reviews of his code versus asking Kevin to fix it, and Kevin would +provide thoughtful, constructive feedback to the junior. + +2. Intrinsic motivation is very powerful + +The junior members of my team often got very discouraged when they could not tackle hard problems. +It would take one of them days to do something that Kevin could do in an hour, so keeping them +motivated was challenging. I did buy one junior food after his completing of a feature on time, +but this didn't work the second and third time I needed him to hit his deadlines. I had to make +a change, and fast, so I decided a more intrinsic approach. + +I took on this junior programmer as a mentee, and made sure that I answered any and all of his +questions that he had as he started his process. I would watch commits as they came in, and tell +him what great work he was doing if a commit was particularly clever. I immediately noticed a change +in him. His overall demeanor was lifted, he would stay late after meetings, take on more work, +and would hit deadlines more consistently and often early. He cited in his final review of my +leadership that feeling supported and valuable made him want to do more with the project, more than +tangible rewards that were given to him. + +3. Provide a visualization of work being completed. + +What was very important to me as a hybrid manager-developer, and to the people on my team, was +progress. It was important for my teammates to be able to see that we were actually getting work +done. At first they cited that they had no idea how close they were to hitting deadlines. I +implemented a Kanban board on [Trello](https://trello.com) and started filing tickets for them to +work on. As new features or deadlines approached, I would add tickets to the TODO column of our +board, and teammates would assign these tickets to themselves based on what they thought they could +get done. With the new board in place, the increase in morale of our group project was palpable, +and my teammates could point to tickets that they completed for the final project to show just how +involved they were to the professor. + +## Would I do it again? + +I don't think so. I don't like managing a team, but I do love working with people. I have a newfound +respect though for all of my past managers, my current manager, and for any managers. Thank you for helping your +employees thrive by doing so much behind the scenes. Your job is a tough one and I appreciate it.