From concept to practice, bypassing function

Why do many so often get things wrong at first?

A topic in a recent conversation I had, caught my attention. The subject was the journey to adopt new, potentially improved ways of doing things. It made me reflect upon my own observations that when a new paradigm or a concept is introduced, but before being accepted as part of the “normal” and becoming a practice, it goes through an intermediate stage in which it is treated as a stand-alone, distinct function. This transitional phase from concept to practice is most likely to appear when a new mindset requires the affected groups to shift their priorities and responsibilities. What I mean by that is when someone is expected to do something novel or do things differently or is asked to care about something new, the idea of the practice tends to take the form of a function first. This is not only interesting but potentially disruptive within a functioning company environment.?

Of course, my observation is a simplification: it includes those pioneering groups/companies that spearhead the proposed mindset change in the first place. Such changes do not usually start in academic research but evolve from a group of innovative individuals who tried something new that, sometimes even to their surprise, actually works.

Hopefully, I've piqued your interest by now, so let’s look at some examples.

DevOps: A classic. Start a conversation with your peers about what DevOps is. I can almost guarantee that the number of permutations and often contradictory definitions will amaze you. Despite the original proposal that called for the unification of Development and Operations into one delivery cycle that was already discussed in the early 1990s, the term was officially adopted in the early 2000s, and as you may already imagine, was about combining the two disciplines of responsibility, ownership, and knowledge. The famous infinity loop shows a continuous process owned by the same people.?

However, what we witnessed instead was the birth of DevOps as a function; it was not the child we all expected. System administrators and people who genuinely liked and understood the infrastructure domain, which was accelerated in complexity with the mass adoption of public and private cloud solutions, rebranded as DevOps engineering to fill the void. A void that should not have existed if DevOps had been adopted as practice.?

Fast forward 15 years and a casual web search for open DevOps engineer positions still yields results spreading over multiple pages. Throughout my career, I have also noticed a reluctance of developers to take ownership of the actual delivery and code they produce in a post-deployment phase, not to mention its operation, let alone trying to understand the underlying services that make their solution tick. Things are better now but not before large and small companies have established a DevOps organization for which they hire DevOps engineers, which in turn has shifted the whole recruitment market to treat it as a standalone function. There are infrastructure and platform engineers on one hand, and there are product developers on the other. While the role of the former is to abstract as much as possible the complex part of the cloud, the role of the latter is to develop and own their solution from idea to post-production with a deep understanding of how the services are running; how to make them observable and how to troubleshoot and fix them in case of malfunction. As DevOps slowly becomes what it was intended to be, a set of frameworks and practices, a role that now has experts, consultants, and a “Heads of…” - is going to be very hard to dissolve.?

Another example of a concept just entering the “function zone” instead of the “mindset and practice” is FinOps. By function, in this context, I refer, again, to a set of responsibilities associated with a defined role within an organization, accompanied by the usual bells and whistles: career progression ladder,? competencies matrix, KPIs, etc. A ladder that also, in scale has leading positions defined. The idea behind this practice is to enable cost control of the cloud services that not once have doomed small companies to spiral out of control. Understanding the costs, applying unit economics, applying proper financial products provided by the cloud provider, and making sure the product is architectured and running most efficiently are crucial for any cloud-based business, both in the early prototyping stages and even more in growth. One would assume that the person who should possess the FinOps mindset would be the infra team, the product engineering team, and someone from the CFO office, if not the CFO itself. Some cloud providers offer training and certification for engineers to grasp the crucial connection between the product and its cost. Yet, to my awe and horror, recently, I saw the “FinOps Engineer” role emerging. Sometimes they hide behind names like “infrastructure efficiency engineer” or “FinOps Analyst”. The latter could make sense if found in the Finance organization, yet those report to the technical pillar and require in-depth knowledge of cloud services on top of financial savviness. This will lead to the creation of experts and consultants and undermine the adoption of the practices that are so much needed by the people located close to where those should be applied.?

