An interview with
David Darmanin, CEO and co-founder of Hotjar

‍

Hope you enjoy our post on how Hotjar built a remote hiring process which helped take them from $0 - $1m in ARR in 6 months

If you like the article, consider joining our free 1 hour webinar with our founder Brett Putter on 'How to Build an Unstoppable Remote Hiring Process' on June 3rd - sign up here.

Otherwise - on with the article!

‍

Hotjar is a SaaS
start-up specialising in providing all-in-one analytics and feedback, with
features such as heat mapping and conversion analytics. The company’s mission
is to change the way digital experiences are built by ‘Democratizing’ User
Analytics and Feedback. It is a business that has achieved remarkable results:
the company went from idea to 60,000 beta signups in just six months, and from
beta to €1million annual recurring revenue (ARR) in another six, and it has now
achieved ARR of €10million since launching in April 2015. The incredible twist
in the plot is that the entire Hotjar team of 56 is distributed around the
globe. Now, as it nears its third birthday, the company is working with
CultureGene to ensure that it is primed for its next stage of growth and further
success.

I sat down (or more
accurately, had a Google hangout) with David Darmanin, founder and CEO of
Hotjar, to find out more about how he his co-founders have created such a
strong company culture that continues to go from strength to strength without a
single shared office in sight.

Key highlights:

-   A thorough five-stage hiring process maximises your chances of
hiring the best with the right cultural fit

-   How and why David and his co-founders built the business remotely

-   The unique challenges that remote presents and how Hotjar overcomes
them

-   How to make everyone feel like they’re part of the business — even
if they’re not a permanent member of staff

-   How and why Hotjar focuses on transparency and trust

‍

What was your
thinking about building a remote team and how did you approach building it?

The main factor
driving our decision to build a remote company came from the previous company
that we had built in Malta, where we are based. I was a VP at the company, one
of Hotjar’s four co-founders, Johan, was the owner of that business, and it
grew to the point where there were 150 people all based in the office. I really
enjoyed it when the company had around twenty or thirty people: it was a time
in my life when I was young and wanted to have fun and party, and the culture
was very social. But when it reached 130, 140, 150 people, something changed
for me and I ended up really hating it. At that point, there were enough people
in the business for us not to know everyone, and it didn’t feel like a family
anymore. It actually felt pretty awkward coming into the office and I realised
that it just wasn’t working for me.

Now, I’ve always loved
travelling, and it was something that in the back of my mind I had planned to
do more of at some point in the future. Because of how I was feeling at work,
travelling became my impetus to look for a remote role — and I landed
one fairly quickly, as a consultant. I loved the flexibility and the freedom of
being able to work how I wanted, whether from home or going out to work from a
café, but there were certain things about the way the company worked that I didn’t
like. For example, because I was a consultant, I had to buy my own laptop.
There were also a few people based in a shared office in the UK so there was
still a feeling of them and us. I just didn’t feel like I was part of the
business.

When we were setting
up Hotjar, we decided to build it from scratch as a remote team; I wanted to
keep the lifestyle I’d had access to in my remote role as a consultant, and I
thought that if I could share that opportunity with other people, it would make
a lot of people happy. I also thought it could be an amazing way to generate
engagement and loyalty from our people, and basically make a lot of people want
to work for us forever!

We adopted parts of my
personal experience of working for someone remotely, but also adapted and
improved upon them. The vision when we set out was that whether someone was an
employee or a contractor, they would be treated equally, even though the
agreements and contracts they signed would be different. The whole idea was to
make people feel welcome by investing in them from day one. We bought people
the gear they’d need to do their work, such as laptops and headsets, and we
also decided early on to put trust in our people by allowing them to have
budgets and allowances that
controlled, so that they didn’t need to
get permission and approval from us. This freed up a lot of time that’s often
spent on back and forth communication with people checking whether they can
spend a bit of money, and it also gave people a lot of autonomy and showed them
that they had our trust.

