The different flavors of IT - Part 2

Understanding the basic IT working modes

Uwe Friedrichsen

14 minute read

A nicely arranged flower bed (seen in Saint-Vaast-la-Hougue, France)

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

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

If you optimize for 2 of the 3 properties “Fast” (short cycle times), “Cheap” (cost-efficient production) and “Good” (required quality), you always need to compromise the 3rd property to a certain degree

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 2
  • Good - increase quality, i.e., deliver a given output at higher quality 3

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

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

The IT working modes “post-industrial”, “industrial” and “startup” aligned along the edges and “pre-industrial” without clear driver inside the triangle (see text for more details)

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

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

Any new IT-based offering will usually need to start in startup mode, then move to the post-industrial mode for growth and finally to the industrial mode after maturity is reached

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

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.

The working modes pre-industrial, industrial, post-industrial and startup generalized beyond 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.

Aligned working modes across levels or units bear little conflict potential while different working modes typically lead to high conflict potential

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

Summing up

These were two quite long posts 10. 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.

  1. The concrete properties that incidentally lead to the name “CAP” are not relevant here. For this post, it is only relevant that you cannot optimize for all three of them at the same time. ↩︎

  2. Note that in this context “cheap” simply means low-priced. It does not mean inferior quality. ↩︎

  3. “Quality” especially in software development often is a topic of heated, yet misdirected discussions. Personally, I stick to the definition that Russell Ackoff made↩︎

  4. There are people who say you do not need to compromise any of the properties because the Internet unicorns have shown that going fast and good also leads to reduced costs. While there is some truth to this, IMO it misses the point of this model: This model is not about indirect long-term consequences of a chosen direction, it is about the direct consequences of a specific mindset that drives your decisions. Going for speed and quality may reduce costs if you do the right things for a longer period of time. Also, most of the cost savings result from navigating the business domain better under uncertainty, i.e., detecting and cutting off idle and value-reducing business ideas before sinking a lot of money in them. The cost savings do not result from immediately reducing the costs of developing a unit of software. Therefore, if you start with cost-efficiency (“Cheap”) as one of your core mindset drivers, you will make very different decisions than the Internet unicorns because you will always try to immediately cut development costs and thus end up with a very different result. ↩︎

  5. This can be different from how the organization describes itself. I have seen several IT organizations that considered themselves being “agile” (i.e., post-industrial), but actually were driven by a deeply industrial mindset – which resulted in cargo cult agile orchestrations that were not agile at all, but just used new terminology to describe their old industrial practices. ↩︎

  6. As most companies have one of the three other modes as predominant working mode, this is not a problem. And if the litmus test should fail, asking two or three additional questions usually is enough to detect the pre-industrial working mode. ↩︎

  7. A few years ago, there was quite a wave of IT-centered startups with a strong Do-it-yourself (DIY) attitude. A few of them survived and grew bigger, maintaining and even cultivating this DIY attitude. While this attitude is risky in a startup context anyway, the developments of the recent years in the public cloud domain additionally changed the situation. Even if you consider yourself the next Netflix, you find powerful managed services for almost any non-differentiating functionality these days. Thus, still going for deep DIY in a startup IT gives you a severe competitive disadvantage today. ↩︎

  8. The “Poor dog” quadrant from the BCG-matrix does not have an equivalent in the other two models. If your offering moves into that quadrant, I typically recommend to cut costs by all means, e.g., by outsourcing the IT solution (potentially even compromising quality) to extract the last bit of revenue from the offering before eventually discontinuing it. ↩︎

  9. Discussing how to resolve the conflicts that arise from colliding working modes is outside the scope of this post. I will probably come back to this topic in a later post. ↩︎

  10. To be frank, I was surprised myself how long the two posts became. When I decided to write about this topic, I expected it to become a lot shorter. Well, I guess I was wrong … ;) ↩︎