Whitney Diehl

Psychological safety is a hot topic across all industries these days, but in the fast-paced and dynamic world of software engineering, it plays an especially important role in driving innovation and high performance. Yet, what exactly is psychological safety? Why is it so important for software engineering teams in particular, and how can it be fostered?  

To gain real-world insight into this complex topic, Code Climate’s SVP, Customer Organization, Karthik Chandrashekar sat down with Anjuan Simmons, Engineering Coach at Help Scout, Heidi Waterhouse, Principal Developer Advocate at LaunchDarkly, and Lisa Van Gelder, VP of Engineering at Avvir.io, to discuss the importance of safety, the strategies they use to implement it, and how data helps them achieve it. Here are some highlights from their virtual roundtable.

Psychological Safety Heightens Speed and Performance

Lisa: [Psychological safety] gives engineers the ability to fully participate in a team. To give their ideas, to debate ideas, to feel free to take risks, to experiment. And if people don’t feel free to do those things, everything slows down.

Anjuan: I boil psychological safety down to two things, truth and trust. People can live their truth – the truth of their experiences, their history, even the truth of their performance.

Heidi: When I come at psychological safety, I frequently come at it from the sort of scientific side, realizing how much of a difference it makes to the performance of a team. The faster a team moves, the more psychologically safe they are, the more they feel like they can take risks, but also the more they feel like they can take risks, the faster they move.

Learning Your Team’s Lived Experiences Helps Cultivate Safety

Anjuan: I think that leaders have to establish authentic relationships with their directs. One of the easy tactical things to do is to have weekly 1:1s. If you’re a manager and have people who you are responsible for, if you’re not meeting with them weekly in a 1:1, then you’re not engaged in a psychologically safe environment, because you just don’t even know where you are.

[During 1:1s] talk about more than just status or work. Discuss their career and personal goals and see what you can do to be supportive. By having those 1:1s, you begin to get an idea of their background and their profile. You’ll probably find that a number of the people who you work with and who are your directs have gone through trauma brought on by work, especially if they are members of marginalized groups. Knowing [someone’s history] is really important to understanding what team members may not be feeling psychologically safe and steps that you can take to help with that. I’ve never found a one size fits all approach to this. You have to tailor it to the individual people who you’re working with.

Heidi: The more senior we get, the more trauma we have. To this day I have a fear reaction when I’m one-on-one with my manager and they close the door. There’s nothing wrong with closing the door to give me feedback. That is in fact the responsible thing for a manager to do. But I got fired enough at crucial times in my career that I have a fear reaction. And so if I tell my manager [about my fear] they know that, and they preface the conversation with “nothing bad, just a little feedback,” and then I can relax and actually take in the feedback.

I think the idea of moving through the world as a trauma-informed person enables you to be considerate of the scars people are carrying around, becoming a force multiplier for your ability to be a good friend and manager, and to get the best out of the people that you’re working with.

Lisa:  It’s not always obvious if your team is having issues with psychological safety. Ideally, they will tell you, but quite often, especially if you are a new leader on a team, they don’t trust you enough to let you in and tell you what’s going on. You kind of have to go into debugging teams mode, observe them, and see what happens. See if there are strange things that they’re doing that you don’t quite understand, because often there’s a safety issue underneath that.

I once had a team that used to hide around the office on Fridays. They weren’t answering emails, they weren’t answering Slacks. They wouldn’t tell me what was going on either. I did try and ask, but I also sat there the rest of the week with them to try and see what was happening. I realized that people were trying to give them work on Fridays and then they would blame them if it wasn’t done by Monday. On the outside it looked like the team was slacking off, when in reality, it was a safety issue. So when I say look for odd things you may have to do a little bit of detective work to see if something’s happening.

Put Metrics in Context

Lisa: When you think about introducing data or metrics onto your team, I encourage you to think about what those metrics are nudging the teams to do in order to meet those metrics, because it’s really easy to accidentally introduce a metric that would harm the psychological safety of your team.

A lot of the time when I come onto a new team, people will say the engineering team is moving too slow, that they want them to go faster and they want to measure this through the velocity of the team. However, it comes with connotations that the team isn’t working hard enough, and can impact the quality of work being delivered.

