Born and raised in Guadalajara, Mexico, Vidal Gonzalez has spent nearly two decades in software engineering, from product manager to head of engineering, eventually becoming Chief Technology Officer at Wizeline, a technology services company. He has seen every facet of the startup journey in engineering-oriented businesses, from the role of trust and relationships in attracting tech talent into new ventures, to overcoming challenges in early-stage hiring.
Two years ago, drawing from his experience in building teams and technology at scale, he co-founded Cerby, a cybersecurity startup that helps IT teams manage and secure “unmanageable” applications that don’t connect to identity management systems like Okta or Azure Active Directory.
In this interview, Vidal sits down with Brandon Deer, co-founding GP of Crew Capital to discuss the lessons from his career so far, the art of managing 30+ engineers in a seed stage start-up, how to assess engineering talent, and how to nurture fast-scaling teams.
Highlights from the conversation:
First hires are essential. They should be generalists who are able to change course, and they should have an ownership mindset that sets the tone for the company as a whole.
While engineering teams are expected to be rooted in the technical details, and sales teams are expected to be focused on helping to solve customer problems, startups can create better alignment across their organization by fostering customer empathy among technical teams and ensuring sales teams have a baseline technical acumen.
Not everyone is disposed to thrive in a fast-paced early stage startup environment. Screening for this in interviews can be challenging if a candidate doesn’t have previous startup experience. In this case, hiring managers should focus on a combination of personality traits and career goals to see if an engineer has the potential to thrive at their company.
People are the most important thing. Build diverse teams made up of people who care about and have respect for each other.
Communication and feedback between engineering managers and their teams should be constructive and candid.
Interview
What advice would you offer when it comes to building an engineering team from scratch?
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.
How have you managed to preserve the right culture as your organization expands?
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.
What about creating integration between the tech team and the rest of the company? Do you use the same methods or does it require a different approach?
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.
What are some key challenges that come with hiring in an early-stage company?
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.
Turning to the question of resources for your teams; there are a lot of tools out there for developer productivity more broadly. How do you balance having the most modern tech stack possible – the tools that the best engineers want to use – but also not going out and buying every new shiny toy on the market?
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.
Keeping the flexibility, that makes sense. How would you say your style as a technical leader changed over time?
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.
Do you screen for that when hiring? How?
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.
When you look back at your career, do you have a favourite mistake that led to a lesson that has been important?
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.
As you say, there can often be a gap between how someone fares in an interview and the reality of the job. People’s performance can also change over time. What is the best approach to performance reviews and feedback for your engineers and technical teams? What are the challenges?
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.
Trust is very important in team dynamics. How do you foster it, especially in a hybrid environment where people are not getting to know each other in the same way?
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.
We’ve seen a lot of companies go for a leader with great technical and coding skills, while others look for someone with leadership skills who understands the tech enough. What’s the right equilibrium to have?
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.
Any last words of advice for early-stage founders?
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.
Related Articles
Building a Mental Health Unicorn:
The Entrepreneurial Journey of April Koh
As part of our founder interview series, Crew Capital’s Dylan Reider and Sonia Damian sat down with April to discuss…
Jake Stein: Lessons from a repeat founder
Jake Stein’s experience as a serial tech entrepreneur makes him the perfect person for us to speak with, regarding the…