The different flavors of IT – Part 1

In a previous post, I discussed pre-industrial, industrial and post-industrial markets. It also helps to understand a lot of other developments and problems (not only) in the world of IT. In this post, I will discuss how it affects the IT working mode.

Different market situations typically result in different IT working modes, i.e., properties that an IT organization implements. As long as the IT working mode is in sync with the external drivers, everything is fine. If not, it leads to problems. But before discussing those problems, let us first look at the working modes.

As this topic is relatively big, I split it in two posts. In this post, I will discuss the properties of IT organizations resulting from the different external drivers. In the second post, I will extend the model with another perspective and discuss the problems that arise if things get out of sync.

External drivers

To start with, let us repeat the defining properties of the encompassing market and the drivers on IT that result from them.

Pre-industrial markets are typically emerging markets. The rules are not yet settled, competition often is sparse and demand is still forming. Suppliers in that market often started with sort of a novel offering that brought them to that market and then stepwise try to explore the possibilities and boundaries of the market.

The rules of the market are not yet clear. Thus there typically is not a clear strategic goal. Understanding and fulfilling customer demands on a per-customer base often is important for survival and success, but beyond that “whatever pays the bill” usually is the predominant strategy.

In an industrial market the rules are clearly defined: demand is a lot higher than supply and thus sales are certain as long as the price is reasonable and you do not totally miss customer demand.

Demand being a lot higher than supply also means the market is supplier-driven. As a result, the supplier dictates the pace of innovation, i.e., the market is wide and slow from a supplier’s perspective.

The strategic goal is cost-efficient scaling of production: sales are certain and the more and cheaper I can produce and deliver, the higher are my profits.

In a post-industrial market the relation between demand and supply is reversed, i.e., supply is a lot higher than demand. There are many competitors per consumer, hence consumers buy where their needs and demands are satisfied best. The market is consumer-driven and the companies that adapt to the ever-evolving customer needs best and quickest, drive the market.

From a supplier’s perspective the market thus is narrow and fast. The strategic goal is to continuously adapt to the needs and demands of the customers in order to stay competitive and successful. If I do not adapt quickly, I will be outperformed soon by competitors that adapt quicker than I do. ¹

A supporting IT department needs to support the strategic goals of its company.

• In a pre-industrial market IT needs to support individually taking care of customers and exploring the market.
• In an industrial market IT needs to deliver software in a cost-efficient way (without compromising quality), while delivery speed is of lesser importance.
• In a post-industrial market IT needs to continuously test new ideas to understand and adapt to the customers’ evolving needs and demands. Delivery speed is key (without compromising quality) while cost efficiency takes a back seat (without becoming irrelevant).

Systemic classification

Another interesting aspect are the types of challenges, an IT department typically faces from a systemic point of view. ²

In a pre-industrial market, things are often targeted towards an individual or help exploring the market space. Many of the tasks are relatively straightforward, i.e., obvious from a systemic point of view. Of course, some tasks also require more analysis to understand what to to, i.e., they are complicated.

In an industrial setting, everything is about optimizing cost-efficiency. The simple parts are already done and the higher the level of existing efficiency, the more complicated it usually becomes to increase cost-efficient further. Still, as the market is supplier-driven (slow and wide), the outcome (value) of tasks tends to be predictable. Thus, tasks usually are just complicated, i.e., upfront planning and careful execution of the plan is usually sufficient.

In a post-industrial market, consumers drive the market and evolve their demands continuously. As a result, a company cannot predict the value of market-facing tasks anymore but must stepwise approach the goal via smalls steps: Make a small change, learn how the customer responds, learn, decide about the next change. In other words: Most tasks exhibit complex properties.

Work and organization model

Having discussed the the external drivers and general systemic characteristics, we can approach the internal properties of IT departments. The first ones are the general work and organization model, usually supported (or enforced) by a related governance model.

In a pre-industrial setting, things are usually weakly defined and IT often needs to respond to individual demands of customers. Therefore, the typical work mode of a pre-industrial IT is ad hoc: someone asks for something, IT responds.

This mode can often be observed in small IT departments. In some places IT employees switch tasks as soon as someone from the business side asks for something different which often leads to all sorts of problems. I will probably discuss those problems in a later post. ³

The industrial work mode is dominated by detailed processes and hierarchies. If you want to optimize efficiency (and you do not need to change fast), these are your tools. We know that for more than 100 years meanwhile – nothing to add. ⁴

The post-industrial work mode is based on collaboration and autonomy. Collaborating teams provide the required complexity in the solution system to tackle the complexity in the problem space. One of the most fundamental laws of complexity theory states that you can solve a complex task only with a system (here: organization) that is at least as complex as the task – thus, cross-functional, collaborating teams.

Additionally, to be able to adapt quickly to the ever-evolving demands of the market, you need to have teams that are aligned with your business offerings and can all move at their own pace – hence autonomy. Still, to be successful as a company, all these teams need to be highly aligned with respect to the purpose, vision and goals of the company.

