Improve Team Performance and Turn Around Underachieving Engineering Teams

Improve Team Performance and Turn Around Underachieving Engineering Teams - Interview with John Ford (VP of Engineering at LogMeIn)

How to improve team performance in software engineering?

This is the question every engineering leader wants to know.

It’s especially important when you take over an underachieving team. How do you turn it around? How do you improve engineering productivity?

This post details the strategy and framework used and developed by John Ford. He’s currently VP of Engineering and site leader of the Budapest office of LogMeIn with decades of experience in engineering leadership. Here, he is interviewed by Karolina Toth on episode 35 of the Level-Up Engineering podcast.

This blog post covers:

• Assessing the performance of your engineering team
  • Build a comprehensive perspective
  • Analyze the data
  • Diversity is beneficial
• Velocity goals for high-performing engineering teams
  1. Developing new features
  2. Maintenance
  3. Security
  4. Support and knowledge transfer
• Focus points for underperforming engineering teams
  • Key areas
  • Metaphor for a perfect engineering team
• People
  1. Assess performance
     1. Backlog
     2. Attitude and relationships
  2. Do your part
  3. Let them work
• Processes: streamline
  • Useful processes
  • Criteria to streamline
• Technology: keep it simple
  • Re-use existing components
• Story about turning around an underachieving engineering team
• Bonus advice
  • Taking over a team
  • Keep an open mind
• About John Ford

Assessing the performance of your engineering team

Build a comprehensive perspective

There tend to be many opinions out there about an engineering team. You need to get a comprehensive perspective. Make sure you understand the context, talk to stakeholders outside the team, and examine the team’s background, especially when you're inheriting a team from a previous manager.

The obvious part is that you need to talk to the people on the team. Make sure to take what they say in context. For example, team leaders are likely to defend their people.

Analyze the data

I prefer to look at data to understand the team’s performance. Appraisal ratings of team members and attrition numbers over the previous six months tell you a lot about the team. Velocity of delivery and generated value can be useful data to measure engineering productivity.

This helps you figure out whether they’re working on the right things. A team may be pushed in one direction to the detriment of other priorities.

Diversity is beneficial

Diversity isn’t just about gender or race, but different types of people. A team full of people with a similar way of thinking don’t necessarily get everything done in the best way or generate the debates that produce a team’s most effective work. It’s great to have different people like a sociable person, a person who stands up and tells you what the issues are, a detail-obsessed person, a person with new ideas, or a person who delivers no matter what.

Different personalities can cause tensions within a team, but they also lead to great results if they’re managed well.

Velocity goals for a high-performing engineering team

You can’t define generalized velocity goals. I focus on the allocation of effort across the team instead. There are four main areas every software engineering team has to work on all the time:

1. Delivering new features

This is the obvious one that developers are hired for. Features can be functional and aimed at customers, or they can be technical improvements, invisible to the users but equally important. Engineering teams get to spend about 50-60% of their time on new features overall, which is less than most people want to admit.

2. Maintenance

Often, especially in a DevOps world, engineers are also responsible for the ultimate resolution of support issues that come out as production incidents for customers. The number of issues, and therefore the size of the maintenance overhead, will rise if you allow too much technical debt to build up.

Technical debt is not necessarily bad, you incur it as time goes on; it’s inevitable, like getting old. You may cause it on purpose by cutting corners to launch quickly. It also builds up naturally because technology changes over time, as a 10-15 years old solid codebase will have issues due to other tech changing around it.

Tech debt is often neglected because the business doesn’t want to allocate resources to clean up the code. They want to build features to benefit the customers and to increase sales. It’s not obvious, but tech debt makes the support burden go up, causing extra expenses, and it can even become crippling to a product in extreme cases.

My rule of thumb is to spend 20% of your time paying down tech debt. This benchmark comes from lean thinking. The principle is that the activities involved in improving your work are more important than the work itself.

3. Security

Security is another aspect often neglected because stakeholders don’t directly see a benefit from it. You may be chasing ISO 27,001 Compliance or other certifications, but security is essential in a world where everybody is working remotely. My teams work on security with a 5% baseline time allocation, which may go up to 7-10% periodically.

4. Support and knowledge transfer

Because engineers know the code and the system best, we are often the “last line” for supporting customers. I also put training activities, knowledge sharing and onboarding engineers in the same bucket with support. The time spent on this can vary from 15-30%.

Focus points for underperforming engineering teams

The metaphor for the perfect engineering team

