Things I Learned on Team Chemistry
Here are a couple of things I learned or just realized about group chemistry, after working for almost 5 sprints together with my PPL (software engineering project) course. Some of these are completely my opinion and bias take on things, but I do feel that sharing them isn't too far fetched.
Create a safe space
I do still believe that the safer each group member feels with one another, the more likely they are to contribute to their full capacity, without having any fear of embarrassment or rejection. Again, this is one of the reasons why it feels better to work with peers from your immediate circle, rather than with some unknown, even though one might just be a better and stronger team member in terms of experience and contributions. Remember that my opinion on this might be bias as I have yet to work for professional working groups.
Communicate, even if you think you’re less knowledgable
Usually in non-professional working groups (such as college groups), some of the members happen to be more experienced than the rest. So when it comes to brainstorming potential solutions/outputs, a stronger or experienced team member would be very likely to give a solution that will be accepted, mainly because being the most experienced means having a better grasp of the situation, hence better solutions. Or maybe it’s just because of the fact that the rest of the group are oblivious to any other solution anyways.
This is one of the important points I learned. Being passive in a discussion when you think you have less experience does not help yourself or the group. Especially if one really has something in their mind. Your idea might just higher the ceiling of brilliance in the solution that is being brainstormed, and you singlehandedly failed that because you assume your idea isn’t worth mentioning.
SImple appreciation is underrated
Some of you can’t even fathom how nice it feels. A simple ‘nice’, or ‘gege’, or ‘ntap’ from peers, or even just ‘good’ from my lecturer can feel really good especially when I know I have worked it. I know I don’t speak for myself when I say that I don't need a direct form of appreciation to somehow feel appreciated.
Give feedback in an exciting way
With my PPL software engineering team, I rarely have to give feedback to other people’s work. Mainly is because their work has been proven to work and to pass test cases, or I was just really bloated with assignments to even be bothered to read every single line of code commit (tons of lines) done by them.
But when I do, I’d make sure it’s not just a bland ‘hey, this will work better if you do it this way’. Instead, I’d throw in some inside jokes, excitement, or any kind of humor just so it feels like an ordinary talk rather than feedback. (Some of mine are too explicit to be written here, but u get the point.)
Do your best for the team
At the end of the day, it’s just you and your team. No external intervention can carry up a team that just doesn’t work together. The chemistry must be built upon since the day the team is conceived. Our PPL team chemistry isn’t anywhere near a perfect team would have. But we manage to get this far with similar trust we put on each other, and our individual responsibility to do our best for the team.
Written as an assignment for my software development project individual review.
