An Inside Look with Codeship: Dan Kador, CTO of Keen IO

Dan Kador is co-founder and Chief Technology Officer of Keen IO, a custom analytics development platform. We had the opportunity to sit down with Dan and chat about the realities of building a start-up, investors, diversity in tech, and the role of a CTO.

An Inside Look is a new series on the Codeship blog where we sit down with notable voices in the development community to explore their experience and thoughts on the industry. Want to see more? Make sure to comment and let us know!

We started Keen in January of 2012 with two other guys, Ryan and Kyle. We were inspired by other companies we looked at. A lot of them were developer companies like Heroku and GitHub, Stripe, Twilio, etc. They were inspiration for a variety of reasons, but one of the big ones was how they took a really hard and difficult engineering problem and solved it for developers. They made it so any regular developer could deploy an app to the web for Heroku, could easily manage a Git repo, accept credit cards, or handle telephony.

And we thought, "That makes sense. That's kind of what we work to do." We felt like it would be a pretty good match-up to try our hand at making an analytics developer platform. That’s what Keen is.

Finally, we wanted to try our hand at creating a different kind of company. A lot of our friends were unhappy with the politics and bureaucracy of large companies. They would go and start their own things but end up rebuilding the exact same policies and the exact same systems. It just felt crazy to us to just rebuild companies in the exact same way, expecting a different outcome. We wanted to try something really different, so we're building something pretty different at Keen.

To start with, I think it's just the level of trust we have for each other and the level of responsibility we give people.

We don't have managers in the traditional sense - or, really in much of any sense. We have teams that own specific responsibilities for the business, whether that's large parts of engineering, sales, marketing, or whatever else. Those teams are wholly responsible for what they do. Asking for a budget, how they do it, hiring, really, the whole gamut. Certainly, we have support systems in place to help teams out, but the idea is we don't want there to be a centralized pyramid like exists at a normal company. We want there to be a very explicit decentralization.

Of course, it's not for everybody. Some people appreciate traditional corporate structure, and that's great; but for those of us who feel like the traditional corporate structure has kind of systematically dehumanized people, this is an alternative one where we're trying to actually embrace people. We want to actually help people on their path towards whatever self-actualization looks like for them.

We definitely put a high emphasis on the people we bring in. A lot of that is culture.

We think a lot about motivation. There's a lot of extrinsic motivation in the startup world, and that comes in the form of compensation, cash, equity, etc. Obviously, that's important and we want to make sure that we're paying people fairly, and people are well-compensated here.

But more importantly is the intrinsic motivation. So, what gets people jazzed? Why are people excited to come to work? What are the things that they would work on even if money wasn't a factor? We try to really figure that out and see if there's strong alignment with what the business needs, or what we think it might need.

We look for really entrepreneurial folks. We have people who are independent and don't need a central authority figure to tell them what to do, because we don't have that.

And then there're some specific values that're really important to us - things like introspection; humility; honesty; not shying away from difficult conversations, but understanding that difficult conversations can be had with grace and with empathy.

On the engineering side, I think all that applies. There's lots of different problems here, so sometimes we're looking for folks to help out with specific pieces of our stack. So, we certainly hire (have hired and are continuing to hire) some of the best distributed systems engineers in the world.

We're also hiring people who just want to be one of those someday. You don't need to already have all the answers to be here. We want people from all walks of life. So, we do a lot of distributed systems engineering. We do a lot of data engineering. We do a lot of amazing visualization work. We do a lot of amazing front-end work. It’s full stack. There's lots and lots of pieces to work on here.

The short version, which is kind of the real version, is that I was a developer for five and-a-half years, and then I decided I wanted to start a company. So I just called myself "CTO." Nobody told me otherwise.

That's the real way to do it: you just do it. Unless you're getting hired by somebody else, that's a different path. If you just start your own thing, you're allowed to call yourself whatever you want.

I think, for me, the hardest part was I know how to not only lead from the ‘front,’ so to speak. I know how to lead by doing the thing I want other people to do. But eventually, I got to the point where I didn't have enough time in my day to do what I wanted other people to do as well as what the company needed me to do myself. I couldn't demonstrate being on call, as an example. I couldn't be on call and go to investor meetings or work on company process.

It was challenging to get myself to the point of being able to tell people, "I'm not telling you to do something at all, but the business needs tasks X, Y and Z. I used to do those tasks, and now I'm no longer going to do them." There’s lots of challenges, but that was probably the single most difficult thing.

That's a great question. I'm going to give you a pretty nontraditional answer, which is: I don't report to our CEO.

Three of us, when we started the company, decided that Kyle would be the CEO, and it was the right choice; it makes sense. But we kind of run the company as a triumvirate. Not every decision has to go through the three of us, but we are on the board. So if I report to anybody, I report to Kyle and our co-founder Ryan.

