Rethink Your Understanding

Transforming Software Delivery

Software Engineering

Mitigating Metric Misuse: Preventing the Misuse of Metrics and Prioritizing Outcomes Over Outputs

by

6 min read

The business needs feedback on technology investments. Teams need insights into flow efficiency and potential bottlenecks.

Part 3 of a continuing conversation regarding today’s delivery system metrics: Flow Metrics, DORA, and the traditional concerns regarding the Gamification of numbers.

Links to the previous posts:

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

Part 2: Developer Experience: The Power of Sentiment Metrics in Building a TeamX Culture.

What problem are we trying to solve?

Identifying the specific problem you are trying to solve with metrics is essential. Could you suggest other solutions apart from using these metrics? How can we determine where to invest and track progress if we don’t use them?

The problem we are trying to solve is the improved efficiency of software delivery and employee engagement. The focus is on continuous improvement of flow. Using metrics, we can illuminate insights into bottlenecks and obstacles that reduce the team’s ability to deliver software. Our goal is to continuously improve the flow of work, which ultimately leads to better outcomes. Improvements in outcomes reflect efficiency improvements.

Business interest in metrics (investing in technology, investing in work)

  • Are we improving our business by investing in technology? Are we getting better?
  • Return on investment, return on outcomes
  • Delivering faster with high quality

Teams (delivering work, removing friction, feeling successful)

  • Improve efficiency by reducing waste, shortening lead and cycle times, optimizing workflow, and promoting employee engagement.
  • We do this by providing teams with data, insights, and optics into bottlenecks and areas of friction that generate conversations around why these bottlenecks exist and brainstorm experiments to resolve them.

Is there an elephant still in the room? What about the Gamification of metrics?

Concern for system metrics like Flow and DORA is still the team’s focus, as they try to gamify the numbers instead of focusing on the data and looking for patterns that highlight bottlenecks and friction, otherwise known as areas of improvement.

Stakeholders need system metrics, and using them effectively within the organization is essential. Some tools can be expensive. There is also a risk of gaming the system to achieve a desired metric, and these tools’ values decrease when teams focus solely on the numbers.

How can we avoid becoming hyper-focused on these metrics this time around? How can we encourage teams to use them? We should separate the business view from the team’s perspective. The team should focus on the insights and illuminated areas of improvement, not just the numbers.

Some leaders adopting these newer metrics and dashboards measuring flow and DORA still warn that Gamification wins, and teams fall back to focusing solely on improving the number.

Yet, numerous teams have succeeded by fostering a positive culture and adopting the right mindset. These teams analyze the patterns and identify the areas that pose obstacles. Doing so enhanced the flow, mitigated friction, and boosted engagement, activity, and overall satisfaction.

The key is leadership.

Bad managers or incompetent managers will diminish efforts.

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 instead of blaming the tools or teams.

The increasing pressure on engineering leaders to be “more data-driven” has pros and cons depending on the managers leading the effort, even with today’s metrics and the “why,” bad managers can erode the value of these modern team data insights.

Depending on the competencies of the managers leading the effort, the push for engineering leadership to be more data-driven can have positive and negative effects, despite the availability of metrics and understanding of the “why.” In the case of bad managers, the value of these team insights can be quickly diminished.

Although metrics like Flow and DORA can offer valuable insights into team efficiency and process bottlenecks, it is crucial to remember their purpose. These metrics serve as tools for understanding and improving the system, not micromanaging, unfairly critiquing the team, or ranking performance across teams.

These are “team” metrics. Misusing these metrics to measure individual performance is an unfortunate managerial anti-pattern. As with comparing teams, managers focusing on individual performance can lead to a toxic culture and create an environment where team members might manipulate the metrics rather than focus on delivering value.

If your teams prioritize numbers instead of identifying improvement areas and working together to overcome challenges, consider examining the person guiding the team and reporting the team’s metrics.

Competent and influential managers:

