Rethink Your Understanding

Transforming Software Delivery

philc

Outcome Metrics and the Difficulty of Reporting on Value

by

4 min read

What does it mean to “deliver value”? Defining value deserves its own focus. This article picks up at the point of the delivery backlog, assuming that your product leadership has identified the customers’ or organization’s needs, prioritized, defined, and outlined the value for the business and its customers, created a business case for the investment (including impact mapping and cost analysis) and defined the expected outcomes from changes or improvements to their digital product.

What problem are we trying to solve?

The outcomes are not kept from the teams, ensuring we are closing the loop.

This article dives into the crucial topic of measuring the outcomes following the release of enhancements or changes and informing the team(s) that delivered the work. Did the change or new feature deliver the expected value? Are we delivering the right things? Knowing the outcome or level of success motivates team members and bolsters their purpose. Teams can use the results to glean valuable insights even when they do not meet expectations.

Fast and agile delivery is not the end goal; value is the end goal

“Making the wrong thing faster only makes us wronger.” 1

In software delivery, it is essential to remember that delivery is not the end goal; value is. It is easy to fall into the trap of delivering software quickly and efficiently. Still, it is all for nothing if it does not provide value to the customer or organization. Delivering unwanted features can be a sad waste of productivity and a misuse of talent.1 These are just a couple of reasons why it is crucial to understand what value means in software delivery and how to measure it.

Organizations need to understand the real-world impact of their digital product changes, so measuring its outcome value, determining the return on the investment, and learning from outcomes are critical. Unfortunately, accurately tracking and reporting outcomes and value returned can be complex due to several challenges.

The challenges of measuring the final outcome of digital changes

What are the meaningful outcome metrics? Are such metrics communicated down to the delivery team level? Do companies practicing OKRs report on the final outcome of those OKRs?

First, many organizations need more tools to help them measure the value of outcomes from software delivery. The lack of tools and data insights can make it challenging to track and report on the success of the delivered changes.

Secondly, measuring the actual ROI requires significant time and effort. It is essential to determine the impact of digital product changes on the business or customer; this can be a complex process. This work may require additional resources, like data analysts or business intelligence tools.

Third, the impact of the software changes may take time to become apparent. It might take months or even years to see the actual effect of the changes delivered on the business or customer. Time duration can make it challenging to accurately track and report the real degree of success or value delivered within the allotted time to influence teams.

Fourth, accounting for the success of an outcome and the value it returns may require additional resources and a shift in the organization’s mindset to prioritize measuring this work.

Finally, there could be pushback when inquiring about the value of the product or platform changes teams delivered. To ensure that the value outcome is consistently tracked and reported, organizations must determine who is best suited for monitoring and reporting the value outcomes of what the teams deliver.

Teamwork and transparency at the team level

For those using Scrum or Kanban or similar lifecycle practices and tools, consider adding elements to the delivery team’s Epics, Features, and possibly User Stories.

Why: Why are we working on this?

Value: Short description of the expected outcome for the organization or customers.

These can align with OKRs for those using them.

Benefits:

  • Shared understanding, alignment, purpose driven development, and delivery.
  • Documenting the why and value enables team alignment and autonomy and increases team member engagement.
  • A more precise understanding of priority reasoning.
  • Learn from the outcomes (gain insights).

Challenges:

  • Tools to help measure the outcome.
  • Measuring the outcome requires significant time and effort.
  • The impact of the change(s) delivered may take time to become apparent, ranging from weeks to months or even longer.

Closing the loop with the delivery teams:

  • Schedule outcome retrospectives with teams.
  • Document the outcome(s) details to Jira, Azure DevOps, Rally, or whatever tool your teams use.

Final thoughts

In many organizations, technology leadership must measure and report on the performance of the software delivery teams.2 Do your delivery teams receive feedback on their work’s value to the organization or customer? Are they aware of the impact and success of their efforts after they deliver on a change? If not, it’s time to reevaluate your approach.

By providing your teams with regular feedback and, more importantly, the overall results or outcomes from their work, you can increase their motivation and a sense of purpose, leading to a more engaged and productive workforce.

