Marianne Bellotti, Author of Hiring Engineers

Len: This interview was recorded on July 21st, 2020.

Len: Hi I'm Len Epp from Leanpub, and on this episode of the Frontmatter podcast I'll be interviewing Marianne Bellotti.

Based in Washington, DC, Marianne is currently Principal Engineer and Engineering Manager at Rebellion Defense, where she spends most of her time thinking about how to build great software engineering teams.

You can follow her on Twitter @bellmar and check out her technical blog at medium.com/@bellmar, and you can also check out some of her great talks on YouTube if you just search for her name.

Marianne is the author of the Leanpub book Hiring Engineers. In the book, Marianne writes about what software engineers need to know when they're tasked with hiring other software engineers, from recruitment to interviewing and making the final hiring decision.

In this interview, we’re going to talk about Marianne's background and career, professional interests, her book, and at the end we'll talk about her experience as a self-published book author.

So, thank you Marianne for being on the Leanpub Frontmatter Podcast.

Marianne: Thank you for inviting me.

Len: I always like to start these interviews by asking people for their origin story. You have a particularly interesting one, I think. So, I was wondering if you could talk a little bit about just where you grew up, and how you found your way into a career in engineering and recruitment?

Marianne: I like to tell people I spent the first 10 years of my career desperately trying not to become a software engineer.

I got into computers, because my father was a computer programmer. And it's funny, because I have compared my experiences - like a young, potential software engineer - to some of my peers. And they all came from environments where their parents actively encouraged them to learn about computers and learn programming - that's how they know what they know.

I came from an environment where my father thought this was the absolute worst thing that could ever possibly happen to his daughter, and was actively putting up barricades as we went. So I basically learned how to hack, by my father constantly trying to keep me away from the computer, and stop me from programming, and me having to bypass different systems to get back on the internet. So that's how it all got started.

And then, when I started looking at careers - I'm from New York originally. I still have really strong ties back in New York City. And until probably maybe the last 10 years or so - when you were a software engineer and you were in the East Coast New York area, you went into hedge funds. You went into finance. You went to big banks. You went to Fortune 500 companies. You didn't really go and start your own company and make millions of dollars. You went into this very different pathway.

And that to me was just the worst possible thing in the world. I was not at all interested in that life or that career. I was very interested in traveling and helping people and seeing the world, and just generally how people self-organized.

So I went into Anthropology and International Development. And then I kept finding these periods where the way I really got myself into the room, was that I also knew how to program a computer - and the organizations I was working for were dealing with a lot of technical poverty. And so they were like, "Oh, can you fix our thing, and we'll let you come to all of the other meetings too." This is sort of how I broke in to ultimately working at the UN and traveling the world, and doing all of these interesting projects - is that I happened to know how to program computers.

And so I did that for a while, and then finally I got to the point where I thought, "Well, maybe I should actually just do this?" Because the industry had really changed by that point.

And so, I would say that I have had moments - like this period right now, I'm in a private sector company. But a lot of my career has been in government, non-profit, third-sector type work.

Len: Thanks very much for that. I'm really interested in talking to you a little bit about the United States Digital Service and your work for them.

Marianne: Yeah.

Len: But before we do that - it's interesting - in some of your talks that I have watched while researching for this interview, you have this interesting metaphor where you talk about how, when encountering legacy code systems, your anthropological knowledge and training actually really helps you. Because encountering a legacy system's kind of like the software version of pottery shards, and things like that. It's really fascinating, the metaphors that people use and the angles that they come at this kind of thing from. I interviewed someone not too long ago who talked about being introduced to some legacy code, as kind of like a crime scene. So you had the like - this idea of a code scene investigator, like a CSI.

Marianne: Yeah, yeah, yeah.

Len: But I really wanted to actually dig into it. How does your understanding of anthropology help you deal with legacy code systems? And if you could maybe talk a little bit about what a legacy code system is, for people who have no idea what that is.

Marianne: Legacy code or legacy systems are essentially software and computer systems that have not been actively maintained. So you could think of them as just old computer systems.

But there are plenty of old computer systems. If people are actively maintaining them and actively contributing to them, then they're not considered legacy.

Legacy's the stuff that's still running in production, but no one's looked at for a number of years. And it hasn't been upgraded, it hasn't been maintained really well - and so now you're dealing with a volume of technical debt.

I actually form a distinction between the concepts of technical debt and legacy code, in the sense that I think that legacy code tends to - because you're not maintaining it, it tends to maintain some sense of consistency. Whereas, technical debt is usually a bunch of short-term thinking decisions that are just piled up on top of one another. But you'll definitely see those two things in the same systems.

So that's basically what I spent a huge portion of my career working on. Because - and it was literally like an "I volunteer as tribute" sort of moment. It's not a thing that most software engineers enjoy doing. Most software engineers actively avoid working on the old systems and the technical debt.

And I genuinely found it really interesting, because I thought about it from the perspective of like - what can we learn about how the organization was at the time this was built, and how people saw themselves, and their role within the organization, and how they saw the customer and the product, and all that.

I found that genuinely interesting, and still do. So it does really scratch an itch for me from an anthropological point of view.

I was rather starkly referred to as "The Technical Archaeologist" at USDS. I would be the one who'd be like, "I want to go figure out why this old system is the way it is, and then come back and tell you why all of this actually makes sense." Whereas everybody else is just like, "Let's just burn it to the ground and build it in something different."

Len: It's so fascinating. Because one thing you talk about is - it's not just the code itself, but there's all kinds of things around the organization that you can see. There's history that you can understand. For example, like, "Why is this code buggy in this particular way?" Well it's because there was just a culture of indifference to that type of problem.

Marianne: Yeah. Conway's law is a real thing.

It's funny to me, because a lot of my writing as of late has focused on people's misunderstanding of Conway's law. People think that Conway's law is some sort of divine mandate that, like, you built it this way, because your org chart looked like this.

But Conway's law is really about incentives, and how people communicate with one another. It's just an understanding that people build things that reflect their current social situation in the place that they're working. And that is fascinating from the ethnological point of view, and just incredibly frustrating from a software point of view.

Len: It's really interesting you mention that. So for example, like you've been - I would say, it sounds like very fortunate in that, because you could make the computers go, you actually got to level up and do more interesting things and get into more rooms.

But I think a lot of people are often in cultures where - if you know how to make the computers go, you get kind of sidelined--

Marianne: Yeah.

Len: And stuck only doing the kind of things that the management views as kind of boring bricklaying.

Marianne: I think that's fair. I think that's also changing though. Because I think that it's - we're building a world and an economy where it is unsustainable for people to not know - to not have a basic level technical literacy.

Somebody reported up to me a year or two ago, who just basically came into a one-on-one and said, "Well, my career development as a software engineer doesn't matter, because I really want to be an environmentalist. I'm just biding my time until I finish my graduate degree in environmental studies, and then I will quit this software job and go off and do those things."

