The first hires are key, and one of the important traits I’ve discovered is that they need to be willing to be generalists, as no one in a startup is focused only on one specific area. Our first hire at Cerby was a site reliability engineer (SRE), he was also writing front-end code or building the API when it was needed. Our mission at that time was to get to production reliably and securely, and build our infrastructure with services that could be managed as code.

Generalists can set the tone of the company in terms of embodying the principle of taking ownership and being open to help wherever it is needed. I’ve been fortunate to have hired people that had been engineering managers or directors of engineering previously in their careers. I was honest and said when they joined, “You’ll get to that level but I need you to be an engineer today”. Once you have been in leadership, going back to writing code at pace and effectively is not easy. Resetting like that is a skill that not all people have it.

As Cerby grew, we started breaking out into smaller teams – design, quality assurance, site reliability – and one of the first things we grappled with was exactly this issue: avoiding silos. Fortunately, some of our product features actually cut across multiple teams. We have one, for instance, which allows you to share accounts across organizations, in terms of permissions and privileges from the original account. That required going deep into our stack and permission systems, and deploying new infrastructure as well as building front-end code. The platforming team and the core apps team had to interact heavily. We have been fortunate in having a cross-cutting feature like that. We have also pushed the principle that every developer needs to be able to get to production safely. This has made collaboration fluid.

Collaboration tools like Slack have actually been a blessing for culture across the company. For example, our engineers are on the sales channel and vice versa. One thing I learned at Wizeline, for example, was the need to create more empathy from engineers about customer problems. Many companies have those challenges. At Cerby, when we started getting feedback, both positive and negative, we decided to have a shared Slack channel called Customer Insights. Sometimes we interpret and comment on the good feedback to rally the team, and when it’s bad we also tell it like it is, so we can figure out what we need to do better. Slack has helped us cross-pollinate thoughts and perspectives and help align the sales and engineering teams.

One of the things I’ve seen is that people have different expectations about start-up life, and sometimes the hiring team doesn’t know how to explain it in a way that really gets the message across. For example, we always receive the question of work-life balance when hiring. I don’t know if we have a good answer to that, as we are a startup after all. Can we turn that question into a different one? Such as, ‘what do you need?’. We have built products before and the going can get tough sometimes. One of the things I’ve been focusing on is being very honest when I am hiring. Startups are not for everybody. That’s the honest truth. If there is a candidate who hasn’t experienced a startup before, you need to dig into their personality and objectives to figure out what it is about them that will really shine and they need to ask themselves if they would actually thrive in a startup. This is hard to do in the interview process, though.

Developer visibility, especially in cloud environments, is really important. You need the logs immediately and in an easy way to query. When we buy technology that will affect everybody, we try to make sure that it’s going to really enable everyone and really deliver. We’ve stuck to mostly AWS services, and most developers also love GitHub in terms of flexibility. And we have instrumented GitHub with different technology and services to make our path production faster. But overall we have kept our spending on engineering tools quite low. We try to use platforms that we can pay for on a monthly basis and then scale, and if something doesn’t work, we can quickly terminate.

I have radically changed the way I build teams, and the diversity of skills and mindsets I bring into it. In the past, I thought people that had strong opinions and were very good at what they did, were the best mix to have a very good team, even though some were abrasive in expressing themselves. My style now is to look for people that are still very smart but they can also express their views in a positive, candid, and constructive way.

Yes. Sometimes we ask very simple questions in the coding exercises to see how someone responds. Ultimately I’m looking for people who are smart but who are also open and who listen. We have a great engineer here, for instance, who has strong opinions, but he’s also an amazing listener. If I tell him something, he will say ‘you know what? That’s a good point. Let me look into that’. That is an amazing quality.

I was actually listening to an interview with Ben Horowitz, and he was asked what he looks for when hiring, and he said “you need helpful people, but it’s very difficult to know in an interview process who is going to be helpful”. That resonated with me a lot. Right now, I have people on my team who are just incredibly helpful – any issue, even if it’s not their cup of tea, I know they have got my back. That’s incredibly important in a startup and that’s the archetype of the culture we want to build.

In the past, I hired some people whose experience looked good on paper and they presented themselves really well, so I just assumed, ‘this person is legit’. Unfortunately, the reality was different and this happened multiple times! At some point, I thought, ‘what am I doing wrong?’ Thinking back on it now, if you look at the best engineers out there, their LinkedIn pages give very little information, some don’t have anything on them. The best engineers don’t say anything because they know they are good. They have a network and if they need a job, they will be immediately hired. If someone sells themselves too hard I would second guess.

I haven’t found the right approach to this yet, to be honest. One thing I’ve been trying to develop over the years is radical candor. In the past, if things were going in the wrong direction, I would not say anything for a while. It’s hard to talk to someone about things that aren’t going well, exactly in the way for some leaders it doesn’t come naturally to give praise to their team. But you need to be brave and equilibrated because there is such a thing as ‘ruinous empathy’ and I’ve definitely been guilty of that. It is better, to be honest and direct, to have such conversations. It’s more of a set of principles and I’m trying to do better every day.

I always look at the way we communicate, especially in writing, like in Jira tickets and on Slack, and try to use language that never puts blame on a person or sounds like we are complaining, even when the going is difficult and we need to do far better as a team, I always try to write things in an optimistic way: what are the things that we can do better here? How can we learn as a team? Even in stressful situations, like an outage, I always try to keep calm and ask, how can we mitigate this? I might suggest certain things. That’s probably one of the things that I should stop doing, but I try to problem-solve with the team. When I do that, it’s always because I trust them but I’m trying to nudge them in a certain direction.

For us, I want a great manager. I know we can hire many roles to have the engineering and technical side covered. But you need a special type of persona that can set up the frameworks, and from the numbers and analytics perspective, can go deep and debug the organization in terms of communication, and culture. I want that for the technical side and that’s a key thing we are looking at for hiring next year.

Surround yourself and work with people that respect you, and that have your back. Bring those people into your circle and care for them. I think all the time, ‘how can I demonstrate to our team that we care a lot about them, and do little things to show that?’ When somebody needs time to deal with a personal issue we say ‘take the time you need’. It’s those things that show we care for them.