The different flavors of IT - Part 1

Understanding the basic IT working modes

Uwe Friedrichsen

14 minute read

A nicely arranged flower bed (seen in Passau, Germany)

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.

Properties Pre-industrial Industrial Post-industrial
Market characteristic Emerging Wide & slow Narrow & fast
Strategic goals None (“Get the bill paid”) Cost-efficiency Fast adaptation

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. 1

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. 2

Properties Pre-industrial Industrial Post-industrial
System theory Obvious/Complicated Complicated Complex

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.

Properties Pre-industrial Industrial Post-industrial
Work model Ad hoc Process-driven Collaboration
Organization model Peer to peer Hierarchy Autonomous teams

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. 3

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. 4

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.


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

Properties Pre-industrial Industrial Post-industrial
Practices “Whatever goes” ITIL, V-Model, SAFe DevOps, Kanban, XP, Agile

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. 5

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. 6


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

Properties Pre-industrial Industrial Post-industrial
Individuals Experts (Cube-shaped) Specialists (I-shaped) Generalists (T-shaped)

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. 7


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

Properties Pre-industrial Industrial Post-industrial
Automation Low Medium - high Very high
Manual work Ad hoc Defined and controlled Avoided

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. 8

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. 9

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.

Properties Pre-industrial Industrial Post-industrial
Programming model Do it yourself Standard Software, Enterprise Frameworks Cloud-native, Managed services, FaaS

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. 10

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.). 11

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.

Properties Pre-industrial Industrial Post-industrial
Market characteristic Emerging Wide & slow Narrow & fast
Strategic goals None (“Get the bill paid”) Cost-efficiency Fast adaptation
System theory Obvious/Complicated Complicated Complex
Work model Ad hoc Process-driven Collaboration
Organization model Peer to peer Hierarchy Autonomous teams
Practices “Whatever goes” ITIL, V-Model, SAFe DevOps, Kanban, XP, Agile
Individuals Experts (Cube-shaped) Specialists (I-shaped) Generalists (T-shaped)
Automation Low Medium - high Very high
Manual work Ad hoc Defined and controlled Avoided
Programming model Do it yourself Standard Software, Enterprise Frameworks Cloud-native, Managed services, FaaS

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.

  1. This is sometimes described as a “Red Queen’s race”. The term references an incident in Lewis Carroll’s novel “Through the looking glass” where you need to run as fast as you can to not fall behind. ↩︎

  2. I will probably write a post later that explains characteristics of systems, especially of complicated and complex systems and then add the link here. Until then, the Wikipedia page for Cynefin or the Cynefin introduction by Dave Snowden, one of the inventors of Cynefin, are good starting points to understand the different types of systems. ↩︎

  3. I sometimes met IT departments of this type that asked for “more agility” because they were not able to handle the requests from their business departments in a timely manner anymore. Yet, their problem was not lacking agility. Their problem rather was being “too agile”. This can be explained easily with queuing theory: more requests than the IT organization can handle, utilization close to 100% plus continuous task switches, leading to extremely high lead times. Thus, my recommendation was to become “less agile” (based on their perception of agility) for a while to solve their problems. But more about that in a later post. ↩︎

  4. To be clear: There is nothing wrong with processes and hierarchies as long as you live in a setting with industrial characteristics. If you live in a different setting, processes and hierarchies usually are counter-productive. ↩︎

  5. If you ask yourself why I put SAFe here and not on the post-industrial side: While SAFe may have a value for some companies it is not agile. SAFe in its core is a traditional incremental-iterative process framework like RUP, just disguised behind agile terminology. It builds on the assumption that the value of what you are doing is certain – which exactly is not true for a post-industrial market. ↩︎

  6. I deliberately do not mention Scrum as most Scrum implementations I know do not tackle uncertainty ad complexity well. While Scrum itself is well capable of tackling uncertainty, unfortunately most of its implementations are not. ↩︎

  7. Note the “T-shaped”, i.e., “generalist” does not mean “jack of all trades but master of nothing”. Generalists should have at least one domain of deep expertise. But additionally they need to understand how all the different domains involved work and interact to create impact with their work. This is how I define a generalist. ↩︎

  8. Judging if this approach advisable, or if a higher degree of automation would be a more sensible approach is outside the scope of this article (and TBH, I do not think that there is an easy answer to this question). ↩︎

  9. It is interesting to observe this difference by looking at different types of CI/CD pipelines. While industrially thinking companies often insert manual “quality gateways” and “release gateways” and just automate parts of the testing (focus on avoiding errors, not speed), post-industrially driven companies make sure that they create pipelines that automatically deploy directly into production, including all the required testing for safe deployments (focus on speed without compromising quality). ↩︎

  10. Unfortunately, even if those companies move into a more mature, industrialized market the programming model often remains the same. ↩︎

  11. The discussion, if standardization, as it often is implemented by big enterprises, actually save costs or rather does the opposite is a complicated one and beyond the scope of this post. ↩︎