If you aren’t doing so already, start tracking, measuring, and reporting on your team’s outcomes to align your business objectives and change investments with their performance, avoid costly and wasteful overproduction, learn from the changes made to your delivered product, and achieve greater success. Are your teams “delivering value”?

Related articles:

  1. Value part 1: Maximizing Technology Team Effectiveness: Insights from a CEO Conversation
  2. Measuring delivery teams: Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks.

References:

  1. Smart, Jonathan [@jonsmart]. “From Faster to Sooner” Twitter, 26 June 2021

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.

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

Agile Software Delivery: Unlocking Your Team’s Full Potential. It’s not the Product Owner.

by

10 min read

This article examines the role of leadership in agile software delivery teams and product organizations. The Product Owner is often considered a leadership role. This article highlights the importance of having an experienced Scrum Master or Agile Leader as a leader on the delivery team. These individuals bring impartial leadership and provide additional benefits to the delivery ceremonies, ultimately impacting the success of the product delivery.

The article also explores the challenges faced by product and technology teams when working together to deliver software in organizations where these are separate functions. The tension between Product Owners, Scrum Masters, and team members can lead to friction and difficulties in aligning goals. Many articles, posts, and podcasts cover the toil between Product Owners and teams. This article aims to provide an alternative perspective on addressing this issue and offers alternative options for improving collaboration and prioritizing work. The insights provided in this article may help organizations better understand their context and adjust their team’s approach for better outcomes.

Your decision regarding team leadership is critical

If you’re utilizing Scrum, Lean-Agile, Kanban, SAFe, XP, etc. – or if you’ve created your version of these methodologies – the roles of Product Owner and Scrum Master were designed as leadership roles to give teams an advantage in achieving success. For teams that want to develop high-quality software with security and performance protocols factored in, three influential leadership positions are necessary: product owner, agile leader, and engineering manager (or technical lead). The level of engagement between these three leadership roles helps the teams succeed.

The Agile Leader Model. This post assumes the following:

  • Your organization or department embraces Agile, Lean, and DevOps practices tailored to meet your unique needs.
  • Your teams are organized as small cross-functional delivery teams.
  • Your team follows a delivery practice, for example, Scrum, Kanban, Lean-Agile, or any method that suits your context.
  • Features are just one of your focuses. You recognize four types of work that flow through your digital product value stream: feature, debt, defect, and risk.1
  • Most importantly, the Product Owner is a part of the delivery team and regularly participates as a team member. If not, why?

In many product and service organizations and delivery frameworks, the Product Manager or Owner is solely accountable for deciding what the team should focus on. Understandably, the Product Manager and Product Owner are responsible for the organization’s product strategy, delivery, growth, and capabilities. They are under pressure and held accountable by the organization to prioritize products over all else. However, this does not necessarily mean that absolute authority or responsibility belongs to the Product Owner; other factors are also at play.

Roles

Here is a summary of the Product Owner’s responsibility from “The Accountabilities of the Product Owner” from scrum.org as published in November 2020: The Product Owner is a member of the Scrum Team and is responsible for maximizing the value of the product resulting from the team’s work. They provide clarity to the team regarding the product’s vision and goal and work to deliver value to all stakeholders. The Product Owner is accountable for successful Product Backlog management, which includes developing and communicating the Product Goal, creating and communicating Product Backlog Items, ordering them, and ensuring they are transparently understood. They may delegate this responsibility to others on the team but remain accountable for its accomplishment and the value delivered. The Product Owner must also earn the respect of the entire organization to make decisions and get the support they need for those decisions. They are the final decision maker for changes in the Product Backlog and should also be getting customer feedback on the product.

Likewise, the Scrum Master/Agile Leader’s responsibility summary: A scrum master is a coach and facilitator in a scrum team responsible for implementing and guiding the scrum framework. They establish processes, resolve conflicts, protect the team, and facilitate meetings. Agile leaders prioritize people, learning, and adaptability over processes and embody an evolutionary mindset of self-awareness and growth. Two key capabilities are the ability to encourage conversations regarding prioritization and attention to the types of work; the other is encouraging discussions about team improvements through team metrics (system data) and team health (qualitative data). To be an influential scrum master and agile leader, one must be humble, responsive to change, embrace uncertainty, and be willing to evolve themselves and the team systems.

