How Speed Shaped Lambda School, With Bob Lauer

Lambda School has been in the news a ton for the way they’re revolutionizing the financial model of education. Today, we get to talk with one of the architects of this revolution.

Bob Lauer is the VP of Engineering at Lambda School. For those of you who aren’t familiar, Lambda School is a coding academy that aims to help anyone, from any background, get a high-paying job in software development.

In this episode, we talk about…

1. The importance of speed at an early-stage startup
2. Why deliberate communication is essential for remote teams
3. How we can be more productive by removing distractions

Listen to the full episode here

Bob thanks so much for joining us today on scaling software teams.

Thank you for having me.

‍

Talk to us a little bit about Lambda School and your role there.

Lambda School is a full-time (nine month) and part-time (18 month) school for training software developers and… ultimately the goal is to allow anyone to achieve a high paying career in software development.

Certainly there are people who don’t have access to the type of education that most jobs look for, and so that is the ultimate goal; to unlock potential around the world. I’m Director of Engineering so I do a little bit of coding, but [I’m mainly] in charge of the team – overseeing the direction that we are going in, the practices that we have implemented, and making sure that we are moving forward and that… we are… completing really what needs to be done and staying focused and staying on task.

‍

What’s a career inflection point that led to where you are today?

So my first job out of college was at a “dot net” shop, and when I started at the company I was employee number twelve. After about four years we had grown to a hundred-ish employees, and so I had grown with this company. I saw, obviously, massive growth and there was a huge hiring period in the middle there. It was a great company. I had a ton of friends there. It was by all accounts a great job, but I really was not interested in the work.

So I made the difficult decision to leave to go focus on web development, and that took a lot of doing on my part, and I think a lot of courage – just because I had formed so many relationships with all of the people there and after five years I was very comfortable. I knew the work… I had a set of clients that I was comfortable with. And I think I could have stayed there and stayed relatively comfortable in that position.

But there was there was a part of me that knew, if I stay here I’m not going to grow as a developer – I am going to stagnate. And so I made the decision to to leave and find a company that was more in line with the work that I wanted to be doing. Looking back, that was a big moment that I really could have just said, “Ah, leaving a company is scary. I don’t want to go through the interview process again and get to know all these new people. I’ve already done that and I’m so comfortable here.”

And so I’m very glad that I did that. It was very difficult – I still keep in touch with a lot of those people but in general it’s a mistake to stay at a company for those reasons. You do need to be thinking, long term, what is my career? What do I want my career to look like and what skills do I need to make that happen?

‍

And there’s some symmetry in the universe. Now you’re in a company whose mission is to make it easy for people to make those decisions.

That’s right.

‍

And when did you transition from being a builder to a leader? Was it while you were at that “dot net” company?

It was. That was the first little bit of it. I wasn’t a manager so I wasn’t doing one-on-ones with people – I was leading a development team. And so in that sense I was doing a little bit of leading but it really came at my second job that I left the first job for.

I was engineer number four. And then when I left we were around 20 – maybe even 30. And so that was the point where I almost got thrust into this role of being a leader. I was engineer number four, but two of the engineers who were there left about a year or two after I had started. And then one of the other engineers became a project manager.

So I found myself in a position where I was the longest-tenured engineer on the team. And so kind of by default I was in this leadership role, and I knew the code base a lot. I was comfortable helping people and answering questions, and so it was kind of a natural transition to start doing one-on-ones with people, and more formalizing the leadership role.

‍

I think that’s a common story as people get kind of thrust into leadership by subtraction. Thinking back to what “past Bob” knew, what knowledge do you wish you could transplant into past Bob’s head?

I think one thing that I didn’t really appreciate is my role helping them out in [people’s] career. I was more focused on the technical side of things, and our one-on-ones would be more about, hey what are you stuck on? Let’s look in the code right and dig through this. Because that’s what I knew – that’s what I was familiar with and was kind of my wheelhouse…

Right now in my one-on-ones, I don’t want a status update on where you’re at – let’s talk about, how are things going. What do you see for yourself? What does the future look like in this job, and how do we get there?

