Sarah Cottrell: Hi, and welcome to The Former Lawyer Podcast. I'm your host, Sarah Cottrell. I practiced law for 10 years and now I help unhappy lawyers ditch their soul-sucking jobs. On this show, I share advice and strategies for aspiring former lawyers, and interviews with former lawyers who have left the law behind to find careers and lives that they love.

Okay, so today on the podcast, I'm very excited to have a returning guest. That returning guest is my husband, Ed Cottrell. Would you like to say hello?

Ed Cottrell: Hello.

Sarah Cottrell: So, Ed has been on the podcast a couple of times before. We'll link those episodes in the show notes, and you can hear all the things about his story—about becoming a lawyer and leaving law—in those episodes. But do you want to do a brief introduction before we jump into what we're going to talk about today?

Ed Cottrell: Yeah, absolutely. As Sarah said, I've been on the podcast a couple of times before. My story is: we met in law school, we both graduated at the same time, and we went to the same firm, which was happenstance, but also fun because we get along.

I really enjoyed being a lawyer for a while. I realized after about two and a half, three years that I probably didn't want to be on the Biglaw partner track. It took a while to figure out what I did want to be on.

Eventually, I ended up in a role at a court where Sarah also worked—again, kind of happenstance, kind of not, but again, fun. And then I found myself in a job that was titled as a senior attorney but was actually more of a software development and software implementations role.

I had actually thought about leaving the law entirely at that point, and that role just fell into my lap. But eventually, it turned into a traditional lawyer job—they wanted me to work on pharma witnesses, and I got out.

Now, I work at a legal tech company called Ironclad. We do contracting software—contract lifecycle management—and I work on the implementation side of that. That's where I am.

Sarah Cottrell: Okay. Yeah. What we're going to talk about today is something that comes up a ton. I work with so many lawyers who have at least an interest in exploring jobs in tech in some way.

Of all the potential career paths, it's one of the ones that I think, for many lawyers, feels the most opaque—often because someone became a lawyer because they were like, "I don't enjoy math," or, "I don't enjoy science," or whatever. "I like writing and reading, and therefore, the grad school I should go to is law school." So, a lot of people who become interested in moving to tech don't necessarily have any technical background, although some do.

Then also, Ed’s been on the podcast, and of course, he has lots of lawyers reaching out to him, asking, "How do I get a job in tech? How do I get a job in tech if I'm not someone who I think of as being particularly technical?"

The same questions come up over and over, so I thought it would be helpful for people who listen to the podcast to hear your spiel about: If you're a lawyer who's interested in tech, what does it look like to pursue a job in tech? Where would you like to start with that? Because I know you have lots to say.

Ed Cottrell: Yeah, so I definitely do get contacted pretty frequently. I think at this point, I probably do at least a couple of informational interviews with people every month.

It is typically people who have a legal background. Many times, they've started exploring a tech role in some way—maybe they're already in a coding boot camp, or they took a comp sci class back in the day and thought it was fun, or whatever. The questions I get are often: "What is legal tech, even?" Because it's clearly not limited to things like the West-law interface that you might have used as lawyers. "What is legal tech? What's the universe of that?" Then, "What are the different kinds of roles? What do I have to know to get into one of those? Am I totally hopeless because I didn't get a CS degree and started coding when I was 10?"

The answer to that is no. Legal tech is huge. You do not have to have a CS degree at all. You don't have to have any experience with coding at all to get into legal tech. I'm kind of a weird bird—I started writing software when I was six, which is a really long story. But I don't actually do that as my day-to-day. I do write some software as part of my job, but that's not my job description. I don't have to do any of that. I just do it because it makes my life easier.

A lot of my colleagues have zero coding experience, and you do not have to have coding experience. That's important for people to understand. I can talk about different roles or how to deal with this.

Sarah Cottrell: Well, the one thing that came to mind as we were talking was also, I think some people have questions about—like, maybe I'm interested in moving into legal tech because it feels legal-adjacent but also potentially just tech in general. So maybe as we're talking, you can speak to what distinctions, if any, might exist there.

