This is similar to (but a bit more specific than) the hierarchy Weinberg lays out in his Quality Software Management series. In his mind, a level 0 ("oblivious

This is similar to (but a bit more specific than) the hierarchy Weinberg lays out in his Quality Software Management series. In his mind, a level 0 ("oblivious") software developer doesn't even know they're developing software. They write code to solve problems. Think accountant scripting spreadsheet to get a sense of how it happens in business. Level 1 ("variable") is when you start to have external customer demand. However, the software developers still generally work whatever way they feel like. This works well with Brook's idea of a small surgical team. But there are few generalisations due to its variable dynamic. Level 2 ("routine") is often what happens as a level 1 team grows. All these processes get added and nobody really understands why except someone said "you're supposed to do it this way". Characteristic of level 2 teams is that they actually work fairly well as long as they don't hit a streak of bad luck. Once they do, they abandon all process and try to rescue projects with heroism and it rarely works out well. Level 3 ("steering") is a rare variant of level 2. At this level, people actually understand why processes should be introduced. They select the processes that fit the circumstances. Level 2 and 3 can look remarkably similar for "regular" projects. The difference is that a lot more projects become regular for the level 3 organisation. Weinberg also lists a couple of higher levels that he never observed in the wild, but which relate to how teams use feedback: In a level 3 organisation, feedback from individual projects are used to improve the outcome of that very same project the feedback came from. In a level 4 organisation, feedback from individual projects are used to improve the processes that lead to the project ending up in that state. (So feedback is used for meta-improvement.) In a level 5 organisation, feedback from individual projects is used to improve how feedback from individual projects is used to improve things. (In other words, meta-meta-improvement.) Edit: I misrepresented things. Weinberg is quite adamant that this is not really a hierarchy and they are not levels, per se. They patterns of working, with none superior than the other in general, only in specific circumstances. I sort of see what he meant by that, but also I don't quite understand that part.