My vision of a well-performing team is that it’s like a well-oiled machine that can go fast and slow as well. I love motorcycles; beside other bikes, I own a Ducati Monster 821. It can go very fast, but it can also go extremely slow.

An engineering machine should be like that too: be able to go fast for short periods, be reliable, not break down, not need much maintenance, etc. The leader should set the pace, and the team should do everything necessary, even if some of them are invisible.

Key areas

When I find that an engineering team is not performing, I break up the issue into three areas. In order of importance, they are:

1. People
2. Processes
3. Technology

People: Assess performance

The sky's the limit with motivated, talented, engaged, capable people working well together. But a team that isn’t engaged lacks expertise, or if it has lots of infighting, it will unavoidably underperform. The leader needs to identify the root problems.

People may have been hired for the wrong role or with the wrong skill set. When the problem is with the people, you can usually solve it by getting a few people off the team. The rest of the team will often thank you for this, because they tend to know who caused issues.

At one time, I took over a badly underperforming team and fired two people out of 10 fairly quickly. This started an upward spiral before changing anything else.

This is what I look at when probing team members:

1. Backlog

Take a look at the work they've done, the work they haven't done, and what’s in their backlog. You get to see how easy or hard the tasks are that they’ve been working on, and you get an idea about how productive they are.

2. Attitude and relationships

Talk to each team member to get a feel for their attitudes. People acting like they know everything is a red flag. No one knows everything, and this kind of arrogance can hurt the team.

It’s also worth looking at their relationships with stakeholders. This helps you figure out if a person is a good colleague, or if they aren’t great at human interactions.

People: Do your part

Engagement

Engagement is an essential aspect where engineering leadership plays a huge role. You need open, honest, transparent communication. Even if you can't tell everything about a specific topic, share as much information as you can.

On the other side, your people need to know that they can share confidential information with you, and you're not going to pass it on. This type of trust gives them the necessary psychological safety. You don’t have to take it to a personal level, but your team needs to trust you on a professional level.

Building trust helps you improve engagement.

Empowerment

I decided to move away from being a technology specialist and to transition from software engineer to engineering manager in 2002. Technology changes quickly, so it’s impossible to maintain the same level of technical expertise for years without constantly using it. Leaders need to let this go.

Delegate the best software engineers and empower them to do the work. Time management for managers is essential, you need to avoid creating a bottleneck by taking on work you don’t have the time to get done.

Empowerment means that you let people make decisions in their area of expertise. You give them clear guidelines and frameworks, so they know what their scope is. Once this is all in place, you let them work.

In my experience, Dan Pink’s theory about motivation is dead right. Software engineers are motivated by finding a purpose, having a degree of autonomy, and trying to do their best. Most people want to get better, and they want to do a good job.

Engineering leaders need to support this.

LogMeIn has found its purpose as the COVID-19 pandemic forced many companies into working remotely, and our product helps make this possible. Working for a cigarette company is a valid choice, but this kind of purpose is the icing on the cake.

People: Let them work

Engineering leaders need to keep steering people in the right direction, but they also need to give them space to work.

Software engineering is one of the most complex activities in the world. It requires deep focus. Every time a manager or team leader interrupts someone, it takes a long time to get back in the zone.

Context switching takes a lot of time and effort.

As an engineering leader, I try to limit the number of all-hands meetings and global conference calls for my team, unless it’s important. A meeting like this doesn’t just take time from everyone; it also breaks their concentration. Software engineers are the only people good at writing code, so we should let them do it, and try to take most of the distractions off their table.

We run quarterly all-hands meetings in engineering. I try to schedule them a couple of days after the business all-hands meeting, so if there's anything that's relevant to the engineering department, I can explain it to them.

I also have an open-door policy, because you often learn things in one-on-one meetings, or over a cup of coffee in the kitchen. People are less likely to speak up in an open meeting, especially since software engineers tend to be more introverted.

I also take information from engineering to the business side. They need to understand that if the code isn’t tested properly, there may be serious issues in production. We take our time with good reason, and we need to communicate that.

Engineering leadership is interpreting between business and software engineering.

Processes: Streamline, streamline, streamline

The second pillar is the processes. Lean thinking has a theory: processes tend to hold people back far more than other people.

Internal processes can get so heavy that it seems like people are bad at their jobs, even though they’re doing their best. It gets especially bad in large enterprises. It’s a good idea to start by looking around within your own scope.

Useful processes

In the case of finances, not just anyone can approve anything, because one needs to know the budget precisely. When it comes to software engineering processes, you can build a system that allows even the most junior engineer to deploy to production. You need to put checks and balances in place.