Leadership needs to create a clear cultural imperative, acknowledging that, while sometimes it may be unavoidable, it is human nature to want to focus on the numbers. However, intentionally doing so will not be accepted. It is important to reinforce a culture of improvement and help teams understand that metrics are not the ultimate goal. Instead, metrics result from efforts to enhance different processes, such as removing bottlenecks, improving flow, automating processes, and enhancing practices. With the focus on improving rather than the numbers, each improvement will increase metrics over time.

  • Foster psychological safety for teams to make all work and impediments visible.
  • Don’t use metrics to compare or punish teams. Each team has a unique set of customers, complexity, and challenges.
  • Use metrics in retrospectives to drive discussion and ideas on improvements.
  • Celebrate experiments and improved trends.

The Benefits.

Teams should be encouraged to view and use the metrics differently than how the business views them. Teams finally have data to advocate for investments in other work besides features.

There are ways in which teams can benefit once they have data to back up the evidence of their bottlenecks and show the business and stakeholders the value of investing in and addressing these bottlenecks. Teams can use this data to demonstrate the necessity for investing in technical debt and efficiency improvements rather than just investing in feature work. The benefits include:

  1. More data to act upon: Give your team more data and insights to talk about, and if required, act upon it before things start to fall off the rails.
  2. Exposing Bottlenecks: Flow Metrics and DORA Metrics can help teams identify bottlenecks in their development process. Bottlenecks include areas where work is consistently getting held up, causing delivery delays. By identifying these bottlenecks, teams can focus on improving these specific areas through automation or other solutions leading to overall improvements in efficiency and delivery time.
  3. Promoting Proactive Improvement: Using these metrics encourages a proactive approach to improvement, as teams can use the data to identify potential issues before they become significant problems. Early detection can lead to a more efficient and effective development process.
  4. Demonstrating Value Beyond Features: Often, stakeholders focus on feature delivery as the primary measure of a development team’s value. However, these metrics can help prove that a team’s value extends beyond delivering features. They can show how improvements in technical debt reduction, process efficiency, and team collaboration can also provide significant value.
  5. Facilitating Conversations with Stakeholders: These metrics provide teams with the data they need to have meaningful conversations with stakeholders about where investment is required. They allow teams to move beyond subjective arguments to data-driven discussions about the state of the development process and what is needed to improve it.

By adopting these newer system metrics, with the support from exemplary leadership, and a great culture, teams can avoid focusing solely on the metric numbers to please the business and shift instead towards an improved flow, higher team member engagement, and a more balanced and sustainable approach to software development.

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

Developer Experience: The Power of Sentiment Metrics in Building a TeamX Culture

by

6 min read

“If you are in a good culture, you will feel and know it, and it’s sometimes hard to put words on those things.” ~ Wayne Crosby

What is the objective of our focus on Developer Experience? We aim to address various aspects, such as enhancing efficiency, encouraging collaboration, boosting job satisfaction, improving output quality, and fostering innovation and creativity.

The Buzz Around Developer Experience

There have been so many publications on this topic lately. Google “developer experience,” and it will return a list of links to DevX definitions, examples of DevX teams, and frameworks.

DevX is a new spin on prioritizing the investment in people and ways of working. I recall every presentation emphasized a people-first culture four years ago. Still, lately, there has been a surge in the number of articles published about developer experience (a.k.a. DX, DevX, and DevEx).

Why is developer experience becoming more prevalent?

During the previous waterfall and project-based software delivery practices, some have argued that developers were treated like a resource from a factory line. They were often referred to as “resources” by the business, measured by their code output and utilization. It’s great to be recognized as a human being and feel engaged and valued. But do the attributes of DevX apply only to developers or possibly many others on a delivery team? In many cases today, cross-functional delivery teams are delivering value.

I have spent much of my career as a software developer and manager of software development teams, my contributions and output have measured me, and I have measured others similarly. I have worked with previous cultures, tools, and practices, and today’s tools, architectures, and ways of working. More than anyone else, I can appreciate the message and focus on the developer experience.

Attributes of Developer Experience

The term “developer experience” refers to the experience of developers as they do their everyday work, including any difficulties they may encounter.

The attributes of developer experience (DevEx, DX) are as follows:

  1. Perception of the development infrastructure: How developers perceive the technical infrastructure (e.g., development tools, issue trackers, programming languages, cloud platforms, libraries) and ways of working (e.g., working agreements, processes, and methods)​.1
  2. Feelings about work (happiness and engagement): How developers feel about their work, including whether they feel respected, care about it, and feel like they belong in their team.1
  3. Value of work (purpose and success): How developers value their work, including whether they feel they’re making an impact and whether their values and goals align with the company​.1

