Leadership

Recent headlines might lead one to conclude that it’s more difficult than ever to build a high-performing team. Hiring is increasingly competitive, salaries are on the rise, and a growing number of people are choosing to switch jobs or exit the workforce entirely. But building a stellar team is about more than just recruiting great talent — it’s about investing in the talent you have. And that’s not investment in the financial sense (though salaries and benefits are important!), it’s a commitment to coaching and upskilling your existing team.

Focusing on professional development is a win-win. Helping developers excel will boost team performance. Ensuring that developers feel both challenged and supported will increase their job satisfaction and make them more likely to stick around.

How Can You Help Developers Upskill?

Of course, helping engineers level up their skills is a multi-layered process. Time and money set aside for learning is important, but it’s not enough. As a leader, there are things you can do to create a culture where positive feedback is welcomed, missteps are seen as learning opportunities, and developers feel comfortable openly discussing their professional goals. Once the cultural foundation is set, you can make adjustments to incorporate coaching into your team’s processes and help ensure that it remains a priority.

Culture Is Key to Leveling Up

Psychological safety is a prerequisite to the success of any coaching or professional development initiatives. In order for developers to have honest conversations about their career goals, or to be comfortable receiving feedback, they must trust that they will not be penalized for aspirations that are out of alignment with current responsibilities.

Though psychological safety is essential, it is just a baseline. An organization looking to prioritize professional development may also benefit from adopting elements of Continuous Improvement. In Continuous Improvement, every member of a team is on the lookout for opportunities to make incremental improvements. The underlying belief is that even small changes to processes, products, and more can have a big impact.

At the individual level, it would be detrimental to engage every team member in a conversation about one engineer’s professional development. The critical takeaway from Continuous Improvement is that improving should not be a top-down process. When it comes to coaching, it’s important to empower individuals with an active role in their professional development. They can actively contribute by identifying areas of incremental improvement, making plans for their own development, and setting and tracking progress toward goals. When they are involved in making plans, they’ll be more likely to see them through. As they realize the value of making small, positive changes, they’ll be motivated to keep learning.

Create Regular Touchpoints

At the process level, effective upskilling requires consistent check-ins and conversations. Regular 1:1s are a great opportunity to surface opportunities for upskilling, and to evaluate progress toward goals. Come prepared with observations and discussion points, and encourage your team members to do the same. Give them the chance to raise their questions and concerns first, so you can get a more complete understanding of what blockers are impacting them the most, and what skills they’d most like to improve. Make their goals a priority whenever possible, and seek out opportunities to challenge team members to envision how their goals align with business priorities.

These touchpoints will be most effective when a baseline of safety has already been established, though it’s still important to be proactive about reinforcing trust during 1:1s. Practicing vulnerability can help establish the right tone. You may also want to remind team members that 1:1s are not meant for work-related status updates, but for bigger picture conversations about their role, skills, and aspirations.

Leverage Data To Coach More Effectively

Leaders can supplement qualitative conversations with Engineering Intelligence data from a platform like Code Climate. With the help of objective data, it’s possible to cut through biases, check assumptions, and more accurately assess how a particular developer is working.

For example, you may observe that a particular team member rarely contributes in meetings, and only speaks when spoken to. You may conclude that this team member is not engaged or invested in their work, or that they don’t value collaboration. Engineering data can help you test that hypothesis. You might find that this same team member is an active participant in Code Reviews, frequently leaving thorough, impactful feedback for their peers. Where you once might have encouraged this team member to be more collaborative, you can now offer more specific feedback around participating in meetings. Alternatively, you may decide to accept their participation in reviews as evidence of their commitment to teamwork, and instead, work with them on another area of growth.

You can also use engineering data to identify specific units of work that may present learning opportunities. For example, if you notice that a developer has an abnormally large or long-running PR, you can have a conversation about the circumstances that are drawing things out. This allows you to surface potential anti-patterns or areas of weakness that may benefit from coaching. You may learn that the developer is having an issue with that particular area of the codebase, or you may find that they would benefit from coaching around coding hygiene.

It’s important to remember that metrics are not diagnostic, and quantitative data must always be placed in context. Different projects will naturally progress at different speeds, and non-code-related factors can impact the data. One engineer may appear to be struggling when in reality, they’re simply working through a tricky problem. Another engineer may be adding value through glue work that isn’t as recognizable as shipped code. If you’re gathering relevant context and having open, honest conversations with your team, you’ll be able to determine whether a concerning data point has a reasonable explanation, is an anomaly, or indicates something that needs to be addressed.