‍

What’s been
successful about building a remote team this way?

In the very beginning,
there were just four of us — three Maltese and one Swede — and we were all
based just a few kilometres away from each other in Malta. However, right from
the start, we worked as if we were remote workers in the same team. We avoided
meeting up — even socially — and we avoided the temptation to get together in
person to make decisions. Instead, everything was done remotely, which was a
counterintuitive move, but it worked. I was actually really stubborn with the
team about this, insisting that we would not start working together too much.
In the end, it was a very successful move because when people joined us
remotely later on, they fitted in automatically and didn’t feel left out because
we’d created and shaped our culture like that from its inception.

‍

What’s been less
successful about building a remote team?

Well, after our first
hire, we managed to get hiring completely wrong! With remote working, it’s
really easy to either under-estimate or over-estimate things because there’s
more of a knowledge gap about what your colleagues know or can do, and your
mind can easily fill in those blanks. I somehow assumed, for example, that my
co-founders had enough experience to make the right hiring choices — even
though I
that they didn’t have experience in hiring! Because we
were working remotely, I kind of forgot that they were inexperienced in this
area and just assumed things would work well. That’s the big difference between
remote and working in an office together: in person, things like this are more
obvious because they’re right in front of you, whereas with remote, it’s very
easy to take things for granted, either negatively or positively.

This meant in the
beginning especially that we hired the wrong people. We had to let go of one
person in particular really quickly — within days, in fact — and that created a
huge shit storm. We learned a big lesson from that experience: hire slow. Hire

slowly, in fact, to ensure there are no doubts and that it’s the right fit.
Once you do that, you minimise the chance of any unwanted surprises.

We also found that
even though it might seem a bit inconvenient, when you do let someone go, it’s
a good idea to give them one, two or three months’ payment to soften the blow
and to manage what happens. You see, the reality is with remote, you risk
pulling out the cords from someone who’s been connected to you virtually, which
means that suddenly, they might be out there alone. Again, because you don’t
have the chance to say goodbye in person, it can be a bit risky. Overall
though, the key thing to remember is that you need to stay lean in your team
and be able to adapt and change as quickly as you can.

Finally, we found
after a few months that we hadn’t really done any in-person networking. We had
set up remotely partly because of our geography (we are based on a tiny island
in the middle of the Mediterranean!) and this would have really restricted who
we would have been able to hire. But one thing we didn’t do initially was
expand or leverage our in-person network. Once we realised that we’d fallen
into a bit of a rut in that area, we started to invite people over, attending
more events and bringing on more advisors and mentors, which helped us build
more of a network.

‍

How do you tackle
hiring?

We have a pretty
thorough five-stage hiring process, regardless of the role we’re hiring for.

Stage 1

The first stage is a
fairly simple yet carefully crafted survey. We frame and ask questions in a
particular way, and at this stage, we’re much more oriented towards identifying
a no as opposed to a yes. The survey is there to eliminate people, which might
sound negative but which is actually much easier for the first step of a screening
process than looking for everyone who might be a potential ideal hire. The
survey is designed to see if we’re on the same page as the applicants, so for
example, if we were hiring a VP of customer service I’d ask a simple question
like, ‘What’s caused this churn?’ Now, you’d think this is a straightforward
question, even an easy one, but it tells me a lot — from just that one answer
alone, I can probably eliminate 60-70% of people applying; because lots of
people say things like, ‘Churn happens when people are unhappy with the support
you provide them.’ That is a completely incorrect answer! I wouldn’t want to be
working with a VP of customer experience who thinks that way, so we immediately
know that this person has self-selected out of the process.

We design questions
for quick and easy no’s, but the key is to avoid false positives, so the
questions have to be bulletproof. One thing we have to be careful about is not
to lead with soft questions such as whether applicants know how to use certain
tools, because these questions might disqualify someone based on something
which is totally learnable, and that would be stupid, quite frankly.
Essentially, the survey is there to quickly evaluate our applicants’ mindsets
and to get a sense of their fit with the culture at Hotjar.

