Imagine a busy emergency room, full of scared patients, worried family members, and blaring televisions doing little to soothe them. Each person waits for his turn to shuffle back to an exam room where he can describe his concerns, be diagnosed, and receive treatment. Making this entire process possible are medical professionals with advanced training and experience – and tools.
These tools are useless without the doctors and nurses who employ them, but doctors and nurses are also handicapped without their capabilities. For example, it would be difficult to confirm tumors or certain types of heart disease without a CT scan machine. Once diagnosed, many conditions also benefit from the aid of tools like arthroscopic cameras or feeding tubes. Both patients and doctors rely heavily on medical machines.
So who makes these machines possible? CT scan builders are not doctors, but rather technologists. That’s because the challenge – how to image soft tissue – is not a medical problem, but rather a technological one. The doctor’s expertise is focused on solving the patient’s problem, while the technologist’s is focused on solving the doctor’s. A technologist needs to understand doctors and their workflows very well to build an effective tool, but he needs to understand technology to build a tool at all. Doctors provide critical input, and then technologists translate those needs into products that meet doctors’ – and patients – needs.
The same applies in legal technology: the most effective tools reflect lawyers’ needs and workflows but are built and maintained by technologists. As with a CT scan machine, a legal tool needs a builder with a deep knowledge of tech. That person can solve the technology problem at hand by translating lawyers’ requirements into an effective and efficient product. He can use his expertise with software challenges, emerging technologies, and abstraction to develop more capable machines.
For example, keeping up with advances in computer vision isn’t a common hobby for litigators. However, a technologist may find it fascinating to follow early advances. And a technologist immersed in the legal field may see an application of this seemingly-unrelated area, as engineer AJ Shankar describes in this video:
Here’s another example: in litigation, reviewing documents for privilege is quite different from building a case chronology. The former requires identifying communications between specific custodians or about specific topics; the latter requires putting events into context with an eye for building an effective narrative. From a legal perspective, these two steps might be performed by different teams, might leverage different metadata fields, and might involve different volumes of data. However, from a technology perspective, these two steps both necessitate performing batch actions, to avoid coding one document at a time or moving one email at a time into a timeline. A technologist can build functionality that applies an operation to multiple items at once, and then adjust for the unique elements of the two respective tasks.
Though doctors and lawyers use technology every day to solve medical and legal problems, the creation and maintenance of those technologies are computer problems. And who better than a technologist to solve those?