6.7 KiB
| title | date | draft |
|---|---|---|
| Lessons Learned: Managing a Team | 2017-12-26T15:42:56-05:00 | 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
- 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.
- 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.
- 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 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.