Challenges and Responsibility

The question of who should determine what work to prioritize among the four types required for an effective digital product is essential. While the Product Owner is typically responsible for deciding what a team will work on and deliver, team autonomy can give members a sense of responsibility and the power to make decisions. Autonomous teams must deliver work that benefits the organization and regularly understand needs, performance, and consequences while speaking to the value of each type of work (features, defects, technical debt, and risk) for the organization’s goals and technology. However, accountability for delivery can also fall on the engineering manager if the team structure includes one. The debate over the effectiveness of product owners leading teams, levels of team toil, and the role of Scrum Masters in assisting them is widely discussed in articles, posts, and podcasts.

The Problem

The problem with traditional approaches to work management is a need for balance in decision-making, clarity of roles, and conflicts of interest; there needs to be more common alignment and shared understanding of goals between the team and the organization. This is a human-driven problem, not one with Agile, Lean, or DevOps techniques. In the industrial era, work was predictable, and workers followed orders from managers with little autonomy. In the previous waterfall software development generation, IT served as the customer of the product team or business, with projects managed by project managers but limited purpose and authority for IT workers. This mindset and experience can create difficulties in transitioning to an Agile working method. It may be assumed that the Product Owner initially instructs the team on what to do; however, this approach only works if Agile is implemented with a more collaborative approach, where the team works together to prioritize and allocate work that aligns with organizational and performance goals.

Having the Product Owner decide what the team should work on can be a conflict of interest with the other types of work.

Three key books helped me to shift my mindset, Team of Teams 2, Turn the Ship Around 3, Team Topologies 4.

Teams

Great teams comprise exceptional Product Owners, Agile Leaders, and Technical Leads who can collaborate to achieve remarkable outcomes.

Product and IT teams must work as colleagues, not just customers and suppliers, to deliver solutions to external customers. In this context, I refer to having a small cross-functional team design. The product owner is on the same hierarchical level as developers and other team roles, each drawing on their expertise. The product owner knows the business and customers, while developers are experts in product implementation, performance, quality, and development processes. The production or operations engineer has expertise in cloud solutions, scaling, and cost. By combining their skills and working together as a team, they can allocate and prioritize the four types of work to meet organizational and performance objectives, leveraging the power of social capital.

Skills

Your teams benefit from having T-shaped skillful team members. T-shaped skills are a combination of exceptional competency in one particular field (represented by the vertical line) and an understanding and proficiency in related areas (horizontal line). Your teams should have clear roles and responsibilities around each member’s primary skills (vertical line in T-shaped skills).

Effective teams do not have an “us” versus “them” mentality (product versus technology), wherein one position dictates all work assignments. By creating a balanced team aligned with the organizational and platform investment goals, joint decisions can be made about work prioritization within a set time frame. Collaboration ensures that teams have a clear purpose, an understanding of business and customer needs, unity of goals, and the ability to achieve company objectives successfully. The organization benefits from the team’s prioritized work. To assess team performance:

  1. Consider the impact of your Product Owner and Agile Leader.
  2. If the team is struggling, ask if they have a clear understanding of organizational goals, their work’s impact, and if they are being encouraged to make decisions or kept on a tight leash.
  3. Ensure that the team has a unified understanding of the four essential components of work and that the senior leadership team understands how the team’s prioritization contributes to both short-term and long-term objectives.

A Solution: The Agile Leader

Some organizations that move from waterfall to agile practices have started to overlook the significance of the scrum master role. A misunderstanding or grasp of the role or financial constraints leads organizations to remove this team member, divide the role responsibilities among other positions, or assign different individuals to take turns as the scrum master. I suggest that the Agile Leader (also known as Scrum Master or a similar title) plays a vital role in achieving high-performing teams and exceptional delivery performance based on team structure and work requirements.

