elburz.io

Is it hard to be a good collaborator?

Interactive projects have a lot of teams working on them. There’s often a gaggle of artists, technicians, suppliers, vendors, designers, clients, and more working on the same project. I’m often surprised by who I want to continue working with and who I don’t want to work with again. There’s obviously an element of quality of output involved in my decisions, but it seems like skill levels are generally raising across the bar, and what tips the scale are soft skills. These soft skills aren’t revolutionary and they aren’t very hard, to be honest. The difference between people I love working with and people I never want to work with again are the simple points below.

Communicate promptly

Communication keeps the world spinning and projects chugging along. There’s nothing that turns me off of collaborators like not receiving prompt answers to emails. I’m not saying I want responses in less than an hour or anything crazy, but prompt responses within a business day should be pretty normal at this point. Anything more than that should be flagged as such with a simple email that says “Hey, I got your email, give me a few days to answer.” That’s it, then I’ll wait a few days without issue. But what I can’t stand and accept is sending emails and not hearing any word back at all for for a week. At that point, you’ve become a liability and a gear that could fail in the grand scheme of the project. I don’t care if you’re some kind of genius, if I’m stressed because I have no idea when you’re actually going to deliver, I’m throwing you under the bus. Moral of the story: answer emails and calls, if you need more time just say so. Easy. Professional. Done.

Flag issues

This one is a bit trickier for artists in general and even more so for folks new to the field. The basic premise is that you should flag (or let people know) issues that happen on a project whether or not they will be resolved shortly or not. All too often what happens is:

  1. An issue or bottleneck occurs
  2. The person waiting for the resolution doesn’t flag it to the larger team/project leads/partners because they think it’ll get resolved soon / they don’t want to cause any stress / they might be shy or soft spoken / they’re afraid of repercussions
  3. The issue doesn’t actually get resolved quickly as expected or further issues / bottlenecks occur
  4. Now they raise the flag to the rest of the team but a lot of time has passed since step 1
  5. Everyone gets angry because it’s now a surprise issue that could have been mitigated either by someone else on the project or at least other teams could have scheduled themselves according to this new issue/bottleneck

The whole point of this habit is that everyone working on the project is an adult. You don’t need to worry too much about managing other peoples emotions / feelings / stress levels and you shouldn’t be worried about unwarranted repercussions or try to cover up issues. When something happens, even if it’s an easy fix, just be transparent and let rest of the team / partners know something is going on but that you don’t think it will be an issue. You should then mention that if the issue isn’t resolved soon you’ll update everyone again so that the project and react accordingly. Being straight forward and transparent is always the best way to go forward.

There’s nothing worse than having to scramble to clean up someone else’s mess that could have been easily dealt with ahead of time. Be transparent. Flag issues.

Meet deadlines

Everyone’s got an excuse when it comes to missing deadlines. I honestly can’t believe the excuses I’ve heard. A recent excuse that really gave me a laugh for a construction crew was along the lines of “software is easy and not really important, construction is real and hard and important, so we’re behind.” Holy shit, that’s some mental gymnastics! Now I’m not saying everyone is perfect and that there aren’t real reasons for delays. Even we have delays on projects if we miscalculated the amount of development time something might need or the amount of iteration something might take to really polish. The difference is the moment I have hesitation about possibly not hitting a deadline I do the 2 previous things mentioned: flag the issue with anyone the delay would impact, and then communicate promptly when people ask what’s up and what the new deadline should be.

All too often (I’m looking at you, artists!) people will start working more and more hours and pulling all nighters right up to the very last minute to try to deliver what they said they would. In most cases, this realistically results in sub-optimal work (and buggy code!), the artist feels like shit, and the clients / partners aren’t that happy. I’ve also seen far too often people will wait to the very last minute before raising the alarms, such as emailing everyone the day before the deadline that things won’t be done. News flash: that’s not acceptable! Flag issues (like I said above) and respond promptly to questions as partners try to re-arrange their schedules to make your delays work in the overall scheme of things. Most people know that delays are unavoidable, as long as people have the time to deal with them at a relaxed pace then they won’t freak out.

Wrap up

If we go back to the top of the post, I asked “Is it hard to be a good collaborator?” After reading, you’d think “of course not by your standards!” yet I constantly encounter collaborators who don’t communicate promptly, who don’t raise flags until it’s too late, and who miss deadlines without taking the schedules of others into considerations. I can guarantee that if you keep these three habits always improving, people will love working with you, you’ll get more referrals, and you’ll be busy for years to come!

I possess a deep knowledge in many professional fields from creative arts, technology development, to business strategy, having created solutions for Google, Kanye West, Armani, and more. I'm currently Technical Director of zero11zero, and lead the nVoid division. Yo!

View Comments

There are currently no comments.
Next Post