Rethink Your Understanding

Transforming Software Delivery

Metrics

Maximizing Technology Team Performance: Insights from a CEO Conversation

by

6 min read

In this article, I share an enhanced version of a conversation with a CEO in August of 2022 regarding the effectiveness of technology teams, measuring improvement, building the right things, and how understanding the purpose and value of their work can impact team effectiveness.

The Importance of Purpose and Value

Achieving success requires understanding the purpose and value of your work. If disconnected from a shared vision, it is vital to pause and reconsider. When clear on how you are adding value, teams can collaborate optimally, prioritize tasks effectively, and comprehend the importance of their efforts. Effective teams solve problems with a sense of mission while being driven by what they bring to these solutions in terms of purpose.

The Measurement Challenge

I recently talked with a CEO from my network about the challenges of measuring the productivity and performance of software engineers and teams and determining if we are making progress. Measuring developer productivity has been a persistent challenge for engineering leaders for decades.

In this discussion, the CEO, whom I’ll refer to as Steve, insisted on his VP of Engineering report on the organization’s engineering productivity. Despite being familiar with outdated metrics centered on individual output, Steve was open to new ideas. As I shared my experience working on this issue in my organization, he was interested in learning how we measure and report the return on investment of the value delivered.

Measuring Progress and Building the Right Things

To assess improvement, it’s crucial to measure both delivery performance and the outcomes of our efforts. Steve mentioned that technology is responsible for measuring delivery performance, but I emphasized the importance of the business quantifying the impact of change and communicating it to delivery teams. Product managers should assess and measure the return on investment of value delivered to stakeholders. However, measuring the ROI of work delivered and business outcomes can be challenging even for experienced leaders. During the conversation, we discussed delivery team performance, but I also wanted to explore the impact of having a clear purpose and value on delivery performance. I asked Steve about his experience measuring the impact or ROI of value delivered by teams.

I suggested: “What if a team could improve from delivering five widgets per week to eight, with the same number of team members and the same number of hours?” I asked Steve, “Did we get better?” His answer was “Yes,” but I disagreed. “How will we know that we are building the right things?” and “How will we know that we have not overproduced and wasted time?” I stated, “the additional three widgets may not provide the expected value, and we could be wasting time and effort without realizing it. Are we overproducing?” As Jonathan Smart said, “Making the wrong thing faster only makes us wronger.” This marked a turning point in the tone of the conversation.

Building the Right Things with Purpose

“People work better when they know what the goal is and why. It’s important that people look forward to coming to work.” – Elon Musk.

The conversation shifted to understanding and communicating value and outcomes rather than just focusing on output. Steve commented that it wasn’t the job of a Vice President of Engineering to question the value; this responsibility for questioning and communicating feature work value lies with the Product Manager, or more likely, the senior product leader — not the head of engineering. Not surprisingly, I took his comments personally. Changing tactics, my intention now was to tie employee engagement back to knowing the value of the work. I asked Steve about employee retention and whether it was the responsibility of the Vice President of Engineering; he agreed and added that it was the responsibility of the Engineering Senior Leader to build a great employee experience and culture.

I brought up the concept of purpose-driven development, where people are motivated by a sense of meaning and fulfillment in their work. I asked Steve about his understanding of extrinsic and intrinsic motivation and if he believed people could be driven by autonomy, mastery, and purpose beyond salary. He agreed. I took this opportunity to tie in the value of engineering teams needing to know the value. Without a shared understanding of value, teams can become demotivated and feel like they are just following orders. To avoid this, it is crucial for everyone from the executive team down to the delivery team members to understand the value of the work they are producing. This leads to more efficient work and prevents wasted energy from overproducing or creating unwanted items. The goal is to ensure that work occurs efficiently and that teams feel a sense of purpose and connection to the outcomes they deliver.

We circled back to the origin of the conversation about measuring performance. The conversation ended with the question, “How do we know that engineering delivery teams are getting better?” As a technology leader, we will measure engineering delivery performance to identify ways to continue improving (get better). My takeaway highlights the importance of understanding the value of what we are producing and how it impacts customer experience and the organization’s goals. Only then can we genuinely answer if we are making progress and delivering the right things.

Measuring the actual outcome of delivery

