The different flavors of IT – Part 2

In the last post, I described how different external drivers (pre-industrial, industrial, post-industrial) lead to different IT working modes and discussed their typical properties.

In this post, I will first add another complementing point of view that leads to a fourth working mode. Afterwards, I will briefly discuss how this model can also help to understand the lifecycle of IT-based business offerings better. Finally, I will show how this model can be generalized to different domains and the problems that arise if different working modes collide.

The CAP theorem for managers

The CAP theorem is quite famous in the domain of distributed systems. The core idea of the theorem is that you cannot optimize for all three properties the theorem discusses at the same time. Whenever you decide to optimize for two of the three properties, you need to compromise the third property to a certain degree. ¹

A similar type of tension between three other properties also exists in the context of this post.

There are three properties that (not only) managers often try to improve:

• Fast - reduce cycle times, i.e., deliver new ideas faster
• Cheap - increase cost-efficiency, i.e., create a given output at lower costs ²
• Good - increase quality, i.e., deliver a given output at higher quality ³

I call it the “CAP theorem for managers” because if you focus on optimizing for any two properties, you always need to compromise the third property to a certain degree. E.g., if you try to go as fast as possible at the lowest possible cost, you will compromise quality. ⁴

Often, I use this triangle in client situations as sort of a quick litmus test to understand the general predisposition of the client’s IT organization. I draw the triangle, briefly explain it and then ask the client to pick the two properties that are most important to them.

Usually, it takes a moment for them to decide because they want all three properties and need to sort out which of them are most important for them. It is not only interesting to see which properties the client picks. Also the discussions accompanying the decision process are very instructive. For me they are useful to understand better which potential measures are promising, which are not, how to argue them, etc.

Different working modes on the edges

The triangle is very useful because each edge describes a different IT working mode including its governance model. Thus, understanding the most important two driving properties of an IT organization gives you a quite good idea regarding their control and decision making process. ⁵

• Cheap and Good span the edge for an industrial working mode – cost-efficiency, scale and repeatability and without compromising quality as main drivers
• Fast and Good span the edge for a post-industrial working mode – reducing cycle times without compromising quality is key
• Fast and Cheap span the edge for a new working mode, the startup mode – discovering product-market fit by testing ideas as fast as possible before the funding is used up

The pre-industrial working mode cannot be detected with this triangle as it does not have a clear driver. Thus, I put it in the middle of the triangle. You usually detect this mode by observing other typical properties, e.g., the amount of ad hoc work or the lack of a clear driver. ⁶

Startup working mode

As the startup IT working mode was not described in the previous post, it makes sense to add a little description here. At first glance, the startup IT working mode can look a lot like the pre-industrial working mode: often you see a lot of ad hoc work with peer-to-peer organization and no clear practices.

Yet, there is a big difference: In a startup IT you have a very clear strategic goal. You want to discover a product-market fit as fast as possible because otherwise you will run out of money. I tend to call it sort of a “continuous near-death experience”. You test your hypotheses regarding customer demands and behavior as fast as possible. If a hypothesis works, you try to drive the underlying assumption further. Otherwise you pivot and test a different hypothesis.

In such a setting, quality obviously does not have the highest priority. You will throw away 90% of your code anyway because as a rule of thumb 9 out 10 hypotheses fail. Instead, delivery speed and cost-efficiency are king. The more hypotheses you can validate with the funding you have, the higher the likelihood that you will find a product-market fit.

As automation supports going fast and also can help saving money, opposed to pre-industrial IT organizations you often find a relatively high degree of automation in startups. They also try to reduce their vertical integration depth as much as possible as this helps them to become even faster ⁷. If you look at these properties, startups may feel more like a post-industrial organization.

Now that we know the four generic IT working modes, their drivers and properties: what else can we learn from it? Probably there are a lot of things to be learned from this model. But in this post I will focus on two ideas:

• The evolution of IT-based offerings along the working models
• Generalization of the model and the problems if different modes collide

Evolution cycle of IT-based business offerings

Any new business offering that is based on or augmented by IT, needs three different IT working modes over time for successful evolution:

• First, the startup mode is needed – moving as fast as possible to find a product-market fit (or killing the idea if the fit is not found)
• Then, for growing the offering the post-industrial mode is needed – still moving fast, but without compromising quality (you do not want to annoy your paying customers) to maximize market share in a (usually) dynamic market environment
• Finally, after the dynamism regarding the offering fades (and the market shares are distributed), the industrial mode makes most sense – maintaining and evolving the offering in a cost-efficient way (without compromising quality) to maximize revenue

You find this product/offering evolution cycle also in other places, like, e.g., the BCG or Growth-Share matrix or the 3X model by Kent Beck:

• Question mark (BCG) → Explore (3X) → Startup mode
• Rising star (BCG) → Expand (3X) → Post-industrial mode
• Cash cow (BCG) → Extract (3X) → Industrial mode ⁸

If you correlate the three models, you can connect the different modes from strategic portfolio planning (BCG) over product development view down to IT working mode. You could even drill down to an architectural level (what I will probably do in a future post). This can help to make the right decisions at the different levels.