Data can do more than help you surface potential areas for improvement. It can help you make those improvements a reality. Goals are more effective when paired with objective data. Metrics make it possible to set and track progress towards specific, actionable targets, which will set your team members up for success. You and your team members will be able to align on exactly what they’re working toward and see how effectively they’re getting there. If progress seems to stall, you can check-in and re-evaluate your tactics — or the goal itself.

Upskilling Is Key to Building a High-Performance Team

Coaching and professional development take time, but they’re critical to driving success and retaining your top performers. It’s not enough to simply hire talented people, as even the most skilled developers will be looking for opportunities to keep growing. With a mixture of cultural and process-level adjustments, you can help create an environment that encourages development while still advancing business priorities.

To find out how to leverage data from a Software Engineering Intelligence (SEI) platform to upskill team members and boost retention, request a consultation.

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.

Knowledge silos are more than just a frustration or an inconvenience — they’re a serious threat to productivity. Yet with a few tweaks to team processes, and a commitment to intentional communication, engineering leaders can break down existing knowledge silos, and make it less likely that new ones will form.  

What are Knowledge Silos?

Knowledge silos are individuals or groups in possession of information that is not readily accessible to the rest of an organization. Sometimes knowledge silos are formed by the intentional withholding of information — an individual or team wants to be the go-to source for answers on a certain topic — but often they’re the result of workflows that fail to encourage collaboration and knowledge sharing. Generally, “knowledge silo” is not used to describe situations where the information in question is privileged or confidential, but rather, situations where sharing information would enable team members to work more efficiently or effectively.

What Do you Stand to Gain from Knowledge Sharing?

When engineers lack access to key information, they might end up spending time devising a new solution to a problem that has already been solved elsewhere in the codebase. Or, they may be forced to make assumptions, some of which will be incorrect, about how their work fits into the broader context of a feature or roadmap. When your team is solving the same problems over and over, or acting on incorrect assumptions, they’ll be less efficient, more frustrated, and more likely to perform unnecessary rework. In the more extreme cases, when knowledge only resides with one person on a team, that person’s absence can bring work to a standstill.

At Code Climate, an initiative to promote intentional knowledge sharing, including logging key decisions and documenting new tracks of work, helped boost throughput almost 70%. A broader study, GitHub’s 2021 State of the Octoverse, found that specific knowledge-sharing practices like creating and maintaining up-to-date, quality documentation, can increase developer productivity by 50%.

How Can you Break Down Knowledge Silos on Your Engineering Team?

Knowledge silos are a natural and expected part of any evolving organization, particularly as it scales, but there are process-level measures leaders can take to actively encourage knowledge sharing.

• Documentation – Though writing code may get all the glory, writing documentation is critical to the success of engineering projects. Documentation allows teams to share context and to align on everything from best practices to project specifications. When documentation isn’t written or maintained, information is harder to access. Engineers not only need to know who to ask about a particular feature or project, they also have to feel comfortable reaching out with their question.
• Pair Programming – Knowledge exchange is one of the most well-known benefits of pair programming. When two developers are working on the same piece of code, they’ll exchange context and perspectives to arrive at a shared solution. With pair programming, more junior team members will have the opportunity to ask questions; more senior team members can share wisdom culled from their own experiences; and team members with different specialties and skill sets can learn from each other.
• Code Review – While different organizations employ different best practices for Code Review, it is a fundamental opportunity for engineers to share knowledge and offer feedback to help improve each other’s work. If you’re using a Software Engineering Intelligence (SEI) solution like Code Climate, metrics like Review Speed and Review Influence can help provide a sense of whether engineers are prioritizing Code Reviews, whether reviewers are leaving impactful feedback or rubber-stamping code, and if PRs are evenly distributed among reviewers. If one reviewer is disproportionately commenting on certain kinds of PRs, or PRs associated with a particular area of the codebase, that could indicate a potential knowledge silo.
• Draft PRs – Designed to encourage collaboration, Draft PRs enable developers to signal to potential reviewers that code is a work in progress while still opening the door for feedback. This allows developers to gain perspective from teammates at the earliest stages while ensuring that work in progress code does not get merged or prematurely factor into any review metrics being tracked in an SEI platform.

By implementing processes that require communication and collaboration, teams can actively encourage information sharing, rather than leaving it up to chance. With more information exchanged, existing knowledge silos will break down, fewer new ones will form, and overall team productivity will get a boost.

