An Inside Look with Codeship: Morten Primdahl, CTO of Zendesk

Morten Primdahl is founder and Chief Technical Officer of Zendesk, provider of cloud-based customer service and help desk software. We had the opportunity recently to sit down with Morten and hear his story of founding Zendesk, taking the headquarters across the Atlantic (twice!), and tackling the future of security.

An Inside Look with Codeship is a regular series providing an insider's perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they've been, where they're going, and what we could all be doing together. You can read all Inside Look interviews here.

I'm the technical co-founder of Zendesk. When we founded Zendesk, there were three of us, and we each had our areas of expertise or interests. My interests are in the heavy part of the technology. Our CEO, Mikkel, obviously, focuses on the business. Alexander has been our chief product officer. We drifted towards the areas where we could contribute the most.

We laid the first bricks about ten years ago, and then we went live October, 2007. Which is when we celebrated our conception.

Before I started Zendesk, I worked on enterprise-grade customer service systems, and they were terrible, from A to Z. Just terrible! The buying experience was really poor because it was a salesman talking to a CIO of some sort. They'd make a deal, buy a million-dollar help desk system, then just put their employees in front of it and expect them to use it.

That was a very different way of looking at software compared to today. It was a really broken time. We saw that, and we said we can do better. We set out to build a company with a beautifully simple product and a transparent approach to our customers.

The roadblocks never stop coming. All the time.

Starting a company's hard. We started it during the credit crunch, so funding was hard to get. We were in Denmark where funding is even harder to get, especially back then. You work long hours, you're not making money, and you need to eat! And you know you had a lucrative job. Staying together was truly difficult at that point. It’s tough to work out, to stick it out.

Since then, we’re always facing scaling challenges. That's not just on the technical side, but on the organizational side as well. The challenge of maintaining the culture. You get challenged all the time, and you succeed when you grow.

"Hang in there." I think we were all very dedicated people, and it helps having three founders since eventually most disputes can be settled with a majority decision. When things get a little rough, you figure it out as a team, and you give each other a little breathing room once in a while.

That was super interesting for us. When we moved to the US in 2009, we left Denmark. We had nothing left there. Then a few years later, 2011, I flew back and hired a bunch of people in Denmark because we couldn't hire fast enough in San Francisco. We hired the first group of engineers in Copenhagen, and that's since grown to a great office of over 30 people today.

When we started we had mostly one code base, and these smart guys we'd hired would just jump in there and start helping out. Then when we branched out, things would break sometimes since they didn't know the history of why things are set up the way they are. Even though we have great tests and all that, it was tough to keep from failing. Nobody wants that in engineering. It's especially worse when the time difference is nine hours, and they were sleeping. Waking people up at night is no way to run an organization.

We ended up carving out a good chunk of the Zendesk product, specifically the help center, and gave it to them and said, "Hey, guys. How about this. Take this product, build it, run with it, own it. Here are these APIs we agree upon, and that's how we communicate going forward."

And we never looked back. After that, things just took on their own life. And everyone is happy.

I think it's important when you hire remotely that people have drive. They need to have some ‘startup DNA’ in them so they can thrive when things get turbulent. So they can be proactive even when communication isn’t optimal and always ask: “What can I do?” I think it's vital to get the right people early when you have remote offices.

Right now we are rapidly growing. We have something around 900 employees at Zendesk, and around a quarter of those are focused on engineering and product development. Up till now, we've been small enough to keep track of what's happening around the world. But we are reaching a size where we need to communicate better in terms of architecture. l like to advocate standards.

A friend of mine has a joke: "Standards are great. Everyone should have one." But I realized I could frame standards in the context of what we deliver to the customer: "Hey, when we think about our APIs that we serve to the public, there's a standard for how they move and behave." That means even though we're different internally on how we approach a problem, our customers are not going to suffer for it.

We're going to put in a bigger effort to communicate standards better and help come up with solid standards where none exist. That doesn't mean we need one for everything. I think every one of our teams are just as qualified to talk about how they want to structure, build, and test their code as we are in San Francisco. We don't go out and dictate this is how you do things, but we want standards to manage how it can affect our customers.

We spend a fair time traveling. When you join Zendesk, generally you fly to San Francisco and meet everyone at headquarters, just to get a sense of the spirit and culture. We get our teams together, quite often, so they can see each other and also talk about what the next year should look like.