Why enterprise startup “garages” usually do not work

E.g., this explains why the startup incubators – typically called “garages”, “labs or alike – that many enterprises started in the recent years to overcome their innovation inertia do not create the desired outcomes most of the times. Dazzled by ideas like Gartner’s Bimodal IT, those companies think they can get along with two working modes.

Those incubator projects work in a startup mode. If they find a product-market fit, they throw it over the fence to corporate IT which works in the second mode. Unfortunately, the mode they are working in is an industrial mode. The whole Expand phase with the associated post-industrial working mode is missing.

As a result the new product offering will die on its way over the fence. Corporate IT will simply reject it because it does not comply to their rules: documentation, tech stack, adhering to architectural and compliance rules, etc. Actually, this should be obvious because the corporate IT is organized for cost-efficient maintenance and standardization and conformance is needed to implement such a mode.

Thus, if you live highly dynamic market environment and need to continuously develop and evolve new business offerings, you need to implement all three working modes. Two modes are not enough.

Shifting an offering to a different mode

A last important note regarding the evolution cycle: On technical level, shifting an offering from one mode to another typically involves quite a bit of extra work, up to a complete rewrite of the code base.

In the startup mode you focus on speed and cost. Okay-ish code quality usually is good enough. Scalability, availability, security, etc. are no issues. Maybe the solution is good enough to survive the first growth wave, but after that you usually need to implement the solution anew based on an architecture that implements the required quality (for the paying customers) and is fit for growth.

When entering the cash cow quadrant, cost-efficiency becomes key. This typically means that the solution needs to adhere to quite a big set of rules and regulations to make sure that a relatively small team is able to maintain and evolve the solution in a cost-efficient way. This typically means quite a bit of extra effort again.

You need to be aware of this fact and act accordingly! Trying to sidestep this extra work usually means entering a world of pain. If you stick with the initial startup implementation, the quality will suffer, changes will take longer and longer and paying customers will be annoyed. If you start with an application ready for growth or maintenance mode, you will be way too slow in the startup phase and most likely not discover product-market fit.

Thus, in the end accepting the extra efforts when shifting to the next mode is the most promising option.

Generalizing the model

Finally, I would like to discuss the generalization of the model. If you ponder the idea of pre-industrial, industrial, post-industrial and startup for a moment, you realize that this model cannot only be applied to markets or IT.

This model can be applied to many levels and organizational unit, e.g.:

• Market
• Company
• Division
• IT department
• Team/project

Depending on your company, you might find some additional levels or organizational units. Applying the concepts of pre-industrial, industrial, post-industrial and startup to different levels and units, you will see in quite some organizations that they act in different working modes, which leads to problems.

For example, I have seen several times that teams tried to act in a post-industrial mode while the overarching IT organization acted in an industrial mode. As long as the team worked in stealth mode and fulfilled the industrial mode expectations at their boundaries everything was okay. But as soon as the internal working mode became visible the IT organization began to fight the team.

At the moment you also see companies quite often that thoroughly work in an industrial mode without having realized that their market shifted from industrial to post-industrial over time. They feel the pain, but they have no real idea how to respond to it. They try to become “agile” (in its core a post-industrial tool) but implement it in an industrial way. They try to cram more of their industrial best practices in a unit of time (using new terminology for the old concepts), making things worse – up to a level where the whole company is endangered.

You see post-industrial business departments faced with industrial IT departments. You see startup labs confronted with industrial corporate IT departments. And so on. Whenever the working modes do not match, problems and conflicts are certain.

Therefore, i recommend to look at the different levels and organization units that interact and try to understand what their predominant working mode is. If they work in different modes, you know that there will be problems you need to address. While this does not yet solve the problems, you expect them and are not taken by surprise – which gives you a lot better chance to resolve them. ⁹

Summing up

These were two quite long posts ¹⁰. We started with considering how the different types of markets affect the IT working mode and worked out the properties of the different working modes in the first post. In this post, we added another point of view, the fast-cheap-good triangle which lead us to another working mode, the startup mode.

We then saw that the evolution cycle of any IT-based or IT-augmented business offering requires all three modes of the triangle (startup, post-industrial and industrial) to be successful. Additionally, we mapped the IT working modes to the BCG matrix and the 3X model which creates a consistent model from strategic portfolio planning down to the IT execution level.

Finally, we generalized the IT working modes to different levels and organizational units. We saw that missing alignment, i.e., different working modes colliding between interacting levels or units, leads to problems that in the worst case can become existential.

I hope that these concepts give you some ideas to work with. They might help you to detect patterns in your organization – especially if working modes clash or if you run in the wrong mode with respect to the task you try to solve. Maybe they even give you some idea how to change if needed.

Still, always have in mind that all this is a model. Your reality will be more nuanced and you probably will rarely find these working modes in their pure form. But the model will help you will to detect predominant modes as well as inconsistencies – which makes it easier to act on it.

For today, I will leave it here and hope that you have some ideas to ponder.