Assumptions of your Agile Leader or Scrum Master:

  1. Belonging to a team: You are a permanent member of one or more teams and refrain from frequently switching between teams or floating in and out of them.
  2. Facilitating delivery: You are dedicated to fostering a productive and collaborative environment within your team by coaching, encouraging team practices, promoting psychological safety, and facilitating communication and decision-making.
  3. Improving team performance: You are responsible for continuously evaluating and improving your team’s performance, helping to remove any barriers impeding effective delivery.

As a Product Owner, it is part of your job to be aware of the value behind your product, explain its worth to teams and stakeholders, comprehend and communicate what needs to be accomplished to deliver the product, and undertake many other duties. However, the responsibilities of coaching, motivating work practices, objectively evaluating team health, and driving effective delivery may better fit the role of an Agile Leader, with the Product Owner focused on delivering features. The Technical Leads and Developers focused on technical debt, quality, and risk; the Scrum Master or Agile Leader is the only role free from conflicts of interest and can focus on the team’s health, promote collaboration, identify anti-patterns, resolve conflicts, and encourage team members to solve them. With agile leadership, the potential for conflict of interest is removed.

Good Agile Leaders lead teams.

Agile leaders, coaches, and Scrum Masters strongly understand empathy, giving and receiving feedback, and the human side of our work. They place a high priority on the happiness of their teams. Incorporating it into Scrum, Lean, and Kanban gives you excellent tools, techniques, and leadership skills for managing workflow effectively.

Agile leaders play a crucial role in fostering collaboration and enabling team members to reach their full potential. They are trained to coach, facilitate team conversations, and create a productive environment where everyone feels supported as a product owner, technical lead, quality assurance personnel, or any other role. Effective coaching is a crucial aspect of the Agile leadership role; it aims to empower individuals with confidence and knowledge.

Agile leaders continuously invest in their core abilities. To offer the best advantages to their teams, they focus on cultivating T-shaped skills and learning enough about other teams’ needs and roles. A well-rounded viewpoint comes with expanding one’s knowledge outside of regular practices.

Team Delivery Efficiency

Agile leaders should facilitate processes and take a proactive role in ensuring delivery efficiency. This is achieved by incorporating metrics and practices that monitor and enhance delivery speed and quality. Experienced Agile Leaders help teams identify waste and bottlenecks in delivery and encourage collaboration and conversations to improve flow. They highlight how measuring flow (delivery efficiency) and realization (value impact) ensures you’re building the right things and building them efficiently. Operational efficiency improvements must focus on both. While teams focus on flow (delivery efficiency improvement), Agile Leaders can challenge product management to define and track anticipated outcomes to avoid misalignment with broader goals, ensuring feedback loops in verifying value realization.

Partnership

Skilled Agile Leaders, Product Owners, and Technical Leads are the three foundation pillars of delivery teams. Agile leaders should provide a strong foundation of trust between themselves, the Product Owner, and the Technical Lead by having regular one-on-one meetings with each team member. They can use coaching contracts for these discussions to help them review what the Agile Leader has observed, what the team is saying, and, vice versa, what the Product Owners or Technical Leads have observed. This approach can improve collaboration, prioritization, alignment, and team delivery.

Comparing an Agile leader to the head coach of a football team is a fitting analogy. The Product Owner can be viewed as the offensive coordinator and the Technical Lead as the defensive coordinator. Like head coaches, Agile Leaders must develop strong relationships with their team members and proactively remove obstacles that impede effective delivery. The success of the delivery teams can be correlated to the effectiveness of the Agile Leader in fostering a supportive and collaborative environment and accepting that part of their role is to coach others and teams to become better at what they do.

I created the following picture to illustrate this model:

Underlying image from Apple TV’s Ted Lasso, Warner Bros. TV.

Good Agile Leaders are in tune with team health and keep a team moving forward.

Final thoughts: Providing the team air cover

