How to Build and Foster High-Performing Software Teams: Experiences from Engineering Managers

Introduction

These days, most software organizations are built around teams where professionals work intensively together on a daily basis to deliver software. Where teams preferably are self-managed and autonomous, there's still a need for managers to establish conditions and guidance and foster high-performing teams. One of the things they often need to work on is balancing team autonomy and responsibilities with alignment between software teams and other parts of the organization.

Engineering managers can enable software teams to learn and improve, and help them move problems and impediments out of the way. In this virtual panel, we'll discuss how engineering managers support teams, what skills they possess, and how they establish alignment and foster knowledge and experience sharing between teams. If you care about fostering high-performing teams where professionals feel safe to do their work the best way they can, this is your way to learn from the experiences of engineering managers.

The Panelists

• Dr. Olga Kubassova, President @IAG, Image Analysis Group
• Michael Gray, Principal Engineer @ClearBank
• Hannah Foxwell, Product Director @Snyk

InfoQ: How do you as a tech leader support and guide different kinds of autonomous teams, each having their own way of working, while ensuring alignment and coordination throughout the organization?

 Dr. Olga Kubassova: At regular intervals (annually), make sure that everyone is on the same page. Make sure all teams understand the organization's core values, mission, and overall vision. Repeat those regularly! This creates a sense of unity and fosters collaboration. Trust is key, so empower teams with decision-making authority within clear boundaries. This lets them work independently while staying aligned with the strategic framework. Provide mentorship and coaching to team leads, sharpening their leadership skills and ability to manage their teams effectively. It is critical to break down silos, but at the same time allow individuals to own outcomes.

As a leader, you should establish channels for regular communication and collaboration between teams. This could involve project management tools, regular meetings, etc. For us, what works well are informal social events (small and big). Transparency builds trust and helps teams anticipate roadblocks or opportunities to collaborate.

It is of course easier said than done, but defining clear, measurable goals for each team that contribute to the overall organizational objectives is a real stepping stone to successful leadership. If there is an opportunity, consider establishing a central coordination team or committee. For instance, a recognition committee that will be responsible for recognizing the achievements of the team members.

The most effective strategy will depend on the specific teams, their work styles, and the overall culture. I always focus on empowering teams to achieve the desired outcomes, not micromanaging them. Finally, celebrate successes achieved through collaboration and install policies that reward such successes. This reinforces the value of teamwork and motivates further collaboration across your teams.

Hannah Foxwell: This is such a common challenge and a lot of leaders are inclined to think standardisation is the right way to go .. maybe because it makes their jobs a little easier? .. maybe because they've seen a certain methodology succeed elsewhere? But, personally, I don't believe a team is really autonomous if they can't evolve, adapt, and improve their own ways of working. 

Having worked on both sides of the fence as an Engineering Leader and as a Product Leader there is always an overarching "plan"  and with it a planning process. This is important at an organisation level to ensure alignment on priorities across teams, make trade-offs visible, and agree on where to invest. Whatever process a team adopts at a local level there needs to be alignment around these high-level plans - to do that I recommend keeping planning lightweight, continuous (not once or twice a year) and communicate the value of it to everyone so that engineers understand why they are being asked to plan beyond the next sprint or iteration.

Michael Gray: For an organisation of our size, ~300 people throughout product and technology with ~30 autonomous teams we have the challenge of balancing autonomy, alignment and visibility. To enable this, we focus on the boundaries and place, what we hope are, enabling constraints. We have a standard set of metrics and reporting that teams must be able to provide, we have a standard cadence for "sprint reviews", although we’re not strict about using scrum internally in the teams. So long as the teams can provide the metrics and the regular review sessions, they are empowered to work within those constraints however they like.

 We work in quarters at ClearBank, each team makes high level bets for the capabilities they are going to build or enhance. All of these bets must relate back to our mission and align with our overarching product strategy. These are communicated in our quarterly planning sessions, and on occasion challenged when it is felt they don’t align. Work is done to summarise and communicate this organisation-wide. This enables the organisation to have just enough visibility on what the teams are working on, and helps assure everyone we’re working in investing in the most valuable areas while ensuring alignment to our mission.

 InfoQ: When do you decide to step in to resolve a team problem instead of guiding the team toward finding a solution themselves?