So I didn’t really have an appreciation for helping [people] advance their career – it was more…  looking at code and talking through code and unblocking people, so let’s do that. That’s where I was comfortable and I was ignoring this other very important side of the coin, which was how do we keep moving you forward in this job?

One thing that I try to tell people is I don’t want you to stay here if you’re not happy. I want to prepare you as best as I can for whatever your dream role is, and if that’s somewhere else – if that’s what makes you happiest – that’s what I want you to do. I’m not trying to lock you into working for me. So whatever skills you want to learn, whatever you see as the future for your career, I want to help you get there.

If that’s with me, great! But it doesn’t have to be.

‍

I love that perspective, because our team members are not going to be with us forever, even if we pretend they are. So why not lean into it and help them be the best person I could be?

Yeah definitely.

 

So at Lambda you use a lot of third party tools. We talked before the recording started about how you see Slack as kind of a canvas for your students, you use a lot of Zoom. How do you build a system that doesn’t drive you crazy when you have integrations and pieces of things everywhere?

When I started we did not have an engineering team, and one thing that struck me was just how far you can get these days without an engineer. So we have piecemealed these third party tools together, and when I started, I thought, “Oh gosh it’ll be so nice to get rid of this stuff and just have this pristine code base where I know exactly what’s going on and I have great oversight into the whole system.”

What I have come to learn is – especially for a startup – speed is just critical, and there is no amount of engineering work that can replace a wizard where you can just click and point and connect services. And so it’s about accepting that some things need to be done using these third party services, and connecting them with other tools – and some things are more critical to the business and they need to be done by the engineering team.

And so it really has taken me awhile to accept that I don’t get to control everything, and everything does not run through the engineering team. And sometimes, that will lead to issues and sometimes people are going to use third party tools when they probably should have gone for a more stable solution. [The engineering team] can put logging in place, monitor everything – the more services you introduce the more failure points you introduce.

So there’s always going to be mistakes as you go, but I think it’s important to remember that at the end of the day, the goal is not to have a beautiful code base, the goal is to have a great product. And whether that’s built on third party services, or custom code base (or most likely a little bit of both) you have to keep that vision in mind. We have to keep trying new things and getting things out the door and iterating on our process, and that’s going to involve engineering… but it’s also going to involve all of these other pieces, as well. And it’s just a tradeoff.

‍

So your decision framework, it sounds like, is between, “Do I build this in code or do I use a tool?” Is that kind of your main decision point? How do you work through that decision?

Yeah it’s: is this an experiment that we’re just spinning up to gather some data to gauge interest? Or is this a process that we’re putting in place that we expect to be here for you know six months, a year, maybe longer? So how high quality does this need to be?

If it’s an experiment we’re just running, and we’re just trying to gauge interest on something then that’s the perfect candidate to just have someone spin [it] up by piecemealing a bunch of tools together. If it’s the application process or something like that – where obviously this thing is not changing, this is core to the business – well then let’s invest in some engineering resources and build this thing out. So that really is the main criteria.

It’s permanence, it sounds like.

Yes. Absolutely.

‍

That makes sense. At Woven we use a lot of Airtable and other tools to just prototype, and that’s a constant back and forth for us – it’s like when are we going to take this out of Airtable and put into postGRASS? When do we know when we stop using Zapier for everything?

You literally just summarized all of the questions I ask myself. Airtable, postGRASS, and Zapier are three big tools that we use, and we are asking ourselves those questions every day.

‍

 

‍

I’ll tell my co-founders that if it’s good enough for Lambda School it’s good enough for us. So what other tools have you found are really effective in prototyping and spinning stuff up, besides Airtable and Zapier?

Another tool that we use extensively is Typeform. So let’s say we want to gauge interest on a potential course. So… do we want to teach iOS or Android? Let’s say we have to choose. Well, let’s spin up a Typeform and say, “Which would you be more interested in learning?”

