How to Motivate and Manage a Remote Software Engineering Team

It's always a challenge keeping a team of Software Engineers motivated. But if you want to bring that big project in on time, motivated is what your developers and programmers have to be. So how do you do it? How do you motivate a software engineering team? 

We reached out to Software Engineering Managers to discuss how they keep their teams on track and motivated to deliver their best possible work.  

 

Mate Varga, Vice President of Engineering at Patients Know Best 

Mate Varga is the Vice President of Engineering at electronic personal health records company, Patients Know Best. With a rapidly growing Engineering team spread across a distributed geography, PKB has been working with organisations such as the NHS since 2008. Given the growth and complexity of the engineering projects PKB are working on, Mate has made the wellbeing of his engineering team a top priority.  

Before the Pandemic, Mate used to meet his team – which is distributed across Europe – in person at least once every other week. For Mate, this interaction was important and is something that – during travel restrictions – his team misses.  

“Remote Developers interact mostly through code. It’s easy to forget that there is a person behind that code.” 

Working in healthcare technology, Mate and his team must adhere to strict regulation and, as a rule, must peer review any code before it goes into production. This can create difficult situations where members of the team are looking for problems in each other's code.  

Mate has been working hard on creating a working environment and culture that encourages and motivates his Engineers.   

 

Measure Outcomes, Not Proxy Signals.  

How you measure a team sets how a team behaves and how well it performs. A team will naturally optimise themselves around achieving the targets they set.  

Too often, teams will focus on tracking the number of tickets handled or time spent in the office and not the results in terms of satisfied customers, retention of key clients, or profitability. Not only does this produce skewed performance measures but it also breeds a finger-pointing culture.  

For Mate, addressing the way his team is measured was key to motivating his engineers – especially when working remotely.  

“ The real achievement of a Software Developer is to solve customers' problems. It’s often convenient to simply look at the developer's screen and see how much time they spent on their computer instead of focusing on how they really contributed to business outcomes. 

 When you move to managing a remote team, you lose the ability to measure in that way.” 

Rather than measuring on an entirely granular scale, Mate ties the measurement of his team to the greater context of the company mission.  

The skill of evaluating actual business impact instead of ‘busy work’ is extremely valuable even when teams return to the office. 

 

Handling Conflict In Remote Teams 

It is impossible to avoid conflict in the workplace. But managing it gets very tricky when you take team members out of the office. Add that to the strain of staying productive during a pandemic, and you’ve got a recipe for potential disaster. One wrongly phrased Slack message could be all it takes to turn a team meeting into a virtual brawl. Without the option of a face to face reconciliation, how can you manage conflict in virtual teams? 

Rule one in the conflict resolution rulebook is usually to handle it face-to-face. Without that option, newly remote managers can sometimes feel like they’re on an up-hill struggle when it comes to keeping the peace. For Mate’s team, who regularly peer review each other's code, handling conflict starts with following a few simple rules to ensure everyone is treated with respect.  

The first and most important rule is that reviewers need to prioritise their feedback, highest value first: functional correctness, then code quality, then test coverage, then code style. If the reviewer does not have the time or focus to evaluate the most important aspects, they should not comment on the less important ones. This is the most useful and respectful way of approaching other people's work. 

Secondly, to make up for the fact that they’re missing out on the queues that body language can give us during a conversation, Mate believes it’s important to indicate your intention when raising potentially controversial topics: sometimes you are strongly suggesting something, sometimes you are just "thinking out loud" in writing. 

Thirdly, if in doubt, pick up the phone. 

 

Early and Challenging Projects Will Build Confidence 

For Mate, the baseline that every engineering team should have is clear documentation on their coding standards and about how to get started. This enables a new starter or a newly qualified remote engineer to hit the ground running and get stuck into projects quickly.  

“We’ve seen people make code changes just five hours after they’ve joined because we’ve streamlined our documentation and provisioning of the development environment.” 

Giving new engineers projects that they can make an immediate impact on is key to motivating them and keeping them engaged. It gives them something to celebrate early and can help ramp up their confidence as they progress through projects.  

Handing over challenging tasks to new hires in their first few weeks may sound like throwing them in the deep end, but it can be an important step in helping engineers succeed. Even if they struggle, you and your team will see how they react to that. Do they look for support? If not, it’s a teaching moment that will ensure the new hire knows where their support networks are.  

For Mate, doing the opposite and giving your new engineering hires tasks that are below their skill level will do more harm than good. 

"Some of the worst outcomes I've seen, they were mostly associated with giving people tasks that are far too easy.” 

 

Kevin Marzec, Head of Software Development at TRI - Triumph Research Intelligence, The Risk-Based Monitoring Company 

Kevin Marzec is Head of Software Development at Triumph Research Intelligence. Joining his first start-up in 1998, Kevin grew that development team to 25 before the dotcom bubble burst, taking the start-up with it. From there, Kevin has been running development teams ever since.  

With over 15 years of experience in Software, we were keen to discuss with Kevin his thoughts on leading development teams and what his thoughts are on how we can best motivate them.  

 

It’s not all about the Money 

For Kevin, the key to motivating developers, especially at the highest level, isn’t always about money.  

“Working on fun and challenging projects that involve bits they need to figure out while bringing them into the architecture is key. Basically, they don’t want to feel like cogs in the machine.” 

It’s a sales maxim that believing in the value of your product or service is essential. Logic dictates you should believe in what you sell. If you didn’t, sales would become a process of unethical manipulation in which you convinced customers to make decisions they would regret later. 

Zig Ziglar, the most famous salesperson and sales trainer of all time, took confidence in your product a step farther when he said, “If you believe your product or service can fulfill a true need, it’s your moral obligation to sell it.”. 

Kevin believes the same applies to developers building products.  

“I think they have to believe in the product they're building. That's probably the number one thing: they have to be excited about what they're building. They should want to make it the best possible product they can.” 

 

Avoid Silos Within Your Team 

Most of Kevin’s experience leading technical teams comes in a distributed context with many of the start-ups he’s worked for drawing talent from a variety of backgrounds. In his current position, Kevin works within a completely remote company with 45 staff.  

We were keen to get Kevin’s thoughts on leading distributed teams and what leaders can do to continue to motivate and encourage team members who may be working in unfamiliar conditions.  

“I think regular communication is key.” 

Kevin has regular one on ones with each member of the development team as well as daily stand ups where we're all chatting - which can generally last up to an hour and gives everyone a chance to talk about their days, challenges and more. Kevin and his team also do group code reviews where everyone pushes through their developments for discussion. 

“It's kind of like a competition. Everybody's like: I want to be pushing through as much as possible.” 

This plays into a larger strategy that Kevin believes is key to running a remote development team effectively.  

“You want to avoid developing silos within your team where developers feel ownership of certain parts of a product. It can lead to an atmosphere where people are hesitant to touch other people’s work and create a bit of a finger-pointing culture.” 

Having an open team culture where everyone understands the objectives of the business and how their work fits into the bigger team picture will help break down these silos and avoid the challenges Kevin has experienced in the past with previous teams.  

Ben Toynton

Senior Consultant & Team Lead

View Profile