Suppose you subscribe that the agile leader role, having the least conflict of interest, can guide, arbitrate, and encourage team decisions through collaboration. In that case, Every team still needs a reliable shield to bear the heat when things go wrong. Usually, this is done by a senior leader or an experienced team member with organizational clout. When the team has unity in goals and skills, psychological safety, enjoys their work and sees the purpose in the value they deliver, motivation to grow better, and authority to make their own delivery decisions with someone who always has their back — then you know they are unlocking their full potential.

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.

References

  1. Mik Kersten (2018), Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press
  2. Stanley McChrystal, Tantum Collins, David Silverman, Chris Fussel (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio
  3. L. David Marquet (2013). Turn the Ship Around!: A True Story of Turning Followers into Leaders. Portfolio
  4. Matthew Skelton, Manuel Paris (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press

The Shift to Software Management: A Skill Guide for New Managers

by

9 min read

“The conventional definition of management is getting work done through people, but real management is developing people through work.” ~Agha Hasan Abedi

“Management is not a promotion, management is a change of profession . And you will be bad at it for a long time after you start doing it. If you don’t think you’re bad at it, you aren’t doing your job.
Managing because it feeds your ego is a terrific way to be sure that your engineers get to report to someone miserable and resentful, someone who should really be writing code.” ~Charity Majors

Why did you become a manager?

The journey from a seasoned engineer to a successful engineering manager often feels like charting a new course rather than simply moving up the career ladder. It is not a straightforward progression but a transformative shift requiring different competencies, strengths, and a fresh mindset. This transition might not be the right fit for everyone in the tech field. Many people, including myself, have discovered that fostering individuals, nurturing talent, and taking pride in the growth and accomplishments of direct reports can be very rewarding.

Leaping into management means you are ready to delve into the complexities of personalities, motivations, and personas. As a manager, one of your most important responsibilities is to build trust with your team. Trust is critical to any successful relationship, including the one between a manager and their direct reports. With a foundation of trust, you can have open communication, take risks, and celebrate shared successes. Building trust takes time and is earned through consistently being honest and transparent.

In this new realm of leadership, something other than what worked for you as an individual contributor may work for those that report to you. What fuels your fire and motivates you might not necessarily ignite your team members’ passions. As you build trust, it is crucial to remember that active listening and understanding what motivates each individual are pivotal aspects of your new role.

Managing people is challenging because each person is complex and constantly evolving. However, the opportunity to mentor and influence future industry leaders is a privilege that can be immensely satisfying. Despite the roadblocks and challenges, successful leadership is possible.

I have had different types of managers throughout my career. Some were toxic and controlling, while others were challenging but inspiring. The latter pushed me to my limits and helped me grow professionally. I am grateful for the excellent managers who have helped me in my journey as a leader and manager. With over 20 years of management experience in this field, my main goal has been to promote, develop, and mentor aspiring engineering managers.

I am here to offer my support and guidance as you navigate this challenging yet rewarding journey. In this post, I will share some tips and ideas about management and leadership. These tips are not new or revolutionary but come from many books, articles, and courses. Plus, I am sharing skills that have helped shape my experience, too. This post is a practical guide for new managers to help them do their job well. My intention is not to come up with a completely original idea. There is nothing new here about management or leadership that you can’t get from the various learning outlets. Instead, I aim to put my unique perspective on things based on my firsthand experiences in the tech field.

You can’t learn management only from books. New managers need multiple support options. I recommend two primary groups, top-down coaching, and peer support meetings or collaboration (new managers learning from the experiences of their peers).

One of many possible lists

Here’s a list of skills that I recommend new managers should aim to develop:

  1. Trust Building: Developing trust with your team is crucial. Being consistent, honest, and transparent over time creates a safe environment where team members can openly communicate, share ideas, and take risks. As a new manager, it is crucial to prioritize building trust as it forms the foundation for a strong team.
  2. Self-Awareness: It is important to know your strengths, weaknesses, biases, and how your behavior affects others. It is crucial to develop emotional intelligence regarding yourself to manage better and comprehend your own emotions and those of your team.
  3. Self-Management: Maintain control over your emotions and behavior, align your actions with organizational goals, demonstrate resilience in the face of change, and balance your professional and personal life. Recognize the things that trigger you and take a moment to pause before reacting, as I’ve learned from my own experiences of responding too quickly.
  4. Leadership Skills and Style Development: Develop your leadership style, strike a balance between authority and approachability, and inspire and motivate your team. You will also learn a lot from all that is out there. Learn to take bits and pieces and build your management and leadership toolkit.
  5. Servant Leadership: Servant Leadership is a leadership philosophy that emphasizes the role of the leader as a servant to their team, prioritizing the needs and growth of team members. When integrating Servant Leadership into the core people management skills for a software engineering manager, consider adding the following: Empathy, Active Listening, Stewardship, Commitment to Growth, Building Community, Self-Awareness, and Healing (Being aware of the personal or professional obstacles that team members might encounter and providing support, understanding, or resources to help them overcome these challenges).
  6. Communication Skills: Develop your skills in active listening, effective team communication, giving and receiving constructive feedback, and handling difficult conversations. Active listening was the most challenging part for me. Learning to pay close attention to the discussion at hand is crucial. If you can’t concentrate, it’s best to postpone it until you can.
  7. Cognitive Biases: Understand and manage cognitive biases, and value diverse opinions and perspectives.
  8. Adaptability: Be open to new ideas, and adapt to changing circumstances. You will fail with a fixed mindset and an aversion to change.
  9. One-on-One Meetings and Coaching: As a manager, nothing shows that you care more about your direct reports’ success than the one-on-one. I recommend prioritizing one-on-one meetings as they are essential for building strong, trust-based relationships with team members. These meetings provide a unique chance to learn about their aspirations, concerns, and needs and offer guidance tailored to each individual’s goals. Showing up on time for meetings and prioritizing them shows you are committed to helping your team members grow and succeed. In these meetings, it’s important to focus on your direct reports and allow them to discuss their accomplishments, challenges, and career goals. These meetings can lead to more profound mutual understanding, trust, and rapport. It’s also an excellent opportunity for coaching and working with different personalities. Over time, these meetings can lead to increased engagement, productivity, and team cohesion. Make sure to equip yourself with the skills to have challenging conversations and negotiate effectively during these sessions.
  10. Emotional Intelligence: Emotional intelligence, or EI or EQ, is crucial for successful leadership. If you possess high emotional intelligence, you can positively handle your interactions with your employees, display empathy towards others, surpass obstacles, and resolve conflicts. Developing your emotional intelligence can assist you in fostering better relationships, making improved decisions, and approaching conversations with a different mindset.
  11. Team Building and Talent Development: Learn to become better at recruiting and welcoming new team members, identify their strengths and weaknesses and focus on improving their skills. Listen to them and help them achieve their career aspirations, even if it means eventually sending them away to pursue higher opportunities.
  12. Recognizing and Appreciating Efforts: Acknowledge and appreciate the contributions of team members, and implement both formal and informal recognition programs.
  13. Visibility and Availability: Be present and engaged with the team and maintain approachability for questions or concerns. This is critical in today’s remote world. Go out of your way to be present either through one-on-ones, recognition, or even a Gemba walk from time to time (search Gemba walk).
  14. The Multiplier Effect (I recommend this book, Multipliers by Liz Wiseman): Create an environment where team members feel valued and smart, empower your team members, and encourage the team to stretch beyond their comfort zones.
  15. Ethical and Fair Practices: Make decisions with integrity and fairness, and treat all team members respectfully.
  16. Delegation: Learn to delegate tasks without micromanaging. Intelligent and capable team members surround you. Learn what you can about proper delegation.
  17. Feedback: It’s important to actively seek and provide constructive feedback to encourage a culture of feedback within the team. Feedback may be challenging, but providing examples and reasoning behind your feedback is essential. Getting feedback from your direct reports may also require effort and attention.
  18. Strategic Thinking and Decision-Making: Make informed decisions that align with the company’s goals, and develop skills in data analysis and decision-making under uncertainty.
  19. Handling Tough Conversations and Performance Improvement: As a leader, you often need to have challenging conversations about improving performance, resolving conflicts, or sharing bad news. Handling these discussions with sensitivity, communication skills, and precision is essential. As a manager, you must give concise and practical feedback to encourage struggling team members. When talking, concentrate on the problem instead of the person, and strive to achieve a favorable resolution every time. Approaching conversations with a sincere interest in helping your team member grow and develop can turn an awkward situation into a chance for learning and progress.
  20. Humility and Vulnerability: Even managers make mistakes, and it’s okay to admit that. Some of the best leaders are those who show humility and are open about their vulnerabilities. When you acknowledge that you don’t know everything and own up to your errors, you build trust, promote communication, and encourage your team to be honest about their mistakes, ask for help, and seek answers. It’s important to acknowledge and appreciate the abilities and efforts of your team members. Being receptive to learning from them can enhance your leadership skills. When combined with effective leadership, vulnerability can create stronger relationships and encourage a culture of understanding and teamwork.
  21. Goal Setting: Once goals are established, your role as a manager is to furnish resources, offer feedback, and facilitate progress, which includes regular check-ins, development opportunities, and obstacle removal. Commemorating milestones and accomplishments maintains motivation and underscores the merit of goal-setting. Understand that goal-setting isn’t static. It’s a dynamic process that evolves with shifting priorities and project developments. Flexibility and open dialogue about adjusting goals foster a realistic understanding of goal-setting, keeping it integral to work reality rather than a stiff, administrative task. Two frameworks for goal setting: The SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound), and the OKR (Objectives and Key Results) framework for more complex, long-term goals.
  22. Managing Change: As a leader, it’s important to have the skill to manage change effectively since change is inevitable. As a manager, you may need to initiate change by introducing new processes, adopting new technology, or redefining team roles. Sometimes, you may have to help your team navigate changes from higher company levels or outside influences. To do this effectively, you need to explain why the changes are happening, listen to and resolve your team’s worries and objections, and provide assistance as the changes occur. Managing change can be challenging, but you can guide your team to overcome it by being open, understanding, and providing strong leadership. Also, acknowledging and commemorating the team’s successful adaptation to the change can encourage a positive outlook toward upcoming changes.
  23. Continuous Learning and Self-Improvement: Seek continuous education to enhance your skills and knowledge. NEVER stop learning and improving. Be willing to unlearn, relearn and rethink your understanding.
  24. Shaping Culture: Managers play a vital role in shaping the culture of their team, which in turn can impact the department and even the entire organization. Culture refers to a group’s shared values, beliefs, attitudes, and actions, influencing how team members interact, tackle challenges, and prioritize goals.

Wrapping this up

Although I covered many essential skills for managers, I didn’t address every skill or subject. Being a manager involves much more, but building trust is the core of all these skills. It is essential for fostering open communication, encouraging risk-taking, and enabling shared successes to thrive. These skills can create an environment that fosters productivity, builds an engaged team, and provides valuable leadership. Combining these skills with a strong work ethic, dedication, and sometimes industry-specific knowledge will pave the way for a successful career in management.

The journey of management is continuous, marked by lifelong learning, adaptability, and the joy of seeing one’s direct reports or teams flourish. When done right, the privilege of mentoring and influencing future leaders makes every step of this journey worthwhile. Only time and feedback will tell how you did as a manager. Remember, there’s no one-size-fits-all solution, and what we’ve discussed is a guideline, not a rule book. Leadership, like Trust, is earned one day at a time. So buckle up. It’s going to be an exciting ride!

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.

The Artistry of Software Engineering: Harnessing Creativity for Impactful Business Solutions

by

5 min read

“Software is a great combination of artistry and engineering.” – Bill Gates

As a senior leader and software engineer, I have witnessed the exceptional capabilities of software engineers firsthand. I recently came upon a conversation that software engineers are human. Of course, they are. After catching up on the context for the statement, it centered around measuring individual software engineers and how older physical production line measures were morphed into earlier attempts to measure engineers’ performance. Hopefully, organizations treat all employees as humans in their approach to performance and culture. The role is not distinguished by the fact that the workers are human or non-human but rather by the need for problem-solving skills, creativity, and experimenting and managing unknowns.

Software development differs significantly from traditional manufacturing processes, such as car production or house building, where the end product is well-defined and established. In software development, there is inherent uncertainty and the need to manage unknowns, aptly described by the Cynefin framework1. Whether your software development and delivery lifecycle is more function-based and waterfall, cross-functional and agile, lean, or a combination thereof, it is not uncommon for scope creep to occur. Could this be due to consistent learning and uncovering of unknowns throughout development? Understanding how we look at software engineering work and measure software engineers’ performance and return on investment in a company is important.

Unfortunately, many organizations still rely on traditional productivity measures that treat engineers like factory workers churning code. This viewpoint is flawed, as software engineers are skilled problem-solvers who creatively craft elegant solutions. Software engineers are more akin to artists than factory workers. Just as we would not evaluate a painter’s worth by the number of brushstrokes or paintings they create, it is crucial to understand that assessing a software engineer’s productivity extends far beyond the lines of code they produce.

The Human Side of Software Engineering

I agree that it’s important to acknowledge that software engineers are not machines but human beings. By recognizing their human side, we can better understand what drives their creativity and passion. Software engineering is a unique mix of art and science that requires technical expertise, problem-solving abilities, and a keen sense of intuition. A software engineer must balance constraints and opportunities to deliver a functional or visually appealing solution like an artist.

Each software engineer brings a unique approach to implementing solutions, and addressing problems, informed by their experiences, knowledge, and innate talents. This diversity of thought and process makes the field dynamic and exciting, ultimately driving innovation and business growth.

Creating Impactful Software and Fostering Team Satisfaction

In software engineering, team satisfaction is closely tied to creating and shipping products that make a tangible difference. Teams feel a sense of pride and accomplishment when they see their work in the marketplace, positively impacting users and solving real-world problems.

Streamlining the process of shipping software can raise team engagement and enjoyment. This involves providing the right tools, support, automation, and environment to help engineers transform their ideas into reality. Capturing and sharing data-driven insights that motivate teams to improve by identifying bottlenecks is also important. A culture of safety, open communication, and collaboration can help teams navigate challenges more effectively and create more impactful software.

The Importance of Developer Experience for Business Success

A crucial aspect of software engineering that often goes overlooked is the “developer experience.” Generally, developer experience refers to the environment, tools, and culture in which software engineers work. Fostering a positive “developer experience” is vital for nurturing the growth and creativity of these talented individuals.

A supportive and engaging workplace can make all the difference in enabling software engineers to explore new ideas, experiment with different techniques, and ultimately create innovative solutions that drive business value. Conversely, a stifling or uninspiring environment can impede creativity and hinder progress.

Measuring Productivity – A Business-Centric Perspective

To evaluate software engineering productivity honestly, we must move beyond basic measures like counting lines of code or completed tasks. Instead, we should consider an engineer’s work’s overall impact on the business. Depending on your organization’s team structure, team metrics may be more valuable than individual metrics. New methods and practices are available for measuring team productivity and efficiency that don’t focus solely on individual performance. Consider shifting your focus from individual productivity to individual performance. Some factors to consider when assessing a software engineer’s performance might include the following:

  1. The quality of the code produced – Is it efficient, scalable, and maintainable?
  2. Collaboration and communication – Does the engineer work well with their team, fostering innovation, sharing and receiving feedback, and team member support?
  3. Adaptability and growth – Is the engineer continuously learning, adapting, and refining their skills to stay ahead in the competitive landscape?

Conclusion

Software engineering is not merely a routine job on a production line. Instead, it involves a complex and imaginative process that requires a combination of technical proficiency and artistic flair. If businesses appreciate the crafting aspect of software engineering, provide a supportive environment for developers, and emphasize producing and delivering purposeful software, they can unleash the full potential of these skilled individuals and empower them to come up with innovative creations.

References:

  1. Cynefin Framework. https://thecynefin.co/about-us/about-cynefin-framework/

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]