And then that Typeform talks to Zapier which talks to Airtable – and now I have my table in Airtable where I can see those results. So Typeform is another tool that we lean on very heavily. We [also] have a lot of zaps in Zapier – we use Zapier extensively. We talked to Salesforce with Zapier-to-postGRASS.

So to go back to my previous point, when I started I thought, “It’ll be so nice to not have Zapier anymore and get rid of all those zaps.” And now I realized that would be a mistake. Certainly there are zaps that could probably benefit from being moved into the code base, but there are plenty of zaps where that is absolutely the appropriate place for that logic to flow.

‍

I think one of the big things we miss from having stuff in zaps and Airtable is really source control and testing. Have you found any patterns about how to maybe wrap some sort of monitoring and testing around zaps and Airtable – anything that you found to be effective?

There is some minimal amount of monitoring you can do. So Zapier does have the ability to post to Slack when a zap fails. So we have at least a few of the zaps – I would like all of them… it’s just a matter of going in and doing it – but we do have a Slack channel for alerting us when zaps fail, because if we don’t have that turned on, they’re just failing in the background and no one is noticing – and then we say, “Hey we haven’t had an application come in three hours, what’s going on?” And so someone says, “Check the zaps.” And something happened, and now it’s been broken for three hours before anyone noticed.

So that little bit of monitoring makes a big difference – obviously it would be nicer if we had more tooling around that to where we could write tests and and have a source control with a review process to make sure that a zap is going to do what we expect it to do.

It leaves a bit to be desired, but… overall it’s a very effective tool and it’s gotten us very far.

‍

Yeah it’s like you said – you want a good, effective product – not a pristine code base.Zapier lacks pristine characteristics but it definitely gets the job done.

 

You’ve been through scaling at a couple different startups, and now [Lambda School is] at seven engineers, you think you’ll double or more over the next year. What are the biggest scaling challenges that you’ve encountered when you’re growing your team quickly?

I think as a remote team, communication is always going to be difficult. The more people you have on the team the more difficult it’s going to be.

I always tell people, when you work in an office you have those watercooler moments where you run into someone it’s like oh hey I meant to ask you about this or how’s this project going? When you’re working remotely those moments don’t happen. So all of your communication has to be intentional; there are not those moments of serendipity where you run into someone…  all communication has to be intentional and that is something that is very difficult to do, and it gets tougher the more people you add to the team.

 

So, ways to mitigate that are things like daily stand-ups. Like I said, we use Slack extensively, so I try to use things like Slack reminders to remind me to reach out to someone and see how things are going. If I give a project to someone, and I say, “All right let me know if you get stuck” – I’ll just give myself a Slack reminder to reach out to this person in 24 hours and see how things are going so it doesn’t fall off my plate.

So communication, I think, is the most difficult part of scaling a team. Even if we weren’t remote, I think it would probably be the most difficult part, but when you add remote work into the mix it really becomes difficult.

 

‍

So the tools you found effective – just normal stand up, scrumming agile practices, Slack reminders to help you stay on top of the follow up. Anything else you found to be pretty effective? Have you grown the number of meetings that are in your cadence?

I’m trying not to intentionally. So we do Monday, Tuesday, Wednesday – our meetups are over Slack, and we just have a bot that prompts us [by asking], what you do yesterday? Or what you do today?

And then Thursday and Friday we do all meet together on Zoom to do a face-to-face stand up. One thing that I am really passionate about, and is really a big focus of mine, is making sure that the developers on the team are not getting pulled into meetings all the time.

I measure success to some degree by how many hours of uninterrupted time the developers on my team have to focus, so I want to give them as many, I call them “FBOTs” or “focused blocks of time”, as possible throughout their day. And that has meant having a lot of asynchronous communication over Slack – so we don’t all post our daily stand ups at the same time. If I’m in the middle of something, I know that’s just waiting for me whenever I’m free or whenever I’m in between tasks.

And that’s what I tell the developers on the team as well. I’ll say, “We’ll ping you at 915 in the morning that doesn’t mean you have to answer it at 9:15 in the morning” right? Don’t interrupt your flow to [tell us about] what you did yesterday, etc.

