Knowing the ins and outs of your product and having a deep understanding of engineering operations are vital foundations for leading an engineering team, but truly impactful leaders also prioritize safety, innovation, and continuous improvement.

Engineering leaders are tasked with cultivating and maintaining an engineering team’s culture by  reinforcing practices that contribute to a healthy team. In this scenario developer satisfaction correlates with team efficiency and better performance. To establish and promote team health in your organization, focus on shoring up these six essential people skills, all backed with the relevant data points.

1. Empower developers

Engineering leaders need visibility into their team’s workflow so that they can report up to stakeholders, course-correct when work goes off track, and address teams directly, whether that’s to reward high performers, or support stuck engineers. Typically this visibility into the software delivery pipeline is gained through traditional status updates and check-ins. But these can be frustrating for developers, at best interrupting their flow and, at worst, veering into  micromanagement.

Data can help you strike the right balance between staying informed about what your teams are working on and giving engineers the space they need to do their work. Surfacing data with a Software Engineering Intelligence (SEI) platform, for example, allows managers to see how work is progressing and use valuable facetime with engineers to have bigger picture conversations and ask informed questions. 

With an SEI platform, leaders can visualize work-in-progress at a glance, without causing interruptions. Once leaders are better informed, conversations about improvement can be even more valuable. With objective data, teams and managers can get on the same page to work towards a common goal.

If the data reveals that work is progressing as expected, engineering leaders can feel more confident about taking a step back and giving developers more autonomy to manage their projects. If the data illustrates at-risk work, you and relevant team members can strategize to mitigate that risk immediately.

If you thoughtfully introduce metrics to your team and communicate how they’ll be used to drive improvement in the organization as a whole, teams can set their own goals and track their progress against them, underscoring their ownership of engineering outcomes.

2. Lead with empathy 

Effective engineering leadership requires a human-first approach. The success of your organization is not just dependent on software delivery and a great product, but also the people behind that product. 

Leaders with empathy appreciate and acknowledge the complexity of the work their teams are doing, including problem-solving, last-minute triages, and ultimately, shipping high-quality code. 

Engineering leaders should be mindful of the difference between productivity and competency in engineering. It’s important to reward engineers who exhibit a high level of competency, by taking on new challenges, collaborating with their team, and mentoring other developers. When conducting performance reviews, consider how they approach problems, make decisions, and navigate their failures. By acknowledging and rewarding their efforts, you’re demonstrating that you understand their hard work and value.

3. Lead with curiosity 

Fostering a culture within your team where engineers are comfortable taking risks, openly expressing their concerns, and sharing ideas creates psychological safety, which in turn improves employee satisfaction, and often leads to better team performance. 

Reframing the way you approach problem solving can reinforce a safe, blameless culture, and that starts with curiosity. Leading with curiosity means investigating issues, rather than jumping to blame. Looking at processes as a whole allows you to consider the ecosystems that contribute to software delivery, inclusive of systems and teams, and to ask the right questions. 

One effective strategy for enhancing safety is to frame those questions around the work itself, rather than an individual contributor. An SEI platform can surface relevant engineering data, like the details of a bottlenecked PR, or metrics about the team’s review processes, to keep conversations with teams and developers rooted in fact.

The use of objective data promotes transparency in the organization, by demonstrating what needs improvement, and it invites collaboration between teams and leadership to solve issues. 

4. Open up lines of communication

Communication is a key trait of effective leadership. Good communication can break down silos across departments, enhance transparency, and enable a culture of trust. 

While data can surface critical information, teams can only get on the same page and work together towards their goals by communicating effectively. 

Engineering leaders can foster a culture of shared communication by creating public forums, like Slack channels for remote or distributed teams, and hosting all-hands meetings for more complex conversations. Detailed documentation on product features and processes can improve communication if it’s shared with all relevant stakeholders, and if it’s a living document in which feedback is welcome and any changes or updates are transparent. 

You can go further again, by encouraging a culture of continuous feedback. Lead by example and offer feedback to developers, while also inviting their feedback on processes and suggestions for improvement. Ensure that feedback is actionable by keeping it based on the work, not engineers themselves.

5. Know how to prioritize 

Aligning the priorities of the engineering organization with business goals can help limit developer frustration by cutting back on wasted work and context switching. This involves transparent communication with the C-Suite and setting clear, relevant objectives for the engineering team. 

Data can serve as a check to ensure product-engineering alignment. For example, engineering leaders can look at metrics like unplanned or untraceable Pull Requests (PRs) that are not linked to project plans. A high number of untraceable or unplanned PRs can signal that priorities are not aligned, which could be contributing to developer frustration. 

Awareness of strategic priorities of the business can also help you identify how resources should be allocated, and advocate for additional resources if needed. You can also put your team’s needs in context of the business, for example, making a case for working through technical debt that frees up time for developers, without sacrificing product innovation. 

6. Be aware of biases 

Biases can show up even within the most well-intentioned organizations. Having an awareness of potential biases in order to combat them is a hallmark of strong leadership. Since your perception of a developer’s performance could be skewed, it’s important to look at both qualitative and quantitative data, as well as general context, when evaluating performance. 

Potential latent biases include gender bias, in which women and female-presenting developers are assessed on personality traits, rather than on their technical abilities. The halo/horns effect, where managers let one trait influence their impression of a developer. And similarity bias, in which managers favor developers they see as similar to themselves. 

To avoid letting biases affect decision making, leaders should focus on the work of the developers, and use data to check assumptions. If you find something that doesn’t meet your expectations – low output, for example – use that as a basis for a conversation, rather than a cause for judgment. Above all, don’t use data as justification for punitive action, but rather as a prompt for specific feedback of constructive conversation. Looking at whether developers practice good coding hygiene like keeping PRs small, how they contribute to code review, and how they navigate and learn from instances of stuck work, are more objective ways to assess developer performance.

If you’re evaluating ahead of a performance review, it’s good to be aware of potential recency bias, where your impression of a developer’s work might be based only on their latest performance. Looking instead at historical trends can offer better insight into whether there are patterns that need addressing, or anomalies. If a developer shows high performance over time, but has recently appeared stuck, it’s worth a conversation to uncover the situational factors that may be contributing to their performance. 

Final thoughts

Data insights from an SEI platform can support you in remaining an objective leader, and grant the visibility to understand how teams and developers are working so you can make mindful improvements. By taking a thoughtful approach to leadership, acting with empathy and compassion, and enhancing communication and alignment, you’ll cultivate a positive culture and motivate higher team performance.