I spent a lot of time telling them about my career, and saying, "You know what? That's fine. If you want to quit your job when you graduate and go work for a non-profit, I'm not going to tell you not to. I think that's great. But right now, you're employed as a software engineer. And so let's focus on making you the best software engineer we can. Because it will open doors for you, that you are going to have a hard time otherwise getting open, because lots of people want to do what you want to do, right? So you're going to have a hard time competing with all of them, and this is an advantage that you can bring to the table."

I think that it'll probably - I hope that there will be more people like me, that have other skill sets and passions, and use technical literacy to open doors, rather than people who are technologists and get the doors closed to them.

I do think that sometimes technologists don't do themselves many favors, because they assume that - there's this sort of general fallacy in American culture as a whole, and maybe Western culture, that like, we have this idea of the genius who's so brilliant that he can literally understand everything - and it's always a "he" - that can understand everything with just like five minutes of perusing it casually.

It does a bunch of people a major disservice, including the people who actually are that kind of smart. Because it encourages them not to respect other people's domain expertise. And then people get territorial, and they close doors to other perspectives, because they are so worried about being made to look stupid, or being disempowered in their own discipline, that they don't embrace a multidisciplinary approach.

I also spend a lot of time encouraging people to like seek out other perspectives. I've been spending a huge amount of time trying to bring more and more design into my engineering teams. I tend to work on more backend-focused teams.

Right now I'm doing core services. Before that, I did a lot of infrastructure SRE-type engineering work. The general conception of this work is like, "Why would I need to work with a designer, I don't have an interface." And I'm like, "You do, it's the command line tool." It's like, "You have interfaces everywhere. And you make design choices everywhere." And those design choices affect how a system scales, and what kind of problems we're going to have. And so these are really, really interesting perspectives, to sort of try and find out how we're going to integrate and bring to the table.

Len: Thanks very much for that. There's a lot to unpack there if we wanted to go into every detail. But I just wanted to say it's funny you mention that - the problem with the notion of the genius. I've got kind of the opposite preoccupation myself, which is the trust that people have in common sense. So like, "Explain coronavirus to me." Like we really do talk this way in our normal, everyday lives - like everything can be understandable in five minutes, or something like that.

But I wanted to actually dig in a little bit to what you were just talking about at the end there, about how design is actually important, even for people who are working in software in the backend. There's a talk that you have on YouTube that I can link to in the transcription of this interview - to me it's really fascinating, and it's something that comes up on this podcast every once in a while. Because with software having fully devoured the world now, everything is built from software. Every company is a software company. It's like you were saying - and I couldn't agree more, that you kind of can't succeed nowadays really without having some kind of technical knowledge. Even if you're an executive who is never going to be touching a command line interface - if you don't know what one is, you're actually probably in some trouble.

Marianne: Yeah.

Len: And so, I was wondering if you could talk a little bit about that? About the design of command line interfaces, how everything in the world that's built now comes from these things. And even the design of code, although that's unlocking another door.

Marianne: I think the point I was trying to make with the talk that you're referencing here, is that the user interface of something - even something that seems completely intuitive, like command line - will affect how something ultimately scales.

If people don't know how to use it correctly, they will use it wrong. And that means they're going to use it in a way that you didn't anticipate and you didn't test for - and you don't know how that's going to change, how it will affect other systems, or how it will effect memory usage - or a whole bunch of other things.

That, to me, was a really incredibly rewarding talk to give. Because I gave it at DevOps Data DC, and a bunch of SRE's come up to me and were like, "Oh my God, I need a designer for my team. Thank you for giving this talk." So there was an actual change. There was actual conversation and change in opinion in that community, even though it's just kind of a local community, around this idea of like, "Well, what are we actually doing when we build infrastructure-related tools? And if people do not know how to use them correctly, that's going to cause us a lot of pain - and we don't want to be caused pain, so maybe we should figure out how to solve that?"

In general, when I run those kind of teams, I tend to tell them that like, "Your customer is product engineering. So the engineering teams that are building the actual product, that is your customer. And you have to approach them the same way they approach our actual 'pay us money' customer. You have to go through the same process with them. And you have it easier, because they are in the same company, incentivized to talk to you, maybe even sitting two or three desks away from you. So you have a huge advantage over them in terms of access to the customer. But you have to take the exact same approach with them as they do with our actual paying money customer."

Len: It's really interesting. One of the approaches there is to have structured interactions with people, where you sort of find out what their pain points are and how they describe them, and how they try and solve them, or don't try and solve them. And you really need to avoid the - you talk about how you really need to avoid the temptation to show them how.

Marianne: Yeah. It's funny how often people who are not used to user research think of it as a tutorial. And it's like, "No, that's not, because it's -" First of all, people don't generally absorb knowledge having it explained to them once. So you will have missed how they actually think about your technology and the assumptions they make about it, which is really valuable insight for you to have. And you also will not have successfully taught them how to use the thing.

But it's hard. Because people - especially when people genuinely want to help, your immediate instinct is, when you see them struggling with something, when you see them going, "Oh, I don't understand what this button does," or, "I don't understand what this command means," there's natural instinct to just go, "Oh, that means this," and explain it for them.

But you really have to see if they can figure it out first, before you give them any hints. And then only really give them hints when you need it to move onto the next level, to see another realm of features or functionality that you want to test with them.

But actually, Google does some really interesting video kind of role plays that they have put on YouTube. I have occasionally trained software engineers to do user research. Which is not ideal. I prefer to have user researchers do user research and for us to just respect their skill set. But it is useful I think sometimes for software engineers to understand generally what the process is. So I've used Google's videos around how you conduct user research - to sort of give them kind of a foundation from which to draw on, of what the expectation should be.

Len: You mentioned talking at conferences and the impact that that can have on people. I guess I'm going to use it as a kind of like a not very sophisticated segue into talking a little bit about the pandemic, which has been something that's been coming up on every episode.

One of the great pleasures of this episode is I get to interview people from all around the world, and ask them about things that are happening in their city, that people might only know from the headlines and things like that. Rather than politics and all that kind of stuff.

Since the pandemic, that's kind of become the thing we talk about. So I was just wondering if you could talk a little bit about how the pandemic has affected your working life, and how things are going in DC right now?

Marianne: Things are weird in DC. Because DC wasn't really or hasn't been yet - knock on wood - really badly affected by the pandemic.

We were affected. We did lockdown. But nothing compared to New York or what's going on down in Texas now, or in Florida now. Nothing like that.

I was joking with a colleague the other day who was out in Seattle, and we were talking about this kind of fear that you will forget that there's a pandemic going on, and do something normal that's actually pretty dangerous in this context. Like go out without your mask or whatever.

And he was like, "I don't know why you, how you could - because like every time you go out in Seattle, everyone is masked. It's everywhere you see. You can't escape it." And I'm thinking to myself, "Yeah, DC just has this trend on bandannas going on right now. You can totally walk out in a DC day and alk a couple of blocks and forget that there's a pandemic going on. Because some people are masked and taking it seriously, and some people are absolutely not taking it seriously." So that makes me sad. Because I like DC as a city, and I want us to do better than that. I want us to like be a better example than that one.