But maybe I'm trying to think—if you're talking to someone, what is the next thing that they're like, "But what about this reason that I can't do this job?"

Ed Cottrell: Exactly, exactly. Yeah, the first question I get is, "Is it even possible for somebody like me?" Which, again, typically means a lawyer with some tech interest, some tech exposure, but not someone who has 10 years at Google under their belt—which, by the way, almost nobody has starting out. That's not how it works.

So, the answer is yes, you can totally do that. The important thing to understand is that, as Sarah says all the time, as a lawyer, you have all kinds of marketable skills. In fact, lawyers and people in most tech jobs, especially programming, actually think somewhat similarly in a lot of respects.

For example, if you are a lawyer and you're drafting discovery requests, you ask the big question. Let's say we're doing a request for admissions, you say, "Admit that such and such, admit that you were at such and such location on such and such a day," or whatever it is that you're interested in.

Then, you try to drill from there into the next thing. You ask yourself the question in your head—and maybe on paper—"What if they say yes? I admit that." "What if they say no? What do I push on next?" You're doing this decision tree—if this, then that logic. Then you're doing a repeat of that. You're doing the loops.

It's actually very similar thinking in many ways. But lawyers don't translate it to code, and coders don't translate it to law, obviously. There's a gap there. What matters, though, is you have these marketable skills of thinking analytically. I’m used to managing projects, managing budgets and people, and so on, and you know how to write, and communicate. All of that translates perfectly to a lot of different jobs. But the question is, how do you market yourself?

Legal tech for many lawyers is actually more accessible than tech in some broad, vague sense. Like, it's hard to jump from being a lawyer to a job at a company that does educational videos that have nothing to do with law because people see you as less connected. Your resume doesn't scream tech; it screams law.

If, on the other hand, you can say, "Hey, I understand the law side of things, and I want to work on something involving contracts or something involving e-discovery," it clicks more in people's brains. It's just easier.

So, legal tech. What is legal tech? Legal tech is huge. Legal tech is your e-discovery platform. It is Westlaw. It is the software I work on, which is contract generation, approvals, signature, and management. It is anything you can think of that would make a lawyer's job easier—whether that's in-house, at a firm, or at a government agency—or anything that would make things easier for people adjacent to the law.

That could be, like, a guardian-ad-litem type role, someone working with the courts, or somebody at the courts working on opinions. Any of those kinds of things qualify as legal tech.

Sarah Cottrell: I think one of the things that people often think about as they're considering, "Do I want to go in this direction?"—part of this is a very lawyerly thing, it's the sense of, "Okay, I hear you that I don't necessarily need to have a technical background. But if I wanted to go out and acquire some type of skill or certification, what would those be, and in what context would I actually benefit from them?"

I say this because—I'm sure this is no surprise to anyone who has listened to the podcast for any length of time—lawyers feel there's a lot of safety in, "I'm going to take a class," or "I'm going to get a certification," or "I'm going to whatever."

And so, I think a lot of people who are thinking about tech sometimes create artificial barriers for themselves because they have this sense of, "Well, first, I need to do these 17 things, and then I can start thinking about this." Can you talk a little bit about that?

Ed Cottrell: 100%. We're good at that. We're really good at finding the issue or the problem.

Sarah Cottrell: I include myself in this group of people.

Ed Cottrell: Yeah, so the first question I get, once we get into "What's out there? What can I do about it?" is, like Sarah said, "What can I do? What's my next step? What's the path?" Often, that's coming from somebody who is already in a boot camp or thinking about a boot camp or something.

I want to preface everything I'm about to say with this: You can never go wrong by learning to code in today's world. Learning to code is great. You can also never go wrong by playing with AI and learning how to write prompts to get something useful out of ChatGPT rather than something useless—or whatever tool you're using.

Those are both invaluable skills no matter what. A boot camp can be very helpful for someone who is just starting out, who had that CS class years ago—even in high school or something—but can't remember anything and wants to learn something like JavaScript or Python. That can definitely be helpful.

But it's not going to get you a job by itself. It's important to understand that. People think that's a magic wand. It's not. It's not like a law degree where, if you're at the right school at least, people show up to interview you because they're looking for you. You still have to do all the legwork.