In addition, a fourth attribute, Onboarding and investment in upskilling: Is how developers value an organization or department that prioritizes the onboarding process for new members and invests in their ongoing skills development.

Here are a few of the initiatives that are driving the developer experience:1

  1. Reduce developer wait times and interruptions
  2. Invest in maintaining a healthy codebase
  3. Make deployments safe and fast
  4. Empower teams
  5. Optimize for high work engagement

Developers with high work engagement exhibit persistence, dedication, and a commitment to delivering quality software. They proactively support the organization and consistently produce excellent work when they have the tools, autonomy, mastery, purpose, and a sense of success.

Success Comes From The Team and Team Experience

As of 2023, many organizations have significantly invested in transforming their ways of working through culture, Agile, Lean, DevOps, and cloud technologies. They invested in DevOps and Platform teams that build the capabilities for teams to improve software delivery and the developer experience. It still takes a team to deliver software today. What is so different about developer experience versus quality assurance experience, agile leadership experience, or product owner experience? We should expand the message to Team Experience (TeamX).

I recognize and respect software developers’ specific type of work; it is knowledge work, so developer experience must be acknowledged. However, we need to expand the focus to the delivery team experience, which includes developer experience.

  • What if the Quality Assurance Engineer could spin up an ephemeral test environment to test changes and have innovative tools and ways to run performance, exploratory, and chaos testing?
  • What if product owners could press the “delivery” trigger in an evolved, highly confident continuous delivery pipeline to deliver features to production or review features in an ephemeral environment?
  • Why would we ignore the agile leaders’ need for tools to facilitate team building, retrospectives, sentiment analysis, cycle management, and more?

Most of the “developer experience” aspects relate to the other team roles on a cross-functional team and the team’s overall experience. Therefore prefer to focus on team experience and promote that “teams and team members with high work engagement exhibit persistence, dedication, and a commitment to delivering quality software. They proactively support the organization and consistently produce excellent work when they have the tools, autonomy, mastery, purpose, and a sense of success”.

Treating all workers with respect is important, but for creative work to thrive, a supportive environment must also be provided. I will continue to advocate for team experience (TeamX, TX) over developer experience (DevX, DX), and that developer experience is part of team experience.

Unlocking the Potential of Metrics

As a follow-up to my first post on modern-day metrics, “Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks,” this post highlights the exciting combination of modern-day insights available today. These insights come from both your delivery systems and the team’s sentiment.

Measuring team experience requires both delivery efficiency (system metrics) and team feedback (sentiment metrics).

System metrics: I have become an evangelist and promoter of today’s system metrics and data insights based on value stream management, the Theory of Constraints, and a mix of flow metrics and DORA metrics as a holistic workflow and measurement to accelerate efficiencies and product and portfolio delivery.

Sentiment metrics: Since 2022, I have increased my focus on sentiment frameworks like the SPACE framework2 and, more recently, the DevEx framework created by Abi Noda, Margaret-Anne Storey (author of SPACE), Nicole Forsgren (creator of DORA), and Michaela Greiler (previously Microsoft Research).3

I have learned that it is not uncommon for organizations to start with system metrics and then realize they can benefit from targeted frequent sentiment metrics.

One unique thing about my experience at my current organization is that in addition to a semi-annual organization-wide employee net promoter score type survey (eNPS), we have been collecting simple team sentiment over many years using a Google Sheet, wherein each team member’s sentiment is recorded at the end of their daily standup comments: How are you feeling today? Positive, Negative, or Neutral.

Wanting to expand on our sentiment feedback, we are looking into creating short, consistent, and frequently delivered surveys in-house using existing tools that provide us with this capability or investing in services with significant experience in this area and the types of questions that bring the best results. As we still learn to master value streams and system flow metrics, we must expand and invest in our sentiment metrics.

Final thoughts

