Code Climate

Mapping Engineering Goals to Business Outcomes When an engineer is deep in code, fixing a bug or completing a review, it can be hard to connect the dots between these actions and what seem like unrelated company objectives. In traditionally structured organizations, the business sets goals for engineering based on its understanding of the market, customer needs, and the numbers it must achieve to appease investors. Without a clear understanding of how engineering activities impact business objectives, it’s difficult for engineering leaders to make informed strategic decisions, keep teams aligned, advocate for resources, or communicate successes. Engineering leaders must understand these business objectives, map their work to them, and clearly communicate them to engineering teams and non-technical stakeholders. Learn more on our blog. #engineeringleadership #engineeringmanagement #engineeringexcellence

What Causes a High Number of Review Cycle? A high number of Review Cycles in engineering might stem from a combination of challenges that hinder the efficiency of the process. These include differing interpretations of what constitutes "done," misalignment between the expected changes and the actual changes resulting from the review, or conflicting views on the best approach to implement a solution. If there are anomalies where Review Cycles are high for a particular submitter, it could indicate they’re struggling with the codebase or aren’t clear about the requirements. This presents an opportunity for leadership to provide individualized coaching to help the submitter improve the quality of their code. The first step in addressing a high number of Review Cycles is to identify the reason PRs are being passed back and forth, which requires both quantitative and qualitative information. By looking at Review Cycles alongside other PR metrics, leaders can look for correlations. For example, Review Cycles tend to be high when PR Size is high. If this is true in your organization, it might be necessary to re-emphasize coding best practices and encourage keeping PRs small. Leaders might also want to do a closer review of PR data to understand which PRs have the highest Review Cycles. They can bring this information to the teams working on those PRs to uncover what exactly is causing the PRs to bounce around in review. Maybe there’s a misalignment that can be worked through, or requirements are shifting while the project is in progress. Leaders can work with teams to find solutions to limit the number of times PRs are volleyed back and forth by establishing expectations for reviews, how solutions should be implemented, and when a review is complete. Best practices for the PR review process should be documented and referenced by all team members. Learn more on our blog. Link below👇 #engineeringmanagement #engineeringleadership #engineeringmetrics

Navigating New Technology Expectations and Realities Software engineering leaders now face increased pressure to achieve more with fewer resources, often under metrics that oversimplify their complex responsibilities. It's no secret that widespread layoffs have affected the technology industry in recent years. Despite this, the scope of their responsibilities and the outcomes expected from them by the business haven't diminished. In fact, with the adoption of new technologies, these expectations have only increased. Viewing software development solely in terms of the number of features produced overlooks critical aspects such as technical debt or the routine maintenance necessary to keep operations running smoothly. Adding to that, engineering leaders are increasingly pressured to solve non-engineering challenges within their domains. This disconnect between technical solutions and non-technical issues highlights a fundamental gap that can't be bridged by engineering alone—it requires buy-in and understanding from all stakeholders involved. This tension isn't new, but it's becoming front-and-center thanks to the promises of new technologies mentioned above. These promises create higher expectations for business leaders, which, in turn, trickle down to engineering leaders who are expected to navigate these challenges, which trickle down to the teams doing the work. Recently, a Code Climate Velocity customer was undergoing a significant adoption of GitHub Copilot, a powerful tool. This particular leader’s finance team told her, "We bought this new tool six months ago and you don't seem to be operating any better. What's going on?" This scenario reflects the challenges many large engineering organizations face. Learn more on our blog.

