Published on Friday, 5 May, 2017
As the years go on and technology becomes ever more entrenched in our day-to-day lives, many (including myself) are looking to use it to remove the necessity of our in-person physical form in the working world, at least some of the time.
Using technology to communicate and work remotely can remove the burden of commutes, better support home lives, and even facilitate people working together who otherwise wouldn’t be able to. Living in rural East Anglia this is something I’m a big fan of. I spend a lot of my time travelling to clients, but technology means that I can also join daily stand-ups or planning meetings without having to waste a day on travel, as well as being able to regularly work and chat with people who are the other side of the country.
I’m not alone. Many companies are embracing this more and more, with Automattic (behind WordPress), inVision, GitHub and many others offering remote options or being exclusively distributed. Year on year, remote working is shown to be on the increase in countries like the US and the UK, but it’s not just remote workers where teams are looking to flex.
Going hand-in-hand with this is a change of mentality from companies about how they approach their digital work. Recent years have included oft-cited shifts to in-house teams, where companies have either bought agencies or started to build their own teams rather than relying exclusively on outside help.
This is something that I’ve experienced first-hand with clients. More and more I see people wanting to understand and learn about the web rather than leaving it as a black box that’s best left to others. Teaching through workshops, on-going coaching relationships, and using projects as a contextual means to transfer skills is something that Records Sound the Same and others like We Are AFK are seeing as ever-important.
But what does it mean if you’re a company who wants to start helping their team work remotely, or wants to start blending an internal team with outside help? This is something that I’ve worked on with clients over the last couple of years, with a couple of notable examples:
One, an international commerce company, already had a small UK in-house back-end development team and print designers, but looked to others for UX, UI, front-end, and other web-specific resource. Based in a rural location, they had good links with a university but often struggled to hire and retain people when the nearby big city lights were shining.
Another big name used to have a digital team run by IT, but this didn’t keep up to date with trends, wasn’t felt to be successful, and eventually disbanded. Several years later, and with the creation of a different structure and principles, they started to think about giving in-house resource another go.
Both wanted the ability to have in-house team members, plus use freelancers/contractors (who may be co-located or remote) for specialist areas, as well as working with web agencies as and when needed. The ability to ramp up and ramp down to help variable demand levels, and to react to different project needs were both important. My role in both of these cases was to provide advice, hiring support, and to outline the strategy.
Both facilitating better remote working for your existing team, and building a new team that works effectively alongside other external partners have some common ground. In these cases there are some really important considerations that need thinking about, some of which I’ve captured here in case you’re in a similar situation. With both of these scenarios you’ll need to lay some groundwork for it to work well, so start this sooner rather than later!
For many, the starting point is to define what roles are needed, or gaps should be filled internally or externally. This is a really important step, and will start to define how you set out on this adventure, but always keep in mind that your needs will change as time and technology moves on. You may also want certain people in place before you bring in others, or hiring an individual will spark different views on other roles. Defining the roles you want is just the beginning.
Say your company decides that they want to hire an in-house User Experience professional:
Not only will you need to define and hire the right people, but you may realise that there’s a need to support them with things like planning and delivery functions, or strategic management. You’ll need a way to define the overall say on priorities, accountability to the wider organisation, and higher-level involvement as well as being able to identify where the overlaps are with existing functions, and to set out the approach for how these will work. Setting out to hire one person may actually mean that you end up hiring a few more.
Maybe you start trying to hire, but you can’t find people that match quite what you were looking for. Are you asking for the right things? Are you wording your job descriptions to be overly specific, or to unintentionally reduce diversity? Know your priorities, and think about what you’re prepared to compromise on. Maybe they can learn skills on the job, or you can stretch that extra £10k for someone special. Perhaps they can be a remote hire rather than always being in your office.
However, it may be that you ideally want a particular role or type of person to be in-house eventually, but you could use web agencies or external people to tide you over, or to help you set the initial strategy and direction so that the team can hit the ground running (we’ve been doing this exact thing, offering CTO/CDO roles as a service and working with people like the RNLI on an ongoing basis).
Once you’ve identified the makeup of your dream team, now you need to make sure that everything else is set up to support them as best as possible. This is where there starts to be even more to think about. If you’ve only ever previously used external help but now want to combine that with some in-house resource, or if you have a team but want to be able to compliment it with agencies, freelancers, or remote working, your processes are going to be changing.
With different parties in play, you’re going to need to think about having some central view of tasks and resource planning giving visibility to all. How will this fit with your agencies’ task management? How will you address the management of scope between parties, decision making, and the method and frequency of communication? Does what’s proposed work for everyone? Get round the (virtual) table and find out what everyone thinks. Having agreed standards, processes, and documentation in place will aid communication by making it as easy as possible for people to speak the same language, and providing points of reference during the tricky early days.
Does everyone on a team know what everyone else does, and how they should be working together? When teams become a lot more fluid, and people are no longer sat with the same familiar faces, these things can easily become overlooked. Outside of kicking off your projects well, using tools like a skills matrix for visibility, sharing contact options and work schedules between the team can all help.
Are there some combinations that won’t work? Does your agency refuse to work on projects where your in-house team has worked on their code? Do your freelancers only want to do the development if they’ve also worked on the design? What happens if something breaks - how will you resolve disagreements over responsibility?
One really important point is that if you’re working with agencies now, they may be unhappy if you start talking about creating your own team, or working with others. That’s understandable! If you’ve built up a relationship, it’s hard to hear that someone may want to do something different. It’s really important to involve your existing partners in these discussions to identify what would and wouldn’t work for them, and why you’re looking to do something a little bit different. Perhaps you want to keep using your agency for all of your public website work, but want an internal team to help with your digital transformation more broadly, and to create private tools. Maybe you’re bringing in specialists in another technology to help with another project, but there’ll need to be crossovers. There are many reasons why your team may start to change its shape, but working alongside existing partners is really important.
Isolation can hurt both the team, and team members. If you’re setting up something new, make sure that you work on relationships with other areas of the organisation just as much as with each other. Don’t foster a mentality that if people aren’t there, they’re not seen as part of the team.
To make some of these things a bit easier, it’s also worth looking at some more technical areas too.
There’s a reason that standards exist in every aspect of life, and making sure that they’re at the heart of your workflow will make your life a lot easier. Everything from your approaches to naming variables, to your approaches to choosing technology, and what you expect in terms of accessibility, performance, and testing will be important to get agreement on between team members. What happens if something comes along that’s better, or if someone wants to change the standards? Establishing a way for everyone to align preferences is key.
Quite often you’ll find that repositories for code, tools, or licences can be set up and owned by agencies or freelancers. It’s worth checking who’s looking after any really crucial bits of your infrastructure anyway, but if you’re looking to transition to more of a fluid team with an in-house core, some of these may need to change hands.
This may impact on things like agreements around code ownership, or even contractual agreements around payment - your agencies or freelancers may not typically deliver some things unless they’ve been paid, which may go against regularly pushing to a repository that they’re not in charge of. More technically, it’s worth everyone getting together and making sure that things like the process around version control (e.g. how/when to branch/merge/name things etc) should be defined as part of your standards, if you haven’t set these out already.
Is your documentation kept in a system that everyone can access, not just those with internal logins? Are you making your IT team thoroughly upset with all this talk of using unapproved channels like Slack, or Google Docs? Best to find out what is and isn’t possible sooner rather than later.
If you’ve got your processes and standards (and automation) in hand then hopefully your testing and deployment is all sorted, but with any changes it’s always good to check that everyone’s on the same page. Is everything going to run as expected if a different team works on something? What happens if things start to fail? What happens if the internal team cause a problem for work that an external party is trying to do? Is your deployment schedule going to be messed up because someone’s holding it up?
If you all work with Macs internally, are you assuming that everyone else will? When you talk about how everyone doesn’t need to be there because you can video chat, how does this work for people on terrible internet connections? Are those premium-rate-from-mobile services you signed up to going to work for people without landlines, or in different countries? Flexibility around teams means supporting much wider variance in situations, so make sure that you’re considering the situations of the people on your team now, and what may come in the future.
Whenever change occurs - whether it’s trying to build something new internally or changing an existing dynamic, mistakes will be made and there will be rough patches. These should be learnt from rather than being kept tabs on and used against the new team. At the start you’ll also need the right mix of people - too many with different ideas who all want to do things in conflicting ways won’t work, and likewise neither will a team without any sense of direction or leadership.
Hopefully the above points will give you some food for thought if this is something that you’ve been pondering, and if so – good luck! If you’ve already switched to more flexible teams, what were the things you wish you’d thought of at the time? – get in touch and let me know.
Back in time:
Capturing the message
Forward in time:
Rebranding and rebuilding
Sally is a the lead consultant and founder of Records Sound the Same, helping people with digital transformation. She's also a speaker, coder, gamer, author, and jasmine tea fiend.