Demystifying individual impact in software development

When we say a developer has impact, we generally mean their work creates meaningful change. The end result of a developer’s work could be a feature that significantly improves user experience, or an innovative piece of code that makes the system more efficient. The question is then: how can one correctly assess this impact?

This is not an easy question to answer. The challenge with impact is that it is hard to measure, particularly at an individual level. As Forsgren, Humble, and Kim (2018) explore in their book Accelerate, assessing impact involves understanding the scope and objective of a project, and the specific role you play in it. But a goal that makes business sense is equally important. This means that the software you develop should solve real problems for its users and create real value for the business.

A good question to always ask yourself before starting any project is “how will this create value for users / customers / partners / ourselves?”

Consider the example of an “infinite scroll”. When a developer implements this feature, they are fundamentally transforming how users engage with the platform. With any change, we can formulate a hypothesis. For instance, “this change improves user retention and engagement, thereby directly impacting business metrics”.

Setting goals that are clear, measurable, and aligned with business needs is vital. In this case, the goal might be “to increase user session duration by 15% implementing an infinite scroll feature within the next quarter”. It’s a clear, measurable goal that makes sense for the business.

At this point, it is tempting to assume we are done thinking about impact. But then, how do we know the goals we set at the beginning were met? How do we validate our hypothesis? How do we know if there are other unexpected benefits we did not account for originally? Or if something went wrong? And how do we assess, and potentially reward, individual impact?

Formulating a comprehensive framework for impact

While there is no definitive formula to calculate the impact of a software engineer, we can hypothetically structure it as a sum of different components. Note how this is different from, but certainly related to, the impact of the project as a whole. Here’s a general outline:

• Business impact: the direct contribution to business metrics, such as increased revenue, reduced costs, or improved customer satisfaction.
• Product impact: the addition of new features that increase differentiation or close gaps against competitors, as well as bug fixes that improve the overall health of the product.
• Process impact: the improvements contributed to the engineering or product development process, such as reduced time to market, increased code quality, or improved team efficiency.
• Educational impact: the extent to which the engineer helps upskill other team members, sharing knowledge or introducing best practices.
• Operational impact: the effect of the engineer’s contributions on improving the reliability, efficiency, and robustness of systems and services.
• Cultural impact: the influence the engineer had on team dynamics, morale, or work culture.
• Strategic impact: the degree to which the engineer contributes to or defines the strategic goals of the project or the organisation.
• Security impact: the degree to which the engineer’s work helps the product meet security standards and protect user data.

Once we have a list of components, we can go one step further and prioritise them based on directness or diffuseness of impact, scope of influence, universality, long-term strategic importance, context-specificity, and so on.

Navigating the interface of individual and team impact

In the world of software development, it’s clear that both individual and team efforts matter. While we’ve discussed the different facets of individual impact, it’s equally important to recognise that a lot of these individual efforts are indeed manifested within the context of a team. Many times, the idea for a piece of work might come from a team discussion, or the task might be assigned based on team priorities. This begs the question, how do we navigate this interface of individual and team impact?

Understanding this begins with the acknowledgment that the nature of software development is inherently collaborative. The most efficient software development teams operate with a high degree of interdependence. Tasks are divided amongst team members, who then contribute their expertise to solve different parts of the same problem. Therefore, it’s important to understand that an individual’s impact is not diminished if the original idea came from someone else, or if a task was assigned rather than self-initiated.

The ability to take an idea from a colleague and turn it into a tangible, high-quality output is a clear demonstration of impact

In fact, it’s quite the opposite. The ability to take an idea from a colleague and turn it into a tangible, high-quality output is a clear demonstration of impact. After all, software development is not just about generating ideas, but also about executing them effectively. Furthermore, being able to work on an assigned task shows an ability to contribute positively to the team’s overall goals and priorities.

In other words, individual impact in a software development team is as much about “how” we contribute to the team’s success as it is about “what” we achieve on our own. This “how” includes our ability to collaborate, our capacity to execute on tasks (whether assigned or self-initiated), our openness to learning from others, and our contribution to a supportive, productive team culture.

When we measure individual impact in this way, we embrace the complex, interwoven tapestry of team and individual performance. We create space for individuals to shine not just in their isolated successes but also in their contributions to the team’s collective success. The challenge is to create an evaluation system that recognises this multifaceted nature of individual impact. It should value individual technical contributions, but also account for collaboration, communication, and other softer aspects of teamwork.

Assessing the impact of a software engineer goes beyond tracking lines of code or number of commits. It involves looking at the larger picture of how an engineer’s work contributes to product improvement, team efficiency, business growth, and user satisfaction. Part of this assessment also includes understanding that the impact of one’s work may not be immediately visible and it may take time for the true value to unfold.

As an engineering manager, it’s essential to set clear expectations, offer guidance, and give recognition where it’s due. By cultivating an environment where engineers are encouraged to seek impact and understand its different facets, we can foster growth, innovation, and ultimately success.