How Technical Debt Trumps Chief Culture Officers
Over the last few years I’ve seen people writing and talking about an organizational role which hasn’t been here before. The name of the role is Chief Culture Officer. Today I’ll take a piercing “why”- “what for” look into the origin and the purpose of this role. As you might know from my previous articles (The Roots of Copy-Pasting and The Manifesto for Big Picture Pragmatism), I’m a fierce opponent of the mainstream trend to copy-paste organizational practices, and my attitude is based on years of observing how the “copy-paste” action often accomplishes the opposite of what is meant to be.
As often is the case, God said let there be a buzz. This time, the buzz has been about the importance of organizational culture for driving business results. I’m not going into the history of how the “culture” buzzword made its way into the life of software development organizations. There have been many books, and authors, etc. but this is not the point for now. I’m looking at how the buzz around organizational culture has triggered a certain wave of copy-paste — because to copy-paste is human, after all :) Just as there have been roles responsible for production, marketing and operations — all those kinds of various “chief <insert here> officers” — they now reasoned that if culture drives business results, too, there has to be an executive in charge of culture, just as there are executives responsible for marketing, operations, etc. In this context, culture is automatically put in one line with the basic building blocks of an organization’s success, as shown here:
Production — Operations — Marketing — Culture (?)
Let’s now consider if this approach is accurate. On what grounds do we usually state that an organization has a healthy culture? Very briefly, this is about people being happy about their work, because the organizational framework allows them to do their work with zero impediments. And, the organizational framework, indeed, does consist of smaller building blocks, which are cohesive with one another. People usually become unhappy if there’s a lack of cohesion between the blocks, OR, if a certain block by itself is fragile and/or hard to sustain. Hence, organizational culture is, to a larger extent, a derivative from the blocks unrelated to culture per se.
I’ve got a shining example of how culture happens, at software development organizations, and one wouldn’t probably see this connection right away. The thing is… it’s software itself, the code, that makes or breaks the company culture. I’m talking about technical debt, the term originally coined by Ward Cunningham many years ago.
For most of the 21st century there has been a need to release fast. This need is rooted, generally, in all things marketing and sales. Agile as a methodology has a lot to do with this “release fast” imperative. Unfortunately, everything in this world comes with a price tag, and the “loans” which cause technical “debt” come with their interest rates, too. The time loan — the fast releases — accrues technical debt as the code becomes messy, much like a storage space to where they stash stuff in a hurry. Usually, there’s someone who’s been around from the very beginning, and it’s this person who more or less knows where stuff belongs, in the code, and why it has been put there, in the first place. Notably, it is in no one’s intentions to make the code messy on purpose. The messiness is either a result of a work under pressure, or a conscious attempt to put off the clean-up of the code to a later time, or both. A lot has been said and written as to why the technical debt occurs, and what can be done about it, e.g. refactoring and/or re-write. My focus will be on the human component. How can technical debt erode the organizational culture?
First, the technical debt implies that there’s a certain group of know-it-all’s who do actually make sense of the mess in the code. These are usually the go-to guys without whom… cleaning up a code would be like fishing in a sewer. And, those guys are perfectly aware of their power. On the one hand, the unique knowledgeability about the messes gives them the upper hand. The newly hired developers, or junior developers, have to rely heavily on those “guru” figures. On the other hand, the gurus will be faced with the dilemmas of their own. Basically, their dilemma would be: do I want to stay secure in my current job, attending to this code, and being a go-to guy for all, or do I want.. something else? Like, do I want to re-write this code from scratch, re-build the logic, document everything properly, and leave a truly neat legacy for my colleagues, so they can make sense of the code when I leave?
And, it’s upon contemplating this question that the guru know-it-all guy may turn into a cynic, because… the constraints beyond personal might not let them act. For a number of reasons. And, if a guru guy is a person of integrity, it’s only a matter of how long they would allow themselves to be torn by the bitterness. For some, stagnation and cynicism overrule and they just stay on until… someone provides a jolt.
The internal struggles of the guru guys make just one side of the coin. Technical debt usually entails more work for technical support — because you never know how fixing a bug in a sloppy code will backfire for users. On a brighter side — paradoxically — a debt laden code usually serves as a fitting launchpad for junior developers. They work with the gurus (as in e.g. pair programming) and learn. And, the more they learn… the more they are willing to bring their best to the table and.. pay off the tech debt, finally! The enthusiasm about building something anew brings a fresh stream to the organizational ethos. The gurus, meanwhile, still stick around, poisoning the culture with their cynicism. This outline is by no means exhaustive, I just want to sketch the dynamics. In the end, we will be faced with the two colliding waves: the enthusiastic developers who want change, and the cynical developers who are comfortable in stagnation. This does sound like a cultural shift in the making… but would it be a job responsibility of Chief Culture Officer to influence the change of winds here? Mostly, an executive in this role would only be able to proclaim values… but what those proclamations would be worth without… well, the proper handling of the technical debt? And, do you see how a Chief Culture Officer is supposed to facilitate the change, in this case? Oh, and I forgot to mention high turnover, as one of the consequences. Would this high turnover thing, which results from the technical debt, be a responsibility of those in charge for hiring and retention? The truth is, people in hiring often know that .. it’s not the perks and office fun that ultimately keep people in the company, but something beyond that. And, well, a balanced technical debt management would be at the core of this “something beyond” space!
The question now is… who‘s responsible ?:) Or, would it be wiser to give up searching for a single role in charge and rather act from a space of empathy and understanding, as one whole unit? It’s the cohesion between the building blocks I’ve been talking about. Culture happens. It cannot be installed like a software update by introducing a role. And, as I’ve observed, a healthy culture just happens when an organization simply lives up to its values by walking the talk.
