We're used to measuring the effectiveness of our product's reach, the strength of our marketing, and the progress of our KPIs. But to understand the foundations of a team's success, and support that success going forward, take a look at engineering productivity. Holistic measures of engineering productivity give you concrete insight into how your team's doing and where support could be most valuable. They also act as a benchmark against which to measure the adoption of workflow improvements and policy changes.
Three pillars of engineering productivity
In order to measure and support engineering productivity, we first have to understand what engineering productivity is. Productivity can be broken down into three pillars: efficiency, quality, and developer satisfaction. These work together in presenting a more nuanced view of developer productivity than the "lines of code" metric of yesteryear.
Efficiency refers to how quickly engineers move through the development process. For teams that release product updates, for example, efficiency could be measured in cycle time or deployment frequency. While efficiency is sometimes the most visible component of engineering productivity, blindly chasing speed without regard for quality or satisfaction is a recipe for disaster.
Quality is the backbone of a team's achievements. It doesn't matter how many updates a team pushes if all of them are bug-ridden. To truly boost productivity, look to improve code quality at the same time as you increase efficiency. High-quality code leads to less developer time spent on debugging and troubleshooting, which improves productivity in the long term.
The final, quieter productivity pillar is developer satisfaction. Are developers happy with the software development life cycle? Do they feel in control, empowered, comfortable? These questions matter more than you might think. Developers are more likely to be efficient and write quality code when they know they're supported and they know where to find the information they need. In the long term, developer satisfaction also reduces turnover, and the associated reduction in onboarding time can be a big boost for a team's overall productivity.
Engineering managers should look to all three of these pillars in tandem to assess their team's overall productivity. Each concept by itself is important, but it's the way they interact that really affects developer productivity. Productive teams develop faster, release fewer bugs, ship often, and are satisfied with their work. This has benefits down the line for other teams and for end users.
Measuring productivity inputs and outputs
It's easy to mistakenly track the wrong things and make developers feel like they're just numbers on a screen. A major pitfall of most metrics is a feeling that they don't really mean anything — developers learn to game metrics like KPIs and lines of code, not because of malice but because they understand that those metrics don't offer a well-rounded view of their productivity anyway. Data-driven policies are the gold standard for operational efficiency, but the wrong data is worse than no data at all. To maximize relevance and usefulness in your metrics, break things up into inputs and outputs, and seek out holistic measures that take all three pillars of productivity into account.
Productivity inputs are what you have control over, the initiatives you put forth to make it easier for teams to be efficient. Unit testing, accountable ownership, and branch-based development are examples of inputs in the productivity equation. Monitor these inputs, and you'll have a good sense of where to expect productivity increases, or where teams can benefit the most from some external support. Many teams find that focusing on standardizing and documenting inputs is a great place to begin their productivity improvement journey.
Outputs tell you whether your initiatives are working or not. DORA metrics are good holistic measures that make useful proxies for developer confidence. Additionally, PR cycle time, review time, velocity, and developer time-to-code are all outputs that can give engineering managers and leaders visibility into where productivity initiatives are succeeding and where they might be stagnating.
One last rule of thumb is to not base people decisions on metrics. Productivity metrics are great for improving visibility into overall team function, but at the individual level, basing performance reviews or promotions on these metrics is a recipe for disaster. Focus instead on employing holistic, team-level productivity metrics to see where organizational change can happen and to identify bottlenecks and areas of risk.
Leveraging developer portals to improve team productivity
Introducing policies and workflows to boost productivity and team performance is an ongoing, ever-evolving task. Follow the three steps below to start with the fundamentals and work up to tools that leverage automation and increase access to knowledge. Developer portals can bring many of these tools to your fingertips easily, simplifying the process of connecting developers to workflow tools and institutional knowledge.
1. Establish a baseline
Positive change requires solid groundwork. You can't tell how much impact a policy is having if you have no baseline against which to compare outcomes.
So, when starting to improve productivity, first think about what you want to measure. For example, is it important for you to see how autonomous your engineers are? As mentioned, DORA metrics are useful as a proxy for autonomy. Another proxy would be measuring how long it takes to get developers set up and coding once they're onboarded. A reduction in onboarding time helps boost aggregate productivity and makes newer team members feel more autonomous and satisfied in their work. To do this, you would gather a baseline developer time-to-code (the amount of time it takes a new hire to push their first product code) and work through the rest of the steps in this article with that metric in mind.
Developer portals aggregate data in a way that makes it easier to see and monitor trends, eliminating the guesswork of setting baselines for team productivity. For instance, if you want to set a baseline PR cycle time, you can use a tool like Scorecards to aggregate information about where your team's at now. Later on, use those same scorecards to see if the PR cycle time has improved.
2. Improve access to knowledge
Developers can get overloaded by the amount of discrete touchpoints in their everyday roles. This makes it difficult to focus and almost impossible to find what they're looking for. With the help of a developer portal, engineers have a single pane of glass showcasing everything they're working on and all of the resources available to them. Looking for a pull request? Here it is. A Jira ticket or action item from a scorecard? No problem! Having information within arm's reach at all times makes it easier to trust that you'll be able to find what you need quickly. This reduces the stress of constantly needing to keep all of these resources in your head and boosts efficiency.
Visibility into ownership and documentation also helps improve engineering velocity by reducing friction when developers work with tools made or maintained by other teams. It's rare to find a software development team that's so well-insulated from others that they don't have to touch any outside tools. A developer portal is a great way to eliminate bottlenecks by streamlining how developers find, use, and learn about those tools.
3. Reduce duplicate work and administrative burden
One big timesink loathed by engineering leaders everywhere is the duplicate work problem. When a developer can't find the tool someone else has already created, they waste precious time redoing work, sending engineering velocity plummeting. By using a service catalog, all of the services your organization has built are arranged into a simple-to-use repository with visibility into ownership and current status. Developers can reference that repository, helping teams save time in aggregate by encouraging the use of solutions made elsewhere in the company.
In addition to reducing duplicate work, teams can also improve efficiency by reducing the administrative burden associated with deploying new services. This burden can arise from good intentions—DevOps teams may define best practices that promote high-quality development but require extra “busywork” from engineers. Tools like the Scaffolder give organizations the best of both worlds, by making it simple to spin up compliant services quickly. Developers no longer have to do the administrative work involved in following best practices, but they get to reap the rewards of services that conform to organizational guidelines and are structured exactly as expected.
4. Monitor ongoing initiatives
Most teams don't have automation set up for security initiatives, platform migrations, or package version upgrades. Instead, developers spend time figuring out what manual processes they should be working on, reporting their outcomes and cleaning up loose ends. This is a textbook example of inefficiency, and hampers a software development team's productivity. A developer portal like Cortex that leverages automation to streamline this type of work reduces toil for developers and gives them more time to focus on important, creative tasks like building new features.
Cortex initiatives provide a seamless experience for engineers wanting to stay on top of their workload. Initiatives highlight core metrics that really matter to developers, giving them visibility into what is affecting them personally. These metrics, including deployment frequency, lead time for changes, mean time to recovery, and change failure rate, offer multiple viewpoints from which to consider whether software engineering teams are spending their time effectively. These high-level metrics help leaders avoid falling into the trap of measuring individual productivity through easily gameable metrics, and shift the focus to improvements at the team level.
5. Track progress and establish new goals
Of course, no policy change is complete without an analysis of how it affects engineering performance. Once you've spent some time establishing a baseline and pulling some levers to improve productivity, it's time to track progress.
Take a look at the outputs for which you set baselines earlier. Have you seen meaningful positive change in DORA metrics, or PR cycle time, or developer time-to-code? Just as scorecards were helpful in tracking down baseline numbers, they're now useful for monitoring whether those numbers are moving in a good direction. If you're seeing positive progress, congratulations! Figure out your new baselines and start the process over again. If your metrics are stagnating, no big deal. Narrow down your focus, or set smaller goals, and revisit the places where you can introduce tools and workflows to empower teams and encourage efficiency.
Parting wisdom for supporting successful, productive teams
Productivity isn't just lines of code, it's a holistic idea that values getting the most out of software engineering time. Tools like the Cortex developer portal have pre-built productivity monitoring features that seamlessly integrate with your development workflows to provide visibility without bogging your team down.
Cortex empowers your engineers to be their most productive selves by giving them the information they need to succeed, and helps engineering managers understand where their teams can best be supported. Book a demo today to see how Cortex can help you measure and boost engineering productivity.
