This is not a piece about a specific agency or organisation I have worked for, but rather an amalgam of various experiences I've had in the past, and as such does not represent a criticism of any individual organisation, but rather to highlight a tendency when working with remote teams: a natural human tendency to place problems "over there" rather than here.
You enter an organisation, say in London, as a tech lead to work with a remote team. You enter into your new role with some enthusiasm having recently been inducted into the agency and found a great place for coffee round the corner - they do a killer almond croissant - even if it is a bit pricey.
With some trepidation but also hoping for great things you meet your remote team. The call is over Skype, no video.
Your main impression is the distance, cold digital spaces and that remote PM must have very tough fingernail polish to stand the way she loudly types during your call with the team.
The remote team are barely polite, borderline surly, liable to blame problems on externals, sloppy with their code and constantly circumvent procedure. In short, everyday is a battle.
Some relationships cannot be fixed, but new ones can be forged. When you come in you have a short window to make things new. I encourage you to treat this new relationship like a 3rd or 4th marriage - to spin the cliché: aim for the triumph of hope over experience.
You've been here before, on both sides of the fence. You know what is required by the members of the remote team:
Most programmers wish to do good work, most people want the project they are embarked on to succeed. Your job is to create the environment for that to happen.
I wanted to say a lot about this, instituting new processes and promoting good practice, working agile and being responsive, but in the end this doesn't matter if you can't make 2 & 3 work.
It's embarrassing to have to say this, but: all good relationships are the same - they are based on trust, respect and communication. With remote teams this gets hard as they don't see you, can't go for coffee with you. They get stuck with unrealistic demands and have to invent a narrative that explains the rollercoaster ride when project requirements change and they suddenly have to strap in and start screaming.
Stand ups, informal chats, tech talks, problem solving - be available.
This is a marriage right? It might not work out but you'd be mad not to try.
As a tech lead you have competing demands, trying to get the best outcomes for agency, client and end user all at the same time. This is impossible without your team. It is essential that they understand you are there, as much as possible, for them. They won't believe that you are 'on their side' and you shouldn't be! You should be on the side of the project, but recognising their essential role in delivery is important - too often they are seen as the impediment not the engine.
Allegiance to company can be tricky. Allegiance to outcomes and projects is something that can be understood and discussed clearly and can meet everyone's requirements without clouding issues.
Humour and emotion all translate eventually when you've had some time to build a rapport. Whatever the pressure there is a always some rye amusement to be had from working in organisations - even if it's the humour of the seriously screwed - that is being human.
Without someone to draw all the requirements, users stories, functional and technical specifications, deployment strategies and UX design into a coherent whole projects fail. The ultimate goal is to get to the point where some small portion of this communicates through to team members and they start contributing to the project rather than just ticking off tickets, pushing to get to delivery of a great product rather than just slogging to the end of the week, and the only way to get there? It isn't through money - we all know tremendously well paid but bitter work-to-rule devs - but through building a team that wants to deliver.