108 lines
6.7 KiB
Markdown
108 lines
6.7 KiB
Markdown
---
|
|
title: "Lessons Learned: Managing a Team"
|
|
date: 2017-12-26T15:42:56-05:00
|
|
tags: ["soft skills", "university"]
|
|
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.
|