If you don't know how to program and you want to become a software engineer, yeah, you gotta go do something—take a boot camp, do some self-study, start putting together some sample projects, even small ones. You gotta do something if you want to learn an entirely new skill set.

If, let's say, you're not interested in writing software, but you want to work in legal tech and you're really interested in, say, the product side of things—bringing the user perspective, which is probably a lawyer’s, to how a product is designed and what features are important—that's a totally different skill set.

You may well actually be able to get an introductory job in that space without having done any training because you already understand what it is lawyers need. You already have the kinds of analytical and discovery skills—drilling down, asking the important questions, figuring out where, when you talk to a legal client, figuring out where their documents are, what subsidiaries you have, or when you did XYZ, who did you email about that, who else knows this information, you have that kind of instinct on how to drill down and get to the core of something. That's what you need for that role.

It depends. If you want to learn to program, learn to program. Absolutely, don't let anybody stop you. But don't feel like you have to go learn to program and also have 25 GitHub repositories set up or something before you can even start applying for jobs.

In fact, don't even start worrying about applying for jobs or even worrying about the boot camp. The first thing you need to worry about is probably starting to talk to people—reach out to people, do informational interviews. You will find that there are a lot more tech jobs out there, and types of jobs, than you ever realized.

The one that is most interesting to you may not even be what you thought. It may not be writing code; it may be implementing software like I do. It may not be implementing it; it may be product. Or it may be design, which is more the visual elements. Or it may be product marketing. Or it may be community building, where you're not working on the tech at all, but you're the person taking that tech and presenting it to your former colleagues who are now lawyers, and you’re not—explaining to them why they need this and how it's going to change their practice.

Tons of different possibilities. So don't get tunnel vision—that's my advice. But absolutely do dive into something that interests you and see if it's something you want to pursue as a new career.

Sarah Cottrell: So, that made me think of a couple of different things. One is that I think it might be helpful to just briefly talk about the different buckets of possibilities. For example, there's product, there's implementation, there's marketing, there's sales. These are all very different types of roles, generally speaking.

Well, to start, do you want to just do a really quick summary of what people are doing in those different buckets?

Ed Cottrell: Yeah, so let's talk real big anatomy of a legal tech company. Depending on the size of the company, whether it's venture-backed and all that, some of this will vary in terms of sizes and so on.

But the big pieces of a legal tech company, you can think of as the go-to-market or GTM side, that's sales, that's all kinds of customer service-type roles. That includes things like support, implementations, and all the people who work with the customer, basically.

Then there is the EPD, or engineering, product, and design side of the house, which is—like it sounds—the software development, the product design of what we’re actually going to build. Then there's the design piece, which is what does it look like? How does it feel? What are the user interfaces? That kind of stuff.

So, go-to-market and engineering, product, and design. Then, of course, there are all the ops pieces. I mean, just like any company, you have finance, you have legal, you have legal ops, you have events and facilities, and all those kinds of things. Those are all possibilities, and they're all in the same legal tech space, but those are the big things that you're looking at.

That’s the first question you want to ask: Do I want to work on the tech, or do I want to work with/about the tech? Maybe you're really, really good at sales and connecting with people, and you actually are most excited about translating how this is going to change somebody's life into words—into phone calls and reaching out to people—and getting rewarded proportionate to your efforts rather than on a fixed salary. Maybe sales is it.

Or maybe you don’t ever want to talk to anybody ever again, and you don't want to do a discovery-type drill down on anything ever again, and you just want to go write code—knock yourself out. You're still going to have those kinds of meetings, but it’s less customer-facing. So, it just depends on your instincts and which way you want to start looking.

Sarah Cottrell: Yeah, and I just want to emphasize what I mentioned a little bit ago, which is ultimately, the way you figure this out is you have to talk to people who are doing these jobs and find out what they are doing in their day-to-day and have enough awareness of yourself and your set of skills, strengths, personality, values, all the things we talk about—to know whether the things that they are describing are actually things that you have an interest in and really want to do.