I think - the way it's affected me professionally - has been that a lot of things that I wanted to shift about my current work situation, have been forced to shift. For example, when I started work - I work for Rebellion Defense, which is a tiny little startup. It just hit its one-year anniversary. So we are very happy about that

When I first started working there, they were like, "Oh we don't want you to hire - we'll only hire people who are in the DC area." I'm like, "Well, that's great - except there are not that many software engineers in the DC area."

When you say you want startup engineers that have more of a Silicon Valley perspective, versus a Booz Allen, Lockheed Martin sort of perspective - the pool gets much, much smaller than that. I was like, "Well what if we hire them within the same time zone, but just let them work remotely?" And they were like, "No, we want everybody in the office."

I was trying to like gently socialize how distributive teams work. That, yes - like five or six years ago, it was really, really hard to run a distributed team. But we've actually learned a lot since then about how to set them up. There's a lot of tooling in this. I've run distributed teams and learned a lot about what made them work and what made them not work, from my perspective. So I was sort of trying to like socialize these concepts, and I wasn't getting very far. And then the pandemic hit, and then it was wonderful. Because it was like, "Well, when are we going to get to come to the actual office? When are we going to actually expect people to show up to the office?" Probably not until 2021, the way things are going. So that kind of opened doors for me to introduce them to some people that don't live in DC, but are amazing - that they subsequently fell in love with. And then I was able to move things over a little bit. Little by little.

I like having an office, because I think that it is really, really important to get people to work together in person from time to time. Every single time I've run a distributed team, the level of productivity and cohesion before we all met in person, versus after we all met in perso, has just been like night and day. There is something really magical about one-on-one personal contact with another human being. You do need it from time to time.

And when you're going to do that, having an actual physical office with your branding and your identity built into it, so you feel like you're coming home and you're at ease - versus being in a beige conference room that you have rented somewhere in the middle of nowhere.

It's a much better experience having an office. So I'm not anti-office. But I do like the flexibility of being able to hire people who live in all different parts of the country, to go do a job as a software engineer.

Len: Thanks for sharing all of that. That's really great. It reminds me - basically because a bunch of subsidies opened up, we hired a bunch of co-op students for the summer from the local university Computer Science and Software Engineering departments. For some of them, it's the only job they've ever had, and the only in-person experience they've had is my colleague, Peter, showing up to leave a computer on the doorstep for them.

They only know remote work, some of them, and it's been a really curious experience trying to develop a bit of a culture. So, lots of Zoom calls and things like that, and trying to be friendly, and make time for a little bit of chit chat here and there.

Marianne: Yeah. Interns and entry level employees, it's the hardest on. Because they're the people that really benefit the most from being physically in and around conversations, so that you don't have to be invited specifically to the conversation, but you can still absorb knowledge from it.

As a young engineer, I remember, so much of my learning just came from sitting quietly in a coworking space, and listening to other people talk about things, right? And so it definitely hits those groups of people the hardest. I don't know that there is a really great solution to that just yet. But we'll probably get lots of blog posts six months from now about it.

Len: It's really interesting you say that actually. I had a personal experience with a similar kind of thing, where instead of getting to listen, I was considered to be like kind of a hot candidate for this job I got as an investment banker. And so they threw me on the financial model within like a few weeks, which is something that usually you don't get to touch for like a year or two.

And so, what happened was - as a result of that, I hadn't been sitting in on meetings and heard people talk about like - I was told one day, like, "Run some sensitivities." And I'm like, "What? What are those?" It took me a while to understand the mistake that had been made, which was that, if I'd just been able to be a fly on the wall and take notes and make PowerPoint presentations - as boring and as subservient as that seems, having access to really smart people, dealing with really important things for some period of time, is actually like the best learning experience.

Marianne: Yeah, yeah.

Len: But this interview's not about my career - and so, you worked for the UN, and then you ended up at the United States Digital Service. I was wondering if you could talk a little bit about what the USDS does, and what you did for them?

Marianne: So USDS was originally founded as kind of a technical SWAT team for the federal government. It's origin story is very tightly connected to the failure of healthcare.gov. And Mikey Dickerson, who is the first administrator of USDS, was involved in the Obama campaign, and so was kind of in their Rolodex, when healthcare.gov blew up and nobody really knew what to do.

What's interesting about this story that is often left out, is that the government was shut down at the time. And whenever government shut downs happen, pay attention to what's going on. Because with weird and interesting thing, people collide that shouldn't, who wouldn't normally have met one another. And so the government didn't have access to the technical people they would normally have access to in order to resolve these issues. They were running on a skeleton crew.

So instead they went through the Rolodex of the old Obama campaign techies, and Mikey's name came up. They pulled him in, with some other people, and then he pulled some other people in.

They liked the results that they got from that format - just rapid triage SWAT team style incident command type work. And so they asked Mikey to come back full time, move to DC and run this organization that they had started. That was issued as the United States Digital Service.

So I would say that USDS - like a young startup, seems to constantly be refining exactly what it is that they do and how they do it. There is still a lot of that SWAT time triage type stuff that goes on. There is also a fair amount of long-term building of technical product that goes on.

One of which is a project called login.gov, that I think we rolled off of last year, but I'm not 100% sure, because I was gone by then.

And so you have all of these great little different ways and different approaches to helping, that are incubated under USDS. But the general idea is that government technology is really, really old and often really, really poorly made.

And what always fascinated me about that problem is that it's not really poorly made because the people who make it are stupid, which is generally people's first assumption. Even if they don't say that out loud, they tend to look at the technology and go, "Oh, you don't know what you're doing, and that's the reason why this is broken."

But a lot of times, the reason why it's broken is because there is all this policy and regulatio that's very well intended, but makes it really difficult to run an agile software development process, number one. Or have any kind of modern tooling of any kind, number two.

One of my very first engagements was with the State Department, and they didn't have any version control on any of their repositories at all. And if you figure out how long we've had version control, that's kind of a mind-blowing thing.

But it was a situation where they had misinterpreted a regulation and decided that they couldn't put that sort of technology on their private network. And so because they couldn't put it on the private network, then no one else could really use it. It wouldn't work. They had to shift binaries around. It was just bananas.

So being successful at USDS is often a mix of technical work with a lot of soft skills work. A lot of what we tend to call "bureaucracy in action," which is really just sitting down with the people who are saying, "no," and understanding what they're trying to accomplish. Because they're always trying to accomplish something. And it's not always a cynical something.

A lot of them are genuinely there because they want to serve the American people. They're public servants, right? They want to serve the American people. They want to create good outcomes. And once you understand that, and you get around to how they see the world, and how they define those positive outcomes, you can usually negotiate that situation and figure out, "Okay, what do I have to get you in order for you to feel comfortable that this thing we're going to, you can improve it and it will be okay."

