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:

HumanDebt? is the equivalent to Technical Debt but for people. All of the initiative, the projects, the intentions we (the organisation) had to do better by them, but we abandoned halfway. All of the missed opportunities to make their lives and their work easier and more joyful. All of the empty talk on equality, respect, lack of blame, courage and trust. All of the missing talk on teams. All of the lack of preoccupation or resources for building better team dynamics. All of the toxic culture that comes from it. That’s Human Debt. 

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. 

I hear tech leaders say “Sure but it’s not up to me” or “I have no training in Psychology” or even “But we already do some of these people things, certainly more than the rest of the organisation does” countless times and it all traces back to a lack of self-confidence. When I do away with the first two objections by pointing out it has to be up to them as they’re the only ones who truly know what DevOps entails in terms of human dynamic and no HR department can come in and sort that, and that they need no training, they have all the knowledge that’s required readily available and that it’s not a degree in Psychology they need, but common sense, willingness and investment in growing their EQ, that last objection comes out and when it does, it needs examining. 

Last week, I challenged a CTO of a financial software company who had told me “Yup, we used to have HumanDebt and I used to hope HR would swoop in and fix my dysfunctional teams who were evidently falling behind because they were riddled with fear and inside politics but it never happened so I took the reigns and am a lot more involved in doing these “human things”. If you went to any retro we do, you’d see.” 

So I invited myself to one. They thought I was joking, I wasn’t. They objected it would be boring, that it’s “complicated” and that I wouldn’t understand. I said I’ll cope. They said they “won’t have time for me” - I said I’m more than happy to do “fly on the wall” muted with no camera but that would just make people impression manage even more so we eventually settled on the team leader asking the team for permission so that we learn and adapt and recording one of their retros for me so I tell them if their “human things” were enough and where in their session, they could use data from the Psychological Safety Dashboard.

I watched the session -several times-, then sent a super-long, super-honest and likely unpleasant-to-read email to the CTO outlining what I learned without naming people but observed behaviours, before asking him if it’s ok to invite the rest of the team in to dissect it -i.e. you guys- and he was, thankfully, not only open to it but excited by the possibilities so make sure you leave comments to this with your own perspectives he is hoping for. 

Going into specifics would be pointless but in short, what I saw were 2 instances of “human things” - an initial “How is everyone feeling about last sprint” generic check-in and a couple of rounds where the team lead intervened to encourage participation stating organisational permission and mentioning psychological safety “Guys can we do an honest round on this one? The more controversial the better, you know this never leaves the room, why do we really think this happened?”. Beyond that, it was all a template-based post-mortem listing incidents, quoting the tickets in question and wondering about improvements to process or technology used, then concluding on some things that were not even recorded anywhere and closing with a feeble motivational speech to an audience who had long lost interest if not even their will to live. 

When I spoke to the team leader after, he gave me all of the aforementioned “Yes but…”s first stating he’s not a psychologist, that it’s hard, that the team has issues that pre-date him, etc. When I asked why does he really think if he’s honest that some of the issues in the sprint occurred I got answers along the lines of “we just weren’t flexible enough, people are afraid to take initiative and change course without approval”; “people are burnout”; “there’s unresolved bad blood”; “such and such is new and afraid to speak up”; “they don’t trust each other so they don’t communicate openly”; and “I guess we say “blameless” but we don’t feel that way to the team” albeit all qualified with “But what do I know?”s .

All true and corroborating perfectly with what I would have presumed were the issues. All undoubtedly evident to not only him, but everyone else in the team, but none touched on, leave alone worked on. When I showed him that each of his observations map to our specific measured behavioural components on the Dashboard, that it was all about the “Flexibility”, the “Resilience”, the “Openness”, the “Engagement” and the lack of “Learning” his face visibly lit up “So this thing will show us if there’s intangible stuff at play that causes some of our issues?” - I asked if I could use that as a tag line and we had a good laugh then advised that they start with a “Team B!tch Fest” from the Playbook when they start getting the data back in the next retro to get rid of some of the historical “bad blood” he had identified.

Any retro that goes by with missed opportunities to identify and intervene to correct any of this “intangible stuff” and where the “human things” are reduced to those two instances, is one that adds to the HumanDebt for the company and ultimately a complete waste of time for the team itself, as few of the process or technology improvements will yield any results. 

Seeing the “intangible stuff” in data that the whole team contributes to, and then having a space that demands they think of the “human things” specifically and come up with at least one exact ticket on a human intervention in the next sprint, means it is no longer the fluffy thing you do once a year at an offsite or the awkward Zoom company quiz night, but a serious and important “to do” that you have you carve time for, that’s intentional, effective and improves a specific team dynamic in every sprint. 

At PeopleNotTech we are great believers in DevOps being the key holders to organisational change at the team level in every tech company and in their extreme self-sufficiency, given enough confidence and data. So much so, that in our next design sprint we need an “Empathy Hackathon” play in our own team focused on “If I were one of these DevOps superheroes I would feel...” to make sure we help them make a dent in their HumanDebt. 

How much of it do *you* have?

—————————————————————————————————

Don't send your teams home with a laptop, a Jira and Slack account and a prayer!

Get in touch at www.psychologicalsafety.works or reach out at [email protected] and let's help your teams become Psychologically Safe, healthy, happy and highly performant.