How engineer hiring can make or break your SaaS business
by Laurent Perrin (Co-founder & CTO @Front) and Pierre Queinnec (Co-founder & CEO @Jenji).
They gave this talk about hiring tech profiles to scale your SaaS startup, at B2B Rocks Paris — the international conference for B2B & SaaS startups.
More info on https://b2brocks.co/paris/
Laurent Perrin: Hey everyone, I’m Laurent. I’m the CTO and Co-Founder at Front. Front is an email client for teams. Businesses usually use emails to communicate with the outside world but email was not made to collaborate. So we augmented email with a collaboration layer so that you can have a segment, you can have private comments. And it means that your inbox becomes a detail of every decision that has been made in the company that you can share with your team.
Pierre Queinnec: And you have engineering teams in US?
Laurent Perrin: Yes. We started originally from Paris and pretty quickly we moved the entire team to San Francisco. We grew there and a year ago, we opened an office back in Paris. So now we have two offices, one in San Francisco where we have about 100 people and one in Paris where we have about 30 people.
Pierre Queinnec: Awesome. Yeah, so I’m Pierre from Jenji. We’re an expense management system and we have an engineering team which is based in Paris and Rennes.
So pretty much everyone wants to hire great devs but no one seems to be pretty sure unless you’re sort of operating a scale on what constitute a great dev and what’s like the best sort of quality that you look into your hiring process.
Laurent Perrin: Yes, so the first thing to realize is that if you’re building a SaaS product, you need a certain breed of engineers. So some engineers work great for other businesses but there is a certain breed of engineers that work great for SaaS. And the main quality is to be on time. So you have this triangle, when you build something, you have “scope”, how much you’re willing to compromise and what ships in the final product. You have “time” and you have “quality”. You have to find people that are willing to compromise on scope. So you have a quarter, the team has to ship something by the end of the quarter and they have to be product-minded enough to realize what is optional and what can be cut and still have a relevant product at the end.
Pierre Queinnec: Yeah, definitely. What do you think is actually specific to SaaS engineering as a whole instead of like classic engineering.
Laurent Perrin: Yeah. So I found that what is really specific is that it requires a really high level of trust. For example, if you’re running a product and you have an outage and if it happens the last week of the quarter, it can threaten and prevent your sales team from closing their quota which has a direct personal impact on them.
The problem is that it’s usually how to build a channel where engineers can receive feedback about how the rest of the company perceived that they’re doing. For example, one thing we do is that you have anonymous questions every week in the company. And so it’s a way for people to be able to ask questions they don’t understand why things happened or why this feature was late.
The very important aspect is to always build your product in a way that you can explain it too. You have to make trade-offs that you can explain so that the rest of the team, even outside of engineering can understand this is a natural evolution of our product and this is not. So if we start to introduce one particular product in a new direction, that’s going to create friction in engineering and it means that it’s harder for them to build it.
Pierre Queinnec: You’re right. In most teams, engineering is the team where there is no direct feedback mostly aside from product. And so you’re trying to build a feedback system that works from the whole company as well as sales, marketing, et cetera and not only from the product.
Laurent Perrin: We try to not treat engineering as a special function of the company. One question we ask our engineering candidates is “Do you think that engineering is harder than sales or marketing?”. And if they do, usually, we don’t hire them. Because the truth is it’s equally hard and it’s equally intellectually challenging.
Pierre Queinnec: Does it sort of cast aside mostly juniors that answer this question like engineering is sort of better or more difficult? Or do you find that the reject rate is sort of across senior to junior?
Laurent Perrin: You have lots of signals and usually they all point in the same direction. I wouldn’t say that there is a better but for Front it’s a lot easier to hire junior engineer that we can grow, than senior engineer. Hiring a senior engineer is something that we have to do because there is an expertise that we do not have but it always feels like a bigger risk for us.
Pierre Queinnec: Both in the US and France?
Laurent Perrin: Yes. I think especially in the US because you have lots of companies that are very successful and if someone has worked at Twitter for many years, they will come with a lot of preconception and of course, that’s an example. It’s hard for them to sometimes realize like “Did I really contribute to the success of this company?” or “Did I join a successful company that was still successful when I left?”
And sometimes, they will insist on doing things a certain way or saying like this is a six-month project and we say like if you look at how the market is evolving around us, we need to find a way to deliver that in a month even if we have to compromise on some things. And it doesn’t mean compromising the quality, it means like building something that’s smaller.
Pierre Queinnec: So what sort of OKR’s do you use?
Laurent Perrin: Yes, we can talk about OKR’s. It’s something that’s becoming quite popular. It stands for “Objective and Key Result” and it’s a set of general goals for the companies that are ambitious but measurable. We have OKR’s that we refresh every quarter. One problem is how do you map these OKR’s in terms of engineering goals. Sometimes we are going to ship these features but that doesn’t correlate to the success of the company if no one uses it for example.
And so one thing that we did is not to have an OKR on the shipping of the product but having a joint OKR between product and engineering on the adoption. We have a general OKR on making a product that customers can’t live without it. And the security team will implement it, “OK, what are all the things that can make the product unsecure? How do we reduce that perception? How do we find a way to measure that?”
Pierre Queinnec: Interesting. So you even have OKR’s for security teams as well and they’re based on like being owned or anything, so proactive.
Laurent Perrin: Yeah. Like for security, one of the first thing is how they would measure is while we have zero security incidents. The problem is that it’s not very measurable because it’s zero until you have one. But what you can do is you can build a threat matrix, you can try to score things in terms of how likely is this to happen, and if it happens, how bad is it for us. And if it’s bad for us, how much it makes us look like amateurs.
Pierre Queinnec: Yeah. Yeah, that’s true.
Laurent Perrin: That’s a threat. And then you can run them and then you can have an OKR. OK, let’s reduce that number of like 10% this month. And we are not moving fast enough, then it creates an incentive to increase the size of the security team. But it’s a decision that almost anyone in the company can make and it means that we give a framework to the rest of the company about how to reason about our security posture.
Pierre Queinnec: So how do you actually track things? Like “delay to deployment” or as you said “rate of activation” for the number of people who actually use the feature?
Laurent Perrin: Yeah. Whenever we build a feature there is always a discussion of how we are going to measure the success of that feature. And so the engineering team is part of the discussion from the beginning, so they know what they’re committing to. And again, it reinforces the fact that engineers have to be very product-minded because they’re in the best position to make choices about the product. They have to be able to reason if we remove this part or if we want to test this part sooner, does that compromise our ability to measure our OKR on it.
Pierre Queinnec: Yeah. And so coming back to maybe hiring. What’s the process? And is it like a unified process between the US and France? Or is it like specific for each country?
Laurent Perrin: So we’ve tried to build a unified process but you have to accommodate. So usually, it’s three phases.
The important thing is that you’re trying to hire someone and that person is also trying to get interested in you. So if you have a great process to vet candidates but they decide to join another company in the end, it’s not good.
So the first part is we need to get them excited about the company. So it’s something that will happen face to face with someone so that basically encourage them to go through the entire process, even if it’s long and even if it’s challenging.
Then after that, there is a second part which is a certain automated part. So usually, we hand out a technical assignment that they have to do on their own time. And finally, we have one or two on-site, depending on seniority where they are going to meet several engineers from both locations including someone who is not from engineering.
And during that process, we try to build an onboarding plan. So we try to find, OK, are you interested in these types of problems? Then it just so happened that we have a current project that matches what you want.
And when we get to the part where we make an offer, we usually build a plan and will say, “Well, if you join us, here are the three first projects you’ll work on.” The first one being a one-day or one-week project, the second one being a slightly bigger project that will get them to collaborate with the other members of the team, and the third one is sort of a mission where you use the fact that no one depends on you. So if you deep-dive on the specific part of the product for a few months, then it’s OK because you’re not like forcing us to compromise on something else.
And the fact that you joined knowing exactly what you’ll work on, it’s usually one thing that allows us to close candidates.
It’s harder to do in France because there’s usually a three-month delay, so it’s hard to project what will be an important project for us in three months.
Pierre Queinnec: Yeah, true. It’s a full quarter. You mentioned it is long as a global process. So it’s sort of average touchpoints and sort of timing?
Laurent Perrin: In the US, it’s usually less than two weeks from start to finish. Because engineers move around companies very quickly and the speed of the process is usually the most important thing.
Pierre Queinnec: Interesting. And in terms of compensation, obviously, it depends on countries. But there’s all sorts of models, the sort of most amateur and maybe probably most uses like age or sort of level. So what’s your sort of compensation model?
Laurent Perrin: So it’s a bit of several things, it’s a bit organic. The first thing is that we do have an internal scale, but we do not have titles. So there is a scale but it’s not reflected in the job title. Everyone is a software engineer, publicly, there is no difference.
But when you talk to your manager, they will tell you like, “Here is what the next level is.” And these levels are entirely based on autonomy. It’s like what is the biggest project that you can work autonomously. If you’re able to contribute to a very, very complex project but you need a lot of supervision, in our mind, that doesn’t count. It’s like what is the biggest thing you can do on your own because that’s how the team scales.
The other aspect is that we have an informal ranking. And the reason is that we do not want to penalize former employees. So if you join the company earlier, you should not stay behind. So sometimes, like we hire an engineer and we have to raise a few more engineers so that the whole system stays fair. You don’t know how people are going to talk to each other. People are OK that a company at a certain stage cannot afford to compensate more than X but it has to be there within the company.
And one last thing is that engineers tend to be more expensive in SF, but we found that if you take everything into account, it’s actually comparable between Paris and SF. Because the Paris market is becoming very competitive and which is causing compensation to increase.
Pierre Queinnec: Interesting. Maybe we can take a few questions from the audience?
Participant: Hi. Thank you very much for this presentation. What do you consider the most challenging in your day-to-day job?
Laurent Perrin: Let’s talk about the scale. And so we handle dozens of billions of emails, so if we do not have a scalable system, everything goes down. The problem is that we are not setting that. So we have to spend as little time on that as possible and as little time on security as possible while being good enough at all of these things. And so the most difficult thing for me is as a CTO is that I constantly make decisions and if I’m too conservative, the company does not move fast enough. But if I exceed a certain threshold, I can kill entirely my company.
Loved this talk? Share the article and video with your network 📩
Want to know more about the B2B Rocks, the international conference for B2B & SaaS startups? Visit our website: https://b2brocks.co/paris/