Because sometimes, at a high level, people will say, "Oh yeah, it sounds really cool to be involved with creating something or designing something." But then the actual day-to-day of someone who's doing some piece of that design work or some piece of that production is actually not something that is a fit for all kinds of reasons. Literally, the only way to figure that out is to talk to people.

Which, I understand. I know because I've worked with many, many lawyers at this point going through this process. I know that for most people, they're like, "Oh my gosh, informational interviews. I don't want to do it. It feels awkward," whatever.

I think also, people often think it's not going to be productive. But it has just been demonstrated to me over and over again that it is almost always more productive than people even think it's going to be. You don't have to have a million people to talk to to start. You literally just have to figure out one kind of role you're maybe interested in and one person who does that role and start there.

But, I think as lawyers, many of us are like, "I want to create a perfect mental model of the tech job that I want to apply for, apply for it, and completely cut out that human interaction piece." Which, listen—I get it, to be clear, I get it, okay? But that is what you need to do.

If you're like, "Oh, sales sounds interesting, and ops sounds interesting, and product sounds interesting," that's great. Amazing. Please talk to people who are doing all of those roles because that's how you're going to figure out what you actually are really interested in.

Ed Cottrell: Yeah, 100%. I think lawyers tend to forget this. We think of networking as super important when we're practicing, mostly for business generation. You're trying to build that book of business and make your case for partner, or make your case for equity, or just get more shares if you're far enough along, whatever.

Networking is obviously important, but we don't tend to think about it when we’re lawyers so much in terms of my next job. Weirdly, lawyers are actually not called upon that much to make a case for why they should be employed at a certain job.

If you're going from firm to firm, for example, your seniority matters more than almost anything. Whether you're in the same practice area—like tax to tax or litigation to litigation—matters more than almost anything. You don't really find a lot of people who are like, "Yeah, I've been doing tax for seven years, but I really would like to switch to this niche environmental law section at a different firm." People just aren't making that case. We're too self-limiting for that. We filter ourselves out. That just doesn't happen.

In the non-legal world, networking is everything. On Sarah's point about informational interviews, I actually applied for my current role. I'd met a couple of recruiters, I talked to them, it sounded like a good fit, they seemed excited about me, I was excited about them. I applied—and crickets.

Just because I was curious, I reached out to somebody who happened to have been a guest on Sarah’s podcast and said, "Hey, I know you have this current role. It doesn't seem like I'm going to be getting this one, but I'm just curious. Can we talk?"

And I did an informational interview with her. Lo and behold, I got a call for an interview—I think it was about an hour later. Networking is everything. I've helped people I knew, who were also lawyers, get different tech jobs, even at companies I don't really have any contact with, but I knew somebody who was there. Networking is everything.

Reach out to people. Most people, especially people who have been in your shoes—or hopefully, your future shoes—of having been a lawyer and knowing what it's like, are very willing to give you the time and talk to you.

It’s not, "Prove to me that you should be here. Prove to me that you are worthy of entry into this special new former lawyer realm." It’s, "No, I want to help you. I want to answer your questions because they're all questions I had at some point in the past." So, absolutely, network.

I was going to say, do you want to talk about what the kinds of roles are? Because I think that the different labels on roles and the seniority levels are very confusing to people, and I hear that a lot.

Sarah Cottrell: Yeah, let's talk about that because that's something that people often run into, even when they're just trying to look for, "What is the job that I'm looking for? What is the title?"

Ed Cottrell: Okay, so first couple things to note—words mean a lot in job titles, but they are not everything, and you really do have to look at job descriptions.

What I strongly recommend people do before you start applying for anything is poke around. Personally, I've done this a lot on LinkedIn. I find it works really well for this. You search for things that you think you might be interested in. Like, "I like JavaScript and I want to be a software developer," so maybe I search for JavaScript and see what comes up, see what job titles are there, see what job descriptions are there, and keep refining those searches to filter out the noise—because you're going to find a ton of noise.

That's the first thing: just figure out what your keywords are. That said, it's really important to understand what the titles themselves generally mean because they do generally mean something.