Monthly Software Engineering Metrics to Understand Team Performance Data-driven insights can provide engineering leaders with objective ways to evaluate developer competency, assess individual progress, and spot opportunities for improvement. While quarterly KPIs and annual performance reviews are great goalposts, managers are constantly thinking about how their teams are progressing toward those targets. Reviewing engineering metrics on a monthly basis is a good way to assess month-over-month progress and performance fluctuations on an individual level and a team level. Which metrics a team considers depends on its defined framework and overall company goals. Here are a few to consider: >PRs Merged vs. PRs Reviewed Looking at these metrics together can show how the two key responsibilities of writing and reviewing code are spread across a team. >Review Coverage vs. Review Influence This helps leaders understand what amount of thoroughness of Code Reviews results in a desired action. >Review Cycles vs. Cycle Time To understand the effect that back-and-forth cycles in Code Review have on shipping speed, leaders can look at Review Cycles vs. Cycle Time. >Impact vs. Rework Comparing Impact and Rework will show which teams are making the most significant changes to the codebase and how efficiently they are doing so. Learn more on our blog. #engineeringmanagement #engineeringmetrics #engineeringleadership

What Causes a High Number of Review Cycle in Software Engineering? A high number of Review Cycles in software engineering might stem from a combination of challenges that hinder the efficiency of the process. These include differing interpretations of what constitutes "done," misalignment between the expected changes and the actual changes resulting from the review, or conflicting views on the best approach to implement a solution. If there are anomalies where Review Cycles are high for a particular submitter, it could indicate they’re struggling with the codebase or aren’t clear about the requirements. This presents an opportunity for leadership to provide individualized coaching to help the submitter improve the quality of their code. The first step in addressing a high number of Review Cycles is to identify the reason PRs are being passed back and forth, which requires both quantitative and qualitative information. By looking at Review Cycles alongside other PR metrics, leaders can look for correlations. For example, Review Cycles tend to be high when PR Size is high. If this is true in your organization, it might be necessary to re-emphasize coding best practices and encourage keeping PRs small. Leaders might also want to do a closer review of PR data to understand which PRs have the highest Review Cycles. They can bring this information to the teams working on those PRs to uncover what exactly is causing the PRs to bounce around in review. Maybe there’s a misalignment that can be worked through, or requirements are shifting while the project is in progress. Leaders can work with teams to find solutions to limit the number of times PRs are volleyed back and forth by establishing expectations for reviews, how solutions should be implemented, and when a review is complete. Best practices for the PR review process should be documented and referenced by all team members. Learn more on our blog. #reviewcycles #engineeringmanagement #engineeringleadership

How to Use DORA DevOps Metrics in Large Organizations In startups, engineering actions are often more directly linked to business goals, making it possible for leaders to understand what engineering is doing and communicate its impact. For example, if a startup is launching its flagship product, contributors from sales, marketing, and product management collaborate with engineering, often with executive support and oversight, to ensure the business goals are met. They consider what the product does, how it works, why it matters, who will benefit from it, and how it will be sold. Startups often have shared key performance indicators (KPIs) and operate on a single timeline. Now scale that same workflow across dozens of teams launching and maintaining different products on varying timelines. While engineering will aim to align goals with business objectives, those goals may vary from team to team, and success will look different for each group. That’s why it’s crucial to establish which metrics are important to the company as a whole and create a framework to measure them. Establishing a framework to measure engineering success ensures that managers are measuring teams in a consistent and equitable way so they can identify and resolve bottlenecks to optimize the flow of work. Using a framework like DORA is a great place to start. The four DORA metrics, Deployment Frequency (DF), Mean Lead Time for Changes (MLTC), Mean Time to Recover (MTTR), and Change Failure Rate (CFR), can be communicated to leadership to give them a holistic view of how the engineering organization is performing.When implementing DORA, it’s important that organizations start by agreeing on how these metrics will be measured. Unified calculations and standards (i.e. company-wide agreement on what is considered an "outage") are critical for measuring effectively throughout an organization. Standardizing on these four metrics and how they will be measured provides uniformity across teams and creates a common language between engineering and company leadership. DORA metrics help teams balance speed and stability and are good big-picture checks into the health of the organization. Managers can use DORA to see how things are trending over time and spot when a team isn't working as expected. However, they must keep in mind that while it can be instructive to benchmark teams within an organization by identifying what high-performing teams are doing that others can learn from, it's important to note the context. Managers must understand that teams tasked with different kinds of work and different projects will naturally have variations in their DORA metrics, which is normal and expected. Learn more on our blog. #DORAmetrics #engineeringleadership #enginneringmanagement