Dr. Olga Kubassova: Some situations require a leader’s intervention. For instance, a crisis that happened as a result of past or recent decisions made by the team. When the team's morale dips in these situations, it's a red flag for a leader. Stepping in effectively can make a big difference in turning things around.

Firstly, I would diagnose the cause, to understand the root of the problem and the need for action. Then, I would propose the goal and the timeline of achieving those. I see a lot of value in talking to team members individually and in small groups, understanding the situation and then guiding them to the resolution.

Hannah Foxwell: Deciding to step in and help a team can be really positive or it can backfire. If a team ends up thinking you don't trust them, or that you're inspecting their work, that can do a lot of damage to their sense of autonomy. It can be tempting to solve every problem but it won't help the team grow in the long run if you take that approach. If the team asks for your help, or you have the type of relationship where you can muck in on occasion, then it's probably ok, but be careful the team doesn't become dependent on you.

Saying that, there are times when I've had to step in to support individuals who were burning out, spiraling, or disrupting their team. In those situations, it's important to take action because you need to demonstrate to the rest of the team that you have their back, whilst providing more support to the individual.

Michael Gray: Tough question, and the easiest answer is, it depends.

 Is it a newly formed team and they’re storming? – Keep well out of the way, let them find their own boundaries with each other. Interfering at this point, in my opinion, results in negative outcomes.

Is the team struggling to find their own boundaries, resulting in negative interactions and behaviours? – Sure, get involved, help draw some boundaries for the team to enable healthier interactions.

Is it a technical challenge they’re struggling to resolve? - Ask some leading questions to help them think about the challenge from different angles and provide a fresh perspective, but ultimately let the team own solving the technical challenge.

InfoQ: What challenges do you face leading software teams and how do you deal with those challenges?

Dr. Olga Kubassova: Software developers are introverted and focused, they are reluctant to show their product to the users (even early adopters). This is a challenge.

The solution is Embed User-Centricity: Integrate user feedback early and often throughout the development lifecycle.

• User Testing: Conduct regular user testing sessions to gather real-time feedback on usability and design.
• Early Adopter Programs: Engage early adopters to provide insights into real-world usage scenarios.
• User Research: Conduct user research to understand user needs, behaviors, and pain points.

Hannah Foxwell: I think one of the biggest challenges for a leader is navigating constant change. There is never a moment of stability. There's always a new technology to learn, new practices to adopt, business challenges, and opportunities to respond to. Getting comfortable with this constantly evolving landscape, whilst providing clarity and focus for your teams is the key to success!

Michael Gray: A common challenge I’ve faced is teams/people playing with fancy new tech or applying new techniques, that don’t help to solve the problem at hand. A great way to help deal with this is to make sure they are crystal clear on the problem they are solving, if they start to drift I always ask them, "does x help get us y"; with y being the solution to x, the problem we’re solving. Sometimes my perspective is wrong, and I’ve learned to enjoy being wrong, and the new tech or techniques does solve the problem in a way I’ve not thought about and therefore it’s a great decision to make, if not I’ve asked them a question to refocus them on the problem at hand without dictating a solution to them.

InfoQ: What do you do to support diversity and inclusion in teams and foster psychological safety in teams and in the organization?

Dr. Olga Kubassova: We openly talk about the challenges and think collectively about how to overcome them. As a female leader, I think it is critically important to champion diversity and inclusion (D&I) and foster psychological safety within your teams and the organization. I encourage other female leaders to be the role models. Even the presence as a female leader disrupts the stereotype and paves the way for others. When you project confidence and competence, you set the best example.

We employ many nationalities and it is important to amplify diverse voices. We actively seek out and elevate the perspectives of team members from underrepresented groups in meetings, presentations, and brainstorming sessions. Creating open communication channels where everyone feels comfortable sharing ideas, even if they differ from yours is important. Of course, as the business grows, we need to start formally tracking D&I and psychological safety metrics, so that we can hold ourselves as a leadership team and the organization accountable for progress.

 Hannah Foxwell: There is always more to do but here are some of the things that can make a big difference.