Creating and delivering digital products is currently an exciting field. Modern delivery practices, methodologies, and innovative measurement techniques bring positive changes. Two types of data analysis are necessary to evaluate team effectiveness and happiness: delivery system metrics (such as Flow and DORA) and sentiment metrics (measured through surveys).

To remain competitive and succeed in today’s business environment, software delivery organizations must update their delivery practices and adopt modern system metrics and sentiment measurements.

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.

References

  1. Ari-Pekka Koponen (28 February 2023), The ultimate guide to developer experience, swarmia.com, short URL: bit.ly/468g0q2
  2. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler (06 March 2021), The SPACE of Developer Productivity: There’s more to it than you think, queue.acm.org, https://queue.acm.org/detail.cfm?id=3454124
  3. Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler (03 May 2023), DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity, queue.acm.org, https://queue.acm.org/detail.cfm?id=3595878

Shift Left Security, Security Unit Tests, OWASP Top 10, and AI: Key Practices for Secure Development

by

6 min read

What are we trying to improve? The adoption of practices to find security vulnerabilities early in the development lifecycle.

What outcome do we hope to achieve? Additional security coverage, where applicable, earlier in the software development lifecycle.

Let’s Shift Left

Are you familiar with the term “shift left”? It is a popular concept in the tech industry for good reasons. I define shift left as enabling the earliest feedback. It’s about determining if your code modification is functioning as intended and detecting any potential damage to pre-existing code as soon as possible. 

Why should we postpone identifying an issue until the last minute? The cost of detecting an issue increases as it is detected later in the delivery flow (cost is a whole other conversation). For us, we started shifting left for quality, running tests at all levels, and moving from depending on extensive, long-running tests in staging or production environments to reducing the number of these tests and replacing them with tests earlier in the flow (shifting the tests left). Several libraries support unit test implementation in most languages. Our journey started several years back with Martin Fowler’s article on the practical test pyramid1 and adopting the practice of test-driven development (TDD).

Security Shift Left Mindset

Security has become indispensable to our work in the evolving technology and software development landscape. It’s no longer just about developing features but ensuring they are secure and reliable for our users. Significant improvements have been made at the platform and systems levels. Here’s the kicker: what if we did the same “shift-left” approach for security? Developers can access helpful tools such as profilers, static analysis, and dynamic analysis scanners. The objective is to identify security issues quickly alongside quality and defects. Why not make security-based unit tests a core practice of your team?

OWASP Top 10: Key Practices for Secure Development in the coding stage

We want to ensure our code is secure and get feedback early. One way to do this is to follow the OWASP Top Ten2 security risks while writing and compiling our code. We can use unit tests to help prevent these risks from happening.

1. Injection (OWASP A1): Create input validation tests to mitigate injection flaws.

// Java
@Test 
public void testSqlInjectionVulnerability() { 
  String maliciousInput = "1'; DROP TABLE users; --";  
  assertFalse(isSqlInjectionSafe(maliciousInput)); 

}

2. Broken Authentication (OWASP A2): Develop tests to verify session management and authentication.

// Java
@Test 
public void testSessionExpiration() { 
  User testUser = new User("Test User"); 
  Session testSession = new Session(testUser); 

  Thread.sleep(MAX_SESSION_TIME + 1); 
  assertFalse(testSession.isValid()); 
}

3. Sensitive Data Exposure (OWASP A3): Formulate tests to prevent inadvertent data leaks.

// Java
@Test 
public void testDataLeak() { 
  User testUser = new User("Test User", "password"); 
  Logger testLogger = new Logger(); 

  testLogger.log(testUser);
  assertFalse(testLogger.containsSensitiveData()); 
}

4. XML External Entity (XXE) (OWASP A4): Test XML parsers for correct configuration.

// Java
@Test 
public void testXXE() { 
  String maliciousXML = "..."; // some malicious XML   
  assertThrows(XXEException.class, () -> parseXML(maliciousXML)); 
}

5. Broken Access Control (OWASP A5): Assert appropriate access levels for different user roles.

// Java
@Test 
public void testAdminOnlyAccess() { 
  User testUser = new User("Test User", Role.USER); 
  Resource restrictedResource = new Resource("Restricted Resource"); 
  assertThrows(AccessDeniedException.class, () -> restrictedResource.access(testUser)); 
}