To learn more about using an SEI platform to spot blockers like knowledge silos and improve engineering processes, 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.

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.

This is the second post in a two-part series. Read the first post here.

When you use an Engineering Intelligence Solution to answer the classic three standup questions, you free up your team’s valuable meeting time for an even more impactful set of conversations. You’ll be able to spend less time gathering information and more time leveraging your expertise as a leader — once you’re no longer using facetime to surface issues, you can actually start solving them.

To frame these conversations, I recommend a new set of questions to ask in standup meetings:

• How can I help remove distractions?
• How can the team help reduce risk?
• Are we working on the right things?

Here’s how to get the most out of each one.

Question 1 to ask in standup meetings: How can I help remove distractions?

To most effectively answer this question, you’ll need to come to standup prepared. Take a look through your Engineering Intelligence Solution and keep an eye out for patterns that might indicate your team’s attention is fragmented, such as engineers who are making commits on multiple different Issues, or team members who have stopped committing for a few days. Code Climate's Software Engineering Intelligence (SEI) solution offers visualizations of individual developers’ coding activity, which makes these patterns particularly easy to spot.  

If you notice an engineer bouncing around, committing to multiple pieces of work in a short time period, it’s possible that engineer is trying to do too much at once. Have a conversion with that developer, and find out exactly what’s causing them to work in this way. It’s possible that they’re trying to make progress on multiple fronts at the same time, or that they’re being pulled in different directions by external forces, bouncing from project to project whenever a stakeholder asks a question or requests a status update. As their manager, you’re in a position to help the engineer develop the tools they need to devote the necessary level of focus to each unit of work. Exactly how you help depends on the situation — a more junior engineer may benefit from some coaching in project management skills, while a more senior engineer may need assistance contextualizing and prioritizing their work.

Of course, every engineer is juggling multiple things at once, and it’s not uncommon for someone to jump to a new project while they’re waiting for a Pull Request (PR) to be reviewed. Still, there’s a point at which task switching becomes excessive, and the visualizations in an SEI platform make that really clear, revealing potentially problematic switching in a haphazard assortment of commits, or delays getting back to paused units of work.

Sometimes, the delay itself is noteworthy. If an engineer is committing to something every day, then stops for a significant period of time before picking it back up again, it’s likely they’ve been pulled away to work on something else. Given how much time engineering teams spend grooming and prioritizing their backlog, this sort of deviation from the plan can be problematic, and yet, well-meaning developers often say yes to side tasks and additional projects without thinking about the cost. As a leader, if you notice this occurring, you can help your team members determine whether unplanned work is worthy of urgent attention, and remind them to assess any new tasks with you before taking them on.

Question 2 to ask in standup meetings: How can the team help reduce risk?

This question gets to one of the key goals of standup meetings: spotting and resolving problems before they derail sprints. Work that is at-risk is work that has started to go off track but hasn’t gone completely off the rails yet, which means you have the opportunity to stay a step ahead of a real problem. An SEI platform will alert you whenever a unit of work meets your criteria for “at-risk,” whether it’s a PR that has stalled without review or one that has too many contributing engineers, giving you the opportunity to quickly get the work back on track.

While some at-risk work can be indicative of larger issues — outdated processes or recurring bottlenecks in your development pipeline — at-risk work is often the result of a miscommunication regarding who should be doing what. For example, it’s common to see work get stuck in work in Code Review because everyone thought it was being reviewed by someone else on the team. When you bring risky units of work to standup for discussion, your team can quickly implement any straightforward fixes, then set aside time to work through bigger issues.

Question 3 to ask in standup meetings: Are we working on the right things?

With an SEI solution, you can easily see what units of work are progressing, so you can ensure your team members are working on the right things. Let’s say you prioritized tickets coming into your sprint, but notice that a developer is committing against the lowest priority Issue — you can discuss this as a team and rebuild alignment in the moment, rather than pretending you’ll always get it right at the top of the sprint. Almost certainly there was a miscommunication, and the developer jumped on what they thought was an important unit of work, though it’s also possible that an engineer thought the low-priority item was easiest to tackle and wanted to get it out of the way. This is rarely a good reason not to work on the highest priority things, and you can help coach the developer back to more important units of work. In some cases, the low-priority item may be the only thing the developer understood, so they jumped into it despite its low importance. This is important to know and address because if one person on the team doesn’t understand something, chances are other members of the team are also confused.

