What a portfolio is for: evidence, audience and the shape of the whole

A claim is a statement about yourself: ‘strong analytical skills’, ‘passionate about legal technology’, ‘experience with automation’. Readers have seen thousands of them and believe few. Evidence is something the reader can inspect: a process map with the delays marked, a decision tree with its test cases, a template with a test matrix, a dashboard with its definitions, a one-page recommendation that shows how you reason.

The evidence does not need to be impressive in scale. A small piece of work that is clearly explained, honestly tested and visibly yours is worth more than a large one that is vague. What matters is that a reader can follow your thinking, and that the thinking is sound.

Most readers will give a portfolio a few minutes. Design for that: a short summary at the top, the strongest piece first, one page for each case study and easy access to more detail for those who want it. Assume that the reader is clever but does not know your field’s vocabulary, and that they have seen many portfolios that say a great deal and show little.

If you have worked through the Legal Engineer Program, you have made a set of pieces.

Do not worry that the examples were set exercises. A portfolio that says ‘this was a course project on an invented company, and here is what I did’ is honest and perfectly usable. The pieces show how you work, and the best of them can be extended into real projects as you find them.

You do not need to show everything. Choose three to five pieces that, together, tell a coherent story about the kind of work you want to do.

• Lead with your strongest, the piece you would most like to talk about.
• Show range, but with a thread. For example, ‘from finding the problem to showing the result’: an assessment, a redesign, a tool, a measurement.
• Match the reader. For a legal operations role, put the process and data pieces first. For a legal technology role, the document automation and AI workflow pieces. For a knowledge role, the playbook and clause library work.
• Include one piece that shows judgement under uncertainty, such as the AI design with its risk check or the data report with its caveats. Readers value evidence that you know the limits of your work.
• Leave out weak work. A poor piece weakens a good portfolio more than its absence would.

One powerful approach is to tell a single story through several pieces: the same invented organisation, followed from the opportunity assessment through the redesign, the template, the dashboard and the AI-assisted review. A reader then sees not five exercises but one project. Module 3 shows how to shape this.

A legal engineer’s portfolio carries risks that other portfolios do not. The rules are simple and they must be kept.

• Never show confidential material. Client documents, an employer’s internal data, real contracts and real names must not appear in a portfolio unless you have written permission, and even then think twice. Use invented or properly anonymised material.
• Check who owns the work. Work done for an employer or client may belong to them. Ask before you show it, and describe it in general terms if you may not show it.
• Do not breach privilege or professional duties. A lawyer who displays a client’s matter, even without a name, may breach confidentiality if the matter can be identified.
• Say what is invented. Label exercises and test data as such. A reader who discovers that figures you presented as real were invented will doubt everything.
• State your own part. If you worked in a team, say what you did. Credit the others.
• Do not overclaim. Describe what you did and what you measured, and no more. ‘In a pilot of 40 test cases, drafting time fell from 60 minutes to 10’ is honest; ‘revolutionised contract drafting’ is not.
• Remember that a certificate shows that you completed learning. Present it as that. The portfolio shows what you can do.