A metric I love to use instead is Cycle Time. I love it because it’s a full-team metric. [For example], if it takes an engineer two days to complete a story and seven days to deploy it, you have a better idea of where to start digging to spot areas that can be optimized. Cycle Time encourages you to find the bottlenecks in your system as a team and address them. It also encourages you to break stories into smaller pieces because the smaller your stories, the quicker you can get them deployed. They’re good nudges that help a team work together to solve problems.

Heidi: Metrics are useful for building safety and consideration around your team while still figuring out where your gaps and your problems are in a blameless way. Saying like, okay, here’s where things are sticking. How do we unstick them? Is that actually the first cause?

Anjuan: As an engineering leader who’s often called to figure out how to measure my teams and how to support them in getting better, there are a lot of metrics that are well-meaning, but are often counterproductive, like how many lines of code people do each week.

Some languages are simply wordier than others. So you can actually end up penalizing people working in languages where you may need 50 lines in one language but can do it in three in the other. It can also drive developers to add more crud to the codebase because they’re trying to gain in number of lines of code.

So you really need to take a step back and say “what are we measuring? What metrics are we trying to use?” to see if they are serving us well. And, “are they creating an environment where our engineers feel that they can inspect themselves, learn from their experiences, do their best work, or are we doing something where we’re actually harming them?”

Small Changes in Syntax can Improve the Environment

Anjuan: As I mentioned before, you always want to hone in on the lived experiences of the people who come through the doors of your company, whether they’re physical or virtual. There’s so many things that you can do to help take our industry, which is still steeped in colonialism, misogyny, transphobia, and all these horrible things, to begin debugging your work. So for example, at Help Scout, we took the common scrum term “backlog grooming” and changed it to “backlog refinement” because the word “grooming” has negative connotations. That small change was a nod to the fact that we understand that some words can be triggering to some people.

One other quick example: master/slave is used in weird ways in our industry when there’s better terminology out there. You can use “main,” for example. So again, if you look for these terms you can make changes to make a better environment.

Heidi: I love the example of the master/slave terminology because it’s also a safety check for your team. If somebody fights you really hard on that, there’s someone to keep an eye on because they are not considering how other people on the team might feel about it. They are attached the way things were.

Anjuan: We also talk about how, when people use the word “guys,” right? People in Slack will say, “Hey guys, I have a question.” Why are you assuming that everybody in the Slack channel are all male, right? Just [changing] little small things like that, you’re debugging your environment to be more inclusive, to be more open.

To find out more about using data to help foster psychological safety on your team, request a consultation.

Technology leaders looking to drive high performance can support the evolution of their teams by creating a culture of feedback in their organization. Read on to find out why honest and constructive feedback is crucial to engineering success.  

The Importance of Routine Feedback

Regular feedback on particular units of work, processes, and best practices can be an effective way to help ensure agile teams are aligned and that all requirements are understood and met.

Employees who receive regular feedback on their work feel more confident and secure in their positions because they understand what is expected of them and the role they play in the organizational structure. According to one report, only 43% of highly-engaged employees received feedback on a weekly basis, while an astonishing 98% said they fail to be engaged when managers give little to no feedback, showcasing how essential feedback is to the cohesiveness of teams.

Furthermore, a positive culture of feedback can enhance psychological safety on teams. When feedback is a fundamental part of a blameless team culture, team members understand that feedback is critical to growing as a team and achieving key goals, and will likely feel more secure in sharing ideas, acknowledging weaknesses, and asking for help.

How to Foster a Feedback-rich Culture

As an executive, it is important to lead by example, as your actions can serve as a benchmark for best practices to be followed throughout the organization.

Leverage the Power of 1:1’s

Regular check-ins can play an integral role in building a successful feedback culture. Providing dedicated time for managers and direct reports to discuss goals, share feedback, and more, 1:1’s are a great way to engage employees and build trust.

During your 1:1’s, you’ll have the opportunity to ask questions and make statements that:

1. 1. Build an interpersonal connection – “How are you and your family”
   2. Encourage collaboration – “What’s on your mind? Is there anything I can help you with that you may be stuck on?”
   3. Show recognition, appreciation, or provide coaching

Here at Code Climate, our executives and managers hold weekly 1:1’s with their direct reports to surface any process blockers, discuss ambitions, and generally catch up. We are committed to this practice as a way to foster safety, transparency, and cohesion within our organization. We aim to ensure that each team member understands how their work fits into larger company initiatives and feels secure enough to share ideas that enable us to continually innovate and improve.  

Enhance Feedback with Engineering Data

The most effective feedback is specific and actionable, so it can be helpful to use engineering data to ground conversations in particular units of work. For example, if you have a question on a specific Pull Request, it can be helpful to surface detailed information on that particular PR to help you place progress in context and check any assumptions you may have. Objective data can also help you identify areas where coaching may be beneficial or showcase areas where you might not have known an IC was excelling. Furthermore, data can help you set and track progress towards goals, adding value and effectiveness to your feedback.

Feedback Goes Both Ways

A culture of feedback is most effective when it’s holistic, so it’s important to make sure you’re giving your team members the opportunity to impart their feedback on processes, workflow, expectations, and more. To help achieve this, you can provide your team members with a forum to share viewpoints during 1:1’s, standups, and retrospectives. In doing so, you regularly afford yourself the opportunity to actively listen to and learn from your team.

Feedback is an essential tool that helps leaders drive excellence on their teams. Remember:

• A culture of positive feedback helps create the ideal conditions for innovation
• 1:1’s can be a powerful way to build trust and create alignment
• Engineering data can help you place observations in context
• A true culture of feedback requires that team members are also empowered to speak up and offer their feedback

With a thoughtful approach, you can cultivate a safe and welcoming work environment that motivates teams to strive for excellence. To find out how to employ data-driven feedback in your organization, request a consultation.

As part of our ongoing series on data-driven performance reviews, Code Climate Founder and CEO, Bryan Helmkamp, sat down with Katie Wilde, VP of Engineering at Ambassador Labs, and Smruti Patel, Head of Engineering, LEAP & Data Platform, at Stripe to discuss the intricacies of performance reviews and how to best conduct them with the help of objective data. Read on to learn how leveraging objective data in your reviews can improve retention, mitigate bias, and positively impact developer confidence. To see the conversation in full, check out the recording here.

Performance Reviews – Intended and Ancillary Benefits  

Objective data can assist in conducting fair and equitable performance reviews that help to improve retention and save organizations the added expense of sourcing and hiring new talent.

“Engineering hiring right now is extremely difficult, and what would be really great is if you didn’t have to backfill roles on your team. If you manage to retain people, that’s way better than having to hire a bunch of new folks,” Katie says, adding “[Performance reviews] are extremely important for cultivating and retaining our top people and that’s a different ‘why’ to the kind of thing people think of with performance reviews… yeah, sometimes we need to fire people for not doing a good job, but it’s actually far more important to make sure that the people that are doing a fantastic job don’t leave.”

To Katie’s point — a survey conducted by LinkedIn reports that, depending on the role, it can take the average organization over 40 days to fill a technical position, while the US Bureau of Labor Statistics projects that the demand for software engineers will grow 22% over the next decade, signaling hiring challenges to come in the space.  

Echoing Katie’s sentiment, Smruti adds “[Data-driven performance reviews] are key for supporting your high performers who want a formal way of [understanding], what does the next year look like? Or what does the next part of the journey look like? And so for me, this process, at the very least, provides missing data where a manager or organization might not even be aware of all the things that [a developer] is involved in, or the initiatives that they’ve led and delivered.”

Using Objective Data to Combat Biases

Biases are a noted flaw of performance reviews, and a great way to mitigate those prejudices is to check assumptions against objective data.

Katie has seen firsthand the inequities gender bias in particular can cause. In one instance, when it came time to review a female engineer, Katie noticed inconsistencies between the engineer’s self-review and her peer reviews. While the engineer had given herself a strong rating, her peers stated that her work pace was a little slow. Katie decided to dig deeper and determine the cause of this discrepancy: had the engineer overstated her own abilities, or were her peers being overly critical?  