Practices

The practices usually match the work and organization model. In the end, they are another facet of the IT governance model.

In a pre-industrial setting, you usually do not find clearly defined practices – “whatever goes” is a recurring theme.

Industrial practices are driven by huge process frameworks and fine-grained regulations, supporting upfront planning and carefully supervised execution of the plan. Typical examples are ITIL, the V-model or SAFe. ⁵

On the post-industrial side you find practices that rather embrace uncertainty and complexity. Typical examples are DevOps (accelerating the IT value chain to be able to test new ideas faster), Kanban (optimizing flow), XP and other agile practices. ⁶

Individuals

Another interesting aspect are the preferred skill profiles of the people involved.

In a pre-industrial setting, the domain often is (still) quite clear and technical solutions are relatively simple (“whatever does the trick”). Therefore, people are still able to understand the business and technical domain in its whole width and depth. Hence, the preferred skill profile in such a setting is the cube-shaped expert, mastering the whole business and IT domain.

Industrial settings are usually too broad and deep to be an expert in everything. Additionally, broad expertise is not valued as cost-efficiency and scalability is key. Experts are not really needed.

Theoretically, you need a few experts to set up the value delivery process, but most often you simply roll out a predefined process. For execution you only need specialists that are good in their small area of work. Division of labor rules, and thus I-shaped specialists with very limited, but deep knowledge are highly wanted (assuming that their deep knowledge will lead to even more efficiency).

In a post-industrial setting, cross-functional collaboration is needed to address the inherent complexity of the domain. In order to collaborate effectively, you need to understand at least a bit about the domains of the people you collaborate with while still having your area(s) of expertise. Without this connection to the other domains, vital collaboration (that creates the required complexity in the solution system) is not possible. Therefore, the ideal of post-industrial settings are T-shaped generalists. ⁷

Automation

The degree of automation and how the remaining manual work is treated is also a noteworthy property.

The pre-industrial “whatever goes” approach typically results in a low degree of automation. The high amount of manual work is performed in an ad hoc fashion. Still, as pre-industrial markets typically involve responding to a lot of individual demands, the low degree of automation and the ad hoc execution of manual work are not surprising.

An industrial IT organization tries to maximize cost-efficiency. As a consequence, they try to automate everything that helps to reduce costs. Thus, the degree of automation is relatively high.

Still, as cycle times (or lead times, if you “speak” Kanban) are of lesser importance, you find quite a bit of routine work that is executed from time to time only. Often the work does not get automated, because it would take too long until the costs of automation would pay back. E.g., in such a setting, you quite often see IT departments doing manual production deployments a few times a year.

As manual tasks tend to be error-prone and errors compromise cost-efficiency, all manual work is strictly defined and controlled. You find lots of regulations, checklists, reports and other stuff trying to minimize the likelihood of errors. ⁸

In a post-industrial context, short cycle times, i.e., short time spans from an idea until the customer can provide feedback, are crucial. To respond to this requirement, IT automates whatever can be automated – not with the primary goal to avoid errors as in an industrial setting, but with the goal to speed things up. ⁹

Consequently, manual work is avoided as much as possible in a post-industrial setting as it tends to slow things down.

Programming model

A final interesting property that I would like to discuss here is the programming model typically used.

In IT departments that live in a pre-industrial setting, you can often observe some kind of “Do it yourself” attitude. The programming model is as ad hoc as the work model and the business demands. ¹⁰

Industrial companies go for cost-efficiency and since the IT department typically is considered a “cost center” in such a setting, standardization for the sake of cost reduction is a big driver in IT. As a result, often large chunks of their IT landscape are paved with standard software and the parts they implement at their own are usually dominated by traditional enterprise frameworks (e.g., JEE/Spring, .net, etc.). ¹¹

Post-industrial IT departments try to speed things up. A powerful lever is to reduce the vertical integration depth. Therefore, you see them strictly going for cloud native approaches at the moment, consequently utilizing managed services and using FaaS as integration glue. This way, these IT departments focus on building the actually differentiating parts of their solutions at high velocity (without compromising quality).

There is a lot more to say about the programming model, but I will leave it here for the moment. Maybe I will dive deeper into the topic in a later post.

Summing it up

If we merge all the aspects discussed before, we end up with the following table.

Of course, this collection and the discussion just scratch the surface and there could be a lot more said about each of the properties. Additionally, there are probably several more properties worth exploring.

Nevertheless, this should already be useful to understand why and how different types of IT organizations result from different drivers. Most likely, the different IT working modes seem familiar to you and probably remind you of IT organizations you know.

It becomes problematic if the external drivers and the internal IT working mode drift apart – a situation I see quite often these days. But before discussing this, I would like to introduce a complementing point of view leading to a fourth working mode that is still missing.

Yet, as this post is too long already, I will leave it here for this post. The discussion will be continued in the second part.