‍

So don’t break the FBOT.

Yeah absolutely. Yeah. So I’m very much trying not to have a ton of meetings slicing up their day into smaller and smaller increments of time in which they’re able to focus. And I think that the tools we have today with asynchronous communication, with Slack – I even think email is underrated.

I think a lot of people now when they’re in a Slack chat – Slack has this sense of immediacy. It almost feels like a text message…  like oh I guess I better get back to someone because they reached out to me over Slack, and there is this sense of urgency, even though there probably isn’t a [reason for that] sense of urgency, that’s just the default tool because you’re in Slack.

But email has never – at least in my view – had that same sense of emergency. Email feels like I’m going to send someone a letter and they’re gonna send me a letter back, right? “Mail” is in the name. That’s how it feels to me. It’s like all right I’m just going to throw this over a wall, whenever they get back to me, great!

And so I try to use email when I want to make it clear that I don’t need an answer right now. Like let’s say it’s 11:00pm and I have something to say, and I don’t wanna forget it, so I’m going to send someone a message…

I won’t send them a message over Slack – just in case they don’t have it set up to where they’re not getting notifications. And I don’t want them to feel like when they wake up, first thing in the morning… they need to give me an answer. So I’ll just shoot them an email… it just feels clear that when I send an email it’s not as urgent…

‍

One thing that I try to tell people is I don’t want you to stay here if you’re not happy. I want to prepare you as best as I can for whatever your dream role is, and if that’s somewhere else – if that’s what makes you happiest – that’s what I want you to do.

— Bob Lauer

And Slack is a great tool – we use it extensively. But I think there is this sense of [being] in a real-time chat app, and so if someone asks me a real-time question, I need to respond with a real-time answer, and I wish that wasn’t the sense.

I don’t think it’s anything Slack is doing, either, that’s just how real-time chat feels, and that is just the default channel that you communicate on – with a lot of teams at least. But I think email is underappreciated for that aspect of, just get back to me whenever you can. This is not urgent. So that’s another tool I would recommend. It’s kind of fallen by the wayside a bit, but I think there’s a lot of utility in using email more.

‍

There’s this is new, crazy technology out of Europe. It’s called the email. [Laughs] It’s great. We should use it more.

I love the idea being intentional about your communication channel and what the norms are on that channel. I think there’s lots of different ways to slice it, but being clear on what response time turnaround is – it sounds like a way to scale that communication.

‍

 

Speaking of being deliberate and intentional, what’s your view on intentional experimentation within your team?

I think as software developers, a lot of teams have this idea of let’s put out an MVP and let’s iterate on it and let’s gather feedback as it’s out and then we’ll keep just churning on this thing and then adding and removing pieces until our customers tell us, “Hey this is what we want.”

That’s a great way to get software out, rather than all right, let’s go for six months and work on this thing. And when we put it out hopefully it’s perfect because we just found it. That rarely, if ever, pans out how you would hope and I try to take that same approach to managing a team.

So if I see something that I think could be improved upon, I don’t necessarily go and think, “What would be the perfect solution here?” I just need a solution that’s slightly better than where we are at now – and maybe it’s not even slightly better. But I can just roll that back. If it turns out that this [solution] isn’t working out – okay, that’s fine!

Like I’ve gotten the feedback, I’ve tried to experimentation, now let’s roll back. Or, maybe it is working out… Is there a version two of this that we could do to keep moving forward?

So one thing that we’ve started implementing is trunk-based development. So let’s say you have a feature branch and you work on that for a month, and then in a month you have this big branch that you want to merge back into master. And that comes with a whole set of complications, right? You may have big merge conflicts, and there’s just this sense of, here is this big new feature that I’m deploying – and sure I’ve tested it, but there is still that sense of I hope this works.

‍

The dread. The unknown.

Yeah absolutely. And so what trunk based development says is: merge into master often – and you may have to hide some of this code behind feature flags or things like that so there’s some overhead there. But you won’t find yourself in a situation where it’s Friday afternoon and feature X is ready to go live, and now you’re merging in a pull request that has 50 files changed and it’s been two months since you started this.

