Reducing the HumanDebt™

First off, and before I launch into today’s meaty topic -warning, you'll need to grab a cuppa, it’s very long-, if you only subscribe to this newsletter and not the “Chasing Psychological Safety” one, then you would have missed on two more articles continuing last week’s theme regarding why we need “teaming” and what the role of a servant leader is in “teaming” and you’ll find them behind these links.

Now…although I know this intellectually, I never cease to be amazed by the utter blindness that some organisations have towards their HumanDebt™. Anyone I speak to about this -and I don’t mention it to some exec types for evident reasons- immediately connects to the definition I gave it in my upcoming book “People Before Tech: The Importance of Teams and Psychological Safety in the Digital Age” which amounts to:

Evidently, this resonates more in the Tech community than anywhere else, as anyone who’s written code can instinctively feel when/if they cut corners or left things unfinished, untested or undocumented and how enough instances of that over time, create debt so they comprehend how this came about in other areas of the business too. Furthermore, being Agile to the core means becoming comfortable living with a degree of “unfinished” and with a blessed mentality of continuous improvement whereas the folk in HR, Finance and so on, are convinced they had completion in every project they ever had their hands on, deluded by their incessant waterfalling.

Resonating with the topic and doing anything about it, are two different things though. While there are some valiant Agile Superheroes who advocate for focusing on people in DevOps inside their organisations with all their might and make that their main epic *every* sprint, there are many other tech leaders who understand the need but don’t feel either entitled or equipped to make it their to-do. Most of it is ironically the result of the HumanDebt itself - in a rigid, stifled and punitive organisation, the appetite to propose anything that’s not in the job description or doesn’t seemingly fall under one’s mandate, is inexistent. Part of it though is feeling inadequate on human topics.

The great paradox of DevOps is that, while it contains the humans most well equipped to deal with people topics in the entire enterprise -both in terms of knowledge, willingness to work and closeness to the team dynamic- they are too modest and too stunted by organisational issues, or lack the self-confidence to do that work, leaving it to those who on paper ought to do it for them but who have no real understanding at all about what it would entail in the new world of building tech with breakneck speed.