Stage 2

Stage 2 involves the
applicant submitting a video of themselves, in which they record their answers
to five key questions. Here, we’re basically looking at the ‘Meet on a Sunday’
test: would we want to spend a Sunday with this person at the office, alone?
There’s a little more qualitative and gut feel at work here, but we do still put some
more structured questions in. So, for example, if we were looking at honesty,
we might ask, ‘If you could do anything on a Monday morning, what would you
do?’ Now, if the applicant responds, ‘Oh, I’d check my email and plan the
week,’ we’d be like, ‘Yeah, I call bullshit on that!’ It doesn’t mean we’re
going to disqualify that person, but if they do move ahead, we will bring that
up later on challenge them about it.

It’s really
interesting to see the way people react to certain questions. It helps us to
see if they are a good fit in terms of remotely being able to be honest, candid
and to explain themselves easily on the fly. It’s important to understand those
things at this stage because of the nature of working remotely; at some point,
they will have to do this via video call, so in a way this stage is a bit of a
test drive. Secondly, and very importantly, it’s at this stage that we start to
look at what they would bring to our culture. We firmly believe that culture is
not static, and everyone who joins the company contributes to it. By asking
questions like the Monday morning question, we can get a sense of what this
person would bring to the table. The first two stages are run by the recruitment
coordinator, Sarah, and a hiring manager who is assigned to each specific role.

Stage 3

Stage 3 is an
interview. This doesn’t have to be done via video; in fact, we typically prefer
it to be done via audio. In the first part of the interview, we ask a few
simple questions to double-check the answers the candidate gave in the survey
and in the video. Then we try to get a feel for who they are and to get to know
them. We ask questions that highlight and focus on emotional awareness, such
as, ‘How would other people describe you?’ Later in the process, we might check
their answers against what their references say, to see how much alignment
there is. This can tell us a lot about their emotional intelligence and
self-awareness.

At Stage 3, we also
dig a little bit more into the actual role they’ve applied for. We quiz people
about specific, role-related scenarios so that we can see their style of
thinking and way of approaching a challenge or opportunity. The majority of the
interview is focused on emotional intelligence and awareness, with questions
such as, ‘Tell us about a conflict you’ve experienced.’ Again, we’re still
identifying red flags at this point, and if there are any, this stage gives us
the opportunity to see quite a few red flags by this point. To be blunt, at
this stage we’re trying to weed out assholes and anyone who would be
unreasonable to work with, such as potentially racist or intolerant people.
This tends to emerge very quickly when you start to discuss certain topics with
people. Obviously it’s difficult to nail this in an hour, but we make an effort
to discover those parts of a person’s character as quickly as possible.

One time we had a very
strong developer, an ex-Googler, in a stage three interview. We asked him to
tell us about a time when he had a conflict, and he told us about a time when
he worked with just one woman in the team. He said, ‘Oh we should tell
what’s-her-name, the girl, the girl on the team,’ and his manager overheard it
and said, ‘Listen, as much as possible don’t say, “the girl on the team,”
because it’s risky, she might not like it and it can come across as
insensitive.’ He got really pissed off that he was corrected about this, and he
said something like, ‘It makes no sense. If she’s a girl, she’s a girl.’ This
for us was such an easy red flag for us because he didn’t even understand why
it was a concern.

Stage 4

At the end of stage 3,
there’s usually one of two situations: either we have roles that are open
constantly, which means we’re constantly bringing people into stage 4. Or, if
we’re looking to hire one person, like a VP for a particular department, then
we will wait to do enough stage 3 interviews to choose two or three people to
go to stage 4 together.

In Stage 4, candidates
complete a task —we call this ‘performance recruitment.’ We design a task made
up of two or three parts; for every role, no matter what it is, one part of the
task involves getting people to look at a current system that is in place in
the business, understand it, create a diagram for it, explain how it works and
suggest how it can be improved. What we’re looking for here is evidence of
whether people can think in terms of systems and whether they are analytical
and able to describe something clearly.