As colleagues serving our actual customers, the external ones, it is our responsibility as IT and Product to ensure value is delivered to the customer and organization. This helps to reduce the risk of waste through the overproduction of incorrect items and allows us to motivate and retain our team members through purpose-driven development.

Delivery teams must focus on the efficiency and effectiveness of what is being delivered. Unless an experiment is being run to determine the usefulness of a product to a customer group, delivering items of work that have no value to the customers or targeted customer population is a waste of time and energy.

Beyond senior leadership, delivery teams should engage in value-driven discussions, considering the customer’s and organization’s goals, expected outcomes, and the value that will be provided to people. This helps to ensure that the team has a clear understanding of the purpose behind their work.

The product owner is responsible for explaining the value behind each feature and how it connects to the organization’s goals. If the product owner cannot do so, they should re-evaluate their approach. Teams should not be reduced to mere “feature factories” without a clear understanding of the purpose behind their work.

Leaders must measure productivity and performance improvements and communicate the value and outcomes of what their teams are delivering. This creates a shared understanding throughout the organization and ensures that valuable work time is spent on creating truly needed things.

Team members should know how their work contributes to the organization’s performance and customer engagement, fostering a sense of purpose and engagement. This helps to avoid wasting resources in terms of money, employee engagement, and other aspects.

Unfortunately, teams often do not see the outcomes of their delivery. Measuring and reporting on these outcomes is important to determine if the right things were built and if the organization is improving.

Final thoughts

Just as IT is held accountable for measuring and improving productivity, the product team and the organization should be held accountable for communicating value and for measuring and communicating the outcomes of the delivered value. To answer the question, “Are we improving as we get bigger?” one must consider delivery performance and know the outcomes of what has been delivered (are we building the right things?). Defining value and communicating outcomes are essential to ensure everyone is aligned and working towards the same goal.

Link to the next article, value part two: Unlocking the Value of Software Delivery: Difficulty of Reporting on Value

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others.

Let’s talk: [email protected].

Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks.

by

13 min read

Note: This article has two parts: First, a view on today’s data insights and metrics. Second, our experience researching the tools in the market.

Data is key to improvement, but it is not just about collecting and reporting it. We must use the right data for the right purpose to improve flow and efficiency, and team health. The way that leadership approaches the metrics ultimately still has the largest impact on success. We can unleash our full potential and reach our goals by adopting a metrics-driven improvement culture and methods that provide insights to encourage and motivate teams.” ~ Phil Clark

What is great software delivery?

To be excellent at delivering software, deliver the right changes efficiently, frequently, with quality, and get customer feedback. Move quickly with the confidence and knowledge that you are building the right things with quality and security. Innovate, Adapt, learn, and solve real customer problems faster than your competition.

What problem are we trying to solve?

Better ways of measuring software delivery performance.
How can we make the most optimal impact? We can assess software delivery team performance with useful metrics that both the organization and team members desire and those that encourage and enable teams to experiment and drive their own improvements. With a continuous improvement mindset, no matter how good we are today, we will get just a little better tomorrow.

Digital Product Workflow

Digital products flow across three primary stages: Product Discovery, Product Delivery, and Operations.

If you are performing value stream management, you create an end-to-end (concept to cash) cross-organizational flow of work for the value stream throughout the organization, understanding both upstream and downstream work and eliminating dependencies, waste, and friction.

End-to-end, Product Discovery, Product Delivery, and Product Operation: All stages of digital product management from idea generation to production or customer use, a.k.a concept to cash.

Product Discovery: The conceptual vetting stage of a digital product, from idea to backlog. Ideation, discussion, evaluation, and consideration for which features or products to prioritize and build to set the stage for increasing organizational performance.

Product Delivery: The delivery stage of a digital product, backlog to production.

Product Operation: The operation and support stage of a digital product.

Product discovery uncovers what creates value, while product delivery produces what creates value.

Measuring engineering performance

How are we doing? What are we doing well? What areas can we improve? What are we getting from our investment?

Measuring engineering performance has historically been a low point of my 20+ year technology career. During the first decade in technology, I was assessed solely as a practitioner by the metrics of that time. I vividly recall the metrics constantly reinforcing the notion of being perceived as a mere cog in a machine and the disheartening label of being a cost center.

