Complicated vs Complex Problems

Complicated vs Complex Problems - Stack Moxie
[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]

One of the most interesting things I’ve learned in the past few years was the concept of complicated vs. complex problems. Borrowing from Ted Kini’s article in Inc, and quoting Rick Nason:

A complicated issue, explains Nason, is one in which “the components can be separated and dealt with in a systematic and logical way that relies on a set of static rules or algorithms.” It may be hard to see, but there’s a fixed order in something that is merely complicated and that allows you to deal with it in a repeatable manner.

– Rick Nason

Pumping crude oil from 6 miles below the surface of the Gulf of Mexico is complicated. So is making an electric car and a reusable rocket (just ask Elon Musk). But once you figure out how to do these things, you can keep doing them at will.

On the other hand, a complex issue is one in which you can’t get a firm handle on the parts and there are no rules, algorithms, or natural laws. “Things that are complex have no such degree of order, control, or predictability,” says Nason. A complex thing is much more challenging–and different–than the sum of its parts, because its parts interact in unpredictable ways.”

To me, Sales and Marketing Operations tech stack are a complicated system. With my deep understanding of the various tools that make up a tech stack and the integrations and configurations, I felt that navigating a tech stack was a large data set of known variables. But as any tech stack escapes a startup size, because of all the  dependencies and potential upstream and downstream integrations, a tech stack is actually a complicated problem.  

Without automation to test the large number of predictable outcomes (not infinite) given a large set of inputs, and a limited amount of manual time to validate them, the tech stack might as well have been complex. Any ops person who felt that testing was pointless because they could never spend enough time or hire enough people to get sufficient test coverage vs the risk of inevitable failures … was right.  

When you add all the complexity of upstream or downstream systems – data augmentation and CDPs and engineering pulling in product details – no human could predict what the output should be for edge cases. Even with perfect documentation.  

In theory, a martech system is a complicated system. But in reality, without data analytics and test automation, it might as well be complex.  Finally, today, the stack is complicated in practice AND theory, Marketing and Revenue Operations.  Which means it finally makes sense to invest in devops style monitoring and testing.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]