This is probably quite
an obvious process for an engineering role, which is all about systems, but we
do it across the board. So for example, if we were recruiting a VP of customer
service, we would get them to look at the process in place around how we deal
with yearly invoices; for operations, we’d tell them to look at hiring. In both
cases, we’d tell them to find bottlenecks in the system and suggest ways of
improving it. Everything revolves around looking at whether they are capable of
systems thinking; if you can’t or don’t think systems, it can create big
problems.

Candidates get an
invite to HipChat and as much as possible, we try and move the conversation
away from voice and video, even to the point where we give them the task via
HipChat. As well as looking at how they complete the task, we want to
understand how they make sense of being given work to do remotely, how they
take remote feedback and how they process information.

We also identify one
thing they would be doing within the first three or six months working with us
and ask them to do it. The most important thing about this part of the hiring
process is getting candidates to tackle at least one thing that we’re actually
going to use in the business; we’ve found that unless you’re inventing
something for actual use, people tend not to reflect and review their work with
a critical mind, because it’s impossible to be critical about something you
don’t actually need! It’s like going to buy a sofa before you need it
— you just look around at the colours and think, ‘Oh, that’s nice.’ This
isn’t practical and it doesn’t translate to reality because you don’t even
think, ‘How big is the room?’ So it helps a lot to have candidates work on
something that is genuinely needed — and no matter how good that product
or process already is, we ask them at stage 4 to change at least part of it,
reworking it and improving it.

When we give
candidates feedback on their work, we deliberately make it a little bit harsh,
to see if they can take it: can they listen, receive constructive criticism and
more importantly do they understand what we said, and do they go away and fix
or change what we wanted them to?

The final part of this
stage is when they present their work to the team. There’s multiple people at
this stage, and candidates’ work is evaluated by the hiring team which always
includes the recruitment coordinator and the hiring manager. We also ask the
candidate to grade their own work, which is really important — it tells us if
they are modest and again, self-aware enough to understand where they did a
good job and where they could improve next time.

Everyone involved in
the final hiring team makes a decision about the candidate on their own and
votes using Trello; then, together, they look at what each person decided. Part
of the final decision at this stage comes from looking at the quality of their
work, and part from how they behaved in the various communication channels
throughout the hiring process.

Stage 5

The final stage, Stage
5, is where we set up a call between the candidate, the hiring manager and
myself. My focus at this point is to check the quality of the hiring team’s
decision by doing what I call the desperation test. My key focus is to find out
if the team was so desperate to fill this role that they lowered their guard
somewhere. Typically I don’t have that anxiety, so I’m able to spot if it’s
been happening. I'm also really evaluating at the highest level whether there
is a culture fit with this candidate. This process is adapted a bit depending
on the role we’re hiring for; for example, if we’re hiring a senior backend
engineer, I’m going to dig much, much deeper here into the relevant questions
for that particular role. I also shift more focus towards questions about this
candidate’s future if they’re applying for a customer services hero role,
considering what it might be a stepping stone to, how long they are going to be
with us and what the real motivation is for wanting the role.

Run me through your
thinking on Learning & Development, including the perks you offer at Hotjar.

I’ll be honest, on a high
level if I had to rate ourselves, I think we’re actually quite low on
the personal development side. We embrace it a lot, but we’re not taking the lead
yet. Probably because our team is so driven and they’re all learning like
crazy on their own.

But here's what we do
have in place: first off, department budgets are set up in such a way that
departments can decide on their own what to do for L&D, such as which
events to go to. We get people to initiate that and be as proactive as possible
about it. We believe a lot in events, so we push a lot for people to attend
them. Events are probably where I’ve learnt the most; there is a lot of value in
hearing people share, live, about what they’re doing and they’re also a great
opportunity for networking.