An engineer role of any kind means somewhat technical. That seems fairly obvious, right? But different engineering roles mean different things. If it says "software engineer," that generally means programmer. If it says "security engineer," that doesn't necessarily mean programmer, but it probably involves some programming. It probably involves a lot of configuration of things.

If it says what my role is, for example, "legal engineer," that can mean a bunch of different things at different companies. But in my role, it means mostly implementations. I'm very hands-on, but I'm configuring software, using the tools in the browser—the same tools that your end user is, not as technical, we'll say—but I'm configuring things to work a certain way. I'm also doing a lot of handholding and talking and education. You really have to look at the job description to figure out what that is.

If you see something like "designer," there's obviously a design component. One of the very important things to understand, though, is word order matters a ton as well. For example, if you see "customer success manager," that is a role where you work with customers and you make sure that they are happy. You're managing their success. If you see "manager of something," like "manager of customer success," that means you are managing people.

Generally speaking, "manager," "director," or "vice president," something upfront implies that you are the manager of that people group. At the end of something, it would imply you're the opposite. Regional assistant manager versus assistant to the regional manager—it matters a lot which order those are in. It's that kind of thing you want to look out for.

One more thing about that—this is one of the major gotchas that people get confused by, and I've had a lot of people reach out to me about it, people are in a bootcamp or something, and they're applying for "staff software engineer" roles and getting crickets, and they wonder why. "Staff," I think, to most of us sounds like an entry-level type role. But "staff" in many contexts, including software engineering, is actually a very senior role. It's somebody 10 years in or something like that, usually.

So, it's important to know levels. If something says "junior" or "senior," that's probably something you can figure out fairly easily. But roles like that tend to go: junior, then no prefix (just "software engineer"), then senior, then you go to staff, then you go to senior staff, then you go to principal, and maybe chief architect and that kind of thing.

But the point is—staff is high up on the list. If you're applying for staff roles because you took a coding camp or a design boot camp of some sort, yeah, you're going to get crickets. So, it's important to know.

Sarah Cottrell: Is there anything else about titles that you end up talking to people about?

Ed Cottrell: Those are the big ones. Again, you have to reach out to people because what it looks like on paper may be very different. I also tell people, this is important, ignore—again, we're not talking about senior roles here—but ignore for junior roles, especially all the details of what it says, like, "You must have X experience with whatever tech," or something like that.

I, back in the day—I'm dating myself a bit here—but back before law school, actually, I applied for a job that said they wanted 25 years of experience with a certain database. That database had existed for three years. They wanted, I think, 30 years of experience with a language that I knew had been around for about six or seven years.

Some of those descriptions make no sense. They've gotten better over time. Generally, it's more the people in the function who are writing job descriptions than it was, say, 20 years ago. But there's still a lot of that nonsense. Just because a company works with a certain tech stack doesn't mean you need to know that stack. They may say, like, "Required experience with JavaScript," and they don't actually care if you know JavaScript so much as you know some programming language.

Or they may say something like, "You must have experience with all these different database systems," or something, and they may not actually care as long as you know what a database is for an intro role. Because you may not even be touching that—you may be front-end and doing stuff in the browser that it doesn't really matter what database somebody's using.

It's important to know which words matter. The words in the title matter. The words in the description about what you'd be doing every day—are you writing code or talking to customers?—those matter. Individual tech stacks and pieces of technology? Probably not.

Sarah Cottrell: Okay, I want to talk a little bit specifically about implementation roles because I think implementation roles in legal tech particularly are often the roles that lawyers are best suited for and, in many cases, might enjoy the most. However, they are also client/customer-facing.

And I know you know many lawyers have been utterly traumatized by clients—having clients, the client demands that you experience in the legal profession. For a lot of people, they have this sense of like, "Working with customers or clients is this. This is the universe of the experience, and it's terrible, so I don't want to do it."

Can you talk a little bit about that? Because I think there is often this sense of, "The way it is to work with a client as a lawyer is the same as it is in other professions," and I think there are parts of that that are true and parts of that that are not true. You want to talk a little bit about that?

