Lawyers, developers, sales: leading three professions in one team

Three languages at one table

A legal tech product is never created by one profession alone. In both companies I have built and run, lawyers and developers worked hand in hand, and sales took the result to the customers. Three professions, three kinds of training, three ideas of when something is finished. The lawyer thinks in provisions and exceptions, the developer in data models and states, the salesperson in dates and commitments.

My experience: the biggest losses in such projects do not occur within any of the three areas, but between them. Time, money and good ideas are lost in the gap between the professions. Anyone leading such a team therefore has one task above all: to close that gap. And that only works if you speak all three languages.

The lawyer wants certainty

Lawyers are trained to find the exceptional case. That is their profession and their value. A contract, an official decision, a dismissal: everywhere there are constellations in which the rule does not apply. In a software project, this strength easily becomes a brake. The lawyer says "it depends", and the developer waits for an answer that can be turned into code.

I know this attitude from my own work as a lawyer. It is justified, because software that does not know the exceptional case produces wrong results. My task was to show the lawyer that "it depends" is a complete answer if you also say what it depends on. That is exactly the role known in legal tech as the legal engineer: analysing legal processes, designing decision logic and translating law into logic.

The developer wants clarity

Developers need unambiguity. A program knows no grey areas, it either branches or it does not. If you give developers legal requirements in the language of a court submission, you either get follow-up questions or, worse, a silent interpretation that nobody has checked. Both cost weeks.

Because I have been programming myself for over twenty years, I can see early on what can be implemented and what cannot. That changed a great deal in the conversations with the development team. I did not have to ask whether something was possible, but could ask what it would cost. And I could explain to the developer why the lawyer was insisting on an exception that, from a technical point of view, looked like unnecessary complexity.

Sales wants a date

Sales stands on the other side. They have spoken to the customer, identified a need and want to meet it. Their benchmark is closing the deal, and closing needs a delivery date. To them, legal diligence looks like hesitation and a technical estimate like room for negotiation.

As a managing director I was responsible for go-to-market and sales myself, with revenue planning and investor reporting breathing down my neck. So I understand why sales pushes. Even so, I regularly had to rein them in: a promise that lawyers and developers cannot keep costs more later than the lost deal. Conversely, I had to make clear to lawyers and developers that without revenue even the finest logic reaches no one.

Translating is not enough

For a long time I would have described my role as that of a translator. That falls short. A translator passes on what others say. A managing director has to decide when the three professions cannot agree, and for that he must be able to assess the legal core, the technology and the commercial side himself. That is why I lead specialists rather than merely mediating between them.

In practice that meant: decisions were taken where all three were in the room, not in separate meetings. The lawyer heard the technical estimate, the developer the customer requirement, sales the legal limit. What at first looks like a waste of time in such meetings later saves the loops in which one area reopens another's result.

What carries the collaboration

All structure counts for little if the three groups do not respect one another. A company only becomes successful when the people in it are in harmony. That matters more to me than any metric, because the metrics only grow out of it. In a mixed team that means: the developer must take seriously that the lawyer knows a case the specification did not foresee. The lawyer must accept that software cannot reflect every individual case. And sales must live with the fact that a no from development stays a no.

I have learned that appreciation between professions does not arise by itself. It arises when everyone has experienced once that the other's diligence helped them. The salesperson who does not lose a customer because of the legal query. The lawyer whose exceptional case runs cleanly in the product because the developer asked. Such moments arise while working together on a product, rarely in a meeting.