Developers are stakeholders

When it comes to prioritising work you may find yourself in an environment where it can feel hard to justify playing "technical" stories. These are stories raised by developers and typically cover

  • Raising the quality of the code
  • Fixing technical/architectural debt
  • Addressing edge-cases
  • Making the system easier to operate

The usual excuse for not playing this work is that a team should only ever be delivering "business value" but that is almost always defined as customer-facing features.

At the same time developers will be responsible for making sure the system works, often obliged to be on call using their precious free time. This is a responsibility which is usually uniquely assigned to developers. You will rarely find a project manager being on call.

This isn't an issue of fairness, on a practical level it is unrealistic for anyone other than developers to fix most issues.

But given developers are responsible for not only delivering but also maintaining these systems it is only fair that they are also treated as stakeholders and need to have a say on what non-shiny work is being done.

But what if the developers spend all their time over-engineering everything?

This is nothing more than a matter of trust. If you do not trust your developers to make pragmatic choices for delivering sustainable systems then you have big problems.

Presumably you are doing showcases every one or two weeks so it should become very clear quickly if your team isn't delivering stuff as fast as you like.

Why didn't they make it sustainable and reliable in the first place?

Remember that whole agile thing of build->measure->learn? And the prime directive? It is unrealistic to expect all software to be perfect when it is first built. Only when you have shipped some code and seen it used do you really start to understand the flaws in the implementation.

If you think you can just ignore the developers and entirely micromanage their time then they will resent the project and especially resent being woken up at 3am to fix a problem which they had anticipated but you didn't believe them.

If you value the following attributes of your system:

  • How easy it is to change
  • How reliable it is

Then you have to acknowledge that the work developers wish they could do has business value.

So talk to your developers, trust and empower them.