How to be a good co-worker
Transitioning to a new team inevitably involves learning new methods and processes – as well as getting used to the personalities of your co-workers, and where you fit in the pecking order! My first two weeks as a Junior Front-end Developer at Mud have been fun, interesting and very challenging at times. So I thought I’d share some of my observations, as well as lessons learnt from some of the previous teams I’ve been involved with.
Be nice to the newb
Every workplace has a different dynamic, and different processes and procedures to get used to. Front-end teams in particular are (necessarily) very process-driven, and on the first day at a new job it’s easy to feel overwhelmed with all the new things to learn. I joined the Mud team from a previous position as an in-house designer, where my job involved designing for both web and print. Although I was used to designing in HTML and CSS, I knew there would be lots of new stuff to get to grips with as I transitioned to a more technical role in an agency environment. I often had to remind myself that I wasn’t expected to know it all by the end of my first day, and that I could always ask my colleagues for help.
Empathy and patience from your co-workers are vital for making any new hire feel welcome, and luckily my new colleagues have been understanding and helpful as I’ve settled in. Allowing a new team member to learn at their own pace, without imposing immediate deadlines, helps them feel relaxed and able to take in more information – trying to take everything on board while simultaneously feeling stressed is unhelpful for everyone.
If you are the newb...watch and learn
When joining a new team, taking notes is useful (particularly of repetitive procedures – so you don’t have to keep asking your colleagues), but with so much information to take in, the best way is often to learn by doing – and by watching other developers. Important too is knowing when to ask for help and when to spend the time figuring something out for yourself. It’s a balance between saving time or ultimately learning more by working it out – and trying not to annoy your busy co-workers with constant questions!
Processes and procedures will largely be dictated by the type of team you’re working with. In my previous job, being the only in-house designer meant I could largely formulate my own processes. The downside was that often my colleagues had less understanding of my working schedule, and how long project tasks might take. I found that documenting and sharing my work schedule helped a lot with that, allowing colleagues to see my backlog of work and deadlines during busy periods so that they could make decisions about what they wanted me to prioritise.
At Mud there are different ways of tracking projects and which people are contributing to them. Most days start with a quick meeting to check what everyone’s doing for the day and flag up any impending milestones. There is nearly always more than one person working on a project at any one time, so clear channels of communication are vital.
Use your tools
When working with remote teams (as I often was in my previous role), communication and documentation become even more important. Here are some of the tools that may be useful to keep you all on track:
This is great for quick chats or message, especially when you either can’t be in the same room as your colleagues, or don’t want to disturb others. You can also share files quickly and easily.
Pretty darn useful for version control, and absolutely vital if you have more than one person pushing code!
A great tool for giving feedback on design and front-end work. You can upload a screenshot, add comments and mark when completed, which was far more effective than logging a huge list of issues in a spreadsheet. In addition, you can create interactive prototypes and a lot more.
At Mud we use Teamwork to keep track of projects, but there are tonnes of other project management tools out there that do similar things, so you can pick whichever one works for you. I find it very useful to make lists of any tasks I need to work on within a project, even if they’re just minor tweaks.
Whatever the size of your team, some sort of front-end automation will save bucketloads of time. Gulp is the Mud tool of choice.
Useful for tracking the time spent on various projects when you have lots on the go.
Pretty much all our team documentation in my previous job was in Google Drive, which is an easy way of sharing between teams. Sometimes a good, old-fashioned spreadsheet is all you really need.
In the words of Coldplay: Let’s Talk*^
...but don’t just use tools.
Fostering a culture of communication is just as important, and there’s no substitute for face-to-face time. Taking conversations offline and getting to know each other in real life helps keep everyone happy – while emails and brief messages can often be misread (especially in stressful situations), and while you could spend all morning trying to phrase something in an email, a quick chat could get to the root of the issue straight away.
In remote teams this takes a bit more work but, whether you schedule Skype meetings a few times a week, jump onto calls as and when needed, or all get together face-to-face for a big blowout once in a while, good personal relationships often make for better working relationships.
That said, no one wants to sit in meetings for hours when there are plenty more pressing things you could be doing! Keep meetings short and to-the-point, with the aim of setting clear objectives, and your colleagues will thank you for it.
In conclusion, a good working culture will not only attract the best employees, but will help you hang onto your valuable existing ones. And with so many tools at our fingertips, it’s arguably never been easier. But it’s not just about management – everyone can play a part in making a great team!
*There are probably far better musical references I could’ve used here.
^ Coldplay reference used without permission of Mud CD
p.s. don't forget Mud are still on the hunt for a mid-senior web designer - check out the details here