6. Cross-Site Scripting (XSS) (OWASP A7): Implement tests to check how the application handles untrusted data.

// Java
@Test 
public void testXSSVulnerability() { 
  String maliciousInput = "<script>alert('XSS');</script>"; 
  assertFalse(isXssSafe(maliciousInput)); 
}

Other examples for the user interface (JavaScript)

1. Cross-Site Scripting (XSS) Protection: To prevent XSS attacks, you should test that your rendering function properly escapes user input.

describe('XSS Protection', () => {
  it('should escape potential script tags in user input', () => {
    const userInput = '<script>alert("xss")</script>';
    const escapedInput = escapeUserInput(userInput);
expect(escapedInput).toEqual('&lt;script&gt;alert("xss")&lt;/script&gt;');
  });
});

2. Injection and Input Validation: Confirm your software correctly validates the user input and prevents SQL injection.

describe('Input Validation', () => { 
  it('should invalidate input containing SQL Injection attempt', () => { 
    const userInput = "'; DROP TABLE users; --";
    expect(isInputValid(userInput)).toBe(false); 
  });
});

3. Authorization/Access Control: Ensure certain UI elements are accessible only to authenticated or authorized users.

describe('Authorization', () => { 
  it('should not show the admin button for non-admin users', () => { 
    const user = { isAdmin: false };
    render(<Dashboard user={user} />);
    expect(screen.queryByText('Admin Panel')).not.toBeInTheDocument();
  });
});

4. Token Handling: Verify that authentication tokens are stored and handled securely.

describe('Token Handling', () => { 
  it('should not store tokens in localStorage', () => {
    setAuthToken('exampleToken');
    expect(window.localStorage.getItem('authToken')).toBeNull();
  });
});

Check out this YouTube video: DevSecOps wins with Security Unit Tests.3

What about AI?

As we focus on modern security practices, it’s worth touching on these efforts’ using artificial intelligence (AI) advantages.

While you can find posts and articles from earlier this year (2023) concerning the security vulnerabilities that code assistance tools like GitHub copilot can create. However, you can also find posts and articles detailing how quickly the security features of these tools are improving.4

There is no perfect solution. Still, tools like copilot can learn from past incidents, analyze patterns, and predict vulnerabilities. They can generate test cases based on software behavior and suggest edge cases to enhance our unit testing process. These tools can enhance security unit tests. Machine learning models can be trained on numerous secure and insecure code examples, predicting whether a new piece of code might contain security vulnerabilities based on patterns they’ve learned. These tools can flag potential security issues as developers write code, providing immediate feedback and opportunities for learning.

AI can assist in static and dynamic security testing. One example is that AI can help with the time-consuming task of sorting through false positives in static code analysis results. Additionally, AI can identify patterns in code that humans may overlook and point out areas that require further examination. In dynamic analysis, AI can help mimic the actions of real users by interacting with the software as humans would, finding vulnerabilities that manual testing might not uncover. The continuous learning process of AI models also ensures that our testing procedures will evolve alongside new threat patterns.

Wrapping this up

While the OWASP Top Ten may not encapsulate all possible security issues, it provides a robust foundation for our security practices. Incorporating these tests into our daily workflow is a strategic move that will substantially enhance our products’ security. Such tests should be designed to verify that the user interface effectively implements various security measures. For teams yet to adopt this “shift left” practice, it is imperative to start integrating security testing earlier in the development process and uphold high-security standards.

To stay ahead of evolving threats and reinforce our software’s security, we should also consider the integration of AI into our security strategy. AI can enable us to identify and tackle potential vulnerabilities proactively. However, it is essential to remember that these powerful tools are intended to supplement, not substitute, our existing security practices and intuition.

Let’s focus on enhancing our security practices as we move forward. We should adopt emerging technologies like AI while keeping our main goal in mind – creating secure and reliable software for our users. By implementing strategies such as “shift left” security and utilizing the tools available to test the security of our code, we can stay ahead of evolving security threats and maintain the trust of our users.

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. Martin Fowler (26 February 2018), The Practical Test Pyramid, martinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html
  2. Aimee, Nikki, and featuring Abhay Bhargav (26 September 2021), DevSecOps wins with Security Unit Tests, youtube.com, https://www.youtube.com/watch?v=i34Ihbuslgw
  3. OWASP Top Ten, owasp.org, https://owasp.org/www-project-top-ten/
  4. Shuyin Zhao (14 February 2023), better AI model and new capabilities, github.blog, https://github.blog/2023-02-14-github-copilot-now-has-a-better-ai-model-and-new-capabilities/