We also have these new projects that are varied throughout all our infrastructure these days. So we've taken care to have members from all the engineering teams to help be part of it. Because we've found that if engineers don't share the history of a project, they just won't understand it. If a new engineer has no history of the project I'm talking about, they will not understand what drives it. Things will get lost in translation, and they will come up with a solution that doesn't take history into account. When you do that, chances are you can fail.

So we're taking great care to have everyone contribute to projects. So once the project finishes, all offices understand the how and the why and can carry it forward.

One thing that we do different, I think, compared to many startups, is that we work pretty decent, regular hours. People show up at nine, ten and leave at five, six. We've never been the company that would go in there and just put that kind of pressure on our employees. We believe in balance and sustainability.

It succeeds, in part, because we've been lucky and good at maintaining our growth. I think it's totally the right thing for us to do for our culture. We want to create a work environment that is, first and foremost, long-term sustainable.

We get half of that for free because of the size of the problems we get thrown at us these days. When you grapple with significant challenges, it forces you to level up. People can move freely within our engineering organization. If you care more about infrastructure than the front end, or the other way around, we can accommodate that. We don't need everyone to just stay in the same seat all the time. There's lots of freedom that comes with being a larger organization where we can rotate folks where possible. If there's something that interests you more in another place in the company, we can do these things very easily.

Now leveling up the individuals can be harder. We encourage people to sit down and pair program or work together. We don't enforce pairing, but we encourage it if you want to learn or just hang out to solve something spectacularly hard. The best way to learn is to work with other people, and we have some really great ones to learn from.

I will say that we've been really good at not solving unique problems. We've taken it very far just using regular database technology and scaling out using sharding. That's a pretty standard approach for our company.

We are currently working on something that I find quite interesting. We're going to start computing some of our most computationally intensive features in a very different way. We're going to start streaming everything that gets stored in our databases out on Kafka as messages or events: an event stream. The outcome is going to be a real time system, rather than one that’s driven by very expensive queries against the databases. This is going to be one of the big stepping stones for us, scaling out our infrastructure in ways where we can just add boxes to keep up with demand.

There’s a lot happening with big data right now. I think that's very exciting and it’s really delivering some practical solutions.

Definitely. We wish there were more women in software development. I think that's a real problem, both in terms of culture and in terms of how we perceive problems. It’s about the spectrum in which you work. It’s one of the bigger problems for our industry.

On the technical level, I think security's a little intense. It's so impressive to see how the world has changed over the last ten years. If you think about all our understanding about SSL, authentication, and all the hacks we've seen in our industry and beyond, it's not going to get easier to do security and get it right. I think we need to care a lot about where we’re going with it.

We, of course, have a large InfoSec team. There’s the standard stuff: we run security across the board, we're responsible for process and compliance, and so on. Then we also have a little dedicated engineering team that we created a year ago. We had the realization that even though all engineers can and do contribute to our security stance, we would like some teams dedicated to working on it more proactively. This team is about owning our authentication systems and protective mechanisms, and advocate security practices to the rest of the engineering organization.

This team allows us to have an engineering-driven, proactive approach to security, where the improvements don’t get edged out by sexy features coming out of the product management. We realize that product management gets paid to sell a product to customers, and we know that, sadly, not all customers care as much about security as we do. So being proactive and carving that separate team to just run with it is something that we find very valuable.

We're a public company so our investors are the stockholders of Zendesk. It definitely is our responsibility to ensure that we are diligent about our culture, diligent about our security, diligent about how we do engineering. Being a founder means being passionate and relentless. For me that translates to caring about technology, caring about customers, and caring about security for the better of all of us.

I think creativity is up there. There are going to be many times in a startup where you have to pick between a good solution that takes a lot of time or a solution you can do in a short time. None of us like to leave technical debt behind, but sometimes it's a reality that we face. Being creative about finding a solution that doesn't come back and give you ten times as much pain in the long run is super important.

You don't want to sacrifice the technological, right way of doing things. Don't get caught up too much in dogmatic thinking. Be pragmatic, work with people, and your code isn't what makes the money; it's the product. Those are often the same things but not always.

I would say go for it, go crazy. Just don't lose yourself.

I'm saying that because sometimes I found, in my journey, that I was so much in the trenches that I forgot to pull back and just enjoy it. To see the perspective of things. Sometimes you can sit in your own head, and you spin in a crazy loop. I would encourage anyone to try stepping back to reflect and process. You will never learn as much as you do on this journey.