I typically represent customers in contract negotiations with their upstream suppliers. That means I do lots of deals with many of the same names on the other side of the table, again and again (Microsoft, Oracle, IBM, etc.)

After over a decade of doing this, I notice that my clients really want the answer to two questions:

1. What are the market standard terms for the transaction?

2. What did we (i.e., the client) agree to in the past?

In big law firms, the answer to these two questions is all too often locked into silos. Either knowledge of past deals is hidden from software because it's buried in MS format binary files, or it's buried in someone's head. It's quite common to see intraoffice communiqués go out by email: "Has anyone done XYZ for ABC in the past?" You might get a few responses...or none at all. It's very spotty, and not a good way to build institutional knowledge. At some firms, there might be a Sharepoint or Lotus Notes "knowledgebase" (ugh!), but those are often next to useless and involve a lot of manual human overhead to maintain.

When people think of technologies to enable deal law practice, they often go straight for document assembly or document management. Document assembly and templating is a bore, IMO. It's an area that is already too full of competitors who are trying to solve problems that I don't actually have. Since I tend to represent customers, I don't usually get to create the first draft of the contract. I've actually built a custom document repository with some nice features (e.g., email dropboxes, etc.) but that's just housekeeping, IMO. The real magic lies elsewhere...

In my view, the "document-oriented" viewpoint is the wrong way to approach these problems. Instead, law firms and their clients should be looking ways to break down the document barriers and convert contracts into seamless, actionable data.

Litigation, and patent/corporate due diligence are currently ahead of my practice area in this respect. My practice area (commercial transactions) involves a completely different set of problems and skills, and is an emerging market for technology applications. I'm biased, but I think my practice is harder to commoditize than, say, searching through millions of emails to find phrase matches or potentially privileged communications.

Since leaving big law, I've worked with other lawyers to develop systems for extracting and archiving the information we need to answer the two big questions: What did the client do in the past, and what is everybody else in the market doing today?

Other areas where we use/develop technology in ways that big firms can't:

- Task assignment systems for delegating work to non-lawyers or offshore lawyers, while retaining a clear, auditable record of who did what. Think project checklist templates similar to Basecamp, but more focused on our use cases.

- Interfaces to our timekeeping APIs (Harvest and Freshbooks) for custom reporting/visualization on how we spend our time. This helps us accurately quote fixed fees for projects, and surfaces interesting data about role in the contracting process.

It's a really interesting area. If you're involved in it at all, get in touch with me. I love talking about it with people who "get it". I'm a coder and a lawyer, so I'm perpetually stuck in both (and neither) of the two worlds of law and coding.