And so  it’s obviously a trade off, but the we want to give it a shot because… why not? If it doesn’t work, we’ll let’s just go back; if we can’t make it work…  well that’s OK we’ll just roll back and we’ll try something else, or maybe we’ll improve upon our existing process. What else could we do? It’s not necessarily all or nothing.

So I think being intentional about the experiments that you run – viewing them as experiments and making sure everyone knows this is an experiment. This is not a mandate coming down from on high… You want to make it clear that, we’re going to try this and we’re gonna give it a fair shot – let’s say we’re going to do it for three months and then we’ll have a meeting. And I’ll put one on the calendar now so we don’t forget three months from now.

‍

Oool I like that – committing to the meeting.

Absolutely, yeah. Because things always fall off your plate – so just do them now.

And so in three months we will re-evaluate; how does this look? What did we learn? What do we think? And if you view your team as a product – in the same way you view your code as the product – let’s get on MVP and then work on it and gather feedback. I think it’s proven [to be] the most effective way to write software that people want to use. And I think that’s the most effective way to build a team that people want to be on.

‍

Now it’s time for the rapid fire round. I’m going to ask a question. You’ll give us your quick reaction. Ready?

Yeah.

‍

What does a “six-star culture fit” look like at Lambda?

A six-star culture fit is someone who really takes ownership of what they’re doing to the extreme – to where they feel they’re a company of one, and this is their product that they need to get done. And obviously they’re going to reach out to other people and they’re not really a company of one… but they are going to to see this thing through.

Nothing is worse than a feature that gets 90 percent of the way there and then dies on the vine because… the last 10 percent is the hardest half, right? And it does feel that way. So someone who is willing to see it through all the way – beginning to end. That is just such an important skill to have.

‍

What advice do you have for an engineer looking to get hired on your team?

Be proactive. This would be true for any engineer looking to get hired on any team – showing initiative is so, so important. I think a lot of people, when they’re looking for a job they just kind of blast out their resumé to a bunch of places and they hope to hear back.

If you reach out to me via email and say, “Hey can we set up a call to just talk through the role?” that’s going to get your foot in the door – that’s going to get my attention… really it’s just a matter of getting your foot in the door and showing people, “Hey I’m not just blasting the resume out to a thousand companies. And if I am doing that, it means I’m willing to talk to a thousand people on the phone.”

So I think initiative goes such such a long way, and it can really distinguish you from other candidates.

‍

What’s the biggest mistake you’ve made in an interview either as interviewer the interviewee?

I think assuming that the technical portion was really the only portion that mattered for a long time. I was really interested in [the question of], “Can this person code? How well are they going to complete whatever take home assignment they’ve been given, or whatever live coding problem we’re giving them?”

And that’s where I put the majority of my focus on. And obviously that’s something that’s important – you don’t want someone who doesn’t know how to code at all, but there are so many other aspects to being a good developer that I simply didn’t focus on that I should have.

‍

Walk me through the interview that left most lasting positive impression of candidate.

I don’t know of a specific interview but in general it’s one where a candidate has a lot of good questions for us. The worst thing that I can see from a candidate is when they don’t have any questions for us at the end, because that’s just such a red flag of, I’m really just looking for a job and I don’t necessarily care where it is…. And that might be the case, but you don’t want to convey that to the employer.

So I think having really good questions and genuinely asking about, what it’s like to work there? What don’t you like [about] working there? What’s a project that I can expect to be put on in the first month? How is onboarding? Just asking questions that ultimately you should want to know the answer to, right?

You could have two companies creating the exact same product in parallel, and those two job experiences could be vastly different. So there’s certainly much more than what is your tech stack? What is the product like? There’s culture and there’s process and there’s a ton of these other things that you really should be interested in.

[So] I loved when people had really good questions in an interview because that just showed me that they were thoughtful about the job.

‍

My guest today has been Bob Lauer. Bob, thank you for being on Scaling Software Teams.

Thank you for having me!

‍