It's a common refrain that external groups, such as customers and senior leaders with accountability, are always the most valuable stakeholders for a digital service. However, when the systems we work on are done so in perpetuity, this feels like a one-dimensional view.
These external stakeholders often only have a high level view of the service and little understanding of the underlying systems that power it. Perceiving business value only as something that addresses the needs and concerns of external actors risks undermining the entire service.
If we want to be more confident in the long-standing success of a service, then we ought to consider the tech teams that build and maintain the systems themselves as valued stakeholders as well.
A common pattern of overlooked concerns
If you are a software developer, then chances are you have experienced the frustration of trying to justify the non-shiny work that still provides value. These are often stories such as:
- Improving code quality
- Reducing tech debt
- Improving onboarding and installation processes for new developers
Fundamentally, the work around these stories will provide business value. However, because they're internal, abstract and not an easily marketable shiny new feature, they are often deprioritised by senior stakeholders.
Sometimes, it's acknowledged that there is work to do to improve the underpinnings of a system, but it's almost always the case that this maintenance work is never brought into sprints.
For whatever reason, the perception is that there are always new features to build; it just so happens that tech debt also builds as more gets piled on top of faint foundations.
Build an understanding of the development process
If developer concerns are not acknowledged by the wider organisation, then this is a problem that risks alienating the one group that works on delivering and maintaining these systems. This may lead to feelings of resentment, and potentially churn if developers feel they are coming up against a brick wall of intransigence.
The relationship between developers and senior stakeholders should therefore be predicated on empathy. Senior stakeholders should afford time to understand what software development work actually entails. It is incumbent upon us as software developers to help in this regard; senior stakeholders don't need to have an in-depth view, but simply an appreciation of what developers contend with when building software is key to establishing empathy and a better relationship.
For instance, the build-measure-learn feedback loop is a common maxim of what folks would consider 'agile working'. However, once the minimum viable product (MVP) is shipped, the actual shape of this feedback loop is prone to become malformed by stakeholders who may not appreciate what software work entails. It becomes less a case of build-measure-learn, and more of build-build-build instead.
Just because software has been released doesn't mean that it's the finished article. It simply means it's working. Much like how flowers in a garden must be consistently cared for to ensure they aren't ravaged by pests and disease, codebases require time and attention to ensure that deficiencies are addressed where appropriate. This work is still providing business value, even if it's not as exciting as new features.
Trust and empower developers to address underlying concerns
It's important to acknowledge that the concept of business value extends beyond the needs of senior stakeholders and customers when it comes to digital services.
Developers - those with an intimate understanding of the systems and how they operate - are stakeholders; they have needs and concerns that must be balanced with those of other groups.
The work developers want to do may not be as striking as a new feature, or may even have no impact on the performance of the service altogether; some work may just be to improve developer experience. However, if organisations want to ensure their services are reliable and that their systems are robust enough to change at speed, then they must acknowledge that these more abstract tasks still have inherent business value. A failure to recognise the importance of these tasks adds risk to a system's longevity.
Trusting and empowering developers with the autonomy and tools to address their concerns will pave a way to improved systems - and consequently a better service for end users.
Top comments (0)