My responsibilities with investors have shifted over time. Early days, it was really building product, architecting things then actually implementing. Then I focused on team building, getting people in the door, as well as a lot of the day-to-day development work.

Nowadays, I spend basically all my time thinking about how to scale the company. I've been involved in all of our fundraises. Early on, it was a lot of talking about technical vision and what's possible. Lately, it's talking about scale and talking about how we actually make the billion-dollar company.

Like I said, unlike most companies, at our stage we have control of the board. So in many ways, our investors report to us - not the other way around. I don't actually want that to sound adversarial. We have two really wonderful investors on our board, and they've been hugely influential and hugely valuable.

We try to give back a lot. We're very, very active on GitHub. I think in Q4 2014, we had the third most stars on GitHub. I think it was Facebook, Google, us, and Adobe.

A lot of what we do is try to build tools that we think would be valuable to us and to our customers, and then open-source them. One big example is the dashboarding repo we built. It made it really easy to build visualizations; and, by default, it uses us as a back end, but you can plug it into anything you want. That might be our single biggest open-source repo, but we've got lots of other tools that range from visualizations like I mentioned, all the way down into monitoring tools for distributed systems.

We try, by default, to assume: "Let's try to open-source this," and, "What would be the reasons not to?" There are good reasons not to sometimes, but we try to go with a community-first perspective.

The biggest one, by far, for me is the diversity issue. I personally spend most of my volunteering time working with women in tech organizations, but it's not limited to women. There's other minority groups as well that are under-represented groups in tech. And that's just unacceptable.

It’s an incredible opportunity; imagine if we actually had equal representation. There're some incredibly amazing and talented people out there who don't have access to the resources they need to participate in our community, or are actively kept out of our community by internal forces. Getting rid of participation barriers in tech helps everyone.

I can talk a little bit about it, but it’s by no means comprehensive of what could be done. We all need to do more.

I think a lot of what we've try to do is, in some ways, wear our hearts on our sleeves about what kind of company we want to build in terms of being a progressive, feminist organization. That attracts certain people, and I think it discourages other people - or, certain people are un-attracted to that. That's a good thing. We want to be really clear about what our values are and what we care about and let people opt in or opt out because of them.

It’s been very individually driven. There are people at the company - myself included - who spend a lot of their time outside of Keen supporting groups whose purpose is to increase diversity in the tech world. One is a group called "Hackbright." They're a developer school - a three month program for women. I mentor for them. We've hired a few people from Hackbright, so there's the benefit of having the communities we're associated with straight-up feed into our talent pipeline.

We do sponsoring and supporting groups, whether they're at conferences, or sending people on scholarships to conferences, or something like that. We try to put our money where our mouth is.

A lot of it is just trying to be open and talk about the problems we see, just admitting that there's an issue. And that helps.

The first one that comes to mind is just perseverance. It's what I tell anybody who wants to be a developer, and it continues in this role. A lot of the battle is just being frustrated and banging your head against something and then finally figuring it out 40 hours later - and, hopefully, asking for lots of help along the way. So you need perseverance; not being afraid to ask for help.

Understanding second- and third-order effects is really important. For example, if you're helping to put in place performance reviews, one of the inputs into the performance review is, you know, "We're going to measure two or three metrics."

Just assume that those two or three metrics are immediately going to be gamed, because that's how people work. Then that's the first-order effect. That metric's going to be gamed. So, what is the second-order effect of that? Hopefully, you can get to the third-order effect. How is this going to affect the product? How is this going to affect culture? That's a really important thing.

I thought about that. We started the company by going through a program called "Techstars," and our managing director was Jason Seats, who founded a company called "Slicehost" that he later sold to Rackspace. And we asked him, "Why don't you go start another company, man? You're young. You're super smart. You've got money. You could go do it again."

And his answer to us was something that I didn't really understand as well as I do now, "You know, I could; but I've lost my naïveté."

That sense of being naïve and just assuming that, "All right. Well, I'll just solve whatever problems come up," and, "I don't need to know everything" is an incredibly valuable thing. I don't think I would want to change that. If I went and told myself three years ago some of the stuff I know now, it's possible that I wouldn't've started the company. Or it's possible that I would've done things very differently, because there's a lot of good stuff when you start a company, but there's a lot of bad stuff, too. The roller coaster's a real thing.

I think that preserving that sense of possibility, being naïve, is really valuable. I don't think I would change anything.

Thanks again to Dan for sitting down with us! You can learn more about Dan, his team, and Keen IO on their site.

Is there a voice in tech that we should interview? Drop us a comment and let us know.