Len: Thanks very much for sharing all that. It's really interesting. One thing I know you talk about is ho, if you come in as sort of like an outside sort of consultant onto some legacy system - and we're talking about systems that might be 50 years old or something like that, in some cases - and you might look at something and go, "Why was it built that way? What kind of moron built it that way? Why don't they have version control?" Or, "Why don't they do this and that?" And one thing you learn after a while is that, 100% guaranteed, there are a bunch of people jumping up and down within the organizationwho can't wait to do it right, and to have that new technology.

One of the things you can do for bureaucracy hacking is actually have the soft skills, and go around looking for people who can be these internal champions for any change that you're trying to bring about. They're there, go find them, and give them some power.

Marianne: When I worked at USDS, I used to tell the people all the time, "Your job is not to fix the technology. Your job is to find the people who are jumping up and down going, 'It's broken, I know how to fix it,' who are generally right."

Sometimes they're a little out of date in their best practices or they haven't quite picked the right implementation of the solution, but they're in the right general area of what the solution should be. Find those people, and then bring them back to us, where we can put them in front of like, in some cases, the Deputy Secretary of State, or something ridiculous like that. It generally wasn't that high-level, but we had the kind of inroads in different chains of command that we could escalate their concerns to a level where things would actually open up for them, and they were actually empowered to do their jobs.

That was the best of both possible worlds,because it meant that we got to declare success, a problem got solved. But it also meant that really high-functioning people got unblocked, and as a result were often inspired and invigorated and re-engaged with what their actual job was. So you were making people more effective. Making the whole system more effective, as well as fixing a problem.

Len: It's really interesting also that you mention that the people are there to do public service, and it's very curious - I mean often if you - presumably if you come from private industry and come into some government bureaucracy, it can seem really slow and backwards and outdated and stuff like that. I think I read somewhere that like the Veteran's Affairs calendar system is 30 years old or something like that? There's all kinds of complicated things around enterprise sales and things like that that can be talked about in those realms as well.

But the kinds of things that are being done are so important, right? Not that companies don't do important things, but if your system is meant to help every single family in the military move their possessions around every year - that's a huge thing, you don't want to just adopt the latest trend, because you feel held back. You've got to keep in mind the service that you're there to provide, and it's a real balancing act, because like millions of people will be affected by the choices that you make.

Marianne: It kept me interested and engaged. I mean, I'm still interested and engaged in these kind of dilemmas - truthfully, to be 100% honest, because it's exactly that.

The reality of it is that sometimes software engineering companies get away with things, because their threat model is completely different than the government's threat model. So the way we build things in the private sector have different consequences than they would if we built them the same way in the public sector. So you get into these interesting dilemmas of like, "Well, what is actually important here, and are they wrong about those things?"

One of the things that, one of the conversations that was going on a lot when I left USDS about two years ago, was AWS, nd like, "Should we encourage the federal government to move all of their stuff onto AWS?" And what kind of leverage does that give Amazon if, say, Congress decides to try to break them up in an anti-trust action, right? Like all the federal fovernment is running on AWS. And then you try to go after Amazon. Does that not create a massive conflict of interest? You do have to play kind of four-dimensional chess with it sometimes. So people who enjoy four-dimensional chess, always love working in government.

Len: It's really fascinating you bring that up. My go-to example for that is email. And the way in I have to making the point is that - if you could go to jail for sending an email to the wrong person, you'd design email very differently. For example, you wouldn't just put the name, rather than the email address. An email doesn't go to a name. An email goes to an email address. And you want to know what email address it's going to. And you also want to know what email address you're sending from. And typical clients - like we use Gmail all the time, Gmail's a wonderful thing in so many different ways, but it hides the information. And I just, every time - actually every time I use it, I'm like, "I can't believe that I entered an email address, and now it's hiding it from me." Like I have to double-check and make sure where it's going. Or it like hides the CC or whatever. Like, are you kidding?

And a lot of the things that, like - when you encounter - particularly in finance. I've never worked in it, but I imagine in defense and in government generally - a lot of the reasons there's barriers up and there's kind of ugly-looking interfaces, is because the incentives are so different, and the service that you're trying to provide is so different from something convenient and nice-looking.

Marianne: Yeah. So right now one of the issues that we're wrestling with - being a private sector company, selling products back to the defense industry - is that one of the things that - the co-founder, the CEO will say all the time, is, "We're not a services company, we're a product company."

What he means by that is the service company in the defense context means the DOD comes to us and says, "I want to rent your engineers at X amount of dollars per hour, for them to build this thing that I've already determined what it is and the specs of it. And then you'll build it, and I'll own it," sort of thing. Versus a product company - which is like a Software-as-a-Service company, where you design the product, and you own it, and you basically rent access to it to the government.

And the problem is that the military doesn't know how to buy software as a service. They have absolutely no idea how to really structure contracts or how to approach it. And they know how to buy services.

So in starting that conversation and building those relationships and getting the ball rolling on our side, we sort of have to play the services game for a little while. But what we're building has to be built in such a way that we're not backing ourselves into a corner with this one particular customer's use case, right?

And so that becomes a huge technical and architectural challenge. It's like, how do you think about your product and the specifications of your product when you only have one customer? You want there to be other customers, but you don't know who those customers are, and you can't talk to them, sort of thing. Like, how to do you like factor in the level of flexibility that you need in order to make something work for multiple customers? So I spend a lot of time thinking about that and helping other engineers think through that sort of challenge.

Len: I've actually got a couple of questions I was looking forward to asking you about recruitment in the defense industry, maybe thinking about it from the perspective of, let's say, you've just graduated from high school into this crazy time, and you'd like to work in defense as a software engineer at some point in the future.

Knowing what you know now - and if you say found yourself now, just graduated from high school, and you wanted a career in defense, in software engineering, would you recommend that someone get a full four-year Computer Science degree? Or would you say, "Well, there's other options. Like you can learn on your own, or you can join a startup and get skills and experience that way, and transition into defense later?"

Marianne: I think it depends on exactly what aspect of defense is appealing to you. If you are in any way interested in security, the government takes certifications very seriously. The government has sort of accepted the fact that software is this weird thing, where the best engineers aren't necessarily people with Computer Science degrees. But when it comes to security, they very much like that you've passed all of the latest exams, and you have all the latest qualifications.

There's also like a huge academic conversation around information security and defense, that's really interesting to be plugged into. So if that is your interest, I think having kind of a four year computer science education might be super beneficial, in the sense that you will have the network to plug into that conversation, which will get you where you need to go.

In general, I would say that it doesn't matter. I'm a self-taught engineer, and one of the most brilliant engineers I've ever worked with - who I'm working with at Rebellion Defense now, doesn't even have a high school degree. So like the ultimate, the penultimate in self-taught, I guess? So obviously, I don't think that Computer Science degrees are necessary to become good at software and to contribute in the tech community.

However, I also understand that there are things that you learn from your Computer Science degree in terms of fundamental assumptions and just - the whole theory, right? I think we tend to de-emphasize the theory of computers, in favor of the practice of computers. Because the practice of computers is what you will do day in and day out in your professional career, and it's what will get you the job and what will get you the high salary - is being really good at the practice.