Using Code Climate, Katie dug into the engineer’s work and discovered that her PRs were in fact moving more slowly through the development pipeline, but not for the reason one might expect. Her PRs were getting held up in code review by change requests, and the requests were often for minor, stylistic changes. Further investigation revealed that requests of this kind were not common across the team, and PRs written by male engineers tended to be approved quickly, without getting stuck in a similar feedback loop. With this information, Katie was able to check her assumptions, calibrate her feedback, and uncover bias in both the review process and the team’s day-to-day work.  

Reflecting on the experience, Katie says “So that review cycle for that entire team went a completely different way than if I hadn’t used data. [Without objective data] I absolutely would have done the review of, give all the men great reviews, tell the woman she needs to be more productive and get her act together, that she’s got some decent skills, but she’s got to do a better job, not promote her, and carry on. It’s just quite eye-opening. I am a woman in engineering. I know how hard it is. So yeah, that’s a case where I’m just very grateful to have had that data.”

Articulating Impact with Engineering Data

Many times during the performance review process, ICs are asked to conduct a self-evaluation. This portion of the review process surfaces an opportunity for ICs to share their perspectives on their own performance, actions, and choices. It also helps managers understand how ICs view themselves in relation to their team and the company as a whole.

Citing personal experience, Smruti observed that ICs can be so focused on what they’ve built and delivered, that they often fail to see why their work mattered and the impact it had on the organization. She noticed that this lack of self-advocacy rang especially true for underrepresented minorities. To combat this, Smruti uses data to link individual achievements to verifiable facts to help ICs break the glass ceiling of self-perception.

“So for me, when it comes down to quantifiable or qualitative data, it comes down to finding the right engineering data that best articulates that impact to the team on business goals. So if you think about it, you can use a very irrefutable factor, say, ‘I shipped X, which reduced the end-to-end API latency from 4 or 5 seconds to 2.5 seconds. And this is how it impacted the business.’”

In using objective data, ICs are able to see the impact their work has on their organization, and advocate for themselves to secure promotions and higher salaries.

The Annual Performance Review Process, Optimized

With Engineering Intelligence data at their fingertips, leaders can develop a review approach that places quantitative and qualitative data into context to deliver meaningful and actionable feedback that promotes the well-being of ICs and the growth of their teams.

Speak to a Code Climate expert and see for yourself how data can help you conduct more effective annual performance reviews and drive engineering excellence.

Standups are a cornerstone of the Agile process and an essential ceremony in many engineering organizations. A great way to facilitate knowledge sharing, team cohesion, collaboration, and more, standups can help keep projects on track and clear of roadblocks. However, standups as we know them are in need of some TLC. When you meet with your team every day and ask the same questions, it can get monotonous, and engagement may be lackluster.

To step up your team’s standups, you’ll need to move beyond the typical standup questions. A Software Engineering Intelligence (SEI) platform like Code Climate can help you do that, making it possible to get your status updates before standup, so you can spend the meeting digging into at-risk work, addressing potential blockers, and helping to drive work forward. Code Climate aggregates data from DevOps and project management tools, acting as a single pane of glass for engineering managers to gain visibility into their team’s sprints and help them better prepare for the day ahead.

Without the help of an SEI platform, your standup likely looks something like this:

Engineering Manager to Dev: What will you do today?

Dev: Today I’m finishing up the Health Check feature. Dev2 had been working on it all week, but they passed it on to me before taking their vacation. Should have everything I need.

Engineering Manager: Great, let me know if there’s anything you’re missing.

Short and perfunctory, this conversation only skimmed the surface.

With the help of a Software Engineering Intelligence (SEI) solution, an engineering manager can more clearly identify at-risk work and potential blockers before standup, so they know exactly what to ask to get past surface-level updates. That means standup can look more like this:

Dev: Today I’m finishing up the Health Check feature. Dev2 had been working on it all week, but they passed it on to me before taking their vacation. Should have everything I need.