You can build an automated test suite that checks whether the new deploy is going to break the system. This type of process adds value.

Another example for a valuable process is doing a short demo for stakeholders. You could send a simple message that you’re done, and it works. But a demo gets you buy-in from your stakeholders, reassures them you’re delivering value, and gives them a tangible update on what you’re delivering exactly.

Criteria to streamline

When a process has parts that take time while adding little to no value, you can streamline it.

Here’s an example: I'm hiring a new person for my team, and they send me a form so I can approve the hire of that person. Why? I have interviewed and chosen that person already. Obviously, I’ll approve a hire that I initiated.

Technology: Keep it simple

I used to be a fan of standardization, consolidation, and rationalization of an enterprise portfolio. Nowadays, the end-user drives the solutions. Twenty years ago, purchasing enterprise software was an executive decision; today, any user can download any app and use it.

Different teams or different people in the same team using different software adds an extra layer of complexity. This slows down the team. Tooling may be the most obvious example, but things can get too complex on the technology front.

Software engineers are smart people, but you shouldn’t put extra obstacles in their way.

Re-use existing components

LogMeIn is working with large blue-chip customers with old code bases. They're delivering a lot of revenue, but some of the technology and the functionality overlap. It’s helpful to look across the architecture and the components to see if you can reuse some of them.

For example, we built a product called Live Lens, a camera sharing solution for providing remote support. We took the camera sharing component and re-used it in other products, upgraded legacy architecture, and rationalized the number of technical components we need to support. This decision reduced technical complexity.

A story about improving the performance of an underachieving engineering team

I'll tell you a leadership story. I used to work for a company in the UK, which I left for a few years and went back to a more senior role as a managing technical architect. I was brought back to turn around a team that was doing what I used to do.

I started on the client side. I built connections with the customers, both on the level of management and technical representatives. They weren’t satisfied, because the team was behind on delivering. I asked to see the issues log, the scope of work, the backlog, what they were working on, and how overdue each item was.

It looked bad.

As a next step, I talked to the team leader and other people on the team. The team leader was a nice guy, but not a strong character. There was an engineer on the team with a strong character, but he was less capable technically and much less nice.

There was also an expensive third-party contractor on the team who didn’t deliver. I talked to him a lot about his issues and reasons for not finishing tasks on time, and concluded that he was just lazy. He was the only person I moved off the team.

I replaced him with an engineer I knew from my first time working at the company. He had amazing technical expertise, but he was an introvert. He proved to be a great support for the team leader, who was a nice guy, but not so strong technically.

After mending the team composition, I relentlessly followed the data. I examined each issue and  item on the backlog:

• Where are we?
• How much work is it?
• What are the options?

We set up a relative priority with the customer manager and made sure that the team focused on delivering an option for each of the most important issues. We started with the most important and kept time as the main driver. It was okay to be late on low-priority things; the focus was to solve the high-priority issues.

In a relatively short time, we went from underperforming to winning a bottle of champagne for being the most successful team in the company. The CIO described the team’s turnaround as a miracle.

This may sound easy, but it isn’t. People are more complex than any IT system.

Bonus advice

Taking over a new team

When you take on a role, you don’t usually know the team you’re going to work with, because you interview with the managers. Before I came to LogMeIn, I did my research on the company, and I liked the area they’re working on. Still, I had no way to know the team’s performance in advance.

People go to work for people, and I met great people while interviewing at LogMeIn. In this case, the quality of the leaders was the deciding factor in me taking the role.

Keep an open mind

My advice for engineering managers and leaders is to keep an open mind because there might be many reasons for suboptimal performance. There are lots of differences between companies in engineering culture, team history, management, etc.

If you’ve been running your team for a while, and the performance is dropping off, the reason is often a lack of clarity around the high-level objectives. In this case, you need to link the product or company strategy to the daily work of the team, and to provide direction about the higher-level strategy. Consider these questions:

• What's important for my manager?
• What’s the team doing that will get us to those objectives?
• What are they doing that isn’t pointing in the right direction?
• Do they have a good reason to do that?

About John Ford

John Ford started coding at the age of 10, only taking a break from IT while he studied languages at Oxford. He was born in England, but he’s been living in Hungary since 2006. He’s been setting up tech centers in Budapest for the last 10 years.

He’s currently VP of Engineering and site leader of the Budapest office of LogMeIn. It's one of the most successful Hungarian software companies with a large team developing, delivering, and supporting SaaS native work-from-anywhere solutions.