How to be a Team Player

This is the 9th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.

Today we talk about a very important topic for the Junior Dev Diaries. It’s a bit personal for me and It’s one I’ve been meaning to write about since the very start. This series is about how to become a better software engineer, not a better programmer. What’s the differences? Well, coders write code and software engineers build multi-version, multi-person programs. Let’s focus on that multi-person element. Whether you like it or not, software engineering is a team sport. We work together as a team towards a common goal. So your team work skills need to be just as good as, if not better than, your programming skills.

Time and Place

An easy trap for new players, is causing disruptions in meetings. It’s a sadly too easy way to really be a terrible team member. In The Real World, each meeting has a time limit and purpose. The idea is have the meeting, exchange the necessary information and then get back to work. Each meeting is expensive (people x hourly rate x time…) so wasting time can really hurt the business. It is incredibly tempting to just ask that question, or offer that suggestion right then and there — but in doing so, you may start a conversation that completely derails the meeting.

One of the traps I regrettably fell into was to try talk as much as I could in meetings, because I thought that’s how I added value. If I brought my plentiful ideas to the table, I’d be contributing the most. However, it turned out, I was doing more harm than good, and just disrupting the meeting. The team got sick of me talking too much and I had to work hard to earn that respect back. I now never talk out of turn in meetings, and if I have an idea or question, I make a note to talk to the suitable people after the meeting. My idea/comment/question (good or not) is still heard and responded to, and I haven’t detracted any value, but the chances of adding value are still the same. Win.

Make Decisions as a Team

In a team, you make decisions as a group. In general, the team decides what to do based on what the majority votes for, with a team lead breaking any ties. This may be a process, a task priority, a deadline, a new hire… anything! Once a decision is made, it’s on you to get behind the idea and put your best effort in. Support your teammates and work towards the goal until it’s done.

Tone and Optimism

So what happens if you disagree with what the team or management has decided? Well it’s a matter of being optimistic and watching your tone. If you think about it, a group of smart people thought this was the best approach, so what does that make you? Watch your tone and try not to make anything personal. Alice or Bob may have raised the idea, but the team is with them and now it’s the team’s idea. If you get down about the decision or simply can’t see why you’re doing it, it’s important not to let that affect your work too much, and use the above Time and Place thinking to raise any concerns. But, before you do that…

Give Ideas Time

Any idea needs a bit of time to work or not work. Especially those relating to process, such a team implementing agile for the first time or a new facet of process. While you think you know how it might turn out, you really just need to give a go. Choose a time scale that is appropriate for the task, this may be a few days to a few months. Once again, give it a go and don’t try and push against it. This takes maturity and shows respect for the team.

Change What’s Broken

It’s okay to be wrong. And it’s okay to be wrong as a team. If sufficient time has passed, and the decision you made hasn’t panned out, for whatever reason, your team should be committed to changing things. Fortunately, agile has Retrospectives and Team Health Checks for this. Now, if you were disagreeing secretly the whole time, now is still not the time for an “I told you so”. There’s never a good time for that. You might gain a bit more influence the next time the team is deciding on something, but certainly not if you were a jerk about it. Don’t be that person.

Pick your battles

However, there will come a time where something just won’t bode well with you. And this is a skill of picking which battles to fight. You only have a finite number, and everyone else only has a finite amount of patience and arguement energy to hear you out with. Choose these battles wisely and make sure it’s the “hill you want to die on”, that is to say, if you do lose, and something negative happens (fired, lost respect, lost time etc)…has it been truly worth it? Do you really care that much? Or can you just get over it?

Team Culture

Everything you do in your team contributes to the culture of the team. Everything. If you’re annoying and disruptive, you’ll breed contempt. If you’re positive and productive, you’ll inspire that in others. You really want to try lead by example here, and inspire others to be like you. Team culture affects everything to do with a company. It affects staff churn, profitability and in turn, your own job stability. It’s truly in your best interest to be the greatest team player you can be. A champion team will always beat a team of champions, and you can be in that champion team and love your job. That’s proudly where I am now after working on the above, and I’m so much happier than six months ago.

The best book to read on this is an oldie but a goodie: How to Win Friends and Influence People by Dale Carnegie. Buy it. Read it. Create actionable steps from its chapter headings.

Good Luck!

This is the 9th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.