Ed Cottrell: Yeah, so, people are people, and you're going to find all types in every role. But, as I know Sarah talks about a lot, the legal world is not normal. Legal jobs are not what everybody deals with. It's not just "Suck it up, all of adulthood is rough." It's not like that.

There's a big difference between a “client-facing role” in a law firm and a customer-facing role outside of a law firm, for example. If you're in a law firm—let's say you're in litigation—why is somebody talking to you as a lawyer? Probably, they're having a bad day or maybe a bad decade. Something's gone wrong, and they are trying to sue somebody about it, or they're being sued.

Maybe they individually have a very small role to play, but they're on guard. They're worried, "What if I say something wrong? What if I misrepresent my company? What if some document comes to light that I wrote 'so-and-so is an idiot' and that shows up on The New York Times?" They're not having a good time.

That's true also if you're doing a deal. You're friction and a box to be checked if you're doing due diligence or trying to work out some terms of an agreement. People who talk to lawyers are not in the best frame of mind, and they're probably unhappy—well, about how much they're paying you, honestly. That's not the best kind of customer interaction.

On the other hand, when you are working in, say, implementations at a legal tech company, if you're getting paid to do that—which, what are you doing if you're not?—but if your company's getting paid to do that, it's because somebody sees this as a net gain for their company. They want to do something, and they realize that you have expertise that they can benefit from.

That attitude is different right off the bat. The people group you're working with is different. You're generally not working directly with lawyers on everything. All the lawyers are in the mix, but the lawyers you're working with are mostly in-house lawyers. They've gotten to a happier place.

So, they're often very busy, and they're looking for things that make their lives more efficient. You're not another box to be checked or a case to be managed. You represent going home at five next Friday, twenty Fridays from now, or whatever it may be. You offer them a better life, and they're happy to talk to you.

They want you to solve their pain. They will appreciate—this happens all the time—I get appreciation that I have some insight into what the lawyers are dealing with when they may feel like nobody else on the call does. Maybe it's a bunch of finance folks or procurement folks, or something, and legal is sitting here thinking, "Well, yeah, but what about my such-and-such attachment?" or "How much of a pain is it to insert this clause?"

I can bring some light to that and say, "I bet you, employer so-and-so, I bet you have this problem because I see other customers with that problem." They're like, "Oh, that's a good point." You have this rapport that you just don't have when you're trying to do due diligence, figure out discovery requests, or figure out who your next witness is. It's just not the same at all.

Sarah Cottrell: What you're saying is being a lawyer is uniquely terrible.

Ed Cottrell: Being a lawyer is uniquely terrible. Yeah, it is a lot easier to deal with people. There are some things about my job that are similar. I do actually keep my time. I don't love that. But it's not these point-one increments, and it actually almost never is sent to a customer.

My scenario is just the company needs to know, for somebody who's in an implementation role like I am, how much are they putting on me. How busy am I with this project or that project? As projects wind down or ramp up, or whatever's going on, they know—are they using me right on this project? Can they put me on another one? Do I have bandwidth to be on this internal initiative? That kind of stuff.

Sarah Cottrell: Yeah, I mean, I think what I would say I've observed is it's actually being used the way you would hope people would use that, which is to say, "Are you doing too much? Do we need to reallocate? Is this customer asking for too much?" As opposed to just like, "We'll just bill as many hours as possible and we will take as many no matter what."

Now, obviously, that's your experience. I can't speak to every tech company in existence. You know, we do exist in a late-stage capitalist hellscape, it’s that piece of things. But I think that tracking hours is not about hitting a target.

Ed Cottrell: Yeah, I have no target on total numbers for the year. We do have targets, but they're not even my target—they're my management's target in the sense that they want to make sure that they're using people for the jobs they were hired for and that people aren't just totally slacking or something.

Depending on your level of seniority, you may be expected to do somewhere in the range of 60 to 70, maybe 75, but probably 60% to 70% "utilization," meaning customer-facing in my role. I personally am expected to be around 60%. Practically, I'm a little higher than that now, but I'm expected to be on a customer project as opposed to internal stuff about 60% of my time. Which does not mean I bill 2,000 hours a year and then have a ton of overhead. It means 60% of roughly a 1,900-hour year. You do the math here.