But the theory of computers, I think is also super interesting, and super valuable. Especially if you work with old computers, like I do. Because once you realize that, "Oh, the fundamental assumptions about what software is and how it's configured, are completely different than they were like 50 years ago." Then understanding the theory of computers is a really valuable thing. So I wouldn't necessarily like poo-poo a traditional Computer Science degree.

What I will tell people is that I don't screen on them. Like if I have candidates coming into my pipeline, I don't care if you have a CS degree at all. So it's not a disqualifying factor for me.

But in terms of like what's going to get you where you want to go in your career? I think, with education, you should always pursue what is interesting to you. So if you go into a CS 101 course and you think, "God I love this, this is amazing - I want to know more about it," then you should definitely do a four-year Computer Science degree.

If it doesn't click for you because you just want to write code and you can do that with your current skills, and read some books and get better at it on your own - but you walk into - I don't know? Like an Art History class and just feel alive, then you should do that instead. Because I definitely know people who have Art History degrees and work as programmers.

Len: It's interesting, I've got a serious question to ask you about theory and your approach to it. But before I ask it - in fact, this is actually kind of a serious question, but - for anyone who's interested in getting into working for the government, and maybe in particular for defense - that's how they want to do their service. And you've done this from the hiring side of things. So is it important to keep your nose clean when you're young?

Marianne: So, it's hard to work in defense if they cannot get you a security clearance. And there are a couple of things that are just automatic deal-breakers with security clearances,. One of them is drugs, including - sadly - marijuana. So there are certain things that you should keep your nose clean about. I would say that - when they do background checks, they're really more interested in things that people can blackmail you over, rather than whether or not you're an angel.

My background check was done by the FBI, and the FBI has literally heard everything under the sun. You can't shock them. So they can be generous on certain points. But there are things - like criminal records, drug use, alcohol abuse - that are just automatic disqualifiers. I think probably the one that has the biggest push back and most likely to change, is mental health, right?

They are very strict on the mental health side. If you are going into counselling for grief, then that's fine. But almost everything else will make them very, very nervous. And a lot of people have pointed out that that means that you are incentivizing people not to get help when they need help. And especially within the military and post-traumatic stress and things like that - it's a serious thing.

So, yeah - if you want to go into defense, you should probably think about your life choices. But also I would say that - if you want to go into defense, I wouldn't go into defense right away. This is something that I also tell people on the civilian side, that is deeply unsatisfying to them. I wish that it wasn't true. But the thing about these sort of high impact roles, is that there are a lot of people that want to work in public service, or want to make a difference in this world.

So you have to actually flesh out your value-add to the organization. If you're coming fresh out of school, your value-add compared to other people, is practically non-existent. So you actually stunt your career, I think, by doing that, in a lot of ways. Because they'll put you in an entry-level job, where you will get paid practically nothing, and it will be extremely difficult to advance. You'll have great career stability, but it'll be extremely difficult to like get yourself in a room where you can make a difference, and actually use your skills.

Government is kind of like one of those places where it's better to go out and up, and then back in, than it is to try to work your way up through the ladder. There's actually an expression for people who do this with political campaigns. It's, "Moving out to move up." So every time there's a major election cycle, there'll be a certain small segment of government people that just leave their jobs to go work for a campaign, with the idea that if the horse they bet on wins, they will come back and they will now be three rungs up where they were, and they will have gotten a promotion.

It was very interesting to me when I first moved to DC and I started getting exposed to all this, and I realized, "Oh this is how our government actually works, this is interesting." It's how all the gears turn.

Len: That is really fascinating. Thank you for sharing that. That's the kind of information that like - if you don't have someone to talk to about it, you'll never get it.

Marianne: Well, the conventional narrative in any industry is that your career should be a straight line. So you should start in one place, and you should go in an orderly direction - like dancing through the rings. That's a wonderful idea, but I think it actually is not the most interesting career you can have. It's not the most rewarding career that you can have. And ultimately, it's unlikely to be the most profitable career that you can have. (cat meowing)

Len: I just want to say hello to your cat.

Marianne: He's been very good.

Len: Just before we move on to talk about your book, Hiring Engineers, you mentioned theory. And one way into your thoughts on that, I think, is probably to talk a little bit about patterns, and you have a specific concept of "cannibal code."

Marianne: Yeah.

Len: I was wondering if you wouldn't mind - I know you could talk about that for a long time. But if you could talk a little bit about what that concept is at a high level? Marianne: Cannibal code is a term that I came up with to describe repeated patterns of user interface and UX in programming languages. So we're going back to this idea of, a programming language doesn't have a user interface - of course it does, right? Just because it's not a pretty, graphical interface, doesn't mean it's not an interface. And why something like COBOL, which was hugely like influential in its adoption rates, right? COBOL is still everywhere. It's in all of the banks. It's in all of the government organizations - from the federal level, all the way down to your smallest local level.

But if you look at the way COBOL's structured as a language, and you look at other languages - what has been inspired by COBOL? What has taken on those interfaces? Almost nothing.

And yet you look at C, and C's many, many children. And you go further back than C, and how that has all broken down. And like Lisp, and how that has spawned different interpretations of it.

When you actually look at these languages and the history of them - what you realize is that, they're completely different groups of people, right? The people who grew up and became COBOL programmers were a completely different type of engineer, with a completely different set of career goals, than the people who grew up and went to code in C.

By and large, most of the early C programmers were people who worked at universities. They were researchers and they were researching computer languages. And so a lot of the idea sharing and a lot of the languages that are inspired by C, ultimately come from the same communities of, "I like computers and I want to research computers more and more and more."

Versus COBOL engineers, which were mainly more pragmatic software engineers that were really interested in doing practical things in a business environment - and those conversations. But those people were also unlikely to start their own programming language after COBOL.

And so, those sort of things are super interesting to me. Because I think when certain design patterns become really, really common - we tend to just assume, "Well things are the way they are, because that's the best way of doing things." But it's not at all. And when you understand why people gravitate towards certain design patterns, then you understand what their expectations are as a user.

And what was particularly interesting to me, when you think about like the rise of Linux - is that, Linux - in a lot of ways, adopted some of the interfaces from Unix, specifically to steal users away from Unix so that they could kill Unix. So I mean - most of the sharing of interfaces, and that cannibal code effect, comes back to that, "The way I get people to use my thing is by offering them an interface that they've seen before."

Len: I find that part of the theory of cannibal code so fascinating - that there's kind of like an evolutionary advantage in some circumstances, to cannibalizing an interface that people are already familiar with. I would love to talk to you about it, but we've been going on for a little while now. So I'll just put a link - I'll put a time stamped link to this great talk you have on YouTube, where you talk about why typically people want to write code in 80 columns, and the history of where that comes from. If you don't know it, it's a fascinating story - and it goes back to like French weavers.

Marianne: Yeah.

Len: And, yeah - it's really interesting. It's a really great example of how these - I mean this is kind of what Richard Dawkins meant when he invented the concept of the meme, right?

Marianne: Right.

Len: There are these things that reproduce themselves through different kind of technologies, in this context. But it can also be ways of thinking as well.

