The quest for operational performance
The production pipeline
Manufacturing is the second of the three macroeconomic sectors, sitting between extraction and services. It is as old as humankind, but has experienced a dramatic growth starting in the late 18th century, fueled by the industrial revolution. This transformation brought to the stage the idea of a factory, which implied two major concepts for improving productivity: mechanization (replacing manual labor for increased strengths, accuracy, speed, etc) and division of labor (which allowed for specialized high performance activities). In the early 20th century, Henry Ford made the next evolutionary step and introduced the assembly pipeline, where the manufacturing activities were cascaded (logically and physically) to reproduce the stages of creating a product from start to finish. Later in the century, the Lean manufacturing concept was created, along with the just-in-time manufacturing, both getting world wide recognition through their implementation in the Toyota Production System. These concepts aimed to reduce waste (in the form of dead times, inventories, etc) and brought in the tool of self-observation in the form of feedback loops.?
In the early days, software was developed to bring to life computers and electronics; only later, with the spread of personal computers, software became monetizable by itself. It thus joined the group of intangible goods that were created in the last century. This association opened up the perspective to look at software as a product and many concepts associated with manufacturing were adopted in the process of creating software. The concept of a development pipeline emerged, which can be best observed in the V-model: a series of stages that succeed in a well defined sequence, each of them contributing to a necessary step in the software creation: concept, requirements, design, implementation, testing, V&V and operation. Much like in a factory assembly line, specialized functions (people, teams or even entire organizations) were mapped onto these stages and they were meant to excel at their specific task.
Not long after this approach spread and became an industry practice, it started to show its limitations. First of all, the creation of a software product (what we may call v1.0) took a long time (much longer compared to the production of a physical good), which allowed the premises it has been based on to change before the “production” was finished. Secondly, by modeling organizations on the stages of development, it led to creation of silos which interacted poorly and oftentimes blamed each other for delays and failures. Thirdly, by optimizing the production process, the business value initially associated with the end product gets diluted and sometimes lost altogether. And the list may go on.
In hindsight, the fallacy of software manufacturing is based on the omission of key differences between the creation of tangible and intangible goods and probably an oversimplification in understanding the manufacturing process. Here are a few of those differences:
At the beginning of this century, a few software craftsmen realized that the software factory paradigm is not optimal; they got together and proposed a new approach where the process was modeled on the act of creation and the approach was highly iterative, covering the entire lifetime of the software product (from ideation to retirement). It was named Agile software development and it addressed many of the shortcomings of the previous model. Since its conception in 2001, it has become wildly popular and has been embraced by many new and established technology companies. The catch is that many adopters have not fully shed the previous mindset, thus hybrid monsters were born and disputes over the effectiveness of the new model became the norm.
The manufacturing mindset is deeply rooted in software development and it may take many more years until fully left behind. We refer to a software application or platform as to a product. There is even a whole vertical in the organization that is named after that. Software implementation team is referred to as Engineering and is tasked to implement the concept made by Product. We use the term pipeline when we refer to deployment (which by the way is a proper place to use it) and have factory methods to create new objects (again, not a bad analogy). The problem is that we are so accustomed to looking at software creation through this lens, that it is very hard to look past it. Even when adopting an Agile framework (such as Scrum or XP), we tend to fill in the gaps left out intentionally by the model with old thinking patterns. Out of all the reminiscent patterns of manufacturing, I’d like to touch on two of them, which I believe are quite harmful for the performance of a technology organization.
1. The CPO - CTO chasm
Every tribe has its chief. Well, companies have more than one. Even flat organizations have them. It is probably in our veins to yearn for recognition and imagine success as being the one in charge. The least disputable role is probably that of the CEO - the owner of the business strategy and the sole representative of the company towards the outside world. Then there are the C level roles that map onto specific business functions, such as Sales, Marketing, Finance and Operations; together with the CEO, these chiefs define how the business should run.
Here is where I become controversial: if the business case IS a software product, then it makes sense for a chief to represent the manufacturing of that product (only one); if the business only needs software as means to operate/automate some of its processes, then probably having no chief is much better. In the latter case, choosing to make or buy a software product is a decision of operations and they should have the final call. I don’t want to sink further into the quicksands of “which is the right set of chiefs” but cannot help to become even less popular by saying that arguably the nonsensical one is the chief for HR (if the focus is on managing resources, make it a function of operation; if the aim is the welfare of employees, get an employee representative; if the goal is to oversee culture, do it from a consulting, not an executive position; and so on).
Coming back to the leadership for the technology organization, the one that builds software. Many companies employ the model with two distinct leaders, one to manage the design and the other to manage the implementation. This approach has two major structural shortcomings:
领英推荐
A. Silos
Shaping organizations by function tends to induce the formation of silos. One of our basic needs as humans is “belonging” and therefore we tend to attach to the group/team we are assigned to in the same way our ancestors attached to their tribe. This need is arguably beneficial inside the team, as it stimulates cooperation, fairness and other similar values, but it also tends to build walls towards the outside. One simply cannot engage in a more powerful relationship with an outsider than with one of his kind.
This is probably less of an issue for organizations that are able to produce value on their own, but for those whose functions are chained (Product designs and Technology implements - none of these have any value by themselves) it is a source of waste. The production pipeline model was not able to point out this issue, but the Agile methodologies, with their “all hands on deck” and frequent iterations, point towards a very tight relationship between roles such as business (dev and operation), design and implementation. If one builds a tribe, it should be around the cross-functional Agile team, and no other way.
Additionally, silos tend to develop a mind of their own [no better example than the HR willing to optimize recruiting (they are tasked to do) by creating a global recruiting function (although recruiting nowadays is about selling a value proposition in a local language with a local flavor)]. Therefore, they will work for their own goals before they join “external” initiatives. The sense of tribe is also accentuated by the construction of hierarchies inside these functional organizations; the need for safety (job safety in this case) is fulfilled by pleasing the boss before doing the work. If there is any disconnect between what the boss asks for and the value production flow, the former will take precedence and waste starts creeping into the system.
B. Dual leadership
Having two leaders will inevitably mean that there will be two views on the business case. Even if they work closely together with the rest of the leadership team to define the value creation flows, there will be inevitable differences in the leadership style and the implementation of the flows. Differences in culture, working methodologies, priorities and level of discipline will create friction between people and will make it almost impossible for them to work as one team (in the Agile view). The Mars Climate Orbiter stands as proof of how the use of different measuring standards (metric and imperial) by two different functions (flight control and design) leads to catastrophic failure.
One particular failure of this dual leadership solution is the gap it creates in the value production flow by a simple choice in the profile of the two leaders. In order to construct a solid software product, the needs (identified in the definition of the business case) are translated into requirements for the solution. These requirements shall cover functional aspects (WHAT) as well as non-functional (HOW) and shall be drafted in such a way that reflect a full and coherent conceptual model - the solution architecture. Particularly the functional requirements shall describe the entities that the system will handle, their properties, functional relationships and describe the flows that eventually help business produce value.
In many cases, CPOs are anything but engineers and CTOs are too much of that, which then reflects on the organizations they build. Product tends to spend more time interacting with Business and end users, to understand their needs; they do that by communicating in natural language, which comes, of course, very natural. On the other hand, Technology spends most of their time dealing with abstract concepts specific to software engineering. During the interactions between the two functions, they try their best to match a new feature with a design pattern, but often they talk past each other (you are now probably checking the factual correctness of this statement). Indeed, in many cases a connection is made and an implementation comes to being, but whatever is lost in translation, will come back to haunt them as “legacy”. Domain Driven Design is a wonderful method, created by Technology, to force a conceptual design that can be better used by the implementation teams; unfortunately, this methodology is not very popular with Product people. Getting Product and Technology to speak the same language at the same abstraction level is a massive challenge and surely cannot be accomplished by this bicephalous leadership solution.
2. The uni-dimensional fallacy (execution vs strategy)
Much like factory assembly lines, software organizations are optimized for execution. Processes are tuned to maximize productivity in the form of throughput and output, various metrics are put in place to observe deviations and time spent on work related tasks is regulated and measured. Working from home led to exaggerated implementations of this last aspect, leading to deployment of mouse tracking applications to prevent slacking (in a true spirit of survival, employees found ways to circumvent this measure, so hats off to those who did that). Focus is often on efficiency rather than on effectiveness; measures to throw in more bodies in dying projects stand proof. The word on the lips of every manager in charge is “status”. The factory mindset is ubiquitous.
What do the following concepts have in common?
They are evidence of the fact that all levels of hierarchies are focused on execution. Of course, they do net execute at the same level of abstraction, but their primary responsibility is to execute. If things go awry, every man from private to admiral must show up on deck.
“What’s wrong with that?”, you may ask, Observed in isolation, there are not too many wrong things about it. I would argue that there’s no need for several ranks to oversee production, but aside from that, execution makes up for 99% of success. The major problem is that focusing on operating the pipeline steals the time and attention from strategic thinking. You may look at strategy as a second dimension of operation, one in which leaders analyze why they are doing what they’re doing and adjust the direction of the pipeline vector or replace it altogether. Strategy and execution are orthogonal; being in one dimension means not being in the other one. One may truly observe the reality of day to day operation only by stepping back (better said is stepping aside, in a new dimension). To better explain what I’m saying: we humans are able to appreciate 2D pictures and drawings because we observe them from a 3rd dimension; being in the same plane with the picture would only reveal to us the neighboring points, no more. We’re able to make sense of it only from looking from outside.
Well, you may say, Scrum has introduced retrospectives, which are opportunities to reflect on what happened and improve. Or that leadership teams have regular offsite meetings to sit back and reflect. Indeed, these are healthy practices and may help with the tactics, but real changes, the ones which address conceptual errors, that point out misbeliefs and fallacies, only emerge when there is plenty of time to think. Valuable observations about askew views take time to distill; we are prevented from doing it faster by the very traits that make us humans: egos, survival instincts, sense of ridiculousness and so on. Some once said that “successful leaders are the ones who can afford the luxury to get bored”. I can hardly express how crucial it is to take time to observe, let the observations sink in, analyze inefficiencies and only then act on those. As mentioned in another post, it is easier to point the finger to the person doing the role than to assess the role itself.
It is hard to suggest a way to improve things here. The whole business mindset is centered around doing, with little to none time for thinking. The solution is probably at the top (remember the chiefs I was mentioning earlier?): either they take a generous amount of their time to fundamentally study the operation their organization is carrying out or employ the Business Cavalry, a solution that my friend Andrei is proposing. Either way, someone needs to spend time on strategy.