My firm, my company, and a lot of companies, we have a "take it as you want it" vacation policy. There's no particular cap, but people will actually get lectured a little bit if they don't take at least a couple of weeks a year of real vacation time. Not like, "I need to go to the dentist"—that doesn’t count—like real vacation.

Most people take three-plus, four-plus, depends on what you can do with your work and keep up with, but the point is, you end up with 1,900-ish total hours that you're working in a year, and I'm supposed to be on customer projects about 60% of that. I'm not supposed to be working 45, 50 hours a week.

Yeah, occasionally I do. I'm supposed to account for 40 hours of my time, but that can be, "Hey, I was out of office for an hour." Yeah, it's way chiller. I do keep track of my time, but in quarter-hour increments, and most days, it's like an hour for this phone call and two hours for this internal work and two hours for this customer work. It's pretty big numbers, and nobody's panicking about whether it's right to the point one.

Sarah Cottrell: Yeah, I think it's really helpful for people to hear this because, as lawyers, we have a certain vocabulary, and words mean particular things. If you tell someone—if someone sees that, in a particular role or hears in a particular role that they are going to have to track their time—understandably, most lawyers who have been traumatized by the billable hour model are like, "No, thank you. Get me away."

Ed Cottrell: Yeah. I probably still overdo it, honestly. I've been told that my time entries are among the most precise of my colleagues because I just can't force myself to block bill as much as some folks do.

But again, it's only really for tracking. I could get away with putting down X hours on such and such a project and vaguely listing "worked on this workflow" or "workflow and meetings." That would actually not cause anybody a real heartburn.

Sarah Cottrell: Yeah, we just have big oldest child energy the whole year in the Cottrell household. Okay, so are there any other questions that people regularly ask you that come up a lot or that you end up bringing up particular things because you think people need to know?

Ed Cottrell: Yeah, I mean, so usually about this point in the call, after I've brain dumped all that, people come back to, "But now what?" Because lawyers really want to know, "But now what?"

Again, the answer really is, do informational interviews, explore stuff. I mean, you don't have to sign up for some super expensive boot camp to figure out if you like programming. Search for an online programming tutorial or something like that—"Online JavaScript tutorial," whatever you think sounds cool. Do a couple of lessons.

If you're like, "It is so cool that I typed these things on the screen and it made 'Hello, World' appear somewhere," and that makes you happy—hey, good news. You may have found something that works for you. Or if you're like, "It took me an hour and a half to figure out how to do it, but I figured out how to sort this weird thing that's not as simple as sorting something alphabetically—it's more complicated than that—but now it works, and I'm so excited about it," cool, you found something.

If, on the other hand, you're like, "I could never, ever do this. Also, Git is scary, and GitHub is whatever," and you have that gut reaction—yeah, okay, probably don't make coding your main thing.

On the other hand, if you take a design class—get on one of the online course sites or something, maybe pay 40 bucks for one, spend an hour learning how to design something, spend an hour learning how to use Photoshop or whatever—and you're like, "Oh man, I could do this all day," congrats, you found something that might work for you.

Two things: informational interviews and poking around. See what calls to you. Do you like looking at code? Do you hate looking at code but love poking around and figuring out how to break something? Maybe security is for you. Do you love design and layouts? Hey, design. Are you like, "I hate all that, and I just want to make some lawyer's life less miserable?" Legal ops, man.

There are all kinds of options for you that do not involve, "I have to go through some bootcamp and learn 25 different database systems" or something like that. Nobody has to actually do that. So just explore and talk to people and do not be afraid to reach out.

Lawyers, like I said—if you're talking to somebody who’s not a lawyer, I get this all the time, people are like, "You're so interesting. You used to be a lawyer, and now you're here," from the non-lawyers, I'm like, "I'm not that interesting, but thanks." You're an odd bird. You're an interesting side quest for somebody during their day if you're talking to a non-lawyer. If you're talking to a former lawyer, they're like, "Yes, let me help you because that sucked, and I know where you are, and I want to help you out."