Marianne: It's all about reference points. A large part of that whole talk - it's one of my favorite talks, "We kill these things with fire," that I gave in Sweden almost a year ago - is all about reference points, and how reference points influence technology adoption and how we see the future of technology, versus our past. And so that was one of my most favorite talks to research, truthfully - and the most fun to give. And so, yeah, it's weird for me to just go, "I definitely recommend that you go see that talk." But I highly recommend that you go look up that talk on YouTube, because it's one of my favorites, so -

Len: I also really enjoyed hearing you talk about how - just now - about how different types of engineers build, but also work on different types of code. I'm Leanpub's resident non-programmer. So I do do some programming, and I have done some programming in the past. But for me, this was kind of like - when I started working for Leanpub almost nine years ago now, or something - it was a whole new world to me, this world of these programmers.

And one thing I've discovered over the years, is that - there's certain types of feature requests that come - there's different types of feature requests that come from people who work on different programming languages. But also there's like different attitudes towards customer support. And I can actually - when someone has a particular kind of problem, that they can express a particular kind of way - I know what book they bought. I know what they bought. And it's just so interesting how these things have these sort of feedback mechanisms, where a certain type of technology's created by a certain type of people with a certain culture, and then people of like mind thrive within it.

Marianne: It's funny that you bring it up. Because I used to work at Borders Books. Rest in peace, Borders Books - ages and ages ago. And every day we'd have people come in and just go like, "I want this book. I saw it here last week. I don't know the title. I don't know the author, but the cover is blue." And how often we could answer that question, and how amazed they were every single time that we knew exactly what book they were talking about. Because people think that they're purchasing choices and that their preferences are unique. And actually they're influenced by a wide variety of different socio-cultural factors. So we could almost always go, like, "Oh, wait - was it XYZ by X, this other person?" And it was like a magic trick to them every single time.

Len: That's actually really interesting. So that's a good opportunity to segue into speaking about books.

Marianne: Yeah.

Len: To speaking about your actual book Hiring Engineers. I guess, let's start with the hard question. So when you've been dealing with a lot of different people in a particular way for a really long time, you can become convinced - like I am - that like, "I know what book that person bought."

Marianne: Yeah.

Len: And I can probably tell you a lot about them. But that brings with it the problem of being overconfident and having biases as well. And so - for someone - when you’re training software engineers to play a role in hiring other software engineers, what do you say to them, about protecting themselves against biased judgements?

Marianne: So a lot of my perspective on building any kind of system, is heavily influenced by safety science and the work of Sidney Dekker. Because I think when you're building any kind of process, the trap that people get drawn into is wanting to design this perfect process - that if it's followed 100% of the time, will eliminate bias in this case. Or will reach a successful outcome every single time.

And like the world is more variable than that. You can't specify any process that's going to work 100% of the time and control for all possible factors. So you really have to trust the person who's doing the job for you - in this case, the interviewer.

And so, a lot of what I do with interviewers in rolling out process to try to mitigate bias, is really talk to them about what makes them feel comfortable in an interview, and what sort of things they need to feel supported and encouraged and look forward and enjoy the interview process.

Because I think that if interviewers enjoy the interview process, then that goes way further to mitigating bias than lecturing them on unconscious bias, right? I think there's a certain degree of awareness work that has to be done. Like you have to like socialize people to the idea that they have bias in the first place. You have to make them aware of the different manifestations of that bias. But I think that if people feel comfortable and empowered as interviewers - all that work that people do trying to mitigate bias, takes root more powerfully, than if you simply try to control them and eliminate the bias without empowering them.

Len: You mentioned process a couple of times. This concept actually has a pretty important role in your book, where you write about how you hate bureaucracy, but process is great. And so what's the difference between bureaucracy and process?

Marianne: So - bureaucracy comes from a place of control. Bureaucracy is about, "I want to prevent bad outcomes." And you can't prevent bad outcomes, because you can't possibly predict all of the possible outcomes that happen. And what might be a bad outcome in one set of circumstances, might be a good outcome in another set of circumstances. I've seen that happen before as well. So you can't really fully ever create a top down process that is going to actually prevent bad outcomes.

What you will end up doing, if you think about your process from a perspective of control, is making it impossible for people to do the right thing. Because you'll put them in these situations where the circumstances have changed, or they've had some kind of weird Black Swan event, where the only way to solve the problem and get a good outcome, is to do the thing that you've outlawed.

And now they have to like weigh, "What are the odds that I'll do the thing that's outlawed, and I'll actually get punished for it." Or maybe, "I'll do the thing that's outlawed, and the good outcome will be the results, and people will understand that and forgive me for doing the bad thing." You never want to put people in that situation, because it's stressful for them, regardless of which choice that they make.

Whereas process should be about helping people figure out the right thing to do. And this is a conversation that I've been having a lot with my manager lately. Because my manager is very much of this, "Well, we should trust our engineers and have them figure out what technology they want to use and how they want to implement it, and how they want to do things." Which in general, I don't disagree with.

But we have some engineers who are working in technology that they've never used before. So our [?], that uses gRPC. We have people that we hired that had to learn Go, and have never written gRPC services before. And so what you're doing, is you're putting that person in this cycle of trial and error, in order to figure out what the right way to implement something is in these particular technologies. And so, if you have a layer of process that sort of guides them through that and eliminates a couple of rounds of trial and error - they get a better result, than if you have no process whatsoever, and they just have to figure it out on their own.

And so, that's basically the difference, is that process empowers people. It guides them towards making the right decision. Because you fundamentally assume that they want to make the right choices, and that you don't need to motivate them or tell them to want good outcomes, if they want good outcomes on their own.

Versus bureaucracy, which takes the exact opposite perspective - which assumes that the operator will do anything in their power to create bad outcomes, because they're not motivated, or they're lazy, or they're not properly inspired. And the only way you fix that is by forbidding them from doing the wrong things.

Len: Speaking of process, I was wondering if you could talk a little bit about what you think about automated screening processes? This is something that has actually been around for a little bit longer, at least with some big organizations, than people think.

So organizations that get lots of applications will often put them through an automated screening process. Where like - I'll just put it in air quotes -= "an AI" looks at it, and then decides who gets through to the first round of interviews, or at least to the first call or something like that. What just generally are your thoughts about the state of affairs with that, and whether it's a good idea or not?

Marianne: I think it's really - it is a scaling solution, right? So I do not recommend it generally, because I think that, best case scenario, you irritate your really senior desirable hires, right? You want to create a certain degree of serendipity. You want people to be able to just apply on the website. A lot of your most desirable candidates will come through recruiting or referral. But you want to have the option that you will be able to just discover people, because they simply applied for your job on your website.

But in situations where we're dealing with candidates that are straight out of school - I think it can be useful, because it's hard - the variance of people who are coming straight out of school is pretty high. There are people coming straight out of school who are like me, programming since the age of thirteen. And therefore, they have a degree now - but they're not coming straight out of school. They're not an entry-level employee whatsoever. Or any people coming straight out of school who never programmed a computer before they sat in their first Computer Science class.

