A Series of Cognitive Frameworks for Police RTCC: 02 - Cynefin

How might cognitive frameworks help people who work inside police "real-time crime centers?" 

To me, it's about putting people, ideas, & pieces of technology together in ways that enhance awareness, sense-making & decision-making. 

The next framework in this series is Cynefin. 

Cynefin is a sense-making framework that helps observers, decision-makers, and doers figure out what sort of system structure or dynamics exist.

This is important because the attitude or approach taken to situations in each of the Cynefin domains should be different. 

Please allow me to riff for just a bit...

Many police RTCCs are filled with highly technical, algorithmic tools that use formulaic processes. For example, tools that might compare objective letters or numbers (such as those recognized in video or photos) against identical strings of letters or numbers in a database. When such digits are matched, certain alerts might be triggered. This is a highly objective process. As such, this sits within the Clear domain. 

Understanding how to use the above system requires training, repetition, and arguably certification. There is an objective determination of whether it was done correctly or not. There are best practices when interacting with this tool, but only when taken in isolation (away from other tools). This is also where automation belongs; and maybe a pinch of artificial intelligence. 

As another example, this time in the Complicated domain, take the naming of cameras. I've seen all sorts of camera naming schemes and formats. I've seen many good ones and some horrible ones. There is hardly a "best" way. However, there are those methods that make more sense than others. In my opinion, camera names, in addition to any descriptive fields, should have a very short identification number of three (3) to five (5) digits of numbers or letters -- maybe something like 7576W. Why I believe this is not the purpose of this example; the purpose is that there are good practices when it comes to camera naming conventions, which are based in experience. To me, good camera names can be easily (and objectively) communicated to others, tell the user some basic attributes of the camera, and tell the user where it's located. In a similar way that "black Cadillac Escalade 123ABC" is both descriptive and objective. 

Another situation in the Complicated domain (bordering on the Complex) is the separation on whether to use native tools/infrastructure or whether to deploy integrator software. Both work; both have serious limitations. This is where both options are "good practices." In a future post, I plan to discuss value chain mapping via Wardley Mapping. [Spoiler: Integrators and native programs both fill a use need.]

In my RTCC, we regularly use over two (2) dozen different pieces of software or applications, and more when you consider the niche tools. That means a user must master each of those individual tools. They must understand each of the technical specs, procedures, operating standards, and the best or good practices that accompany them. Users must know each tool inside and out.

But it doesn't stop there. Users must understand the interplay between these systems. And where they collide and connect is within the Complex domain. (These tools also flirt with complexity when they interact with the real world, but that's a deep discussion better left to be had over beer or whiskey.)

The interplay between systems requires users figure out what systems to use, how to use their features, and under what circumstances. There is no standardized workflow or order of systems to be used. The interdependence or interplay between them is something that requires vast experience and wisdom. To which system do you turn first, and for seeking what advantage? Is it the system that is likely to get you the highest return-on-investment on your effort? 

In the Complex domain we see our big disagreements. The unresolved tensions. The compromises. The conflicts. Both between how different RTCCs do their business, but also within a singular RTCC user who must pick an exploratory course of action that could result in no advantage and time wasted - - which just as easily yielded a huge break in a case with minimal effort. Experimentation, as well as failure, must be an encouraged part of RTCC duties. 

The purpose of this post is not to teach the Cynefin framework; there are plenty of free resources that help do that. Learning it is a multi-year journey to scratch the surface. However, the intent is to show some basic applications of Cynefin onto a variety of RTCC aspects. This is from leveraging isolated technical tools ... to clashing with a confusing reality through using tools in exaptive ways - where they're used in ways in which they were never engineered nor imagined to be used by their designers.  

I hope this post puts you on that journey to take a deeper dive into Cyenfin. 

***

What other cognitive frameworks would you like to see applied to RTCC? And I'm going to use the term "framework" quite loosely in this... and include all sorts of models, theories, infographics, and whatnot.

I've got a few others queued up. I've even created a tag for this series! 

***

Lou Hayes, Jr. is a detective supervisor in a suburban Chicago police department, collaterally detailed to a regional major crimes (homicide) task force.  He has a passion for multi-jurisdictional crime patterns, criminal networks, & regional intelligence. With a background in training, he studies human performance, decision-making, creativity, emotional intelligence, & adaptability. 

Follow Lou on LinkedIn, & also the LinkedIn page for The Illinois Model. ***