Engineering Manager: Ok, I also see there were multiple discussions on the feature that required you to make a change in the code two weeks ago. Did the requirements change?  

Dev: Actually, there have been bugs reported so I am adjusting my approach.

Engineering Manager: Ok, let’s grab some time this morning to walk through your approach step-by-step as this has been a tricky part of the codebase.

Because the manager came to standup with context on the PR in question, they were able to dig deeper and ask questions that uncovered potential risks. Both parties were then able to walk away from standup with clear objectives and next steps to keep the sprint healthy and on track.

There are many ways to structure standups, but one fact always rings true — the more prepared you are walking into standup, the more effective your meeting will be. Request a consultation to learn more.

Effective engineering leaders today deftly balance the needs of their organization with the needs of their developers. Tasked with making strategic decisions, coaching their teams, and driving process improvements to meet business objectives and key results, leaders are often distanced from the actual work of writing code. As such, leaders must empower their team members to excel, and engineering intelligence data can help in a number of ways.  

Find out how data can help you cultivate an engineering environment that drives success in our new ebook, The Engineering Leader’s Guide to Empowering Excellence with Data.

Focusing on four key areas—removing blockers, minimizing micromanagement, personalizing coaching, and fostering a culture of psychological safety—our ebook will help you gain actionable insights from data, rather than gut feelings, to achieve a developer-focused work environment.  

With the right data, you can determine when to step in to lend support, and when to step back and encourage autonomy, so you can empower your team members to go above and beyond. Used thoughtfully, data can help you build stronger, more successful teams and drive continuous improvement.

An empowered team is a successful team. Download our ebook (for free!) today.

The final principle in the Agile manifesto urges developers to reflect on the past and use that knowledge to improve future outcomes. Since we learn from the past, holding sprint retrospectives is key to improving the results of future iterations. Conducted well, sprint retrospectives can boost outputs and propel teams forward; conducted poorly, they may breed toxicity. The careful use of objective data can help you steer your retro in the right direction — read on to find out how to leverage data from the beginning to the end of the retrospective process, so you can maximize the value of this key opportunity for continuous improvement.

Preparing for Your Sprint Retrospective  

Practices vary by organization, but sprint retrospectives may be facilitated by anyone familiar with the sprint, from a developer on the team to a stakeholder from another department. If you find yourself in the facilitator role, it’s crucial that you build a strong foundation for your retro by performing an audit to collect data in advance.

Look back on the lifetime of the sprint, and ask yourself questions like:

1. What was finished?
2. Did we deliver all the items we intended to? If not, why?  
3. What specific units of work didn’t get shipped?
4. What bottlenecks or blockers arose, and are they part of a pattern?

The answers will help you identify patterns and problem areas and formulate meaningful conversation points to guide the retrospective.

For example, if your sprint finished with a lot of unshipped work, you’ll want to know that in advance, so you can dig into the reasons during the retrospective. Look for unassigned tickets, which may indicate that some units of work were not prioritized correctly or that tickets were lost or overlooked unintentionally — though you’ll need to bring these tickets up at the retro to know for sure.

You’ll also want to look at the Issues from the iteration that are still categorized as In Progress, and see how many days they’ve been open. You can dig deeper by looking at the Pull Requests (PRs) associated with that Issue, and taking a look at relevant activity and comments for each. This can help you formulate a hypothesis as to why a unit of work was unshipped. For example, Issues with many PRs may indicate that work was not batched efficiently, while PRs with high levels of Rework may signal that an engineer was struggling with a difficult area of the codebase, or unclear technical direction. You can further investigate that hypothesis during your retro by discussing particular units of work to gain additional context and information.

While you can piece together this information from your VCS and project management tools, gaining a holistic view can be tedious as this data is typically dispersed. A Software Engineering Intelligence solution, like Code Climate, can save time and add a layer of valuable insights by aggregating that data in a series of customizable dashboards and rich visualizations.

Prioritize Your Sprint Retrospective

Typically, retrospectives last approximately 30 minutes for each week of the sprint, so if your sprint was three weeks long, you may want to carve out an hour and a half for your retro. Keep this time frame in mind to help you prioritize speaking points and focus on conversation topics that will keep your team engaged and on task.