As a manager, I was responsible for evaluating the performance of software engineers using the same criteria that I was assessed on as a practitioner. Based on these metrics, I would make decisions regarding individual team members, including stacked ranking. I have experienced the negative impacts on culture, engagement, and adverse side effects stemming from legacy metrics that treated people like machines (individual productivity measures, lines of code, and tracking hours).

Knowledge work is distinct from the repetitive workings of a mere machine.

Avoid measuring individual development activities in your business as it harms team dynamics and productivity; doing so will not help you reach your business goals, making it an ineffective use of time and resources. It is not just about the performance of individuals but all about successful teams. A shift to focusing on team outcomes and capabilities and measuring performance for continuously improving team flow is inspiring. Today’s delivery teams are seeking ways to maximize efficiency and streamline workflows. They can now access meaningful metrics to verify their efforts are paying off. By utilizing these revolutionary team metrics, teams can gain visible insights and signals to enhance their product development and delivery process further.

Whether Flow- or DORA-based, today’s metrics should combine system/process data (quantitative) and self-reported data (qualitative).

We are not the teams of yesterday

Significant influences have shifted how we can instrument and measure engineering performance (IT, digital product delivery) from the past. 

The team’s design has changed: shifting from large, skill-based functional silos that hand off work to the next functional team to small, cross-functional teams that can deliver solutions with the least dependency on other teams.

Capabilities have changed: architecture (microservices, DDD, event-driven, lambda, serverless computing, and more), culture, team design, continuous integration, continuous delivery, cloud strategies, automation, quality practices, SDLC (agile, lean), DevOps, platform engineering, and more.

Systems measures have changed (quantitative): It provides visibility to change the system rather than focusing on the individual people.

Dora Metrics (Product Delivery: Development to Production)

Flow Metrics (Product Discovery and Product Delivery: Idea to Production)

  • Project to Product by Mik Kersten
  • Lean practices and Value Stream Management (VSM) and Flow metrics
  • Platforms: There are several options in the VSM and Flow space, such as Planview Tasktop Viz

Self-reported data around team health and sentiment metrics have improved (it can be both qualitative and quantitative).

People aren’t happy because they’re successful; they’re successful because they’re happy. Happiness is a predictive measure. 1

  • Developer Experience (DX); I recommend and focus on Team Experience (TX)
  • SPACE, a New Framework to Understand and Measure Developer Productivity
  • Platforms: DX (getdx) plus one that focuses on team experience (TX) like TeamRetro or agilityhealth. Most likely, several more in the market should be mentioned here. 

Note: I have no equitable affiliation or endorsement benefits from any of my recommendations

Separate the business from the team conversation

Separating business pressure to drive metrics from a team’s motivation to use metrics for improvement is crucial. Teams that focus on continuous improvement and have visibility into metrics can identify and solve bottlenecks, leading to better outcomes and aligned results with business expectations. Metrics can be imposed by the business, risking gamification, or embraced as tools for team improvement.

Teams need motivating metrics. When teams manage improvement insights, they view the metrics as feedback to provide visibility into areas where they are performing well or where they can improve. They mine for bottlenecks and improve overall flow and outcomes. Despite their imperfections, metrics like these help to evaluate the outcomes that teams produce rather than just focusing on the numbers or outputs of individual contributors. Through monthly reviews, the teams can collaborate and develop ways or experiments to improve the bottlenecks.

How might metrics be viewed differently between the business and the delivery teams?

Business interest (focus in on the numbers): 

  • Are team metrics, the numbers, improving?
  • How can we predict the delivery estimates of a team?
  • Are department metrics improving (aggregate of all teams or portfolios)?
  • What actions are teams taking to improve?
  • Capacity, development cost per product, and return on investment.

Benefits:

  • Team throughput and delivery insights.
  • Time to market.
  • Improved predictability.
  • Delivery performance is an artifact of organization valuation. Over time, this creates a higher-quality system with fewer problems.