Tech is not the only area where such a phenomenon is observed. Let’s take the star of the recent headlines: DEI. Diversity, Equity, and Inclusion - a framework, a mindset, a practice that aims to straighten the historically skewed way companies are hiring, compensating, praising, promoting, and maybe even simply treating their most important asset - human beings, on a daily basis. DEI is a goal, not a department, not a function, and not a role. DEI is a practice, a mindset, a framework of actions, not a department, and probably not a role in HR. Yet we see DEI departments, “Heads of..”, and designated individuals that are being put in charge, ideally with a good intention to make sure the company is doing its best, yet leading to the fortification of a newly born function with complex sub-roles, competencies, and hierarchies. Some people became rubber stamps and report generators, and the reason they have come under fire recently is that, in some cases, they achieve exactly the opposite of the mission they were assigned to. Similar to DevOps, we see an establishment of a role instead of the adoption of practices, and diminishing the personal responsibility of the people who are managing, hiring, and promoting others. People who have a direct and immediate influence on how those processes are done.?

Why is this happening? Why are the people with the maximum influence and impact so happy to accept the adoption of a new by someone else??

I will leave it to the industrial sociologists and psychologists to discuss the theory behind the process. But as a friend suggested, one possible reason for taking the long road from concept to practice incurring collateral damage caused by creating fundamentally unnecessary roles and functions along the way, is rooted in human nature itself. Humans, especially in individualistic societies, continuously seek to differentiate themselves to increase their perceived value. Value they provide and are thereby rewarded for it. This inherent pull toward self-promotion and differentiation places personal goals above those of the larger group. The same trait inhibits the adoption of agile, team-centered, ways of working and focuses on personal performance over team-level performance. There are team goals, but not a team performance review. Establishing a function based on a person’s specialty or expertise is a good way to achieve such personal differentiation and create a market for rewards, both intellectual and financial, for those who lead the domain. That encourages participants, who become expert employees or consultants to perpetuate this cycle by carefully, or in some cases also aggressively, protecting their know-how in the interest of job security. This centralization of skills, in turn, creates a convenient environment for those who should have been picking up the new concept and turning it into practice - ?to not do it. The reason is simple, cognitive load is high initially, despite of the benefits waiting on the other side of the learning curve.?

Another potential reason for the centralization of practices instead of adoption may lie in a trait people have of fixating on the “how”. The “how” is elevated to such a grandiose level of importance that it becomes an objective of its own. And when there is an objective, there are experts; when there are experts there are hierarchies; when there are hierarchies there are bureaucracy, competency matrices, KPIs, and titles - so many titles.?

Few would dispute the value in the adoption of a DevOps paradigm or the value of having a diverse and inclusive society in which all members are treated fairly and equally. However, very few can as easily explain rationally why those problems have yet to be solved or the mindset adopted in practice. The arguments of immature tooling, the complexity and multidimensionality of the issues, and the systemic nature of problems, look more like convenient excuses to me than compelling reasons not to start doing something.?

On the other hand, an argument supporting such a lengthy transition from idea to value, or practice in the context of this article, is that ideas can be vague. Concepts are theoretical. It takes time to polish the concept and bring it to a tangible form; one in which the idea can be applied to the real world, full of other ambiguities and unpredictabilities. It takes experts to make all the mistakes and find the optimal workarounds, to distill procedures and frameworks that can be easily understood by others, before being used by all. Yet, even if this is true, we, human beings, are usually quite bad at letting our perceived value go. One modern testing principle crafted by Alan Page states: “We [testing specialists] expand abilities and know-how across the team; understanding that this may reduce (or eliminate) the need for dedicated specialists.”. Sadly, throughout my career, I have only met a couple of testing professionals who believed in it, and, most importantly, acted this way.?

What keeps me hopeful and sanguine in this journey is that, eventually, some of the better practices are indeed being adopted. It happens slower than I would like to see, but it does happen. The ownership of quality and the migration from large QA organizations to a shared responsibility model for quality as well as holding product teams, and every developer accountable for the quality of the solution they produce, is now more mainstream than before. It has only taken us several decades. It has only taken us the better part of two decades for DevOps to become a mindset and practice of stream-aligned product teams. With progress accelerating exponentially, I am convinced that concepts like DEI and every follow-up concept that aims to improve how we do things will become mindset and practice - without becoming a role - and hopefully much faster too.