blog/content/post/managing-a-team.md

---
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.