Year One – part two – Work

This is continuation of part one, a series of posts summarising what I have learnt from my first year of freelancing, in the hope that my experiences will help others considering something similar. This post discusses what I’ve actually worked on this year. It’s a bit of a lengthy one, so grab a cup of tea.

Work and play they’re never ok to mix the way we do

Work, on the whole, was good this year. The start of the year was slow, intentionally, but not actually as slow as I’d wanted. I had intended to take at least January totally off from this crazy web world, to read books, go indoor skiing whenever I wanted, and generally enjoy life away from screens. What happened was that I found that a lot of my enjoyment comes from being in front of screens. I did manage to go skiing, both in Hemel Hempstead and Austria, but I also sat and learnt codey things that I hadn’t had time to do the previous year, which baffled my family and friends as to why I would find that enjoyable. I started picking up little bits of work after a while and slowly that turned into doing more, and since March I’ve worked mainly with some agencies and one company directly, solidly apart from holidays and conferences. I actually wish I’d made more time for investing in personal projects, but the nature of the contracts meant that there wasn’t room for this. It’s definitely something that I want to do more of next year.

What kind of things?

The type of work I’ve done has varied hugely. I’ve deliberately taken opportunities that have helped me learn new things, and every contract I’ve had has involved a lot of personal growth, which has been great. I’ve made sure to do a mini review at the end of each engagement, listing to myself what I’ve learnt, what I’ve enjoyed, and what I haven’t, and this has really helped me to focus.

I’ve worked with more of a UX focused role, I’ve been an analyst and technical consultant, I’ve been a product manager, and I’ve done some prototyping and development work. The work I preferred the most was definitely the analyst/consulting bits, but the thing for me is that everywhere has been massively different, and it has been really good for me to see those differences. It’s been fascinating to see how different people treat my kind of role, and how they sell it and integrate it into their offering.

I haven’t always felt able to talk about on-going work, but this is something I want to do more of, and will work with companies to see if this is possible.

Challenging perception

One of the things that has stood out the most, is how different places can challenge what you think you know. My background is heavily web builds, and I’m firmly in the RESPONSIVE GOOD, POINTLESS APPS BAD camp, however that was challenged on the very first day of my current contract. Working on video on demand projects has meant that things I normally take for granted go out the window, simply because the platforms and technologies still have severe limitations. I’m working on a project for a particular broadcaster which was set up to be a responsive web build with a Flash player from a major video service on desktop, with apps using the same codebase except players that use native SDKs, packaged using Cordova. It was decided that if a mobile user attempted to browse the site, they would get an immediate intentional door slam telling them to download the app, and explaining why. Certain things had fed into this – because the app was using the same code as the site for listings etc, it would likely be refused by Apple if both the website and the app had exactly the same format. It was also assessed that it would provide more frustration with the user being kicked out to download the app at the point of playback rather than having the situation explained up front. There are however issues with things like sharing when apps get brought into the mix. I still don’t necessarily ‘agree’ with it, and I think we should be doing a lot more to try to overcome these limitations instead of working inside them automatically but it’s interesting to see how different industries sometimes have to work within different constraints that might not always apply.

So… wait… what exactly do you do? WHAT IS YOUR JOB?

The single biggest thing that I’ve found in terms of my role this year is that nobody gets what I do unless I attempt to explain it in person (and even then sometimes don’t), and nobody has a job title for what I do. Quite simply, I provide technical consultancy and discovery services for web-based projects.

I touched on the problems in a post earlier this year, where** **I wrote about the problems of searching for work in this crazy sea of meaningless job titles as a response to Chris Coyier’s blog post.

I know what I’m good at, and what I enjoy doing. I know how that fits in with other people. The problem is that this isn’t an established role with a shiny label around it that people go “oh yeah, you’re a X!”. I’m not an easily packaged “developer” or “designer”.

Because of a recent conversation I am in the process of totally redeveloping my site at the moment, from the content up. It’s not enough for me to know what I do – I need people to easily understand how that could help them without me having to meet them and jabber on. I’m stuck in the inevitable design ‘challenge’ phase where it’s all built and written but looks moderately like a small child has thrown things at a browser, but it’ll launch soon regardless. So come back soon if you still don’t understand, because I’m not about to duplicate all of my new content here!

Enjoyment

The most important realisation for me this year was that my enjoyment of the type of tasks I’m doing is hugely impacted by the scope and subject matter of the project. Back at Lightmaker, I used to absolutely love doing absolutely anything for Electronic Arts, right down to putting together a matrix of all of the translations for the site, or painstakingly tagging pages for SiteCatalyst. Even the grunt work was enjoyable, because I was working in a field that I had an interest in. Working on the Mass Effect sites is still something I’m so excited to have done and I would absolutely love to do something similar again one day. I definitely want to do more working on things I love, and for companies directly next year. The nature of what I do, and my background to date has meant that it’s definitely easier for me (at least mentally) to approach agencies and find work with them rather than contacting companies as a one-man-band, however next year I’m going to throw out the net to industries that excite me, and see what comes back. So hey, if you’re a games, music, travel or nerdy toy company (hey Lego), let me know if you need some help! Likewise, I’d really appreciate any advice from people who aren’t part of a collective who provide individual services directly to businesses.

In terms of the above, as much as you hear people saying that we’re lucky because as freelancers we have the luxury of picking what we want to do, this is only true up to a point. Outside of whether you need to take work for financial reasons etc, no matter what you think you may get out of a job and how much you try to cherry pick, the reality has been for me that I’m there because people have an overflow, and need you to do things that fit their gaps. You may sometimes be brought in for a nice juicy steak of a project, but sometimes you’ll be there to sweep up the scraps that nobody else wants to touch. You might be overrun with work, or sitting around and waiting. Stick with it, and even when it can be rubbish remember what you wanted to get out of it in the first place.