"We bought this new tool six months ago and you don't seem to be operating any better. What's going on?" - Finance Team This scenario reflects the challenges many software engineering leaders face. Here's how they can take actionable steps to address challenges with new technology such as AI, No-Code/Low-Code, and SEI Platforms: 1. Acknowledge the disconnect with non-technical stakeholders, fostering cross-functional alignment and realistic expectations. Facilitating open discussions between technology and business leaders, who may never have collaborated before, is crucial for progress. 2. Clearly outline the broader scope of engineering challenges beyond just writing code—evaluating processes like approval workflows, backlog management, and compliance mandates. This holistic view provides a foundation for informed discussions and solutions. 3. Establish a shared understanding and language for what constitutes a healthy engineering organization is essential. #engineeringleadership #genai #engineeringmanagement

How to Navigate New Technology Expectations in Software Engineering Leadership By Andrew Gassen, Sr. Director of Customer Org at Code Climate Technology is evolving very quickly but I don't believe it's evolving as quickly as expectations for it. This has become increasingly apparent to me as I've engaged in conversations with Code Climate's customers, who are senior software engineering leaders across different organizations. While the technology itself is advancing rapidly, the expectations placed on it are evolving at an even faster pace, possibly twice as quickly. There's Generative AI, such as Copilot, the No-code/Low-code space, and the concept of Software Engineering Intelligence (SEI) platforms, as coined by Gartner®. The promises associated with these tools seem straightforward: >Generative AI aims to accelerate, improve quality, and reduce costs. >No-code and Low-code platforms promise faster and cheaper software development accessible to anyone. >SEI platforms such as Code Climate Velocity enhance productivity measurement for informed decisions leading to faster, efficient, and higher-quality outcomes. However, the reality isn’t as straightforward as the messaging may seem. >Adopting Generative AI alone can lead to building the wrong things faster. >No-code or Low-code tools are efficient until you hit inherent limitations, forcing cumbersome workarounds that reduce maintainability and create new challenges compared to native code development. >As for SEI platforms, as we've observed with our customers, simply displaying data isn't effective if you lack the strategies to leverage it. While the potential of these technologies is compelling, it's critical to address and understand their practical implications. Often, business or non-technical stakeholders embrace the promises while engineering leaders, responsible for implementation, grapple with the complex realities Learn more on our latest blog. #engineeringleadership #genai #engineeringmanagement

How Does Your Software Engineering Organization Compares to the Industry? Download our benchmarks report to assess where your software engineering organization stands. The benchmarks were established by analyzing data from roughly 300 Code Climate Velocity customers over the past year, using robust statistical methods to ensure accurate results. #benchmarksreport #engineeringleadership #engineeringmanagement

How to Use Data to be a More Proactive Software Engineering Manager (Part 2) Long Term Strategy: Support Professional Growth and Improve Team Health A proactive EM also needs to identify struggling IC’s, while simultaneously keeping high performers engaged and challenged to prevent boredom. This starts with understanding where each individual IC excels, where they want to go, and where they need to improve. Using quantitative and qualitative data, an EM can gain a clearer understanding of what keeps each IC engaged, surface coaching opportunities, and improve collective team health. Qualitative data on each IC’s coding history — Commits, Pushes, Rework, Review Speed — can help signal where an IC performs well and surface areas where it might be useful for an EM to provide coaching. An EM can then use qualitative data from 1 on 1’s and retros to contextualize their observations, ask questions about particular units of work, or discuss recurring patterns. For example, if an EM notes high levels of Rework, this signals an opportunity to open up a meaningful discussion with the IC to surface areas of confusion and help provide clarity. Or, an EM might see that an IC has infrequent code pushes and can coach the IC on good coding hygiene by helping them break work down into smaller, more manageable pieces that can be pushed more frequently. Using a combination of both data sets, an engineering manager can initiate valuable dialogue and create a professional development roadmap for each IC that will nurture engagement and minimize frustration. #engineeringmanagement #engineeringleadership #engineeringdata