We also give
memberships to Udemy to the whole team, so that they can go  and learn anything they want on the fly. Then
we have the personal development budget, which is a yearly budget of five
hundred Euro per person (we also recently created a 200 Euro budget per person
for wellness). Everyone is given a Kindle and has an unlimited budget for any
books they want to buy.

Every week, we show on
the demo site how people are using their personal development budget, such as
whether they’re buying books or taking courses, and we share that with the rest
of the team. It’s down to department leads to focus on that and there isn’t yet
a centralised approach to it.

The main feedback
we’ve gotten from the team around L&D takes the form of requests for
guidance about what to learn. Generally the response I give to people is
looking for someone to tell you what to learn is not an ideal place to be. I’m
happy to challenge people with suggestions and ideas, but I see learning as
something that you should take your own initiative on, where you create your
own path, fail and learn, just like anything else.

One of your values
is transparency. Describe how you live that at Hotjar.

There are two main things
we do to be transparent. One is that our financials and business plans are
available to the whole company and we actually present them every month, so
there’s transparency around output and results as well as state of the business
and plans for the future.

The second part is the
way in which decisions are taken or calls are taken; they are all open for
anyone to listen in on. However, having the team join a super long call
just to see how we’re deciding something isn’t the most effective way of working.

Transparency really
comes down to the way we operate on a daily basis, which is simply to be frank,
open, direct and honest. The problem with this is obviously that the more you
scale, the more this level of openness comes less naturally and the more it
becomes something you need to design for. If there are twenty people in the
company, it’s easier to be transparent and open with everyone, but once you
start reaching 70-80 people, you need a system for it.

Another thing we’ve
done and always prided ourselves on is our ongoing work to eliminate politics
and back-talking. For example, as soon as we thought, ‘Let’s speak to
investors,’ the first thing I did was to jump on a company meeting and
tell everyone. I told people that we were going to speak to investors, and why.
‘We’re not saying we’re committed to this or not,’ I said, ‘but here’s the
thinking.’  Even though some people
panicked because they don’t want investors in the business, they appreciated
the fact that we told them about it.

The purpose of
transparency is to build trust. It’s laying your cards on the table. It’s not
about tricking people, but it is about showing your intent and putting action
behind it. That’s what makes you transparent at the end of the day.

‍

You had the CEO of
Radical Candor come and speak to you — take me through your thinking
there.

What I realised is
that while I’m very good at giving feedback and being quite candid, maybe not
everyone understands where I’m coming from. One of our team members read
and said, ‘Holy shit! I read this book and it sounds like I’m
reading David’s manual of how to manage people.’ When I read it I thought it
was fantastic resource, because if there’s one thing I’m weak at, it’s teaching
people. I love to find books with good frameworks and bringing in people to
teach the team, so this was a big win.

It’s on my bucket list
to eventually become better at teaching. Someone on the team was an ex-teacher
and he gave me this really simple tip: teaching, he said, is about asking
questions —
telling others what they should know! That stuck with me
because I realised that I don’t ask enough questions: I tell people things. So
now I’m testing this new approach on my four-year-old! (It’s working nicely.)

What are your
observations about the role of discretionary energy at Hotjar — the extra 20
percent that people willingly give over and above their time at work, because
they are fully engaged and inspired?

Generally, I don’t
think we have massive engagement with discretionary energy. It can obviously be
a huge positive for a business, but on occasion it can also be linked to
stress. Where I do notice people taking an extra burden is in certain key
leadership roles. We encourage people to take enough vacation by displaying
names on a ‘wall of shame’ of the people who haven’t taken enough time off. In
general, I think our people tend to be very good at switching off — but then
again, this is an assumption and it’s something for us to look at further.

You mentioned
earlier that you had fired somebody in a matter of days. How do you work out if
somebody is not a good fit at Hotjar, and what’s the process for letting them
go?