So the variance is pretty high of new grads. And so, it can be useful to just sort of see generally where they are. And it's relatively harmless, because everything in that traditional four-year education preps them to go through interviews that are very similar to the structure of what i-screening will put them through.

So I think that it can be useful when you have such a high volume of candidates, that it's a choice between either putting them through a screener, or they go into a pit that no one ever looks at ever. I think putting them through a screener is better than dropping them into a black hole, for certain.

But if you're - most companies, most organizations are not at that scale, right? They're not getting thousands and thousands of applications to everything they put on their website. They're getting a handful of applications. So I generally recommend that those groups of organizations not bother with it. Because you won't get the level of signal you think you will, and you may alienate people who would be really valuable.

Len: My next question is something you address in the book, which is - why is it hard to hire software engineers?

Marianne: I mean it's really competitive. It's really, really, really, really competitive. And it's competitive for - we're to blame for the fact that it's competitive. Because we have not, as an industry, been super good about cultivating talent internally. Everybody wants to hire the already groomed, already grown and developed talent - nobody really wants to take people who know nothing and educate them and grow them and invest in them.

I think - somebody was telling me, the average tenure of a software engineer in any company is like two years - maybe less? So, two years is not enough time to really have invested in an engineer, to groom them to where you need them to be ultimately. So it's our own fault for it.

But it is incredibly competitive. And even more so, as software continues to eat the world. So there are lots of options for engineers, and lots of people hiring - and not enough great software engineers in the world.

Len: That's a really great answer. I was expecting something about the risk that comes from hiring somebody, because they might just have a - you might be stuck with them for a long time, and they might be creating things that are really core and important - and then you can get stuck with bad work at the heart of it.

But that, it's actually like from the other perspective. that it's like, "No, no, no - we need as many good people as we can - and that's what makes it hard." That's really fascinating.

And why do you write that, "If it's a maybe, it's a no," when it comes to making the final hiring decision when you've got a candidate?"

Marianne: Well, I can't take credit for that. This is an old piece of advice from many, many hiring systems. But the best practice, in my mind, is that every single person that we extend an offer to - we should be really excited about their first day. We should be counting down the days to their first day. Even if they're a junior candidate. Like, I've definitely had junior engineers that I've hired, where I'm like, "I can't wait for this person to start," like I have planned out the whole first three months of their career already. They have no idea what they've signed up for.

I think people should be excited. I don't know anybody who wants to go into their first day of work and realize that their colleagues are like, "Meh, whatever. So you're here now - okay, here's some stuff for you to do." Everybody wants to comment, and have colleagues that are excited about them. And everybody deserves that.

So I think - it's very hard when you're interviewing people, and then when you're ultimately you're making a hiring decision, telling people, "No." But if you think about it from that perspective, what will that first day be like if you're not excited about them?

Or even worse, you're dreading them. I've definitely had hiring committees, where it was very clear to me that the engineers that would be working with the person we were talking about, were actively dreading them coming to work. But they had technically passed all their screens, and they were having a hard time really articulating what was bothering them. But there was obviously something that was bothering them. And I'm like, "That's awful. Who wants to come and work in a place like that? Don't do that to anyone ever, please."

Len: And how do you know - actually, that reminds me about doing it to somebody once when I was doing interviews - not for Leanpub, for something very different. We got somebody who - it's sort of hard to put this in context - he was kind of too nice. And after the interview - because it was a very high pressure job - and after the interview, my colleague that I was interviewing with said, "I don't think we should do it to him."

Marianne: Yeah. I mean, that - really high pressure environments, that's a tough one. I generally want to trust the candidates, know what they're getting into. I know some nice people, that they ended up having just hearts of steel almost, right? Like you put them in a dog fight, and they didn't stop being a nice person, but there was a reservoir of strength that I could never have predicted.

We've had that come up a couple of times, because we do work in the defense industry. And so we'll have people that'll come in and we're a little bit unsure of whether they can handle like the complications of it. So like we were talking about before - when you have a security clearance, you have access to classified information. You can't talk about classified information. And very few people understand what that really feels like, until you have something that is just sort of gnawing away on the back of your mind, and you realize you can't come home and talk to your partner about your day at work. You can't go out for a couple of beers with your friends and talk about it.

It can be stressful in a really weird way. And one of the things that I try to explain to people, is that when we talk about work stress, people tend to think about anxiety and depression. But there's a different form of work stress which is addictive. It's when you find something exhilarating and you want to do more of it. And you stop eating right, and you stop sleeping a full eight hours. You start relaxing your personal relations. Because you just want more and more, and you're chasing this high. That is also work stress.

So when it comes to like - are people tough enough to cut it - I tend to just try to put that in the candidate's court, rather than have the hiring committee make that.

But there are other things. We had a candidate come through my pipeline a couple of months ago, who, it was very obvious, was very experienced and knowledgeable technically - but couldn't explain it, right? And actively avoided explaining things - would give these very short kind of clerk answers to things.

And ultimately, the decision that we made about that, is that even though we were very confident in his technical ability - we also felt that like we're not a command-and-control style organization. We're an organization that makes decisions via consensus. Which means you have to get people to buy in. You have to build relationships and earn trust. And if you can't explain things to them, you're not going to be able to do that. And so as a senior level person, we weren't going to be able to leverage his skill sets, because he wasn't going to be able to advocate for his ideas.

And so that's a different story. Those sorts of things happen. Culture fit is a real thing, and it's a hard thing to interview for. Because it can be so nuanced and it is a place where there are so many vulnerabilities in terms of [?], right? Like, are you rejecting a person because you think they're a poor culture fit, because they made you uncomfortable, because they were a woman? Or because they made you uncomfortable because they're a jerk, right? Like one of those things. A-OK, let's kick them out. And the other one is a very, very different story. So it's a really hard area, but I always - I tell people, "This is where we really earn dividends by defining our core competencies well."

This is something I go into in quite depth in the book, of like, "What are core competencies and how do they look?" When I'm writing technical competencies, I tend to try to bring in some of those cultural issues. It's not just about, "Do you write good code?"

Like - what is our perspective and our environment and our culture around that? Are we a place that there are programmers? Are we a place where junior people do code reviews for senior people? Are we a place where if you use Emacs - get the hell out of here, because it's Vim all the way? What is our culture around these things? Because if you start to incorporate some of that flavor into your core competencies, then it becomes easier to have that conversation, and it becomes easier to make sure that when you're saying, "This person's not a great fit for our team," you're actually making that decision based on something that's not motivated by like race, gender, age, etc., etc., etc.

Len: Thanks for that great answer. You captured a lot of the nuances much better than my crummy little anecdote could ever possibly capture. And it's interesting, just the sort of - I guess dialectic that you're engaged in. Where like - you're gazing at the interviewee, but they're gazing back at you. And you've got to understand that there's like - for example, you said - I think near the beginning of this interview, that one thing you say to people is like, "When you're designing a process, think about what it would be like to be on the other end of it."

Marianne: Yeah.

