[et_pb_section fb_built=”1″ _builder_version=”3.22″][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.8.1″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]<\/p>\n
How do chiefs of staff navigate, and help their execs and leadership teams navigate, decision support in an increasingly complex world? This week\u2019s guest writer is Aaron Rinehart, Founder and CTO at Verica, who pioneered the application of chaos engineering to computer security during his tenure as the Chief Security Architect at the largest private healthcare company in the world, UnitedHealth Group (UHG). He argues that in an increasingly complex world, simplifying isn\u2019t always the best way for leadership teams or organizations at large to deal with complexity. Check out why and his tips for helping leadership teams navigate that world.
\n<\/i><\/p>\n
<\/p>\n
We are in the middle of a dramatic and broad technological and economic shift in which software and the internet have changed how we consume and deliver products and services, how we work, how and how much we interact with other humans, and other aspects of how we live. It used to be that a company was known for producing or delivering X, and they used technology to do so. Now, companies are technology companies that produce and deliver X.<\/p>\n
Given this broad trend toward technology-first business models, it\u2019s important to begin to understand a few key principles we have inherited as a result of the choices we have collectively made:
\n1.\u00a0\u00a0 \u00a0Software only increases in complexity over time.
\n2.\u00a0\u00a0 \u00a0Software abstraction hides that complexity.
\n3.\u00a0\u00a0 \u00a0There are different kinds of complexity, including essential and accidental.
\n4.\u00a0\u00a0 \u00a0Complexity, rather than something to be avoided (even if it could be), IS your value or significantly contributes to your value in this new world.
\n5.\u00a0\u00a0 \u00a0We avoid complexity at great risk to our organizations and careers.<\/p>\n
<\/p>\n
It may seem as if software has become easier and more accessible, but software suffers from a number of inherent ironies and paradoxes. As a result of years of rapid technological expansion (e.g. microprocessors, the internet, social networks, cloud computing, etc.) software has also grown through continuously being abstracted as a result.<\/i><\/p>\n
<\/p>\n
<\/p>\n
<\/i><\/p>\nSoftware abstraction hides that complexity<\/h5>\n
Software abstraction occurs by simplifying the steps required for a person to interact with a system. Such simplification \u201csuppresses\u201d or masks the more complex series of steps that must take place behind the scenes. For example, computers still function using binary code despite the fact that no one is really writing modern software in 1s and 0s.\u00a0 This has allowed engineers to add additional levels of functionality and business-enabling capabilities that would otherwise have been too complex to for us as humans to grok. Software complexity both reflects and drives the complexity we face when making critical business decisions. Abstraction is only one of many contributing factors to software complexity.<\/p>\n
<\/p>\n
Essential complexity is a direct result of phenomena such as Conway\u2019s Law, which states that \u201corganizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.\u201d What this means is that the designs of the computer systems we build to operate our business are a direct reflection of how that business functions as a whole and all the assumptions, processes, and decisions involved in how it functions. The complexity inherent in how a business operates is also correlated to the reasons why it is successful. The technological foundations we have replaced them with inherit these same characteristics. For example, we didn\u2019t stop making special customer widgets. We just started building and delivering them faster and cheaper online. The business processes, procedures, requirements, and functions that take place in making these special customer widgets didn\u2019t change. Rather the way we built and delivered them did. The complexity in producing, managing, and selling these widgets is directly reflected in its technological replacement, typically through software.<\/p>\n
Accidental complexity occurs through the essence of what software is and how it is built. Software systems are more complex for their size than perhaps any other human construct, for the reason that no two single parts are alike. Software is also constantly subject to pressures for change, just like buildings, cars, and airplanes. But buildings, cars, and airplanes are infrequently changed after they are delivered. Software is thought to be “infinitely malleable,” in that it can be changed as often as we like and is quite easy to do so. So, accidental complexity in software comes from the fact that software can change as much or as often as we want it to.
\n<\/i><\/p>\n
<\/p>\n
<\/p>\n
<\/i> We avoid complexity at great risk to our organizations and careers.<\/strong> For example, in the name of Agile, many organizations have adopted a mindset of \u201cjust start building something and iterate, and it will all work out.\u201d Or, more specifically, that a useful system design emerges out of a series of mostly independent and disconnected \u201cuser stories,\u201d use cases, or scenarios. But, in failing to account for the broader complexity, these organizations might never arrive at a useful solution but a disjointed set of disconnected solutions. Or, they might lose precious time or be leap-frogged by competitors by doing iterative work they could have built in if they had done more analysis or planning early-on, which feels antithetical to Agile. Agile does guard against analysis paralysis, but totally flying by the seats of their collective pants doesn\u2019t serve these organizations any better. They have to make intentional choices about risk tolerance and what level of planning will most likely drive the best outcomes, all of which might or might not be supported by an Agile methodology, at least not initially.<\/p>\n Another example is, in the golden age of so-called big data, an organization might base a go-to-market decision on personas or an \u201caverage\u201d customer, when their actual customers might not reflect the average at all. Todd Rose wrote a great article about the time the U.S. Air Force discovered the flaw of averages (see the References section below for more reading on that topic).<\/p>\n In the end, I\u2019m not arguing that we should seek complexity or add to it for its own sake. There\u2019s plenty to go around as a natural consequence of the dynamics I mentioned above.\u00a0 But it\u2019s critical to understand where complexity comes from and find ways to appropriately navigate it in order to make more effective decisions.<\/p>\n <\/p>\n A better way forward – navigating complexity versus avoiding it<\/strong> First, evaluate supporting decision information in terms of \u201cwhat has happened in the past,\u201d \u201cwhat is currently happening,\u201d and \u201cwhat might possibly happen\u201d. Past and current information is sometimes only an indicator of the information we knew of or thought to collect based upon our understanding at a point in time. In considering what might happen, we mentally align our understanding of how we believe things work versus how they actually work, thereby lessening the possibility of being blindsided.<\/p>\n Next, consider the decision through a multitude of different vantage points. When dealing with complex systems, perspectives matter. For example, consider using different data, sorting and filtering and querying the same data in different ways, and seeking the perspective of someone you don\u2019t regularly interact with. Overlay and analyze your initial decision information with the alternative perspectives you collected to build a more accurate model of the complexity within the decision landscape.<\/p>\n Lastly, based upon these previous steps, execute a series of small, scoped experiments to slowly reduce uncertainty and validate the decision landscape. Recall that when dealing with complexity we learn to navigate it by making mistakes purposefully instead of avoiding them by design. Making small mistakes cheaply and early allows us to learn from them and make more informed decisions as a result. Taking these three steps can help limit the possibility of adverse impacts, increase confidence, and maximize the potential for success.<\/p>\n <\/p>\n References<\/strong> [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Guest Aaron Rinehard argues that in an increasingly complex world, simplifying isn\u2019t always the best way for leadership teams to deal with complexity.<\/p>\n","protected":false},"author":5,"featured_media":31318,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":" \u00a0<\/p> How do chiefs of staff navigate, and help their execs and leadership teams navigate, decision support in an increasingly complex world? This week\u2019s guest writer is Aaron Rinehart, Founder and CTO at Verica, who pioneered the application of chaos engineering to computer security during his tenure as the Chief Security Architect at the largest private healthcare company in the world, UnitedHealth Group (UHG). He argues that in an increasingly complex world, simplifying isn\u2019t always the best way for leadership teams or organizations at large to deal with complexity. Check out why and his tips for helping leadership teams navigate that world. \u00a0<\/p> <\/i> Given this broad trend toward technology-first business models, it\u2019s important to begin to understand a few key principles we have inherited as a result of the choices we have collectively made: \u00a0<\/p> Software only increases in complexity over time<\/strong> \u00a0<\/p> \u00a0<\/p> <\/i> \u00a0<\/p> There are different kinds of complexity, including essential complexity and accidental complexity<\/strong> Accidental complexity occurs through the essence of what software is and how it is built. Software systems are more complex for their size than perhaps any other human construct, for the reason that no two single parts are alike. Software is also constantly subject to pressures for change, just like buildings, cars, and airplanes. But buildings, cars, and airplanes are infrequently changed after they are delivered. Software is thought to be \"infinitely malleable,\" in that it can be changed as often as we like and is quite easy to do so. So, accidental complexity in software comes from the fact that software can change as much or as often as we want it to. \u00a0<\/p> \u00a0<\/p> <\/i> We avoid complexity at great risk to our organizations and careers. For example, in the name of Agile, many organizations have adopted a mindset of \u201cjust start building something and iterate, and it will all work out.\u201d Or, more specifically, that a useful system design emerges out of a series of mostly independent and disconnected \u201cuser stories,\u201d use cases, or scenarios. But, in failing to account for the broader complexity, these organizations might never arrive at a useful solution but a disjointed set of disconnected solutions. Or, they might lose precious time or be leap-frogged by competitors by doing iterative work they could have built in if they had done more analysis or planning early-on, which feels antithetical to Agile. Agile does guard against analysis paralysis, but totally flying by the seats of their collective pants doesn\u2019t serve these organizations any better. They have to make intentional choices about risk tolerance and what level of planning will most likely drive the best outcomes, all of which might or might not be supported by an Agile methodology, at least not initially.<\/p> Another example is, in the golden age of so-called big data, an organization might base a go-to-market decision on personas or an \u201caverage\u201d customer, when their actual customers might not reflect the average at all. Todd Rose wrote a great article about the time the U.S. Air Force discovered the flaw of averages (see the References section below for more reading on that topic).<\/p> In the end, I\u2019m not arguing that we should seek complexity or add to it for its own sake. There\u2019s plenty to go around as a natural consequence of the dynamics I mentioned above.\u00a0 But it\u2019s critical to understand where complexity comes from and find ways to appropriately navigate it in order to make more effective decisions.<\/p> \u00a0<\/p> A better way forward - navigating complexity versus avoiding it<\/strong> First, evaluate supporting decision information in terms of \u201cwhat has happened in the past,\u201d \u201cwhat is currently happening,\u201d and \u201cwhat might possibly happen\u201d. Past and current information is sometimes only an indicator of the information we knew of or thought to collect based upon our understanding at a point in time. In considering what might happen, we mentally align our understanding of how we believe things work versus how they actually work, thereby lessening the possibility of being blindsided.<\/p> Next, consider the decision through a multitude of different vantage points. When dealing with complex systems, perspectives matter. For example, consider using different data, sorting and filtering and querying the same data in different ways, and seeking the perspective of someone you don\u2019t regularly interact with. Overlay and analyze your initial decision information with the alternative perspectives you collected to build a more accurate model of the complexity within the decision landscape.<\/p> Lastly, based upon these previous steps, execute a series of small, scoped experiments to slowly reduce uncertainty and validate the decision landscape. Recall that when dealing with complexity we learn to navigate it by making mistakes purposefully instead of avoiding them by design. Making small mistakes cheaply and early allows us to learn from them and make more informed decisions as a result. Taking these three steps can help limit the possibility of adverse impacts, increase confidence, and maximize the potential for success.<\/p> \u00a0<\/p> References<\/strong> \u00a0<\/p>","_et_gb_content_width":"","footnotes":""},"categories":[114,41],"tags":[120,110,113,112,111],"class_list":["post-29470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-chief-of-staff","category-home-news","tag-ceo","tag-chiefofstaff","tag-pmp","tag-program-management","tag-project-management"],"yoast_head":"\n
\nComplexity, rather than something to be avoided (even if it could be), IS your value or significantly contributes to your value in this new world<\/strong>
\nSoftware that never changed would be very unsatisfying after a while. We come to expect more from it with each iteration. Likewise, a business that never changed anything would not continue to provide value. With change comes complexity, but both are core components of delivering business value. Therefore, we must learn to navigate complexity instead of trying to simplifying it away.<\/p>\n
\nOften, we respond to complexity by attempting to \u201csimplify\u201d away the changes. This shows up as, or as part of, \u201cdigital transformation\u201d initiatives and the application of Agile to just about everything.\u00a0 The problem is, attempts to simplify typically result in a similar level of complexity somewhere else. They displace complexity but don\u2019t make it go away.<\/p>\n
\nWhen it comes to strategic decision making and designing the organization structures and their correspondent interactions between processes, technologies, and people that drive our strategic outcomes, we have to learn to navigate complexity instead of trying to simplify it away.\u00a0 So, how do you do that?<\/p>\n
\n\u2022\u00a0\u00a0 \u00a0Marc Andreessen, \u201cWhy Software Is Eating the World,\u201d Wall Street Journal (August 20, 2011): https:\/\/a16z.com\/2011\/08\/20\/why-software-is-eating-the-world\/<\/a>
\n\u2022\u00a0\u00a0 \u00a0Fred P. Brooks, “No Silver Bullet \u2014 Essence and Accident in Software Engineering,” (1986) Proceedings of the IFIP Tenth World Computing Conference: 1069\u20131076.
\n\u2022\u00a0\u00a0 \u00a0Todd Rose, \u201cWhen U.S. Air Force discovered the flaw of averages,\u201d The Star (January 16, 2016): https:\/\/www.thestar.com\/news\/insight\/2016\/01\/16\/when-us-air-force-discovered-the-flaw-of-averages.html<\/a>
\n\u2022\u00a0\u00a0 \u00a0G\u00f6k\u00e7e Sargut & Rita Gunther McGrath, \u201cLearning to Live with Complexity,\u201d Harvard Business Review (September 2011) https:\/\/hbr.org\/2011\/09\/learning-to-live-with-complexity<\/a><\/p>\nJune 4, 2019 (Adapted from my newsletter, The Briefing<\/em>. Originally published May 22, 2019.)<\/h6>
<\/i><\/p>\u00a0\u201cSoftware is eating the world\u201d \u2013 Marc Andreessen<\/h4>
We are in the middle of a dramatic and broad technological and economic shift in which software and the internet have changed how we consume and deliver products and services, how we work, how and how much we interact with other humans, and other aspects of how we live. It used to be that a company was known for producing or delivering X, and they used technology to do so. Now, companies are technology companies that produce and deliver X.<\/p>
1.\u00a0\u00a0 \u00a0Software only increases in complexity over time.
2.\u00a0\u00a0 \u00a0Software abstraction hides that complexity.
3.\u00a0\u00a0 \u00a0There are different kinds of complexity, including essential and accidental.
4.\u00a0\u00a0 \u00a0Complexity, rather than something to be avoided (even if it could be), IS your value or significantly contributes to your value in this new world.
5.\u00a0\u00a0 \u00a0We avoid complexity at great risk to our organizations and careers.<\/p>
It may seem as if software has become easier and more accessible, but software suffers from a number of inherent ironies and paradoxes. As a result of years of rapid technological expansion (e.g. microprocessors, the internet, social networks, cloud computing, etc.) software has also grown through continuously being abstracted as a result.<\/i><\/p>\u201cSoftware complexity both reflects and drives the complexity we face when making critical business decisions.\u201d<\/h4>
Software abstraction hides that complexity<\/strong>
Software abstraction occurs by simplifying the steps required for a person to interact with a system. Such simplification \u201csuppresses\u201d or masks the more complex series of steps that must take place behind the scenes. For example, computers still function using binary code despite the fact that no one is really writing modern software in 1s and 0s.\u00a0 This has allowed engineers to add additional levels of functionality and business-enabling capabilities that would otherwise have been too complex to for us as humans to grok. Software complexity both reflects and drives the complexity we face when making critical business decisions. Abstraction is only one of many contributing factors to software complexity.<\/p>
Essential complexity is a direct result of phenomena such as Conway\u2019s Law, which states that \u201corganizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.\u201d What this means is that the designs of the computer systems we build to operate our business are a direct reflection of how that business functions as a whole and all the assumptions, processes, and decisions involved in how it functions. The complexity inherent in how a business operates is also correlated to the reasons why it is successful. The technological foundations we have replaced them with inherit these same characteristics. For example, we didn\u2019t stop making special customer widgets. We just started building and delivering them faster and cheaper online. The business processes, procedures, requirements, and functions that take place in making these special customer widgets didn\u2019t change. Rather the way we built and delivered them did. The complexity in producing, managing, and selling these widgets is directly reflected in its technological replacement, typically through software.<\/p>
<\/i><\/p>\u201cWith change comes complexity, but both are core components of delivering business value.\u201d<\/h4>
Complexity, rather than something to be avoided (even if it could be), IS your value or significantly contributes to your value in this new world<\/strong>
Software that never changed would be very unsatisfying after a while. We come to expect more from it with each iteration. Likewise, a business that never changed anything would not continue to provide value. With change comes complexity, but both are core components of delivering business value. Therefore, we must learn to navigate complexity instead of trying to simplifying it away.<\/p>
Often, we respond to complexity by attempting to \u201csimplify\u201d away the changes. This shows up as, or as part of, \u201cdigital transformation\u201d initiatives and the application of Agile to just about everything.\u00a0 The problem is, attempts to simplify typically result in a similar level of complexity somewhere else. They displace complexity but don\u2019t make it go away.<\/p>
When it comes to strategic decision making and designing the organization structures and their correspondent interactions between processes, technologies, and people that drive our strategic outcomes, we have to learn to navigate complexity instead of trying to simplify it away.\u00a0 So, how do you do that?<\/p>
\u2022\u00a0\u00a0 \u00a0Marc Andreessen, \u201cWhy Software Is Eating the World,\u201d Wall Street Journal (August 20, 2011): https:\/\/a16z.com\/2011\/08\/20\/why-software-is-eating-the-world\/<\/a>
\u2022\u00a0\u00a0 \u00a0Fred P. Brooks, \"No Silver Bullet \u2014 Essence and Accident in Software Engineering,\" (1986) Proceedings of the IFIP Tenth World Computing Conference: 1069\u20131076.
\u2022\u00a0\u00a0 \u00a0Todd Rose, \u201cWhen U.S. Air Force discovered the flaw of averages,\u201d The Star (January 16, 2016): https:\/\/www.thestar.com\/news\/insight\/2016\/01\/16\/when-us-air-force-discovered-the-flaw-of-averages.html<\/a>
\u2022\u00a0\u00a0 \u00a0G\u00f6k\u00e7e Sargut & Rita Gunther McGrath, \u201cLearning to Live with Complexity,\u201d Harvard Business Review (September 2011) https:\/\/hbr.org\/2011\/09\/learning-to-live-with-complexity<\/a><\/p>