Isomorphic Experience & Moneyball

Introduction

If you hang out with the cool software engineering kids, you’ll probably hear about isomorphisms. While this term has a formal mathematical definition, for most purposes it’s just a big word with a simple meaning. Specifically, that two different things are functionally identical for some purpose. Pizza and ice cream are very different, but are isomorphic with regard to wrecking a diet.

This piece is about isomorphic experience in tech; that is, work experience that appears unrelated to what a company is looking for when hiring for a role but is really the same as the listed requirement. I focus on my experience in law (specifically patent litigation) and management consulting in this piece, but the general idea applies to candidates with backgrounds in medicine, the sciences, and other areas.

You may be asking at this point why, other than academic curiosity, you should care. Well, if you hire, being aware of isomorphic experience allows you to expand the pool of possible candidates, and capture talent your competitors may have overlooked. Exploiting labor market inefficiencies was one of the main lessons from Michael Lewis’s classic Moneyball - here we are just applying it, well, for lack of a better word, isomorphically - to the tech industry.

Two Case Studies

Law

The beginning of my career was spent almost exclusively as a patent litigator. That means once a dispute led to a lawsuit over patents, I was on the team arguing our client’s side. (The majority of the time this meant representing large companies against non-practicing entities, better known as trolls.) I did not write patents. I argued about what they meant. I was usually also the only tech person on a team of 7-10 attorneys.

The meant whatever the accused product was, I had to understand how it worked. Completely understand in all relevant detail. When a Bluetooth patent was asserted against WiFi products, I had to understand the BT protocol, 802.11a/g, the stateful vs. stateless difference between them, be able to read the client’s internal design documents, talk with the people who engineered the products, talk with our outside experts, and understand all that material.

That was the easy part. Next came taking that material and presenting it back to our team, who were great attorneys but lacked engineering backgrounds. That meant taking the material, teaching it, omitting irrelevant parts (and knowing what was irrelevant, and what might become relevant as our arguments changed), and, as is crucial in patent cases, figuring out how we were going to propose define important terms in the patent. (The Markman process).

Still, pretty easy. Smart attorneys, and they could figure out the technology given time. The hard part was presenting to the court, or worse, a jury. Jurors do not want to be there, and are not engineers. Judges are not engineers, and generally dislike doing patent cases. Under very tightly prescribed time and page limits, you had to make an argument to a bored party of something very complex, do it understandably and not condescendingly, and get them to take your side.

It’s worth reemphasizing that last point. People think of legal writing as long, dull, stilted, and painful to gaze upon. That’s true of some forms. It is not true of litigation writing. Litigation is about persuasion. Your need to write no more than is necessary to make your point, you need it be clear, understandable, and as engaging as possible. And since the page limits are always too short, you get much practice editing your work to be as succinct as possible.

One example: I once had a pile of low-level CPU microarchitecture design documents dumped on me. I had to go through them, figure out how the translation lookaside buffer was being implemented, figure out the implications of that implementation in terms of our arguments, explain it to our team, and prepare persuasive arguments for a court disinterested in technology about how the TLB fit into the case. I had to take in the technology at the lowest and rawest level, understand it, translate it to different levels of detail, and finally create persuasive arguments around that in a different context, the context that the reader was concerned with.

This sounds a lot like technical marketing, and it was. On paper, law and tech marketing seem completely unrelated, but as the old saying goes, the isomorphism is in the details.

Management Consulting

I spent time at Cisco as a “Lead Technologist, Cisco Consulting Services, Internet of Everything Practice”; that title, despite its length, never really conveyed what our group was doing. Cisco at the time had a management consulting business unit. That group worked with Cisco customers. Cisco customers would be brought to our main campus by their sales team to see the latest and greatest Cisco products; our practice maintained an ancillary Showcase/Lab that showed off various custom-built IoE solutions we had made.

Our group - about 4 of us - did several things:

1. We maintained that Showcase but putting new IoT demos in it. Some were re-purposed from customer engagements, others were blue-sky prototypes.

2. When visiting exec groups would come by, we would present in the Showcase to them. These would generally be VP-level execs from Fortune 500 companies. We’d show them past solutions, demos we created, and talk to them about the challenges of their business. This was the most ‘management consultanty’ aspect of our work, since we had to identify opportunities for IoT-related technological innovation of actual business value specific to their vertical.

3. Regular management consultants would get to make Powerpoints after that step that said “go do that”. We had a group rule of no Powerpoints, so we instead went out and built the prototype we had just proposed (see this article in the IEEE IoT Newsletter for information about the tech we used). We built hardware, wrote software, and created UIs so ugly that finally securing funding for a graphics designer was a slam-dunk.

A colleague in another group thought we were most similar to Technical Marketing Engineers. We overlapped with TMEs as much as anything. We did far more technical work than most management consultants, but we worked much closer with clients than TMEs, with a big part of our job being able to speak the language of the vertical and figure out where technology could positively impact the business. We also tended to build our ‘products’ ourselves.

Part of what we did is exactly what management consulting calls to mind. The rest was more similar to a TME (or perhaps dev evangelist) mixed with a prototyping engineer. I don’t think anyone from our group has ever managed to fully capture the scope of what we did on a resume, and I don’t think we were unique in having roles that don’t fit neatly in the normal job buckets.

Wrapping Up

Experience is hard to quantify, but we often try and force it into predefined categories in order to winnow our candidate list. The goal of this piece was to illustrate some ways in which we can evaluate candidate experience from a more skill-based perspective to gain a competitive advantage in hiring talent. And also to remind us that JavaScript is not the only thing that can be isomorphic.

Acknowledgments: I’d be remiss if I didn’t thank the various people (from very diverse backgrounds, but excellent editors all) who reviewed this, and made incredibly useful editorial suggestions.