Sarah Cottrell: Yeah. Okay, on vocabulary, can you briefly—so, I know what Git and GitHub are because I'm married to you. As we tell our couples therapist, we both want to live in each other's brains.

Ed Cottrell: Yeah.

Sarah Cottrell: But I'm sure there are a lot of people who are like, "What was he even saying?" Like, do you want to literally spell it?

Ed Cottrell: Yeah, so Git is G-I-T. It's an old English word that means "jerk" because the guy who wrote it thought of himself as a jerk. You can debate whether that's right, but he was like, "I need a good, funny name that's easy to type—Git. G-I-T."

GitHub is now a Microsoft company, but it is the de facto place where programmers store their code. That's true whether you're a solo person working on something or a gigantic corporation—most have repositories.

A repository is just, again, a place where the code goes for a particular project. This is the kind of thing that if you are interested in the technical side, this will excite you. If it doesn’t, I apologize for the next 20 seconds.

I bet it used to be that programmers, in the bad old days, had to use tape to cover over a hole they punched in a card by mistake. In my bad old days, it was, "I made some changes, but I'm not real sure about them. I'm going to make a copy of my entire project in a different folder in case I screw this up."

Git lets you do what's called concurrent versioning. As in, I can go work on one piece or feature of the product, Sarah can go work on something that is probably completely unrelated but maybe touches on some of the same things, and there's a way to bring that work back together. Then we test it and move all that work that we've brought together from both of us into a different branch for somebody to do other kinds of testing. Then we move it into another “branch,” and that is what actually ships out to our customers.

If you're into that kind of thing—if you're into, "Hey, let's go do cool stuff and then figure out how to bring it all back together and figure out, oops, I accidentally changed something you were relying on"—if that stuff is cool to you, yeah, programming is fun. If you're like, "Oh my goodness, I could never," well, maybe not.

Yeah, it's just one of those things. If that speaks to you, great. If it doesn't, it's by no means the only job. I mean, again, we have a lot of engineers at my company, for example, and I think we're pretty representative in this respect. Even though it's a lot, it's well less than half the house. I mean, engineering, product, and design as a whole is only about half the house, maybe a little less. There are tons of roles that are not as techy. There are more customer-facing or community-facing or events—whatever it is that calls to you.

Sarah Cottrell: Okay, so is there anything else that you think lawyers who are interested in tech need to know?

Ed Cottrell: Just don't be afraid. You really do have marketable skills. I mean, you're a lawyer—I'm going to go out on a limb here and say that your PDF of your resume, and the underlying Word doc or Google doc, whatever you do, are probably formatted better than 99% of what business people can do.

You're actually a power user, more likely than not, whether you realize it or not. You have a lot of technical aptitude. If you're surviving as a lawyer in 2025, you have a lot of non-technical skills that translate to any job. If you are able to present yourself as a lawyer, you will 100% be able to present yourself as somebody who should be in a tech role.

You can explain it, you can say, "Look, these are my weaknesses, but I'm good at XYZ, and I think it translates." Again, for those junior-type roles, you don't necessarily have to know exactly what somebody's doing. You're not going to know exactly what they're doing on day one anyway—you’re going to be a little bit lost. So it's okay if there are some gaps. It's okay if you're not already ready to be one of the most senior people in the company. You're not—you don't need to be. It's really fine.

So just don't be afraid. Reach out to people, take a course that seems interesting to you online, dabble in one of the in-browser things you don't have to pay for, and just network like crazy. That's how you'll find something you love.

Sarah Cottrell: Yeah, don't be afraid—and go to therapy.

Ed Cottrell: 100%.

Sarah Cottrell: Also something you should do. It's unrelated, but, you know, never truly unrelated.

Okay, well, thank you for joining me today on the podcast. For everyone listening, you have just heard from my favorite person. And I should also say that if you like Former Lawyer, if it has helped you—it would not exist without Ed. So, thank you for being here.

Ed Cottrell: Thank you for doing it.

Sarah Cottrell: Thanks so much for listening. I absolutely love getting to share this podcast with you. If you haven't yet, I invite you to download my free guide: First Steps to Leaving the Law at formerlawyer.com/first. Until next time, have a great week.