Once you have compiled a list of topics, see if you discover any common themes and group them together. It may be helpful to get the perspective of your team members when you reach this point. Here at Code Climate, our facilitators ask the team to vote on which items should be talked through first to ensure engagement and alignment.

Open the Floor to Collaboration

In order to have a productive retrospective — one that surfaces meaningful opportunities for improvement — the team must feel safe talking through any missteps. The purpose of a retrospective is to measure processes, not individuals, so it’s important to remind your team to focus on the work, and not on the people behind it. As you set the stage for your retro, keep in mind that the data you gathered during preparation is to be used purely as an empowerment tool. When used appropriately, data can keep the conversation grounded in facts and tackle negative biases, allowing you and your team to have genuine conversations about things that could have been done better without making developers feel singled out.

Discuss

Now to discuss. Based on the topics you prioritized, you can split your sprint retrospective discussion portion into easily digestible parts. Though format can vary based on team and personal preference, many teams focus on three categories using a “Start, Stop, Continue” exercise, which asks developers to provide feedback on the following:  

• Start: Actions we should start taking
• Stop: Actions we should stop or do away with
• Continue: Actions we should continue and codify

It can be helpful to use a visual aid to facilitate this exercise and keep the conversation on track. For in-person teams, that might mean distributing sticky notes that can be written on and affixed to a board; for remote teams, that might mean using a collaborative online platform like Trello. Take time to talk through each part, and…

Develop an Action Plan

By the end of the sprint retrospective, you and your team should have several actionable ideas to put into practice to help the next iteration go smoother. While this data is qualitative in nature, these new ideas can then be measured against the quantitative data (such as PR size) they are meant to improve during the next sprint, enabling you to enhance software development strategies as time goes on.  

Standardize Sprint Retrospectives and Keep Improving

Best practices are best utilized when reinforced. Each new retro you hold keeps you on the path of continuous improvement.  

While there is no golden rule as to how retros should be structured and held, some form of review is vital to achieving continuous improvement. By incorporating data into your retros, you can maximize the value of your discussions and help build a highly capable team that can successfully drive business goals.

Engineering metrics can be a powerful tool for tracking and communicating engineering progress, debugging processes, boosting team performance, and much more – but they must be wielded with care. When misused, metrics can backfire, creating confusion and resentment.

To help engineering leaders successfully leverage metrics, Code Climate has partnered with  LeadDev on a series of blog posts and webinars that explore the fundamentals of data-driven leadership. Drawing on the expertise of engineering leaders from a range of industries, we highlight real-world perspectives on the what, why, and how of measuring as an engineering leader. We touch on everything from selecting the best metrics to track for your organization, to introducing metrics successfully, and specific use cases, like using metrics to run more impactful standups.

Here are some key insights:

• “I’ve found that metrics are valuable in helping zero in on what might be getting in the team’s way. Instead of treating them as a way to judge performance, I believe metrics are most useful in bringing to light areas of opportunity.” Leslie Cohn-Wein, Engineering Manager, Netlify
• “First and foremost, I use metrics to help me identify what the biggest bottlenecks are across different teams. Without metrics, I’d be left to make this judgment based on hearsay instead of methodology. The second reason I use metrics is to understand changes over time, particularly as we undergo organizational changes or make investments in specific areas.” Abi Noda, Developer Experience Expert
• “Cycle Time is a metric that I consistently come back to — it’s a great proxy for engineering speed, and can be a useful high-level look at whether certain key decisions are having the desired impact. If we’re moving slower than we had been, I can then isolate parts of the engineering pipeline and investigate where exactly things are going off track.” James McGill, VP of Engineering, Code Climate
• “The outcomes of productive standups ripple throughout the engineering team. By discussing specific metrics in standups, you can tell if your team is moving forward. You can ensure that the risks are being addressed from an objective, quantifiable standpoint rather than opinion.” Khan Smith, VP of Product, Code Climate

To dig deeper into what engineering leaders are doing today with metrics, check out the full series.

Ready to get started with engineering metrics in your organization? Contact our product specialists.