Published: August 14, 2021
In 5th grade, Mrs. Papendorf accused 10 year old Brian of “always questioning and having the last word.” To which I replied “Not EVERY time.” I recognized the irony as soon as the words left my mouth but my intrinsic desire to question things has never gone away.
The emphasis on an ability to think critically was HIGHLY evident during Marine Corps Officer training. I remember exercises where nearly the entire assessment was based on HOW we approached a problem, and mostly disregarded the actual outcome.
But, it became clear to me that not everyone possesses a similar mindset when I witnessed Marines running a help desk and struggling to solve problems that weren’t “in the manual” or “taught at school.” This is not an uncommon phenomena in the US military (as I later discovered). [1] This comprehension put me in a 10 year battle against “certs” and “checklists”, ensuring that my teams’ training time was spent with a focus towards developing thinking muscles.
Any practitioner of a highly technical disciple recognizes that no one else has all of the answers. Many of the answers can’t be found in a book. Some problems don’t even have answers. How does someone charged with solving a problem tackle something that may not have an answer?
I think there are three parts to approaching this challenge:
A recognition that there may not be a “right” answer and a willingness to proceed despite the uncertainty. There may be partial solutions. A path which doesn’t provide a desired solution is a now a discovery and extra point of knowledge. There may be an answer that is less terrible than other answers. Recognizing this possibility frees up the mind to explore in different ways.
Frame these problems in a way that allows us to act and progress despite. Frameworks, mental models, or software patterns are ways we can address a challenge, in a way that seems more familiar. These are different from checklists in that there is sufficient flexibility to adjust as necessary and the underlying understanding that a “model” isn’t printed on stone.
Experience tackling problems. The more problems someone tries to solve, the more natural this way of thinking occurs. Fighting through Leadership Exercises gave me a perspective I can apply towards a problem our software team is facing. Implementing a new software capability provides new knowledge which I can use when considering malicious adversary actions. The more you think critically, the more models you have, the more natural it all becomes.
I’ve spent the last 18 months building and observing training events in which we help Information Security Professionals gain hands-on experience doing probably the hardest part of their job: hunting down bad guys in complex computer networks. This is a prime example of a space that does NOT lend itself well to checklist style learning. There is another thinking human on the other end of the problem. Critical thought is an absolute requirement. No manual contains the answer to what the other person did.
I’ve discussed this a bit in another blog post here: Training Secrets of Great SOC Teams, but I want to reiterate how obviously different the approaches, questions, and methods are for students who possess and practice the above steps, versus those who haven’t developed the skills yet. And, regardless of technical skill or experience, the end result confirms.