When hiring make sure you have a diverse pool of candidates to interview. This might need you to put in more effort in initial outreach to potential candidates. A personal message from you as the hiring manager is almost always going to get a better response rate than a recruiter. It's also important to challenge yourself on what the "must have" vs. "nice to have" requirements are in the job spec. By limiting the "must haves" you open the door to more candidates from different backgrounds.

One thing that helps remove bias from decision making in hiring is making sure the interview process is the same for all candidates and that you have pre-agreed scoring criteria for each phase of the interview. Commit to hiring the highest-scoring candidate. However, if candidates are not at the same level, maybe you interview a Senior and a Staff Engineer for the same role, and make sure you adjust your scoring criteria accordingly.

To build inclusive teams it's important to make sure everyone has a voice and everyone's contribution is valued. Celebrate successes but also encourage teammates to celebrate each other too. One simple way to do this is to have a standing item on all team meetings for shout-outs and kudos and see what happens!

Celebrate failures too! If we messed up and fixed the issue, captured our learning and took action to improve then that's a good thing, not a bad thing. This helps to create an environment where it's safe to take risks and everyone improves when we share our learning!

As a manager, I want to make sure everyone in my team has an equal opportunity to succeed. I spoke about this recently at QCon London and shared some of the mistakes I've made throughout my career. Early in my management career, I tried to treat everyone the same way, but this didn't work. A better approach is to adapt yourself to each individual and be flexible to meet their needs. Consider if an individual needs coaching, mentoring, or sponsoring, and be cognizant that women and minorities are traditionally over-mentored and under-sponsored.

Michael Gray: We focus on making sure we incorporate a flexible working environment, allowing people to work the hours that suit them, and work where it suits them. We have a great internal dimensions team that educates the organisation on people’s beliefs, religions, cultures so that we can all better understand one another.

Our engineering teams are built on a culture of trust. They own capabilities of the system and, along with their product counterparts, are empowered to make autonomous decisions for the areas that they own. More importantly, they are allowed to fail. Not everything can be successful and failing is how we learn and make better decisions moving forward.

InfoQ: What leadership skills have you developed over the years and how do you apply these skills in your daily work supporting teams on their journey towards high performance?

Dr. Olga Kubassova: I love seeing people grow in their roles and beyond. When I see that someone is able to achieve more if they are given the right opportunity. I work with the individual to see if they are up for a challenge and want to try their skills in a new role.

Hannah Foxwell: As a manager, there is always more to do so you have to learn to prioritise your time effectively. You need to get comfortable with delegating, trusting, and also sometimes just deferring work until later. It can be hard deciding what not to do, but just as your teams will value focus and clarity, you as a leader will have more impact if you learn to say no in the right way.

For my teams I would always encourage them to reduce WIP (Work in progress) and finish a task before moving on to the next thing. It's always better to work with them on a realistic plan than manage a team that's burning themselves out in pursuit of an unachievable deadline.

Michael Gray: Earlier in my career I used to see the world one way, my way. Over the years I’ve learned not everyone sees the world in the same way that I do, (sounds obvious, I know), but that everyone has their own perspectives. Learning to be curious about those perspectives and why people have them has been invaluable for me and my ability to lead. Being curious makes people feel heard, allows them to be part of and, importantly, feel part of decision making processes which brings them along on the journey.

I’ve also learned to trust and leave space for people. When I reflect on my career, I’ve worked for some great leaders who didn’t give me all the answers, but created a safe space where I could try to figure them out, feeling like if I failed, that was okay. I try to give people the same opportunities now and create that psychologically safe environment and space for them to grow.

Going back to the point I made earlier, "Not everyone sees the world in the same way". All people and teams are different, understanding how they like to work, how they like to be communicated and interacted with, and what levels of support they expect/need. This is something I’m very conscious of. Some teams need more directive communication and a clear focus, and expect and need this, others prefer a quick conversation every now and then but drive their own team autonomously. Making sure you understand these needs and therefore how to communicate and collaborate with each team's individual needs is vital.

