Transcript
Matusov: My name is Lizzie Matusov. My goal is to make you walk away thinking a little bit differently about what drives the highest performing engineering teams. When I was at Red Hat, I had a pretty interesting job. I was a software engineer, but I worked in our consulting arm, which basically meant every six or so months, I would get together with a new group of engineers, and we would have a product that we were working to deliver. We would go through the forming, storming, norming, and performing process as we figured out what were the processes that worked best for us to deliver our products over the finish line. We would do really great work.
Then, six months later, we would deliver our product, completely disband and start again with a new team. In running that process as many times as I did, I came to understand that social dynamics, they were driving our performance quite a bit. As I continued on in my career, I realized that those social drivers were critical towards understanding the performance of our engineering teams. To take a step back for a second, it’s actually no surprise that social drivers impact how we work in general. We’re human beings, and that means, by nature, we’re quite social. Social interactions really govern how we see the world. It’s no surprise to know that those social drivers also impact how we perform in situations like at work.
One of my favorite examples away from the engineering world of just how important social drivers is, is through, “The Bear”. It’s a show about a restaurant that goes through this transformation from a casual diner to a high-end restaurant. In one of the most famous scenes of the recent season, it’s one of the first nights of operation of this high-end restaurant, and things are really moving. It’s a very high stakes night. From the front of house, guests are being served these fantastic, high-quality dishes in a dimly lit setting, and it’s really a great experience.
From the back of house, the tension is starting to build with the people that work as the chefs. They’re supposed to be working together as a team, and they’re delivering good work, but the social dynamics between them is a little bit tense. Pressure is growing, and as it mounts over the course of the night, things start to amplify. Finally, the head chef gets locked in a freezer, is getting screamed at by his teammate from the other side, and is then left there for the rest of the night. Not how you want things to go on a team.
It’s actually a really important lesson here, because without knowing the social drivers that impact a team, we don’t know how our team is going to perform under different circumstances. Those chefs, as an example, were incredible at their work, and they were outputting high-quality products, but this was a volatile situation because of their social dynamics, and it could really impact the performance of the restaurant. That same principle applies to engineering teams. I could show you a graph of speed versus quality, and you could look at this and say, this is an engineering team that’s pretty performant. On the left-hand side, you’ve got velocity, which is steadily improving over time.
On the right-hand side you have quality metrics, like change failure rate, which is telling you that the team is deploying regularly with minimal impacts to production and their builds. This would be what we would call an elite performing team. If I showed you these graphs, you’d suddenly think a little bit differently about this team. This is a team that has ever-decreasing psychological safety and heavily increased risk of burnout. This is a team that’s on the edge of breaking. What you see on those top two graphs is not going to last if things don’t change. You might be looking at these graphs and thinking, Lizzie, that’s great, but capturing and analyzing this type of data, it’s not an easy feat.
Confidence by Measurement Cadence
Also, let me tell you why this is important. We took a sample of responses from about 30 companies and asked people to tell us, how often do they measure social drivers and how confident are they in their understanding of their team’s productivity? What you’ll see is that the teams who measure social drivers on a quarterly or monthly basis are more likely to feel confident that they understand their team’s productivity.
It’s not a guarantee, but what this shows us is that without doing some regular measurement of the social drivers on your team, you are just not likely to feel confident in your team’s productivity. In this talk, I want to show you what matters, how to capture that data, and then the steps you can take today to get started.
Timeline
We’re going to first introduce a framework that’s called TAPPs, that covers the most important social dynamics that you should know to understand the performance of your engineering team. Then we’re going to talk a little bit about the measurement. We’ll get into the who and the how. Third, we’ll talk about how to get started.
The TAPPs Framework (Setting the Scene)
Before we get into those dimensions, I want to set the scene. This is probably a situation that many of you have been in before, so it might sound a little bit familiar. Let’s say that we’re thinking about a software engineering team, and they’re working towards a big launch. This is a really important launch, and it’s going to drive a lot of revenue for the company, so no pressure, but a lot of pressure. They’re getting close to the finish line.
The launch plan has been written. We’re on to the final stages of development, and suddenly somebody discovers a bug. We don’t know what the impact of that bug is. We don’t even know really the severity. We just know that it exists. The question is, what does that teammate do? I’m going to walk you through how you should think about that. I’m going to continue the story using what I call the TAPPs framework, or the top four social drivers that you can use to understand the performance of your engineering team, which is trust, autonomy, purpose, and psychological safety.
1. Trust
Let’s start with trust. Trust is the belief that the people you work with are on the same page as you. It’s knowing that the teammates that you work with are going to deliver on their commitments, share honest feedback, and support each other’s work. How does that story go when you have low trust versus high trust? In a low trust setting, the teammate who discovers the bug, they’ll share what they discover to their team, but they’re just not sure that they believe the team is going to take it as seriously as they need to. They’ll tell the team, but they’re also going to go ahead and do their own discovery, their own analysis, their own research, and maybe form their own conclusion.
The rest of the team is probably going to do the same thing. They’re thinking, let me find out for myself, because I’m not sure that I trust my team to have the right assessment of what’s going on. What you just had was a lot of redundant work and a lot of wasted effort. If the bug is not high impact, then what that means is the team just wasted a ton of cycles all doing the same amount of research to come to that same conclusion. If the bug is significant, then all that time that was spent doing redundant work could have been spent helping find a solution. We’re also just assuming as well that the team trusts that the individual has the right assessment of a bug.
There just as well could be a case where everybody says, “I’m not sure that I even trust this as a bug, because you were the one that shared it”. It’s not a great situation. Let’s play out a high trust scenario. In a high trust scenario, the teammate will share what they’ve discovered and call together a meeting. They’ll do some initial diagnosis work together, and then they will break up to do various pieces of the discovery, the analysis, and the triaging. Then the team comes together to knowledge share.
Now they get to learn from one another, they get to pool their knowledge, and they’re able to much more quickly identify and resolve the issue. If it’s not an issue, then we probably found out pretty quickly, and if it was an issue, the team came together quickly in order to find a solution. Trust leads to open communication, faster problem solving, and less rework. It’s what allows the team to break up, work independently, and then come together and share in what they’ve learned, knowing that they understand the whole team is on the same page.
What’s some of the research behind it? In 2019, a team of researchers at Google asked over 600 developers across three different companies to identify what factors impacted their productivity most. What you’ll see in this graph is the top factors, starting from F1 moving down to F10, that predicts engineers’ productivity. Highlighted in yellow are the factors that relate to how well they trust their team, which is 40% of the top 10 factors. These are things like, people on my project are supportive of new ideas, or people who write code for my software are highly capable. These findings show us that trust is imperative in the productivity of software engineers.
The impact of trust is extremely important when it comes to the performance of a team. For team performance, you heard me share earlier about how improves collaboration on the team, which helps makes the team much more productive. From a product performance standpoint, you see increased product reliability and other downstream effects like decreased deployment time and decreased change failure rate. What’s incredible is that the DORA report in 2022 and 2023 found that a high trust culture correlated with a 30% increase in organizational performance.
2. Autonomy
Now that we know that trust is a massive driver of performance on engineering teams, let’s talk about autonomy. Autonomy is the ability of software engineers to make decisions independently about their work. The whole team is going to have a clear sense of alignment on goals and boundaries, but within the team, teammates feel empowered to figure out what makes sense, how to prioritize their work, and how to achieve their team’s goals independently and how they see fit. Let’s consider the story here. In a low autonomy ending, the team is often inhibited by process or permissions, which impacts their own ability to quickly triage and determine the severity of the bug.
This new engineer, or this engineer that comes in and discovers this bug might have some ideas about what it could be, but instead needs to pass it over to a formal channel, instead of independently taking those first steps to discover how severe and what the impact could be. That means there’s a delay in determining how important this issue is. If it’s not a big issue, then there was a small lag. If it is a big issue, then it’s possible that that was just sitting in a queue waiting to be looked at by a formal process, when that engineer could have gotten started understanding what the impact is and come with a much richer discussion. Let’s look at a high autonomy situation.
In a high autonomy situation, the teammate who discovers the bug is going to decide that this is an important thing to look into to understand the potential impact. They’ll probably prioritize it over another task that they’re doing, because they think that the impact could be big. What happens is, if this is not an issue, then they just saved the team from spinning their wheels over something that wasn’t a concern. If it is a big issue, then they’re going to come into the conversation with a lot more information about the impact, the severity, and what they should do next, which allows the team to move much faster.
Autonomy is what gives engineers the power to solve problems faster. As engineers, one of our strongest skills is in our ability to solve problems. Autonomy is really the foundation that allows us to do our best work. Let’s talk about the research. I first want to bring back this study that we just talked about before. You remember how I told you that 40% of the top 10 factors related to trust? Another 30% of them relate to autonomy. Things like, my job allows me to make decisions about what methods I use to complete my work, or, my job allows me to use personal judgment in carrying out my work. There’s another great study that we can look at too.
In 2017, researchers asked software engineers and managers to identify and rank what makes a great manager of software engineers. On the left you’ll see what’s called a violin plot, which shows you the top ranked answers from top to bottom. For each attribute, you’ll see the wavy line shows you the distribution of responses for engineers on top of the line and managers below the line. Then the thick horizontal lines will show you the interquartile range. The vertical line shows you the mean. The most important thing you should take away from this, though, is that enables autonomy was number three.
More interesting thing is that it really had the highest consensus equated from both engineers and managers on being highly important. Basically, engineers and their managers agree that autonomy is foundational for the performance of engineering teams. The results really speak for themselves. Autonomy empowers engineering teams to increase collaboration and improve delivery cycles. In fact, high-performing teams are two times more likely to have high levels of autonomy than low-performing teams. Behaviors of autonomy also just lead the team to move faster, as we heard in our story above.
High autonomy teams are 1.4 times more likely to achieve high deployment frequency and lower lead time compared to people with less autonomy. Perhaps most interesting is that when you give teams a shared goal and the teammates have the space to choose their way of aligning with that goal, it actually builds strategic alignment. You’re giving people the space to say, this is the goal, and how you help us get there is your own way. That’s really important for helping to build organizational alignment towards the same goals for the year.
3. Purpose
We’ve talked about autonomy. Now let’s talk about purpose. I’m sure we’ve all felt the contrast of going from a place where you’re just clocking in and clocking out, and it’s a 9:00 to 5:00, and we’d like to be done with the day, to a team and a company where you feel like what you’re doing really matters. That feeling is purpose. It’s that clear shared understanding of why a team’s work matters and how it aligns with broader organizational goals. Let’s talk about a low purpose ending. You guys have seen, “Office Space”. I think that is one of the most fantastic examples of a team that has very low sense of purpose. In this world, an engineer discovers a bug and they feel indifferent.
Or worse, they’re annoyed, because they’re like, “Now I’m going to have to work late tonight, and I just really didn’t want to be here in the first place”. They’ll probably communicate the issue, but it’s not going to be with the same sense of urgency. The team is probably not going to find the most optimal solution to resolve it, because, quite frankly, if the team has a low sense of purpose, then they don’t really care about finding the best possible outcome for their users. You can see in my description how product quality suffers.
When a team cares a lot about the impact of their work, they’re going to make sure that that work speaks for itself. In a high purpose environment, the engineer and the team will quickly come together to minimize the impact to their project and keep the team marching towards the deadline. They’re going to come up with creative solutions to minimize impact to their end users, because they really care about delivering something for their customers. They’re going to thoroughly report, advocate clearly, and resolve effectively, again, because they care.
Purpose matters, because it aligns engineers’ work to the customers that they serve. There’s actually some really interesting research about this. The 2024 DORA report found that with high user-centricity, delivery throughput did not correlate with product performance. Let me take a step back and talk about what that means. First off, I’ve talked about the DORA report a couple of times, but I realized I didn’t level set what it is.
The context is, the DORA report is a study that’s performed by the DevOps Research Assessment group at Google, where they collect data from over 30,000 engineering leaders across the world, and then they use that to understand what are the drivers and signals of high-performing engineering teams. This year, what they found is that actually in teams with higher user-centricity, which means higher alignment to their users, delivery throughput, or how fast features get delivered, actually doesn’t correlate with product performance. This means that even if you deliver at half the throughput, it doesn’t necessarily mean that your product is going to be better, as long as you have high user-centricity.
That doesn’t intuitively make sense, because we know that rapidly delivering features to your customers usually builds better products. Why does that happen? In the words of the researchers, there’s no longer a disconnect between the software that’s developed and the world that it lives. The researchers believe that it’s because when a team feels a sense of purpose towards their work and the users that they serve, they’re always going to be pointed in the right direction of delivering value. Purpose matters. It’s what makes teams perform better. It makes them excited about their work. It improves both their collaboration and their job satisfaction.
It’s what improves both the stability, the reliability, and the performance of the product. Then, from an organizational standpoint, it’s what keeps the organization together and reduces attrition. Teams want to work on products that they believe really matter.
4. Psychological Safety
Finally, I want to talk about psychological safety. I want to talk a little bit about what it is as well as what it isn’t, because it’s a word that gets thrown out quite a bit, and I want to make sure that we’re clear on what it means. What is psychological safety? It’s the belief that a teammate can take interpersonal risks without fear of negative consequences. Things like speaking up, asking a question, admitting that something went wrong. It’s what allows team members to do that in an environment where they feel safe and comfortable doing that. There are some really important nuances here that I just want to make sure that we get right. Let’s talk about what it’s not.
Dr. Amy Edmondson, a Harvard professor who really brought this term into mainstream popularity, once said, this term implies to people a sense of coziness, that we’re all just going to be nice to each other. That’s not what it’s really about. What it is about is candor. It’s about being direct, taking risks, and being willing to say, I screwed that up. It’s a common and very misguided understanding of the team when people say things like, psychological safety is comfort, or that it’s a soft type of team. Let me walk through how it manifests on teams. I’m going to continue our story here, so that way you can really see how it would play out.
An important additional factor I want you to consider is accountability, because the way psychological safety manifests, depends on how much accountability is present on the team. Let’s say we’ve got a team, this team that we’re talking about has both low psychological safety and a low sense of accountability. This is what we would call the apathy zone. There aren’t really repercussions for mistakes. Teams don’t really have that much support. What happens is people actually struggle to care about their work because they feel a little bit disengaged. It honestly sounds a lot like a low sense of purpose.
It’s actually true that if you have low psychological safety and low accountability, you’re also likely to have a low sense of purpose. If the bug is identified, it’s probably not going to be treated with much of a sense of urgency, but there’s also not a lot of accountability in doing that. Let’s say this team has a high sense of accountability and still, low psychological safety.
This is what we would call the anxiety zone. It’s that fear of humiliation or punishment or blame that keeps the team from working effectively. If you’ve ever experienced a situation where you want to bring something up, but you really don’t want to sound stupid, or you want to mention that this bug is happening, but you don’t want to out your teammate and have them get in trouble for it, that sounds a lot like this anxiety zone.
In the case of our team here, the individual who discovers it, they might try and scramble and solve it themselves, cleaning it up so that nobody else sees, mostly because they don’t want to be associated with that bug. If they bring it up, they’re worried it’s going to be a blame game. They don’t want whoever maybe caused the bug to get in trouble either. We’re focusing a lot on who did it and why are you bringing this up, as opposed to, how do we actually solve for it? That’s a huge communication failure that keeps the team from focusing on what matters, which is solving this bug before we have this launch.
Let’s talk about higher psychological safety. Let’s say we’ve got high psychological safety, but we have low accountability. This is often what people think about when they talk about psychological safety, and they use it in an incorrect context. In this case, the team does work really well together. They have comfort. They know that they can take risks and speak up, but they don’t really have a push to be held accountable for it. They’ll feel comfortable communicating that issue. They’ll triage the impact, and they’ll find a solution, but there’s not really that sense of urgency placed on the team.
The good news here is that the team does like working together, that’s always great. They know that they can take risks. The bad news is they feel no reason. They’re not compelled to take any risks. The real magic happens when you have both high accountability and psychological safety. The team moves fast. They’re focusing their problems on what to do and how to solve, instead of looking back at who did this or why would you ask that. In our story, this would be the team that would work quickly to identify the impact, put out a solution, and would never put an individual to blame in the process.
The team has the opportunity to learn from their experience moving forward, and they’ll be compelled to do better next time from the lessons that they’ve learned. These are the teams that move quickly, perform well, and learn a lot. Psychological safety is the driver behind taking calculated risks, learning quickly, iterating, and building the most innovative solutions.
For the research here, I want to talk about an extremely impactful and one of my favorite research studies on workplaces, to really highlight just how critical psychological safety is. In 2012, Google endeavored to discover, what is the most performant engineering team? They looked at about 180 teams internal to Google to understand, why do some teams consistently perform better than others. They looked at factors like team size, composition, management style, individual skill sets, so many things.
For a while it was just noise, until they started thinking, what if we measure the dynamics that happen within those teams and bring that in as a data point? Suddenly they started seeing correlations. What they actually found was that these individual factors, like team composition, individual skill set, managerial style, they were actually far less important than how the team worked together. They discovered five key elements in order of importance, from top to bottom, that set successful teams up.
At the top, you have psychological safety, followed by dependability, structure and clarity, meaning, and impact. Psychological safety was so important that they basically immediately created working groups to figure out, how do they make every single team exhibit higher psychological safety so they could gain on their performance? What’s also really nice here is that you’ll see some of the items we talked about from the TAPPs framework are also covered here in Google’s Project Aristotle.
Another really awesome way of showcasing the value of psychological safety is the 2019 DORA report. They evaluated which factors contribute to organizational performance and productivity. What they found is that psychological safety is the only dimension that actually impacts both. Solving for psychological safety will improve not just the productivity of the team, but the performance of the organization, more broadly. The impact is profound. Teams with higher psychological safety are up to 20% more productive compared to teams without it.
On the product side, psychological safety correlates with better product performance across the board, because teams feel comfortable taking risks and experimenting and trying new things, knowing that failure isn’t going to be seen as a threat against their own selves. All these benefits give the organization a huge lift in their overall performance, but also in retention. People want to work on teams where they can take risks, try new things, and do so in an environment that supports them.
Measurement: The Who and How
We’ve now covered the dimensions of the TAPPs framework. I want to spend a little bit time talking about measurement, the who and the how. Then we’ll talk a little bit about how we can apply it to our teams today. Let’s first talk about who’s involved in this process. In an engineering organization, the groups that you can imagine are, of course, the engineers who are on the team, the management, and at the highest level, the executive. You need the team to contribute data, because they’re the ones on the ground experiencing and contributing to the social dynamics.
Of course, giving visibility to management and executives is important for building buy-in, for executing these larger projects. I want to focus on a really key line here that is often overlooked, and we should be talking about. The team should be involved in both viewing and analyzing the data. This might seem obvious to some of you, but it’s actually not the status quo.
As engineers, you can probably relate to the experience of someone sending you a survey to fill out that you spend your hard-earned time on, and then you finish it, and you submit it, and you never hear anything again about what happened. Does that sound like an experience some of you have had? Yes, happens all the time. It turns out that the research overwhelmingly shows that having engineering teams see the data and contribute to the analysis of the data is what’s going to lead to actual change on the team. Why is that? There are two big reasons. One, to contribute the data, teams must trust the data.
In the case of social drivers, the most powerful way to capture that data is to ask the engineers who are living that experience day to day. If an engineer just doesn’t believe that this data is actually going to be used to improve their team, why are they going to spend the time on it? Even worse, if they believe that that data could be used in an adverse way against their team, then they’re certainly not likely to give authentic and honest responses. This is something that was also highlighted in Nicole Forsgren and Gene Kim’s book, “Accelerate”. The second reason is because building alignment is what drives results.
When the team can weigh in on their perspective and build buy-in on what actions the team should take, they’ll feel a greater sense of ownership over that work. When they feel greater sense of ownership over the changes, those changes will get executed faster. We just talked about how autonomy builds strategic alignment by giving the team the independence to achieve an organizational goal in the way that they see best. The same thing goes for driving these performance improvements more broadly. The more you can give the engineering team the opportunity to build alignment in their social drivers and how they work, the better the results will be.
Now that we know who should be involved, let’s talk about how to actually measure this data. In my work, I’ve talked to thousands of engineering leaders, and sometimes I’ll ask them questions like, how are you guys measuring these social drivers today? A very common answer that I get is, we do it in one-on-ones. If you guys have experience with one-on-ones, which I would venture to say at least 80% of the people do, then you probably know something about how those agendas might go.
In a 30-minute discussion, let’s say, you’ve got to talk about your holiday PTO coming up. How’s this upcoming project? Any challenges? Any blockers? What are our priorities for Q4? Let’s make sure to have that performance and career conversation so you’re set up for next year. We forgot to talk about the team social drivers, let’s make sure to cover that too. I don’t know how long you guys have for your one-on-one conversations, but this is a lot to pack in to 30 minutes. That’s a problem, because what that means is that it’s rushed, and the team might not be getting the space to really think about the social drivers that impact them.
Worse, it’s unstructured, biased data. It’s unstructured because you’re probably not going to be listening to people compare apples to apples. What you’ll be hearing is, here’s a story of how trust was impacted in my engineering team. As a manager, those stories are really important, but it’s very difficult to understand how one story compares to another story as far as severity and impact.
More importantly, we’re asking teammates to exchange information on social drivers with another human being. You have to assume a certain level of social drivers being present in order to have that conversation. If you think back to psychological safety, if you have a team with low psych safety, a teammate is going to feel hesitant bringing up some of these situations because they don’t want to get another teammate in trouble, or they don’t want to look like the person who is bringing up all these issues and causing nuances in the team.
In an honest search for information, the strategy of one-on-ones is actually not a very effective way to capture this data. The best way to measure social drivers on engineering teams is through anonymous, aggregated surveys. The biggest criticism we hear is that, and it’s just so hard to set these surveys up so they’re measuring the right thing and getting the right responses. I hear you. Let’s talk about how we can actually do this. To design a survey well, you need a few ingredients. I’m going to use trust as one of our TAPP social dimensions here as an example.
First things first, you need to have a clear research-backed question. This question is actually pulled from one of the research papers we talked about, so it was designed by the researchers at Microsoft in one of their productivity and performance studies. Actually, I’ll share a link so you guys can just get all of the TAPPs questions, the questions that you would want to ask on your team, so you don’t have to even worry about designing this. One thing that I will point out is that it’s a single barrel question, which means it’s only asking one thing, that makes it clear and easy to map to the original dimension.
The second thing is a survey scale. What you need is consistency. Here we’re using a Likert scale, which is, from 1 to 5, strongly disagree to strongly agree. It’s easy to understand. It creates space for outlier answers. Most importantly, you can start to do statistical analysis on this data and see how the mean or the ranges change over time.
Finally, and perhaps most importantly, you want to design the survey to be anonymous and also aggregate your responses to the team level over time. Social dimensions are inherently about the interactions between teammates, and so your atomic unit should really be the team, not the individuals who are responding. To reinforce this and to also keep a high trust environment, you’re going to want to make this data anonymous, and again, aggregated to the team level.
How to Get Started
Now that we know what the social dimensions are, we can understand how best to measure them. Let’s talk about what your teams can do today to go out and start capturing this data. To get started, you’re going to want to focus on three key steps that I’m going to break down. First, you’re going to want to build a process that’s going to allow you to capture this data over time, more reliably. Second, you’re going to want to review the data regularly and with curiosity. We’ll talk about what that means. Third, you want to drive actions and improvement, and create a consistent flywheel, from measurement to improvement.
First things first, you want to build a process to reliably measure TAPPs over time. This means that you’re regularly collecting data so you can analyze how it changes over time. There’s nothing wrong with starting with one-on-ones, but the benefit of moving to a survey-based structure, especially an anonymized and aggregated survey, is that you can more easily establish a process that allows you to see that change over time. You can look at things like the range of responses. You can look at the means. You can see how this graph changes over time.
Suddenly, you’re getting a much better understanding of your team’s psychological safety over a longer time horizon. I also recommend that you measure these dimensions at least quarterly. If you establish a flywheel and good trust with your engineering teams, capturing this data monthly is actually going to be your best bet, because it allows you to capture early signals of changes that need to be addressed, as well as crazy outliers that might be a conversation that you need to have.
Now that we’ve talked about how to set up that process, let’s talk about how to review that data with curiosity in mind. For this, I have a few tips. When you’re analyzing this data, think about changes over time over a single snapshot. Again, if there’s a crazy swing, you’ll want to know what happened there. In general, you want to look at how things are trending over time, because that’ll give you a better sense of how does the team actually operate in their day to day and the social drivers that impact them, as opposed to maybe what happened on a particular Tuesday.
The second thing you want to do is ask yourself, why? As teams we should understand the stories of what’s going on. If you see a giant spike upwards, that could be after a team off-site, where the team really felt like they came together and really understood each other. Or if you see things suddenly shoot down, and you look and say, this correlates with when our deadlines got pushed up by six weeks, and pressure really mounted. Ask yourself those questions. Think about the why. Then, third, I touched on this a bit before, but don’t over-index on a single data point, particularly when you’re looking at ranges.
You really want to think about, how are the averages, or how are the team’s responses changing over time? Instead of, again, really over-indexing on a single data point. Now the team is capturing data and they’re reviewing it regularly, you can now use that data to drive meaningful improvements. For example, if you see a consistent trend of the team’s sense of purpose declining, you could consider bringing your team closer to their end users. Maybe that’s having them listen to some customer success conversations, or having the product team come in and do a lunch and learn where they’re able to talk about this last feature that was built and how it actually impacted the users.
Then, those actions are going to drive changes in your team’s sense of purpose, and hopefully, if you’ve set up a consistent form of measurement, you can see those changes over time. Now you’re able to create this process of continuing to collect the data, analyzing these data, taking the right actions, and seeing change on the other side.
Key Takeaways
First, to capture the top social drivers behind engineering team performance, use the TAPPs framework, that’s trust, autonomy, purpose, and psychological safety. Why do these four things matter? Trust is what unlocks open communication, faster problem solving, and less rework. Autonomy empowers engineers to make decisions faster and solve their problems. Purpose is what aligns engineers’ work to the customers that they serve. Psychological safety enables risk taking, honest communication, and greater innovation. That is the TAPPs framework. How do you go about executing it?
For the best results, engineers should have visibility into data collection and analysis. Of course, you want to make sure that management and executives are involved as well, but don’t leave this line out. The best way to measure social drivers is through anonymized, aggregated surveys. One-on-ones are a great place to start, but if you really want to kick off that flywheel of moving from information to action to measurement, you’re going to want to use a consistent measurement technique like surveys.
To get started today, teams should build a consistent process, review the data regularly, and of course, with curiosity, and drive actions and improvements. When we know the top social drivers that impact a team, we can create a happier and higher-performing engineering culture.
Resources
You can actually access the survey questions for the TAPPs framework, www.getquotient.com/qcon, so if you want to grab that, start measuring it on your team. You’ll also be able to access research from this presentation, and more, and other topics on engineering leadership.
See more presentations with transcripts