Risks: 

  • Pressure for individual metrics. Developers are more than just coders. Overemphasizing individual developer focus can be detrimental to team culture and overall performance. It is the collective effort of teams that delivers software, not the work of individual developers.
  • Organization leaders with a heavy hand push on the numbers. Teams use gamification to drive numbers, please the business for what their company wants to see, and risk limited or no real improvements to throughput.
    • If you still fear team gamification and misuse of metrics that defeat the value of modern ways to measure and motivate efficiency improvement, consider improving your leadership before blaming the tools or teams.
  • Comparing teams, pitting them against one another and the behaviors that arise from this, and knowledge hoarding. Each team’s work is most likely different than other teams’ work, making it difficult to compare.
  • Retention.

Teams view (focus on bottlenecks and conversations):

  • How are we doing? Where and how can we move the needle to improve throughput flow?
  • What areas are we doing well? Why might this be?
  • What are our bottlenecks to flow (what steps in our workflow take the longest time)?
  • What are the current obstacles we face regarding lead time, cycle time, PR time, and failure rate?
  • Where can we reduce waste? Can automation help?
  • What capabilities or practices can we change or add to help us?
  • What types of work need to receive the proper attention?
  • More experienced teams: How do we compare to similar cohorts or cohort clusters in the industry (if this data is available)?

Benefits:

  • Teams have the data insights to highlight underlying bottlenecks.
  • Improved time spent in active states versus wait states.
  • Collaboration and knowledge sharing across teams.
  • Autonomy, teams have meaningful metrics to allow them to solve efficiency problems (address the bottlenecks).
  • Teams use qualitative feedback (sentiment metrics) to encourage conversation, improve collaboration, and reduce toil and friction.
  • Team member engagement and employee retention.

Risks:

  • Focusing on individual team member performance. It has been my experience that small teams will not tolerate underperforming team members over time; if the team can’t solve the concern, they can surface the issue to the individual’s manager. I like using the analogy of a music band. The other band members will recognize an underperforming band member.

Leaders must avoid the outdated mindset of individual metrics, measuring individual productivity and lines of code and having teams compete against one another (comparing teams by metrics). Instead, leaders should focus on metrics that improve team flow and delivery efficiency. These metrics should combine system/process data (quantitative) and self-reported data (qualitative).

“When teams recognize the value of today’s metrics and utilize them to enhance their delivery flow, focusing on the bottlenecks and friction points, the business numbers will naturally follow suit. By embracing this approach, improvements become inherent, allowing the numbers to care for themselves.”

Qualitative Metrics: Developer Experience (DX) versus Team Experience (TX)

Prioritizing workplace happiness is crucial for success as it can lead to improved productivity, innovation, and revenue. It surpasses traditional metrics and should not be considered a perk but a key driver of a more profitable workplace.

Developer experience (DX) has been a hot topic in the technology industry lately. Most organizations build software as teams; I speak for cross-functional teams that consist of developers and other roles necessary to deliver software. Developers construct the code, but the whole team must provide the solution.  I recommend ongoing survey questions for self-reported qualitative metrics centered on developer and team feedback (TX). Earlier in this post, I shared the names of a couple of solution providers.

Team experience (TX) includes day-to-day work delivering work on teams. It encompasses all the different points of friction team members encounter in their work, including the organization’s tools, processes, and culture. Improving TX is critical to the business’s bottom line, as research shows it is a top predictor of engagement, productivity, and satisfaction. Companies with top-quartile team experience outperform their competition regarding productivity and their ability to innovate faster.

Summary on metrics

Effective teams want to improve. By offering teams a clear strategy, including an illustrative map (like a value stream or flow map), and specific expectations of outcomes, they can be afforded autonomy. They will be free to make their own decisions. Additionally, by providing them with team-based metrics that spotlight any bottlenecks in their process, the team members can confidently decide how best to positively improve the overall efficiency and effectiveness of their role in the workflow.

The business still needs to see results. Assuming team autonomy and motivating team metrics, as a business leader, you can step away from the teams and leave them alone to do their best work. You identify leaders to support the team to focus on outcomes and performance. You can focus on aggregating the signals of the metrics that matter to you. There is no “one” metric to gauge efficiency. Combining the feedback from multiple signals before raising concerns would be best. This approach means you don’t have to interrupt people or teams to get them to justify their numbers unless you have concerns. Suppose the data over a more extended period raises concerns. In that case, you can gain an understanding from the team of what might be happening and provide any guidance or action that may help them get back on track, if necessary.

