Editor’s note: Every week I write this newsletter myself. This week is different. Mike Childers, a good friend and one of the sharpest thinkers I know, agreed to be the first guest author of Workforce Rewired.
Mike spent a decade as a labor and employment attorney, then did the rare thing. He crossed over to build the AI systems he used to advise on, and he is now a Principal Product Manager at Amazon. I have learned more from our conversations about where legal, engineering, and product actually meet than from almost anything I have read on the subject. He keeps coming back to the question I care about most in this work: what kind of professional can operate across a boundary instead of guarding it, and what kind of organization makes that possible.
His piece argues that legal review at the end of AI development is already too late, and that the real fix is a design choice made while the system is still taking shape. It sits squarely inside what I write about here: the roles that are changing, the fluency the next decade rewards, and how good systems actually get built. Read it, then tell me who you think should write the next one.
-Christina
TL;DR: By the time an AI system reaches a legal toll gate, it is built, scoped, and approved, and the most a late review can do is flag risk that is now expensive to remove. Mike Childers makes the case that legal reasoning belongs in the room while the architecture is still open, where it shapes what gets built instead of grading it afterward. His examples are concrete: a data store that turns into a misuse vector, a deletion rule that can erase the record of a bad actor, a conversion metric that means two different things depending on how you count it. The through-line is a kind of professional, and a kind of organization, willing to close the gap between disciplines.
A few years ago, before I crossed from legal into product, a VP I supported made an unusual decision: when Legal’s travel funds for client meetings were cut, he started covering my travel to his team’s planning meetings out of his own budget.
We’d been doing this for years when, over dinner in Edinburgh after one of those meetings, he explained his reasoning. It came down to something simpler than most people expect: when legal is in the room while options are being debated, it has full context – the unfiltered version of the problem, including why each design choice was made, what alternatives were considered, and what the real constraints are. That context is rarely preserved when review happens at the end. By then, a complex deliberation has been compressed into a brief, a slide deck, or a ticket, and the information that would have changed the legal analysis has been lost in translation – not through bad intent, but because nobody knew which parts of the discussion were legally significant.
Full context and real-time delivery are not separate benefits. They are the same benefit. Being in the room means legal can give better advice – because it has heard everything – and give it immediately, while the decision is still open. The compound effect is what he was paying for: decision-makers who can focus their finite time and energy on the best of the options in front of them, rather than debating solutions that will fail a legal review or force unnecessary risk onto the organization. They don’t have to decide and then wait for a legal read that may never come. They get the analysis in the room, when it can still shape the outcome.
By the time a decision goes to a legal toll gate, engineers have built it, product managers have scoped it, and executives have approved it. The instinct is to preserve it. That instinct is expensive.
This model – legal review as a gate to clear before launch – made reasonable sense when it meant checking a terms of service or a vendor contract. It makes much less sense when the product is an AI system making consequential decisions about people.
The problem isn’t that legal teams are slow or unsophisticated – it’s structural. The most a late-stage review can do is identify risk that is now expensive or impossible to remove.
There is a better model. It requires rethinking not just when legal gets involved, but what legal involvement actually means in an AI development context.
The Difference Between Reviewing a Product and Shaping One
When legal reasoning enters the development process early – before architecture is finalized, before data flows are designed – it doesn’t slow things down. It changes what gets built.
Consider a system designed to verify identity or detect misrepresentation in a high-stakes context – hiring, lending, benefits eligibility. The instinctive engineering approach is to build a data store, enrich it with information from multiple sources, and make it available to downstream systems that need to verify someone’s claims. Clean, intuitive, extensible.
But that architecture creates problems that compound over time. Every downstream system that consumes the data becomes a potential misuse vector. Each new consumer raises questions about whether the original collection purpose covers the new use, whether data minimization requirements have been respected, and whether the technical access controls match the policy constraints that are supposed to govern them. Purpose limitation isn’t an abstract principle – it’s a design constraint that affects whether you can legally do tomorrow what seems technically straightforward today.
These questions are far easier to resolve before the data store exists than after it has been built into eight systems and three vendor integrations.
Sitting on the product side of the table now, I understand that instinct viscerally – it’s how you build extensible systems. But the legal training asks different questions first: why are we collecting it, how long do we actually need it, what happens when its purpose is served, and how should access rights change when circumstances do. Holding both sets of instincts simultaneously is what makes the early conversation productive rather than adversarial.
The Complications That Only Surface Early
There is a category of design problem that late-stage legal review almost never catches – not because the lawyers miss it, but because by the time they see the system, the decision has already been embedded in a way that makes the right answer architecturally inconvenient.
Data deletion is one of the most instructive examples. The standard legal instinct, and in many jurisdictions a regulatory obligation, is to honor requests to remove someone’s personal information. Build a deletion mechanism, make it accessible, respond to requests within the required window. Straightforward enough.
But in any system designed to detect fraud or prevent bad actors from re-entering a process, deletion creates a tension: if you remove the record of what a confirmed bad actor did, you lose the ability to recognize them when they return under a different identity. The legal obligation to delete exists to protect individual privacy interests. In this context, honoring it literally may undermine the very interests it was designed to protect – and those of the people who would otherwise be harmed.
The answer isn’t to ignore the deletion obligation – it’s to design an architecture that honors the purpose of the deletion right while preserving what is necessary to prevent recurrence: a minimal, purpose-limited retention approach that protects the system’s integrity without retaining more than is justified. That is a design decision, not a legal opinion delivered after the fact.
I now sit on the product side of exactly this problem. When legal is embedded in the design process, it catches that decision before it becomes expensive.
The Metrics Problem
The same dynamic plays out at the analytical level, and this is where the argument extends beyond legal questions into how teams reason about evidence.
Imagine an identity verification system being evaluated for deployment. Simulations show a meaningful drop in a key conversion metric when the system is active. On the surface, that looks like a business problem: fewer people completing the process means fewer candidates, customers, or applicants – depending on the domain.
But conversion metrics can be measured in at least two ways. On a single-session basis, a user who abandons a process midway and returns hours later to finish it registers as both a failure and a success – the metric appears to fall even if the user ultimately completed the task. On a multi-session basis, that same user completed the process and the rate holds. The metric looks dramatically different depending entirely on what you are choosing to count – and if you are making a significant product decision based on the wrong version, you are wrong before you have analyzed anything.
And even if conversion rates genuinely fall on the right measurement, the relevant question is whether that affects the outcomes that actually matter. If the quality of downstream results remains stable, the users being filtered out are likely not ones who would have converted to valuable outcomes anyway. A conversion rate drop combined with stable downstream results is not a problem. It may be the system working exactly as intended.
I learned to ask these questions from years of quantitative work before law school – the instinct to distinguish between a metric that looks alarming and a metric that tells you something is actually wrong. Legal training develops its own version of that skepticism: the habit of asking what evidence actually establishes, and whether an indicator shows what people assume it proves. Both instincts point in the same direction, and both are more valuable when the people who carry them are in the room while the analysis is being framed rather than after the conclusion has already been drawn.
The Organizational Implication
None of this happens automatically. It requires legal professionals who understand how the systems work, engineers who understand why the legal questions matter, and deliberate organizational choices about who is embedded where and what genuine technical fluency means in practice.
In baseball, the relationship between a pitcher and catcher is called a battery – a unified system where expertise has to flow in both directions to function. The catcher needs to understand pitching well enough to call the right pitch at the right moment. The pitcher needs to trust the catcher’s read of the batter and situation well enough to execute it. Neither can do their job in isolation, and the gap between a battery that works and one that doesn’t shows up immediately under pressure. Embedding legal in engineering works the same way. When an engineer describes a data flow, legal should be able to identify immediately where it implicates a retention obligation or a purpose limitation. When legal articulates a compliance constraint, engineering should be able to propose an architecture that preserves the product goal while removing the exposure. The conversation does not stop at the boundary of each discipline – it moves through it. That bi-directional fluency is what turns legal from a toll gate into a genuine design partner.
The question isn’t whether legal should be involved earlier. It’s what kind of professional can actually function in that role – and what kind of organization creates the conditions for them to do it. The answer requires people willing to close the gap between disciplines rather than patrol the boundary, and leaders willing to fund that investment before the ROI is obvious. The VP who paid for a lawyer to attend his planning meetings was making exactly that bet. It paid off – not because legal said no to fewer things, but because the things that got built didn’t need someone to say no.
Mike Childers is a Principal Product Manager at Amazon who spent a decade as a labor and employment attorney before crossing over to build the AI systems he used to advise on. He writes about what happens when legal architecture is upstream of engineering rather than downstream of it. You can find him on LinkedIn.