In my latest contract role, I was managing a core team with a content strategist, community manager and data analyst, and a wider team that included a director of strategy, artworker, designer, copywriter, front end developer, back end developer, UX designers and I’m sure I’ve forgotten someone! It was a great project, lots of moving parts, and very difficult to get bored. One key skill that I’ve just added to my CV is briefing work in.
In previous roles, I was only really working with the core team so there was always an understanding of what tasks needed to happen and why. We were always working so closely together that we knew eachother inside and out. This time around though, only the core team were present for important meetings, and then it was my responsibility to book resources to complete many of the tasks needed. Working with senior colleagues was easy – they’d done this a thousand times and knew how to read between the lines for a brief that was generously worded. The challenge was working with juniors, who are great at what they do but sometimes reluctant to ask questions or not sure how to point out that an instruction might be ambiguous.
So here’s what I have learned:
- A brief is just that, brief. Keep specifications clear and concise. I like to lay mine out in bullet points or numbered lists. Say how many things are needed, precisely what format the output should be, what the deadline is, maybe how it will be used, and some examples of what it is you’re after. “Do this, not that” is helpful. Write a brief so that literally anyone could follow it. Most companies should have a template already.
- Set up a folder with all documents and relevant reading. Include a style guide (if it exists), templates for slideshows or documents, perhaps one or two previous examples of what you are looking for. Send the folder to the maker and make sure they can open it.
- Check in with the maker before and during the task to make sure they understand what they are doing. There are few things more frustrating than getting to the end of the task only to find out they didn’t really understand a key instruction. It’s demotivating to them and frustrating to you. Often I’ll just ask if I can check in with them if they’re not in mid-flow.
- Let them know what the client thought of their work once you’ve handed it in. Few makers get to speak to clients, so it’s always helpful to give constructive feedback. It helps long term that team members know you always have their back.