Complexity

In software development there are three levels of complexity that are in play.  You should focus on the primary complexity: taking a complex business problem within its native domain and designing a technical solution.

Examples of primary complexity issues are designing a strategy-based plugin architecture for mortgage calculations, designing a star schema to later use for predictive analysis of snack cart Skittle consumption on college campuses (spoiler alert: finals week and wild berry are a solid marriage).  Secondary complexity in software include items that the folks in the domain don’t understand but the technical folks need to do their work quickly. The QA team, the fact that you need to upgrade Visual Studio every two years in a Microsoft shop, your check-in policy and coding standards – these are typical examples of secondary complexity.  Tertiary complexity are items that the domain folks and the technical folks don’t fully understand. The fact that Steve and Ralph freaking hate each other, the morale impact of low raises on a team, the fact that communication can kill a team over a certain size, poor meeting practice, etc. are all examples of tertiary complexity. This type of complexity is colloquially referred to as “bullshit” (in some provinces “horseshit” or more rarely “dogshit”)

Consequences

The levels affect each other predictably. If the problems of one level are not solved, they affect levels above them. If half of your team are French and the other half hate French people, that’s a tertiary complexity problem that will lead to awkward code reviews, poor rework throughput and affect your ability to ship software that solves domain problems. If your QA and UAT databases “timeout” more than a cranky 2 year old, you can’t ship software.

Talent Effect

By “effect” I don’t mean slow down only. If you have too many secondary and tertiary problems, the people that work in the primary domain will grow frustrated. In software development these are creators – developers and those that feed them information (BAs, User Interface folks, reedit). This is a dangerous situation. If you hire a talented pizza chef but all the pizza shows up two hours late (or not at all) you have secondary problems (failed delivery channel – broken down Civic) or tertiary problems (your delivery guy likes pot more than tips) eventually the chef will feel that their work doesn’t matter and leave.

Management

If you make the move from developer to manager, you are effectively saying that your team will handle the primary work while you work on secondary work (processes) with their input, but try as much as possible to shield the tertiary problems (bullshit) from them. Where this gets more complex is when tertiary complexity is high in an organization. The most striking example of tertiary complexity in some organizations are middle managers jockeying for promotion position – this activity does not improve processes or help with production, but creates a situation in which these things are harder.The balance of tertiary vs. secondary complexity is indicative of where a company is and whether it can heal its key problems. If the tertiary complexity is low, then there is enough management capacity to solve secondary issues and allow producers to create great things.