On Monday I was writing about my trip to Oregon. I didn’t mention much about what happened on the ground (can’t) but I can summarize by saying their problems aren’t technical — they’re just a dysfunctional team.
Software, especially software engineering as a discipline, is not a solo endeavor. To be truly successful in today’s market, your product team is going to have to be just that — a team, ideally with diverse experiences and viewpoints.
Now it’s Friday. Since Oregon, I’ve been involved in at least three or four different teams in different organizations. Some are dynamic and high performing, some are slow and methodical, and some are just straight up toxic. Even got into a verbal fight in one such toxic environment just yesterday.
A Lawyer’s Transition to Team Player
It got me thinking about lawyers who want to make the jump to the legal engineer role and be a member of technical teams. It might be a hard transition to navigate.
For context, maybe I should level set with my own experiences. I came to law after about ten years of writing code in small and large companies. Never did actually work for a firm full-time after law school, but I did clerk pert-time for four different law firms while in school and then worked full-time for a federal judge for almost two years.
I admired many of the professionals working in those firms and learned a lot from them. However, the political and organizational skills demonstrated by the lawyers in those environments was very, very different from the skills I see in small, successful software engineering teams.
A Legal Engineer’s Core Teamwork Skills
In this post, I want to highlight a handful of the skills I think are critical for legal engineers, targeted primarily at lawyers making the transition.
One of the first things a new legal engineer may notice is that they’re deeply embedded with a group of other people, sometimes shoulder to shoulder, day after day. There are rarely doors to close where software is being developed.
In these teams of software engineers, product managers, UX designers, and etc., there’s little status within the team, which may be a hard switch for someone coming from a high status profession like law. Here you’re going to be just one of the team, roughly equal to everyone else, except that you may feel intimidated if you’re just coming up to speed on the technology side.
Thus you may find yourself trying to assert your status or value to the team through any number of behaviors. You might be tempted to get defensive, be quick to correct other team members, project an air of superiority, be overly guarded, or, worse of all, become critical of other team members, the project, or the company. Oh sorry, I didn’t mean you, but maybe you know someone from the legal profession who might act like that from time to time when feeling out of place.
Your team is only going to be successful if everyone on the team feels safe to offer ideas, to take risks, and to try things without worrying whether they’ll be called out. “There’s no team without trust,” leads a popular HBR article on the topic of team safety.
Protecting team safety is everyone’s responsibility, not just management’s. That’s because anyone on the team can damage safety within the team. Any “provocation by a boss, competitive coworker, or dismissive subordinate” gets interpreted by our lizard brains as a fight or flight moment,destroying our ability to bring our creativity to the team.
So, as a new entrant to the software industry in this valuable new role, I beg you please, make preserving team safety your first objective.
And if you find yourself in a team where safety is low, lead from the front and be a safe team member.
Openness, Transparency, Vulnerability
If you’re on a safe team, then everyone, including you as a new legal engineer, is free to be open, transparent, and vulnerable.
Unfortunately, these aren’t traits highly prized in the legal profession. Indeed, if you’re a litigator they may actually work against your effectiveness.
Put another way, just because you’re free to begin to embrace these traits, which we all have if we choose to use them, doesn’t mean you’re going to open right up.
So take baby steps.
And know there’s a big reward waiting for you if you can work in a safe team where everyone is open, transparent, and vulnerable. It would feel almost like family, wouldn’t it? And most importantly, the team wouldn’t have to waste much time on office politics and could focus on creativity and getting awesome stuff done.
Resilience to Try, Fail, Learn, and Start Again
The legal profession is famously risk averse — for a reason. Lawyers have to get it right the first time when they’re drafting a major corporate merger agreement, someone’s last will and testament, or filing a points and authorities memo with the court. When litigators make arguments in court, they don’t get many chances to change course or walk back a mistake.
In today’s highly agile software industry, we approach it exactly the other way around. We don’t try to get it right from the beginning.
In the software industry we take a lot of chances. We try things. They fail. We learn what worked and what didn’t. We try again, and probably fail again. But we keep iterating until we get it right.
You’ll shed a lot of anxiety, and it’s a lot of fun when you embrace it.