In the specific case I
mentioned earlier, there were clear indicators that the person wasn’t right for
the culture and the team. It was pretty horrible, actually: someone was given
the wrong task, it was around our third hire, and they didn’t even know the coding
language we wanted them to know. More importantly though, they had an attitude
problem and didn’t communicate well, so we knew instantly it was a poor fit.

In other cases, because
we are self-funded, fast moving and scrappy, one of the most obvious tell-tale
signs that someone isn’t a good fit is if they are simply not executing. It
will seem like there’s a project black hole — projects go there and nothing
comes back! Typically that’s where the process of letting someone go starts.
Sometimes, as in the example I just gave you, we see an attitude problem. I
think bad attitude cases are actually faster and easier to pinpoint because we
are so tuned culture-wise that we can spot it really quickly.

In cases where people
aren’t executing, that’s where we’ve been a little bit too slow to act, but
we’re getting better at detecting when that happens and acting on it earlier.
Typically it’s not that the person isn’t working enough; typically it’s that
their approach and mindset are ineffective. So for example, they might be doing
projects that are way too big, or they might be overcomplicating things. Very
rarely, you can tell that they’re just a little bit lazy and not moving fast
enough. Recently we let a product designer go because they were just not
getting anything done, it was moving too slow and the ideas weren’t good enough
and ironically, we had found that he had launched his own tool on the side and
that actually coincided exactly with when he had received the first warning. It
was interesting that we picked up on that quite quickly.

In terms of timing, I
think in the last two examples it took us about a year to act on it, which was
too long. We extended our probation period to nine months — not for financial
or legal purposes, but more so that everyone has the right mindset around how
they approach their work — and now we’re aiming to at least have any mis-hires
sorted by nine months. For us, six months at this point would be impossible. It
takes three to six months to realise there’s an issue, and we’ve been a little
bit too slow and too nice to act on it. This has been one of my main pieces of
feedback to managers and team leads. I think it’s probably one of the specific
issues with remote working. You think, ‘Well there was a misunderstanding,’ or
‘Things will get better,’ but because you’re not there face-to-face to see how
someone is working, it’s easy to make assumptions and to over-estimate them.

It’s probably one
of the things where over time a really optimal remote environment cuts that out
quickly and builds systems around it.

You’re right, it’s
about building a system. We did use to do a review, based on our five key
values, highlighting each one and we rating each person by questioning them. So
for example, we’d ask, are you learning and actively trying to learn? Are you
executing at a good pace and getting stuff done? We gave a rating to each
answer and calculated an overall average score. But at a certain point we
stopped doing it, and I think we need to reintroduce it.

Describe your
onboarding process at Hotjar.

 Even before someone joins, they receive a
welcome pack with their Kindle, headsets, the Strengths Finder book and their
company credit card.

Then, when they join,
all of the core stuff that’s the same across every role — assigning hardware,
equipment and getting to know people — is centralised with operations, so
that it’s equal for everyone. New joiners get to know people and sign up with a
Trello board. The role-specific part of onboarding is left in the hands of the
person running the department, and their processes around this have been
improved iteratively over time. So people in the support team, for example,
follow one program, and developers follow another, and we’re getting the
different leads to speak to each other so they can learn from each other.

We build connection
and trust in a couple of ways. When we hire someone in Product, in most cases
we fly them over to Malta so we can meet them, and everyone else who joins
typically takes a call with me.

The company is also
divided into tribes, which are independent of teams. When someone joins, they
are automatically assigned a tribe based on their strengths and role. We mix
people up into different groups so that tribes have diversity. At the moment,
when someone joins, they have to publish an article sharing ten fun facts about
themselves, which is a great way for people to get to know someone new, but not
for them to get to know us. We are thinking about introducing welcome parties
to tribes, to help establish the new relationships — and again, this would
all be done remotely. You put it in a very eloquent way: It’s about trust.
That’s really what we should be focusing on.

‍

Learn more about Hotjar at their website: http://www.hotjar.com/.

‍