A fresh perspective on performance measurement is emerging in the industry. These metrics focus on optimizing flow across the organization and should provide system and process level data (quantitative data) combined with self-reported health metrics data (qualitative data) to remove negative impacts on team culture. This improves engagement and puts improvement decisions at a team level. With this approach, the entire organization should see gains in optimizing the flow of work and improving delivery outcomes.

Removing the pressure of the business’s view on the team’s metrics is essential to foster confidence and trust that the team can review and act on insights, allowing them to identify areas where they can improve how they deliver software. To better insights and increase team engagement, using system-measurable metrics and regular, consistent surveys capturing teams’ experiences (sentiment) is essential. These visible metrics empower the teams to review and experiment with improvements.

Researching the market

The challenge

As a department leader, I am responsible for equipping our product development and delivery teams with performance feedback and metrics that will provide them with insights they can use to continue improving, even if they are already performing at a high level.

My team and I recently evaluated Value Stream Management (VSM), Flow, and DORA metrics platforms to assess the depth of data visibility into the product discovery and delivery phases and workflows through dashboards. The current market at the time of my writing provides many solution providers boasting different features, focuses, and prices, so it’s essential to do your due diligence before choosing one that fits your organization’s needs best.

Most solution providers focusing on VSM and Flow Metrics serve mid-market and enterprise organizations. In contrast, the solution providers focusing on DORA metrics serve small and medium businesses (SMB) and mid-market organizations. This evaluation experience was rewarding; it generated great conversations with solution providers and within my team and inspired this post.

Selecting a provider and partner

Selecting a metrics tool provider requires thoroughly understanding your organization’s needs, goals, and budget. Although we recommend a solution that covers all stages of the value stream, these options are targeted at enterprise-level budgets. They may not be affordable for SMB and mid-market organizations.

After evaluating the market, we identified two primary categories of metrics tool providers. The first category provides a comprehensive view of the entire value stream and can ingest data from various sources. In contrast, the second focuses on development and delivery, with optics around or extensions of the DORA metrics. We found that VSM metrics platforms tend to target enterprise budgets, while DORA metrics platforms are more affordable for SMBs and mid-market organizations.

We prefer a think big, start small, scale-out approach for most change efforts, as we did with our agile and DevOps transformation and our decision to select a VSM metrics solution provider. If development and delivery are your most significant bottlenecks, start with DORA and local metrics. Otherwise, you can expand to other parts of the delivery planning or discovery optics from value stream management solutions to gain operational efficiencies.

In my selection research, I found that some vendors measure performance and efficiency across the entire flow, while others focus only on one stage, measuring product delivery. However, I did not find one solution that measured both stages well. Additionally, I needed help finding a solution that provided strong team health metrics and qualitative data around human dynamics and team operations, in addition to system measures.

Another critical difference I discovered between service providers was the degree of data integrations or data read access available. While all platforms offer visualizations to identify bottlenecks, some providers do not integrate with systems of record that provide deeper insights into stages and the tasks causing the bottlenecks. When evaluating a solution, consider whether additional metrics are necessary to narrow the bottleneck or which components need to change to improve the bottleneck.

Visualizing the instrumentation options

I created the following diagram to help me convey these concepts when having this conversation with others:

Final thoughts

I am encouraged by the digital product delivery metrics available today that focus on teams’ usage to make decisions to improve performance and efficiency. Two measurements are necessary for teams to have the information they need to succeed: system process performance data and human dynamics, sentiment, and how teams operate.

While some solution providers have been in the market for some time, it was apparent that this market is still relatively young and proliferating with new vendors and improved features from competitors. Your approach to metrics and the degree to which you can visualize data in one solution can be the difference for your team. There are drastic differences in prices and capabilities among these solutions. I suggest you examine how you present flow and optimization across the organization. Select a solution that best fits the context of your teams and organization.

Another exciting aspect: Linking data to business value outcomes and impact (closing the loop). We can quantify the impact of our investments in agile, lean, and DevOps software delivery best practices.

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.

Let’s talk: phil.clark@rethinkyourunderstanding.

Related Posts

References

  1. Sutherland, Jeff; Sutherland, J.J.. Scrum (p. 148). Crown. Kindle Edition