Whatever caused the low-priority item to be started, the team now has the opportunity to decide what to do about the unit of work in question. It may be that the work is so far along it makes sense to finish it, or it may be something the team decides to pause until higher-priority work is completed. Without a SEI solution, there would be no choice to make, as you’d only find out that someone was working on the ‘wrong’ thing after the work was already complete.

Data is a Powerful Tool for Skilled Managers

Though some leaders hesitate to leverage data, fearing that it breeds micromanagement, it’s important to remember that you’re already gathering information about stalled work or stuck engineers. Standups are one of the many ways managers seek out that information, but they’re not the most efficient way, since meeting time is better used for solving problems than surfacing them.

True micromanagement is not found in the gathering of data, but in how that data is used; micromanagers wield punishments and prescribe solutions, while great managers ask questions, offer guidance, and help their teams collaborate on solutions. With a Software Engineering Intelligence (SEI) solution pointing you towards work that needs attention, you’ll spend less time looking for opportunities to help and more time actually managing your team.

It’s no secret that performance reviews are flawed. Not only is occasional feedback unlikely to affect meaningful growth, but the feedback itself can also be suspect — studies indicate that numerical ratings reveal more about the rater than the person being reviewed, while open-ended evaluations are subject to a host of performance review biases.

Despite this research, most companies still rely on some form of performance review. They’re not ready to pivot from the idea of using reviews to promote professional development, and many employees aren’t either. As an engineering leader, you may not be able to overhaul your company’s review process, but you can still take steps to minimize some of its flaws. Engineering data found in your VCS and project management tools can help by acting as a check against anecdotal evidence and gut feel, helping you combat some common performance review biases.

Common Performance Review Biases

Biases may be evident in nearly every aspect of your day-to-day, but the open-ended format of most performance review frameworks is particularly vulnerable to some common biases. If you’re aware of their existence, you can take steps to counteract them.

Recency Bias

When reviews happen infrequently, the period of time right around review season is freshest in the reviewer’s mind and tends to be given the most weight.

What you can do: A skim of the Issues a developer worked on over the past year can be an important reminder of all they contributed, and a great way to refresh your memory. In addition, a deep dive into specific engineering metrics can help you distinguish longstanding patterns from recent anomalies. For example, you may have noticed that a developer is prioritizing their own work and putting off reviewing teammates’ Pull Requests. By looking at trends in a metric like Review Speed, you can determine whether or not that’s a new development, so you can calibrate your conversation accordingly.

Halo/Horns Effect

The Halo/Horns Effect occurs when a manager lets one trait — good or bad — skew their entire impression of an individual.

What you can do: There may be an engineer on your team who rarely speaks during meetings, and only participates when directly spoken to. You could take that as evidence that they’re generally disengaged at work, but data might reveal otherwise. If that same engineer has a consistently high PR Throughput and frequently participates in Code Review, it’s more likely that they just don’t like speaking up in group settings. With this information, you can offer specific feedback about their participation in meetings, rather than general (and inaccurate) feedback about their overall level of engagement, or you can adapt your expectations to match their work style.

Gender Bias

Studies show that reviewers tend to focus more on the personality traits of women and female-presenting individuals than on their skills or accomplishments.

What you can do: Make a conscious effort to focus on an individual’s work, and be sure to check any of your assumptions against objective data. For example, you can look at a developer’s history of commits, pushes, and review activity to confirm whether their work is in line with your expectations for a developer in their role. You might expect a more senior developer to spend less time committing new code and more time giving feedback to their teammates, but your expectations may be the opposite for a more junior team member.

Similarity Bias

This is the tendency of a manager to look more favorably on team members who remind them of themselves, perhaps due to a particular personality trait, a shared work style, or an aspect of their training or background.

What you can do: You may feel a particular kinship with a developer and assume that they’re achieving at the level you would in their role, but a look at the data — whether it’s their PR Throughput or a review of their contributions to Code Reviews —  can help you regain perspective and ground your assessment in the reality of their work.

Using Data to Check Your Performance Review Biases

Data is not only a valuable tool for dismantling performance review biases, it can help you deliver specific, actionable feedback and collaborate with developers to set clear goals for the future. As with any tool, however, it must be used carefully.

Quantitative data should always be contextualized with qualitative data, and it’s important to resist the urge to compare or rank the members of your team. Developers coding new features will naturally work at a different pace than those working through technical debt, and team leads will likely be focused more on coaching or project management than committing code. You’ll need to pair data with an understanding of the circumstances surrounding each team member’s work in order to have a complete picture of their overall performance.

If you’re interested in learning more about incorporating data into your performance reviews, request a consultation.

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.