unModified()

Break stuff. Now.

Handling a Student Team

What I did back in college to handle different personalities

April 2, 2015

A year an a half ago, I was in despair that I actually posted for help on the interwebz on how to manage a student team. As far as I remember, that time we were under several school projects and I was also doing stuff outside school (freelancing, sidelines etc.). I very well know I can do what we're tasked to do, but just can't because of the sheer amount of work and the kind of people I have to deal with. Fast forward a year later, here I am. I graduated, I have a JavaScript+Python gig at a startup, and breating fresh air (for now). So what did I do and how did I do it? Here's how:

Problem #1: Team mates don't know anything... at all - Guidance

These guys don't listen in class, and by "skip counting" or "raffle" I end up with them. Some are willing to do the project, which I tend to concentrate in helping (because they show up in meetings). I try to explain in simple terms, with diagrams and all, but they still can't grasp the concept of the project.

This was an overstatement. What I eventually did was to spoonfeed them to get them up to speed, as well as delegate tasks to people who are better suited for it. I wrote down a README containing the minimum required commands and steps to contribute to the code. I also turned down the offer of being project manager since I am only in campus once a week. We enforced the use of an issue tracker, instead of tasking people via Facebook.

Eventually, people got up to speed. Devs would just look at the bugs and backlogs tags while testers just waited for issues to be tagged "For QA". Project manager... she's a monster, but she got the project done by assembling a core team to do the bulk of everything, while keeping the rest for trivial stuff, stuff that would otherwise get in the way of the core team.

Problem #2: Not meeting deadlines - Adjust

True that we have our other deadlines, but deadlines should be deadlines. I usually hold my end of the bargain, but the others usually don't. They usually say "I can do that later. The project deadline is still 2 weeks away. Why rush?". This happens, and then everything piles up near the deadline.

Missing deadlines was a common-place in projects. However, we were not taught how to gracefully deal with deadlines. All we end up doing was cram at the last minute, doing 200% capacity. Cramming one thing was tedious enough, but cramming a handful of projects... (flips table) (throws notebook out the window).

Eventually, I learned to say no and delegate the tasks. I spread out tasks to other people. For my thesis team, I told them that RnD and documentation is covered, just do the administrative stuff for me. Chase instructors, do testing, do the surveys, we good? In the end, we pulled-off the greatest feat ever. This soon prepped me for agile development, which is the mainstay in the software development world.

Problem 3: Total dependence on me - Carry

So they don't know how to do it (but I do), they delay everything to the last minute (but I don't). When they realize that they can't do it, they turn to me because I know how to do it, and I have nothing to do since I'm done with my end. Note that I have tried to explain to them what to do before starting off.

Mother once said: "In the end, you can trust no one but yourself." - and I accepted my fate as the "carry player" of the team, regardless of what team I'm dropped into. This came at the expense of having no sleep, having to learn a lot of stuff, spend a lot, gain weight, and be the most ruthless member of the team.

In order to pull off the greatest feat, I had to orchestrate everything, a game plan. Basically, I was "playing god", but isn't that what you basically do in RTS games? In the end, I pulled off thesis, one major, and one big deadline at work in one month and still manage to do some chill time, play DOTA2 and all that crap. How? People management.

Problem 4: "Rockstars" and Hot-air balloons - Understand

Some of these slackers are, unfortunately, "rockstars" and show-offs which do code their way (think of globals and single-filed C code) and talk a lot but can't do a thing at all, respectively.

You can't escape the fact that there are people like these. However, what I ended up doing is delegate tasks that they can do to these people. For my thesis team, took advantage of one member who was good in talk. He did PR duties for our team, talked to people, did interviews, and even did a quick comedy during defense. The other was clueless of the project, but he was always in campus. I tasked him to do survey and instrutor chasing duties.

Like Einstein said - "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." Nobody is stupid, they're just better than you at something else. One-on-one is pointless when the situation can still favor one side.

Problem 5: They are not afraid to fail - Don't fail

I may not be a dean's list candidate, but I am afraid of failing class. But my team mates? They accept failing. In fact, they fail at least 1 class a semester. A failed class would be like a walk in the park for them.

"When all else fails, we don't" - A famous line in G.I. Joe which I always keep in mind. You have to learn that in the real world, there's no one tasked to catch you when you fall. When you fall, you fall hard. All you have is yourself. Don't fail yourself.