According to Lizzie Matusov, technical drivers like velocity offer an incomplete view of team performance. Social drivers—trust, autonomy, purpose, and psychological safety—provide a fuller picture and reveal important areas of opportunity for improvement. She spoke about the social drivers behind high-performing engineering teams at QCon San Francisco.
High-performing software teams reliably and consistently deliver high value to their end users, Matusov said. They balance technical excellence, efficient workflows, and a supportive team culture focused on collaboration, well-being, and continuous improvement.
To understand what drives a team to keep performing at a high level, look at their technical and social drivers, Matusov suggested. Technical metrics (like velocity or quality) focus on the efficiency and quality of the output, while social factors (like psychological safety and autonomy) reflect the environment and culture that enable or hinder that output, she added.
To keep performing at a high level, teams need to have a combination of efficient technical processes and a strong social environment that motivates them to continuously deliver at a high bar. The social drivers are in many cases equally or more important than the technical drivers, but organizations often only focus on the technical factors, Matusov explained:
When a team is first thinking about looking at the social drivers on their team, I tend to recommend a framework called “TAPPs”. This stands for trust, autonomy, purpose, and psychological safety. These four drivers create a very comprehensive view of the social dynamics of the team, and how that drives their overall performance.
When a team has high trust – that is, they believe their teammates will reliably contribute and support the shared objectives – they are significantly more productive, Matusov said. In a study on predicting developer productivity over 600 engineers ranked factors that make them productive. 40% of the top ten factors related to trust. Trust creates a tremendous impact on an engineering team, improving performance on a team, product, and organizational level, she mentioned.
To foster autonomy, managers can set clear goals and objectives that are aligned with business outcomes, while giving the team the freedom to determine the best approach to achieve them. This empowers the team to take ownership of their work, make independent decisions, and reinforce their commitment to shared goals, Matusov said.
Purpose keeps a team aligned with business goals and values. When the team understands the impact of their work, they are more compelled to achieve that impact, Matusov explained:
The 2024 DevOps Research Assessment (DORA) Report found that engineering teams who have higher alignment to their work consistently achieve high product performance, regardless of their throughput.
Psychological safety is the shared belief among teammates that they can take interpersonal risks without fear of negative consequences. It is about taking risks and demonstrating candor, not being prudent or cautious, Matusov said. Teams with high psychological safety are the most risk-taking, disruptive, and innovative teams. They aren’t afraid of failure, which usually leads to finding the best solutions for their users.
Matusov suggested measuring social drivers. Teams that want to understand how to unblock engineering productivity and increase performance need to first understand what’s causing their roadblocks. In other words, you can’t improve what you don’t measure, she said.
To measure social drivers, Matusov recommends a “Build, Review, Drive” strategy:
- Build a process: to make meaningful improvements, teams need more than a single data point. Create a plan for measuring on a monthly (ideal) or quarterly basis so you can understand trends and also analyze the impact of actions.
- Review with curiosity: as you establish a baseline and trends for a team, remember to approach the data with curiosity. Resist the urge to over-index on a single data point, and instead prioritize change over time. Always ask “why” to get to the root of how social drivers are impacting the team.
- Drive actions and improvements: reviewing the data with curiosity should unearth opportunities to make improvements. Talk to the team, and commit to an action that improves the team’s performance.
Creating this feedback loop will build an iterative process of improvement, and will yield major improvements in the team’s overall performance, Matusov concluded.
InfoQ interviewed Lizzie Matusov about measuring and analyzing social drivers.
InfoQ: How can we measure the social drivers that influence the performance of software teams?
Lizzie Matusov: The most effective way to measure social drivers is through a survey that is anonymized and aggregated to the team level. A survey consists of a series of single barrel questions (i.e. only asking one thing at a time), with a 1-5 Likert scale answer.
For example, one way to measure psychological safety is by asking the following question: “If I make a mistake, it won’t be held against me.”
By asking on a regular cadence (monthly or quarterly), teams can measure quantitatively how sentiment changes over time for the most important social drivers.
InfoQ: How can we review the data and take action?
Matusov: The first thing a team should figure out is if they have a complete picture of what’s happening on the team, which would include both social drivers and technical drivers.
As an example: a team’s system metrics may show that they consistently struggle with very slow code review cycles. Without including social drivers, they could choose an action that won’t solve the root cause of their problem.
Measuring social drivers may indicate that the team struggles with autonomy. This means the team does not feel that they “own” their code reviews to push the process forward, which causes more idle time in the review process. Solving for autonomy will improve their code review cycle time, and allow the team to deliver features to customers faster.
