Hi there. I’m Raph Lee, Lob’s Head of Engineering. You may remember me from such blog posts as Lob’s Culture and Values.
Every engineering team I’ve worked on has felt totally different from the others. Our vision for engineering at Lob is unique, so I’d like to pick up where Engineering Culture at Lob: Six Ways To Move Fast and Not Break Things left off and provide an update on how our team has evolved in the past 15 months (!).
Ultimately, our engineering culture can be captured in three ideas: agility, collaboration, and autonomy. They influence everything we do on a daily basis and provide a framework for evaluating prospective hires.
Building out a platform for businesses means we can’t “move fast and break things”, since breaking things is unacceptable when you’re building out a service platform that customers are building on top of.
Engineers can’t move quickly if the code they’re changing is hard to reason about or easy to break by accident. So we’ve invested in tests, tools, and infrastructure to keep code quality high and minimize risk. We believe that doing the extra work up front will help us move faster later.
Lob boasts 100% test coverage for all of our production code, enforced through code review, which also provides peer accountability for consistent style, application security, and other standards and best practices. Thanks to continuous integration, we lint code and run tests as soon as branches are pushed into repositories. We practice continuous delivery to package up our builds for deployment on demand.
There’s no way to reduce the risk of bugs to 0%, so we’ve also invested in tools to detect problems early and revert as quickly as possible after detection. We monitor business and system metrics through Datadog, alert on-call engineers with PagerDuty, and provision, scale, and rollback services using Convox. Incidents are discussed openly through blameless postmortems so that the entire team learns from individuals’ errors.
Taken all together, our toolchain affords incredibly fast iteration speeds and gives us the confidence to move fast without fear.
Engineers at Lob win by working together on clear, shared goals. We look for good collaborators who are outstanding communicators and can find ways to scale themselves up by helping others.
We have engineering challenges that are unique to our business domain and tech stack. It’s easy to make the wrong decisions unless you have all the context you need. We explicitly look for strong communication skills because they’re so central to daily engineering work. To succeed at Lob, engineers need to be able to clearly articulate the business and engineering constraints that inform their decisions.
When you assemble a group of outstanding communicators and put them all on the same team, a culture of teaching, learning, mentorship, and peer feedback grows organically. As I was ramping up, many of the engineers told me this was the aspect of our team that they valued most. We help each other grow by disseminating new information as we learn it. We also invest in engineers’ learning and development by sending them to conferences and spending on training materials.
Just as we’ve invested in tools to move fast, we also think about tooling for being helpful at scale. We built out an internal engineering wiki this quarter because answering questions on a 1:1 basis doesn’t scale. Engineers routinely find ways to automate away painful workflows, both for themselves and for other teams.
The last piece of the puzzle is something that can’t be taught. You have to want to be helpful to other people and feel rewarded when you’ve helped someone else succeed. We look for strong evidence of this trait in our interview process.
Making a team of 10 people 20% more effective is as good as, or better than, hiring 2 more people. We scale up our impact by giving others more leverage.
My goal as the head of engineering is to nurture a team of outstanding problem-solvers who can operate autonomously.
As joint owners of product with PMs, engineers help spec and scope our deliverables to clients. Rather than lobbing specs over the wall to an engineering team responsible for implementation only, our product development cycle gives engineers visibility into all the research that went into the problem statement and makes them co-owners of prototyping and validating viable solutions.
In between our two-week sprint cycles, engineers have 2 days to work on whatever they want. Engineers use this time to design original projects, refactor code, research new technologies, or automate painful processes. We trust engineers to bring their own senses of creativity, problem identification, and prioritization to figure out how to spend their 20% time. Some of our most business-critical infrastructure comes from engineering side projects.
To encourage autonomy we’ve built an environment where it’s safe to fail. Sometimes great decisions result in poor outcomes. That’s just business. If we never fail at the things we try, it means we’re not experimenting enough. Failed projects go through a postmortem, where we discern the root cause so we can try again with better hypotheses.
Our assumption is that if you gather great problem-solvers and give them all the context and data they need to make good decisions, you’ll end up in the right spot most of the time.
We are a small team. But each engineer enjoys a tremendous amount of leverage because our engineering ecosystem helps us move fast without fear, find ways to make each other more effective, and trust and train individual engineers to make good decisions. If these values speak to you, take a gander at our Careers page. We’re growing rapidly and looking for great people to help us navigate the next few months.
In the next post, I’ll share a snapshot of how our teams are structured and some of the problems they’re working on.
.png)
.png)
.png)