Startup Life

Hey! This is the 2nd post in my “Startup Life” blog series, where I write about my experiences and lessons learned working as a legal operator in the start-up ecosystem. ICYMI, here’s the 1st post about why you should work at a startup at least once in your life.

In today’s post, I’m tackling some tips on how to work effectively with software developers as a lawyer.

…

Working with Software Devs

At a Root all-hands meeting earlier this year, the team was asked a fun question (our usual way of ending all-hands meetings):

If you could switch roles with a colleague for a day, whose role would you choose and why?

As we filtered through responses, software engineer, sales exec, product manager (my pick) and even COO all got mentions as desirable one-day-only vocations.

Then, to my total surprise not one but 2 of my colleagues, both software engineers, said they’d be keen to experience life in the legal team for a day.

I nearly fell off my chair.

Never did I imagine that people who write code and build software for a living would find lawyering interesting and cool.

Mind-blown.

I’ve since pondered about the relationship between lawyers and software developers. There’s usually a tension between lawyers and anyone trying to innovate and build tech stuff. Lawyers playing the conservative, risk-averse foil to maverick software developers, pushing the frontiers of innovation.

But it doesn’t have to be that way.

Being able to work effectively with software developers is an absolutely critical skill to being a good tech or startup lawyer. Even if you’re in practice, chances are that the CEO, COO and CTO of your tech company client will probably have some software engineering background.

Here are 3 lessons I’ve learned about working effectively with software developers as a lawyer:

1. Speak the language

Lawyers love sounding like lawyers.

It’s true. We didn’t suffer through those long, arduous varsity years, reading reams of case law in dank, hidden library stacks only to not casually throw around terms like “mutatis mutandis”, “res ipsa loquitur” and “de minimis non curat lex”.

Like we’re in the corridors of Hogwarts, casting spells on the way to Defence (Attorney?) Against the Dark Arts class.

To the rest of the world, we may as well walk around in long, black robes (Oh, wait…) given how much lawyer-speak normal humans actually understand.

While your sales or finance team will probably tolerate you speaking to them about warranties, indemnities and liabilities, your engineering team definitely won’t. Ditch the verbose lawyer language and just use plain English.

That’s half the battle won.

Learning some basic technical software engineering terminology and concepts also goes a long way, and shows you’re genuinely interested and committed to understanding their work. If you’re at a tech company, this is probably a key part of understanding the business you’re advising on anyway. It also makes you extremely versatile and valuable in any cross-functional role.

Plus, if you can’t give legal advice that your clients can fully understand and put to use, you may as well be practising magic.

Learning dev slang also makes you sound ultra cool. When words like “borked”, “mechanical turking”, “deprecate”, “noob” and “debug” roll off your tongue, you’re on the road to winning at startup life.

2. Find common ground through curiosity

The practice of law and software engineering actually have lots in common.

Both involve complex problem-solving where winning turns on solid logical arguments (premise-premise-conclusion arguments and if-then statements).

If you’re an inhouse lawyer, find a project where you can work closely with devs or your product team and solve problems together. You’ll be able to marry your legal and compliance expertise with their technical ability to build nifty, legally compliant products or solutions together – a great outcome for any tech company.

If you’re a practising lawyer, do a deep dive into how your client’s services or products actually work. Read their terms of use. Find out what’s on their online product roadmap.

They’ll be super impressed that you’ve taken the time to understand what they do.

Be curious, ask lots of questions and always look for opportunities to learn and bridge the gap.

Approaching every interaction with the software engineers in your team or company as a learning moment reaps massive rewards over time. You’ll be seen as part of the team, rather than some ivory tower department to be avoided at all costs.

As an inhouse lawyer, developing those relationships pays off big time during your startup life when the shoe’s on the other foot and you need input from your engineering team (looking at you data privacy risk assessments & security questionnaires).

3. Stop, collaborate and listen

By now, most tech companies have adopted the mantra coined by Mark Zuckerberg: “Move fast and break things.”

The basic idea is that innovation must happen quickly, and if you aren’t breaking things, you aren’t innovating fast enough.

By getting products to market quicker, you’re able to learn more and faster. The faster you learn, the faster you can iterate and improve your product. The faster you can improve your product, the sooner you’ll have a product that the market wants to use and will pay for.

The sooner people are paying for your product, the better chance your company has of becoming profitable and surviving.

It’s this urgency that usually creates the battlefield between lawyers and innovators.

If a simple “Yes, go ahead” will do, software engineers don’t have time for a long-winded opinion in classic IRAC (Issue-Rule-Application-Conclusion) format nor back-and-forth about the balance of probabilities of an edge case risk coming to pass.

This is incredibly difficult to master.

On one hand, you could do your client a professional disservice if you don’t do proper due diligence and give them the full picture. But on the other hand, you’re potentially creating more problems by being unnecessarily risk-averse and blocking progress.

Over-lawyering is the enemy of innovation, and striking the balance is more art than science.

We’ve all been guilty of this before, right?

Be deliberate about managing the relationship

The best advice I can offer is to communicate clearly with your software dev team member/client and pay careful attention to what they’re asking of you (i.e. what’s the job-to-be-done?).

If something is genuinely risky and warrants moving slowly, be explicit about why and think about what can be done to make it less risky. If a decision is very unlikely to kill the company or your client and doesn’t justify spending lots of time debating it, be clear about that too.

This is hard because it means being open and honest with yourself and your team/client about when you feel you’re erring on the side of caution or heading into ‘cowboy’ territory.

All of this probably applies to any advisor-client relationship.

Communicating clearly and honestly gives your team/client a chance to challenge any assumptions you’ve made and correct any misunderstandings. It’s also a far more collaborative way of working that builds a relationship founded on trust.

Bringing your dev team / tech client into the fold means getting better buy-in on key decisions, and ultimately better outcomes. After all, good outcomes make happy clients.

And happy clients make happy lawyers.

….

• Please share your experiences on the relationship between lawyers and software devs in the comments below! Any funny anecdotes get bonus points 😃
• Don’t forget to follow me on LinkedIn for more cool stuff like this, and reach out in my chat if you’d like to connect.