Posted by Joel Low on 29 September 2013 | 2 Comments

Tags: ,

So Assignment 3 was submitted 2 days ago. I honestly do not believe it was ready for prime time, but deadlines are deadlines. As a team, we weren't as productive as we should have been. This led to a substandard product (in my opinion, anyway) and would probably cost us.

I'm going to try to distill what I think could have been done better, hopefully never arriving at the same problem again. I don't mean this post to be critical of other people, but rather how I could have handled the situation better. Stuff here might not be useful in a school context -- school cannot replicate what goes on at work -- but I think it's useful to learn anyway, so I'll write them down here. Once again: this isn't meant to be myopic for school projects only.

Lesson 1: be ruthless, but fair

I think this cannot be overstated. I felt that maybe I was being too nice to my team mates, which resulted in our contentment with mediocrity. When things weren't going well, I didn't have the courage to admit to it and change the way we were doing things. I became part of the mediocrity. I didn't have the courage to tell my team mates off.

Sometimes people just need a dose of reality forced upon them. I try hard not to do that to people, but this was one time I really should have, and I failed to do so. Of course, whatever one speaks must be fair, even if it sucks to be on the receiving end. If it's truth, it can't be helped.

The final component to this was as such: if people aren't delivering, cut them out. I really didn't want to do this. I tried hard to make sure everyone could contribute positively to the product. By the time it looked like we were going to hit a brick wall, we didn't have the time to recover. Our other assignments and deadlines prevented us from trying so. I need to learn to be a little less naive about people and learn when enough is enough.

Lesson 2: have healthy skepticism

Never assume. I looked for people to form my team, thinking that they would be able to deliver. My mentality was as per Week 0: the people of this module is supposed to be good. Otherwise there's no reason for them to be here. Let's say that assumption turned out to be false, 66% of my 3 picks proved to fall short of my expectation. Before this assignment was due, this was inconceivable to me. 2 days before the deadline, I was screaming within me.

Also, when we used completely foreign frameworks and languages (look! I learnt Python, Flask, Mongo, Angular in this one assignment!) I knew I would not be performing at my best. On hindsight, I think I did decently (feel free to disagree -- and tell me why and what to better do) and I did allocate sufficient extra time to work on things. So that at least turned out okay.

Lesson 3: know your capabilities (aka don't risk too much!)

I knew what I was capable of. I knew what one other team mate was capable of. I knew what two other team mates were capable of. Hang on -- I know nothing about them. Translating capabilities into a feasible product has got no causation, and a weaker correlation than I thought. Having experience in something does not mean you're good at it (even if you've been working on it for extended periods of time)

So, how do we get around this? Take lessons 1 and 2 together. Have that "red line." When things aren't moving, tell people off, burn your bridges, whatever. The objective is to deliver. If one can't do that, he is functionally useless to the team. Move on without him if need be. Oh. And call for backup if you can. Remember the objective is the product.

Lesson 4: post mortem

Writing this post-mortem is something I would not have done before. Having nearly completed it, I think it's a good idea for reflecting on what I did (rightly or wrongly.) I would do this more regularly in future, I think it's good for my development as a person.