Photo by Henda Watani on Pexels.com

“Cattle not pets” is a well-used analogy in cloud infrastructure about the change in mindset needed in order to embrace the power of infrastructure automation, auto-scaling, etc. Its point is that your servers are no longer lovingly hand-crafted machines named after characters from genres such as Lord of the Rings (guilty in a previous incarnation) but instead are just anonymous beasts of burden to be spun up and discarded without a moment’s thought. For a platform engineer in 2020 (or anyone else employing IaC), servers just do their job and are entirely disposable when no longer needed.

When it comes to systems / products / applications (*) in mid-to-large organisations, many permanent employees (and oftentimes the conscientious contractors) will tend to feel a sense of ownership of the system they are working on. They will want to improve “their” system to make it easier to work with, better for users, and to improve the internally structure. They will invest in the system at an intellectual and/or emotional level and they will want to make it something they can be proud of. This doesn’t necessarily mean that it’s technically whizzy, a stunning lean startup product in a new market, or at the cutting edge of current UX theory but that it’s serving a useful purpose, delivering value to its users and value for the organisational sponsors who pay for it.

In many scenarios, this is a good thing. The feeling of ownership, or at least of being bought into the outcomes of the system, feeds the sense of “purpose” as in Daniel Pink’s motivational trio of “autonomy, mastery and purpose”. If people care about what they work on they will usually do better quality work and be more focused. They may also lavish more time and mindshare on it but whether that’s a good thing is open to question (see also: sustainable pace, taking a break, getting some exercise, etc.). In many ways, the system / product / application is a bigger version of the hand-crafted servers. However, as long as people don’t become obsessive then this seems like a positive thing, right?

The problem comes when other people in the organisation see this particular system / product / application (*) as one of the cattle, not a pet. The system provides a function to be shunted around based on the opinions of people outside of the team working on it. This may range from keeping it on a very low budget to throwing it into some form of BAU team to replacing it completely with a module of SAP / Oracle (*). Alternatively it may involve some aspects of the system being mandated as part of an organisation-wide standard around security, data management, cloud hosting, etc. so the team lose control. In such cases, the idea of “ownership” of a system is not likely to be a concept shared commonly across the organisation and this is where it becomes tricky. You don’t want people to be detached from what they’re working on but equally it’s a corporate asset, not a hobby or side-project.

Now in some cases, replacing all or part of a system that has been lovingly crafted may make sense. If an organisation is using techniques such as Wardley mapping to manage the lifecycle of the functionality it needs to pursue its business then there will be parts of the estate that move from being custom-built to commodity as the world changes around them. This (to quote Gene Hunt in Ashes to Ashes) is the way of the world. The challenge is how to get everyone to share a common idea of where a given system is in this lifecycle.

The first part of this is to get everyone to acknowledge that there *is* such a lifecycle. It may be sobering for someone working on a team in the first flush of the discovery phase to consider that in a few years time they, or their successors, may need to switch the system off and replace it with something more off-the-shelf. Equally, people who are used to delivering software by way of a project and then pushing it into some state of “BAU” suspended animation need to understand that if it’s worth the investment to build a software-based system then it has to be worth proactively evolving it (if not, you may just have made an expensive buy vs build mistake).

The second part of it is to hand the ownership of that lifecycle to the team around the system / product / application. If they are responsible for the delivery of the business value and for the budget available to deliver it then their knowledge of the system should put them in the best position to make a good decision around its evolution as long as a) they have sufficient time available to do the thinking and keeping up with the market in their domain to know what is available outside the organisation, and b) the organisational incentives reward good behaviour of flipping custom systems at the right time as opposed to accumulating systems, people and scope.

Letting go of things that were once a large part of your life is often difficult but it’s always easier if you’re involved in the decision of when and how to let go.

* delete as appropriate based on your current organisational dialect