Webinar Rundown: Enabling and Empowering Remote Software Engineering Teams

Our panel of engineering managers discussed the art of enabling and empowering remote engineering teams from maintaining a sense of belonging to onboarding new remote engineers.

If you missed the webinar, you can watch it here.

Meet the Speakers

Evelina Vrabie, Engineering Manager at Hopin

Founder, manager and engineer with fourteen years of experience in technology startups. Evelina cares about product development and research for happy users, delivering high-quality software, independent system architectures, creating high-performing teams and increasing workplace happiness. Evelina is 100% keen on remote work and async communication.

Alex West, Head of Tech at Neighbourly

Former technology manager and MVP at Just Eat and Kaluza, Alex has well over 10 years experience leading technology teams. In his most recent role, Alex is working with Award-winning giving platform, Neighbourly, that helps businesses donate volunteer time, money and surplus to local good causes.

Prabhjot Singh, Engineering Manager at Booking.com

Prabhjot has held previous Engineering Leadership positions at Barclays and brings the experience of leading remote teams across multiple organisations. An experienced Software Engineer with a demonstrated history of working in the financial services industry. Skilled in Java, Spring Framework, Javascript, React.JS, Mobile Application Development, PHP, Databases, Scrum & Agile Methodologies, and Apache Kafka.

Key Highlights from the Webinar

Below you’ll find a collection of highlights from the Webinar

How do you maintain a sense of belonging and engagement in a remote team

Evelina answered this one:

First, I’ll share my understanding of belonging. And second, I’ll share the three factors that I find important to create belonging and collaboration.

So my definition of belonging Is one I came across from the biceps framework by Paloma Medina. She defines belonging as a sense of community friendship and closeness within a group. So this culture is an environment where people feel they are cared for, and they have mutual understanding. And that’s a really nice definition. So I guess the question is, how do we create such environments.

Fortunately, I believe that building and growing teams is less art and more science, behavioural science, ethnographic science, system science. So looking at all of these, I found that we need three main ingredients.

One is energy. So we need a high level of energy. And each team needs something that I call ‘seeds’. These are high energy, proactive and charismatic individuals. And they are connectors between team members. They are the kind of people who start conversations with others, they offer the their time to others, either to help them with the problem. We’re just spark ideas, you know, ask intelligent questions about the status quo. So it’s very important when we build teams to ensure that we are these connectors early on.

The second one is engagement, right, the team needs to be engaged with one another. And engagement comes from strong human bonds, and finding purpose in our work and research to the rescue here, and perhaps a bit counterintuitive, I believe role clarity trumps goal clarity in creating engagement. And this means that having clarity of what each team member contributes, and how they are mutually accountable, is more important than having these goals broken down into details.

Having the role clarity and those human bonds in place, engaged teams will bring clarity to their goals, and even change the goal as they discover new information, for example.

And the last one is exploration. So this means that the teams need external exploration and engagement, they need to talk to other team and other individuals so there is a good influx of novelty and knowledge in the teams. And of course, they can do that through all sorts of initiatives like guilds, engineering, tea time, lightning, talks, demos, and more. So yeah, to sum this all up, I think, you know, as leaders, we can increase these three things, energy engagement, and exploration, and will definitely increase the likelihood of building connected teams and with a strong sense of belonging.

What Skills, if any, should you look for when recruiting a new remote Software Engineer?

Prabhjot Singh answers this one:

When we’re looking for engineers, I think we don’t really emphasise whether it’s a remote role or not. I think we’ve tried to build a process where we take away that awkwardness of not being in person to be able to see the body language of the candidate.

Other than that, I think the main thing is to just look for a good Dev, or good tester, a good engineer, someone who’s self motivated, he can bring their experiences, their thought processes to the business, bring something new. Plus be a good cultural fit.

Do people have a collaborative nature? Are they able to work with other teammates? would they be able to share their understandings and knowledge because a lot of what you expect from people who are coming into the industry or coming into your business is to bring something with them, and then teach the rest of the team. So I think that’s what we usually try to emphasise or try to focus a bit more on.

Everyone’s got their way of tackling remote work, some people miss going back to office, some people prefer working from home depends on everyone’s else’s situation. So there is obviously conversation around or discussion around, which is better, I would say, you know, flexibility is better.

So I think in general, you just look for good engineers, or people up to the task up to the rule. Are they good fit, culturally? Do they have technical understanding?

Remote work can often blur the lines between rest and work – as leaders, how do we manage that?

Alex answered this one:

So for me, it’s ensuring that anything I communicate happens within Office Hours, so scheduling emails, making sure you know, Slack goes off at appropriate time. But we also have the the opposite end if either we encourage flexible working. So if somebody does have a dental appointment, they can do that when they need to. So for me, it’s a case of ensuring or allowing the engineers to essentially work the hours that they need to and making sure that they’re explicit in which they are working. So if they are working like six to eight in the morning, taking a midday break, and then working 12 to four or something like that. They’ve told the rest of the team, so they know when to contact them or when not to contact them. Obviously, for slack installation, we’ve got notifications turned off automatically pass fine. Same with an email. So we have that as a job lock. So if you’re still working, we have to actually check is slack in your email. But it means that people don’t get drawn into work, if it’s their time off. And to me that that’s the most important thing is to respect that.

New members of the team, especially Junior Engineers, traditionally learnt a lot through osmosis – how do we maintain that passive absorption of knowledge?

Evelina answered this one:

We have something called an onboarding buddy, which is there for the first two weeks or more, and these buddies are assigned to offer their time, answer questions and allow the new joiners to observe how things work in practice. So for example, our team has recorded several backend and front end onboarding sessions that the new joiners can watch. And the feedback I got from a new joiner on my team is that we have quite a good and effective documentation. But of course, docs get outdated quickly. And so I like saying that, the good way to learn is to teach so I like the new joiners to actually continue to update this documentations because it gives them meaning and mission to learn and relearn how certain things work.

After they’ve been onboarded we use the three amigos pattern. I think if you’re familiar with from from agile is we use it to help refine You work like in identifying dependencies and concerns and edge cases and risk. So we tend to do this, for example, when we have our backlog refinements from from the scrum methodology, which we use, but that’s not, you know, we’re not prescriptive. So different teams have different working patterns. This is what we found useful. So this involves a number of different people, like a developer, Product Manager and they work together to refine and break down some of these complex work that might need input from different, different experts. I think this works really well to enable this collaboration and encourage people to reach out even outside the team.