Beyond Features: A Software Engineer’s Code of Conduct for Delivering Impactful Product Outcomes

by

3 min read

“The software industry is a great example of an industry where the responsible thing to do is not always the easy thing to do.” – Bill Gates

and

“With great power comes great responsibility.” – Uncle Ben, Spider-Man

When you are hired to work for someone else, it is essential to prioritize their interests in your work. The organization, its customers, and your team trust that you have their interests at heart.

In the rapidly evolving world of software development and digital product companies investing in digital transformation, cross-functional product delivery teams often grapple with effectively managing four critical aspects of their products: features, technical debt, risks (security), and defects. 

Moving Beyond the Feature Factory Mindset Today

Despite the widespread adoption of agile, lean, and DevOps practices, an excessive focus on delivering new features can lead to technical debt and deprioritized defects, ultimately hampering the team’s efforts and overall product quality. This misalignment of priorities and culture is often the result of overdominant voices influencing the end product.

Showcasing Security, Quality, and Performance as Core Product Features

One solution to this challenge lies in cultivating a team mindset and culture that values risk (security), quality, and performance (technical debt) as integral aspects of the products delivered to customers. As one Product Manager insightfully mentioned in a podcast, he and his team view quality, performance, and security as core “features” of their products.

To effect lasting change in team culture, we must foster collaboration and alignment across all roles, working together towards a shared purpose and goals. This balanced approach to feature development, technical debt management, risk mitigation, and defect resolution can lead to a more purposeful alignment of goals and exceptional customer products.

Introducing the Software Engineer’s Code of Conduct and Responsibilities to Product Delivery

As a software engineer hired to craft and deliver software on behalf of my team, my organization, and our customers, I will:

  1. Goal Alignment, Outcome Clarity, and Realization: Developers should ensure their work aligns with broader organizational goals and clearly understand desired outcomes before starting any task. Work items include features, technical debt, defects, and security risks. Clarity promotes alignment, purpose, and direction, ensuring every effort contributes to the organization’s strategic objectives. Additionally, clarity involves evaluating results after project completion. Teams should compare actual metrics with expected ones to assess the impact of their efforts. This reflective process fosters continuous improvement, ensuring that work advances progress rather than just increasing output.
  2. Strive for excellence: I will produce high-quality implementations using the best of my abilities and skills at the time, and I will speak up when quality is compromised or overlooked.
  3. Foster collaboration: Actively collaborate with team members to share knowledge and achieve collective goals, recognizing that teams – not individuals – deliver software.
  4. Embrace testing and continuous improvement: Implement all required automated tests, follow test-driven development practices, and actively participate in pull request code reviews to ensure high code quality and incorporate feedback before deploying to production.
  5. Prioritize security: Ensure code is secure and adheres to best practices to minimize risks and vulnerabilities before production and address any existing vulnerabilities in the code I work on as part of my daily routine.
  6. Manage technical debt: Regularly refactor code to maintain readability, optimize performance, and minimize accumulated technical debt, speaking up for any debt that is being ignored.
  7. Use my voice: Feel safe speaking out when the other five responsibilities are neglected, and seek alignment from the team to understand why.
  8. Protect intellectual property and responsibly use AI: I recognize the benefits of leveraging AI in software development. However, I will act responsibly to protect my organization’s intellectual property. I will not share proprietary information or code without proper authorization and will ensure that AI technologies are used ethically and in compliance with applicable regulations.

Adopting these principles for software engineers working in cross-functional teams can help prioritize a balanced approach during product planning. This will lead to consistent production of high-quality, secure, and performant software while avoiding a backlog of risks, defects, and technical debt that can result from constantly adding new features.

Poking Holes

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

Let’s talk: [email protected]

Related Posts

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

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.