Len: But you've also got to keep in mind that you've got your own instincts that you should trust, but that you should distrust at the same - you should always be questioning at the same time.

Marianne: Wellbeing - on the other side of it, was actually what got me into building hiring pipelines in the first place. So when I joined USDS, USDS was just a few months over one years old. And they had done mainly their hiring through referral. In fact - it was bad, that when I walked in and started at USDS - every single person asked me where what I had worked on at Google, and where I worked on it in Google. And I was like, "I've never - why does everyone assume that I worked at Google?" But it was because everybody was through referral, and there was just this - it seemed like this direct funnel from Google into USDS at that time. It wasn't quite as bad as that, but that was the way it felt to a lot of people.

And so, when I went through the hiring process at USDS - they didn't do a technical interview with me. And then they hired me as a software engineer, and that was not a pleasant experience. So I went in to those interviews really anxious. Because technical interviews are not fun. And I was somewhat relieved when they were high-level conversations that we didn't really get into details on anything.

And then I started work, and I'm working with people who were like early stage Amazon, ten years at Google, ten years at Twitter. And I was like, "Oh shit, they made a mistake."

You want to talk about imposter syndrome - the little voice that's in every software engineer's head, going like, "You've tricked them, and one day they'll find out." If you have an interview process where no one does a technical interview, and you come into an environment like that - my impostor syndrome was completely out of control. That went on for several months until Mikey actually - I was in a one-on-one with Mikey, and he actually - I can't remember what he was saying and what triggered this - but he actually stopped me and said like, "You didn't trick me, I know who you are, and I know what your skill levels are." And then he started to talk to me about how value I had brought in such a short time, and that he was aware of where I was and what I knew, and what I didn't know, and what I wasn't good at - and that he would make sure that I would always have support. That being acknowledged, is what helped me get over it, and sort of settled in.

But the lesson that I learned from that, is that interviews don't have to be tough for the sake of being tough. When a candidate goes through an interview process that is thorough and fair, you're going to increase their confidence when you hire them. If you put a candidate through an interview process that doesn't reflect what it's like to work there - then when you hire them, they're only going to feel like, "Oh my God - I have somehow managed to trick them into hiring me, and they'll find out, and I have to protect myself by hiding my inferiority as effectively as possible." And that's just unproductive.

Len: Just moving on to the last part of the interview, where we talk about your experience as a writer. You write at the beginning of the book that you wrote it so you could stop writing it, because you kept writing the same thing whenever you were brought into a role in a new organization. So you decided to finally create a book out of what you've done over the years. Why did you decide to use Leanpub as the platform?

Marianne: Yeah, so this is funny - because this is not actually my first book. I had been writing and publishing for a while, and I've always done a mix of both. I have a book coming out in February from No Starch Press, that's actually taking a lot of those concepts of legacy, modernization - and talking about how you run those teams. I might as well just plug it, it's called Kill It with Fire.

Len: Oh please do.

Marianne: I have always kind of done both at the same time. And for me, the choice to self-publish, versus going with a traditional publisher, really depends on the nature of the project. With Kill It with Fire, I had all these ideas that were very raw, and I'd never actually sat down and tried to write them all down before.

So one thing that is really interesting about the traditional publishing process, is it is an incredibly intense and thorough feedback cycle, right? It's not just, "We'll check your spelling and grammar." Well, they do do that, and I do definitely appreciate that. But every single aspect of what you're saying and how you're expressing it, is basically critiqued. And so when you don't really have a clear idea of what you want to say, that can be hugely beneficial, and I found it to be hugely beneficial. I would absolutely do it again. Loved it.

Whereas, with a book like Hiring Engineers, I had been writing these thoughts down in various formats every single time I built a hiring pipeline, because I had to explain to people what core competencies are. I had to document every aspect of the pipeline for all the people that had to be involved in running it, in a way that was accessible to them. So I new what I wanted to say, and I knew exactly how I wanted to say it. I didn't want to argue about it, and I didn't want it to be up for debate.

But that is generally when I start to gravitate towards self-publishing stuff, is when I'm very decided in what the vision of the book is. And with this one, I was very decided in what the vision of the book is. And it's also only about 30,000 words - which most people will tell you is kind of small for a book. Books tend to be closer to 70 to 80 thousand words.

So it was a project that I felt like - if I were to take this to a traditional publisher, the first thing they would ask me to do is bulk up the number, the word counts - for no practical reason, just to get it more into the book size - which I don't want to do. That's not, that's not really of interest to me.

And that process - the traditional publishing process - is also super long, and I didn't want to really go through a long process with it at all. Like when Kill It With Fire comes out in February, it will be two years since the day I signed the contract for it. Now that's a little extended in the COVID-19 world, the pandemic screwed things up a little bit in publishing timelines - but still, it's a long process.

So, yeah - I gravitated towards Leanpub, because I was familiar with the quality of Leanpub's product. And I had bought books on Leanpub before. I've been very satisfied with them. And so I was like, "Oh, this seems really easy, so I'll just do this this way." And it was, and I was very happy with it.

Len: Thanks very much for that. And good luck with your No Starch book. I really enjoyed hearing that answer, because you nicely balanced in one response the differences between traditional publishing and self-publishing, and why there are tradeoffs, but like why it's really one choice - for one type of book, it's one way of doing things. For another type of book, it's another way of doing things.

The last question I always like to ask when the guest has published a book on Leanpub, is - if there was one thing we could fix for you, or one feature we could build for you - what would you ask us to do?

Marianne: Oh, I really, really like the interface for writing Markdown on Leanpub. But I really wish that it would tell me when I spelled a word wrong. Not necessarily a full spell check, but the little squiggly red line is so comforting for me. I found that - I am the type of person that like writes completely wrong words and sentences, or just misspells them in hilarious ways. And so I've found that I had to actually copy a chapter out of Leanpub into Word to run spell check - and then copy it back into Leanpub to like finish doing editing. So actually just having a very simple, "Oh, this looks like it might be wrong," on the spelling side, would be really useful.

Len: Thanks very much for that very practical request. I can't speak for the whole company, but I'm pretty sure that spell checking is something we're going to do someday. It's pretty amazing that we don't get the request more often. One of the reasons is that we have many different writing modes, right? Including one of which is just Bring your own book. So you can just write your book however you want, and bring the PDF, EPUB, or MOBI to Leanpub, and just upload it. So, you can be using spell checkers in whatever your tools are.

And also we have - you can write in Dropbox, or you can write using GitHub and Bitbucket. Which means you're using whatever app you prefer to write in. But we also do have the in-browser text editor. And, yeah, I'm actually surprised that we don't get that request more, especially as spell checking has become something that happens automatically in your email client or whatever.

Marianne: Yeah.

Len: Spell checkers are everywhere now. But thanks very much for that, and I'll report that to the team that you vote for that.

And thank you very much Marianne, for taking the time out of your day to do this. I really appreciate it. And thanks for using Leanpub to publish Hiring Engineers.

Marianne: It was my pleasure. I really enjoyed talking to you.

Len: Thanks very much.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.