InfoQ: How do you foster knowledge and experience sharing across teams, including failures and valuable lessons learned from them, and what benefits does this bring for the teams and the organization as a whole?

Dr. Olga Kubassova: Encouraging knowledge and experience sharing across teams, including failures and lessons learned, is crucial for boosting innovation, efficiency, and overall organizational success. Our team works closely together and we are sharing knowledge constantly. This can happen in small groups or in team-wide meetings. I find having a shared library is very important. We work across multiple therapeutic areas, and it is impossible for one person to know it all. Having a shared repository definitely helps!

Hannah Foxwell: It can feel a bit formal but having a regular cadence of "town hall" or "all hands" type meetings can be a good way to publicise achievements to a wider audience. Sometimes these meetings can be very top down but if you include experience reports from engineers, with a warts-and-all account of what went wrong and how they overcame the challenges it can be both inspiring and memorable for everyone else on the team. Whether it's a new feature development, an incident, a security issue, or a new technology, some good storytelling will make it relatable to the wider team!

Encouraging teams to write down these accounts as well as speaking about them is also a great investment of time. That way it can become searchable in your internal wiki and anyone who missed the presentation can still benefit from the content.

Michael Gray: At ClearBank there are a few things we do.

Firstly, how we manage and communicate our more serious incidents, thankfully they are fewer than ever these days, however, they still happen on occasion. When we do have a more serious incident we have a blameless post incident review session (PIR) walking through all the contributing factors that led to the incident, discuss what we could do to improve next time and take actions to mitigate risks. We then communicate a summary at our Monday 10am product engineering all hands so the rest of the product engineering floor can understand contributing factors and learn from the incident too.

Our Architecture Advisory Forum also plays a role in this. It is our forum where we make wide impacting decisions. Anyone is welcome to attend, and they can listen to the discussions we have to make our technical decisions. This serves as a great way for people across the floor to understand questions they should be asking when making technical decisions and helps them learn how to think about problems and how they might solve them.

We have guilds that focus on specific areas, i.e. our security guild, QA guild, where they get together to discuss the latest security/QA trends, which is an open forum. Anyone can present or share at these forums so long as it is on the broader topic of Security/QA. We also have other guilds, some are for specific levels, for example our Engineering Managers, who get together once a month to talk through challenges they may have and they talk through and share experiences and support each other.

The final piece to touch on is our ‘Tech it easy’, which we run every Friday. Anyone can talk on any topic at all, sometimes it is work related, other times it’s whisky tasting, other times is 3d printing or home automation. This is a great way for people to build relationships, meet others in the organisation they would otherwise not encounter day to day.

Conclusions

Tech leaders have to ensure alignment and coordination throughout the organization. They can support and guide different kinds of autonomous teams by communicating the organization's core values, mission, and vision. Leaders can give teams authority within boundaries, by balancing autonomy, alignment and visibility and trust, aligning on priorities, and placing enabling constraints. Standardization isn’t the right way to go, teams can only be really autonomous if they can evolve, adapt, and improve their own ways of working. 

Leaders should know when to step in to resolve a team problem and when to guide the team toward finding a solution themselves. They shouldn’t interfere when a new team is finding their way or solving technical issues, and be careful that through interventions the team doesn't become dependent on them.

There are many things that leaders can do to support diversity and inclusion in teams and foster psychological safety. Examples are actively seeking out and elevating the perspectives of every team member, creating open communication channels where everyone feels comfortable sharing ideas, adapting themself to each individual to meet their needs, making sure everyone has a voice and everyone's contribution is valued, and allowing people to fail and celebrate those failures.

Engineering managers can support teams on their journey toward high performance by delegating, trusting people, being curious, creating safety, and understanding what level of support their teams need. They should also be capable of deferring work until later and learn to say no in the right way.

Encouraging knowledge and experience sharing across teams is crucial for boosting innovation, efficiency, and overall organizational success. "Town hall" or "all hands" type meetings can be a good way to publicise achievements to a wider audience. Attending architecture forums can help engineers in understanding questions they should be asking when making technical decisions and learn how to think about problems and how they might solve them.