Confidence

My self confidence is always liable to plummet on any given bad day, but overall I’ve done a lot to build it up this year. This is really important, because you will likely get the fear towards the end of a contract that you’ll never find another one, and you’ll also have to keep going into new places to be judged. You will be judged, it’s the nature of things. People are bringing you in to do a particular job, and you’ll be under scrutiny constantly. You’ll likely be earning more than people who do the same job as you, and you’ll need to not only show that their decision to bring you on board was justified, but that they may want to contract you in future.

And so back to my intention to pursuing more particular industries next year. Whether or not this happens remains to be seen, but this is also tied to confidence. If you’re not good with rejection, then you can spend a lot of time questioning yourself. Luckily with life in general I’ve become pretty hardened to not being wanted over the years, and am pretty brazen in asking if someone wants to work with me. Both at the start of the year and at the end of my last major contract I sent a lot of speculative messages. Here’s the thing – everyone’s usually perfectly nice, but they may not be looking for contractors, or your role, or may just not reply. You will worry about becoming that person that you know is annoying to be on the other side of, the one who turns up in inboxes uninvited, but if you don’t ask, you don’t get. Be polite, explain why you’re getting in touch, and if they don’t need you then so be it.

Analysis

I wanted to use this year as data to base my Year Two on. I wanted to see whether people wanted my skills, how much I would be earning, whether work is regular, and whether I enjoy it. I’m still not sure about long term – I feel that I’m still quite niche – there are only so many places that are prepared to spend money on (or offer as a service) technical analysis and discovery activities, although there are some great agencies out there branching out from solely offering UX consultancy, into a place where they augment that with research into the realities. I personally think that it lends credibility to do some early technical research. It helps inform propositions and dependencies, and means that you can really get to know the realities of a project. This doesn’t need to be used as a negative; far from it. It helps show that you’ve thought concepts through as a really well-rounded piece, and that you aren’t just wishy washy “blue sky thinking” dream merchants.

Something that has cropped up a few times is that people don’t necessarily want contractors for this kind of role. It’s not cost-efficient over a longer term, plus with client contact and project vision being so key to it, you want those people to stick around. Some advice I was given, after being offered a great job, was that you need to really know what you want. If you’re not interested in a job and want to stay contracting, make that very clear, to yourself as much as anyone else.

Process

Everywhere I’ve been this year has followed a totally different process, which I absolutely love. I’ve worked on pure agile projects with no design/UX front-loading at all, I’ve been in war rooms, I’ve been in a heavy waterfall project, and have worked my way through a huge amount of post-its. Everyone is different. One experience that I have really enjoyed is a company who use Google Apps for everything. I switched over to my new Mac, and never bothered to install Office or any alternatives. This obviously won’t work for everyone, but I love it. The collaboration and visibility which naturally comes from doing absolutely everything through Google Docs is great, and I think it helps to make documents less of a set-in-stone artefact.

I enjoy it when the scope of a project is more than a document. This year I’ve found that the most effective Scope of Work ‘documents’ are in fact a set of multiple resources – a combination of wireframes, design direction, technical approach notes, and a collection of epics/user stories that can be refined, rather than a single, static document. This requires the right client, and for the process to be explained, but I feel that this produces better relationships and better output.

In terms of technical documentation, I’ve done a lot of research on this front throughout the year. From the start of projects, even before contracts are signed, I’ll often be picking up useful information or making decisions which need to be documented. As the project goes on there are again important annotations that need to be made throughout design and build. This information needs to be fed into the project, and I’ve been looking at the best way to do so. I’m currently doing a lot with GitHub wikis and seeing how they can be applied to different types of projects. The above is a post or a talk in itself, so I’ll come back to you later on this one.

Technologies

Here’s a list of things I’ve enjoyed spending some time looking into this year because various people have used them and I like knowing more about everyone’s stack.

Python, Node.js, Grunt, CI (Jenkins specifically), Handlebars, Moustache, Ruby/Rails, Jekyll.

I’ve gained no more than an overview of each at best (plus some shiny CodeAcademy badges), but I always prefer to have at least a basic grasp on things that I’m working with people on, even if I’m not actually using them myself.

Other places have used .NET/PHP and Sitecore/Wordpress/Drupal, and done things that I have historically had more exposure to. Again, the different processes and workflows employed, matched against different technology sets has been particularly interesting.

It has been great working with people who have taken tools and have really pushed them creatively, using them for things they may not necessarily have been intended for, but which work really well.

Having had some interesting experiences in that area, I have always felt that a server-side language needs a strong CMS offering to sit alongside it to really help drive the popularity. I don’t typically believe in bespoke offerings, even though I spent a large amount of my career working on one. I think this is still true to an extent, but it’s been nice to work on things which haven’t relied on your ‘standard’ CMS roll-out every time, and which need simple management tools for very particular tasks. These don’t necessarily require the classic CMS frameworks that a lot of people run to, and can show when a more bespoke or lightweight system can be much more useful.

I’ve become a lot more interested in the front-end side of things, which I think has been down to the sheer amount of stuff going on in that space in the last few years. That’s been really nice, and whilst my front-end work still isn’t nearly up to scratch, it’s been a hell of a lot of fun messing around along the way.

Up next…

The next post is on the more personal side of things; the bits that apply when you’re not ‘at work’. It’s around the support that I’ve had and needed, as well as thoughts on travelling for work.