No organisation ever knows what it wants, but it always knows when it wants it by

This is not a blog post about computer science; it is about one of the many reasons why building software that effectively fulfils the requirements of your employer is so hard. Because in the real world, change is constant.

No organisation ever knows what it wants

No organisation exists in a vacuum; an organisation’s strategy can change the moment any stakeholder makes a decision:

• Losing or gaining a large customer can have such a large impact on the organisation’s income that just the threat of this happening can trigger changes.
• New regulations can have a wide ranging impact on an organisation, the introduction of GDPR and the sudden need to be able to find and delete all data held on individual users is a prime example.
• New executives are often hired specifically to drive the next stage of growth.
• Even everyday office politics can introduce unexpected shifts.

The more time passes, the more stakeholders make changes and the more likely the organisation is to react and adapt what it wants from its product and technology teams.

But it always knows when it wants it by

An organisation’s leadership does not exist in a vacuum either and answers to any combination of owners, investors, regulators, and the board. These stakeholders are powerful but do not dedicate the majority of their time to the organisation, and so need a way to quickly gauge the organisation’s health and progress. This often results in goals and timelines. And because these goals and timelines are conveyed to the most powerful decision-makers, they are very hard to move.

Stuck in the middle with you

When taken together these mean that product and technology teams are caught perfectly between a rock and a hard place. Any technology takes time to build, if what the organisation wants is always changing, but the deadline it wants it by does not, then inevitably the organisation will eventually request a change that runs over the deadline.

How to cope

Unfortunately offering advice on how to cope with this phenomenon is very hard because the forces that cause it are different at every organisation. But there are some approaches you can employ:

• Understand what causes changes - Knowing the why can better help you cope with the challenge and adapt to it.
• Advocate for improved processes - Explain how practices like agile development use a deliberately short development cycle to accommodate changes rapidly.
• Educate stakeholders - Remember that everyone around has their responsibilities and they might not understand what the day to day of software development looks like or why their small change can have such big consequences.
• Show them the money - Most people don’t understand what technical debt or developer experience are, but everyone understands money. Focusing on how changes increase costs or reduce profit can be much more effective.

Conclusion

The difference between a good developer and a great one is not the quality of their code, it is how well they solve problems and create value; code is just the vehicle developers use to do this. But if you want to maximise the value you provide then you need to understand what problems you are solving, where those problems come from and who you are solving them for. Learning to navigate the organisational culture you are in is a good first step.