Interview with Craig Bryant, the founder and CEO of KinHR.com and WeAreMammoth.com

Transcript

Ledge: Craig, it’s good to have you on. Thanks for joining today.

Craig: Thanks for having me.

Ledge: So, maybe you can just give a little background story of yourself and your work and your company, so the audience can get to know you a little bit.

Craig: Sure. I’m the founder and CEO of a company called Kin. We are a people operation system, so Kinhr.com. We help build happier, healthier workplaces.

The way we do that is with a SaaS product called Kin that helps small businesses improve their new hire onboarding experience with digitizing paperwork, task management. Once new hires are onboarded, we focus on engagement and retention.

Basically creating a digital workplace. Making sure employees are taking their time off. Making sure that all those policies are uploaded into Kin so that employees can know who their workplace is, take advantage of all that they have to offer.

We help with feedback as well. Feedback and job alignment. So, getting your objectives into Kin, doing regular check-ins with your manager, your peers, and so on and so forth.

I’m based in Chicago. We’re an entirely remote company. We haven’t always been. We launched initially in 2013 as a startup within a startup. I have another company called We Are Mammoth which has been around since 2006. We call ourselves a venture studio. I would say we’re a slow-rolling venture studio, which is to say everything that we do is self-funded. I think kind of like gun.io, we own everything. Everything is bootstrapped, everything is self-financed, and we’re just getting to the end of a redesign of Kin itself.

It’s been going on for the better part of a year. We initially thought we were going to be releasing this thing in January, and here we are coming up on April. We’re getting close. I’m excited. The whole team is excited. So, yeah, it’s that last mile.

Ledge: That’s where you and I were riffing about off-mike before we jumped in here. I’ve seen this. We’ve gone through hundreds if not thousands of projects and, no matter what, it’s sort of like you’re 80% done forever.

I always wonder how that happens. Is it a founder perfectionist thing? Or is it underestimation of how much is left? Or what about this or what about that? Where does that come from, because there isn’t a reason that the last bit of work should cost and feel like ten times as much as the first 80%, but it’s always the case.

Have you analyzed this or are you just stuck in the mud right now?

Craig: I’m always analyzing it and I think what you said is spot on, that it should never be done. At some point you have to say it’s good enough and you need to release.

The thing that I’ve enjoyed about the last couple of months, even though we’re technically behind the schedule that we’ve promised to our customers, is that we have a consensus amongst the team that certain aspects of this new product are not good enough so we’re going back to improve them.

There are things – I’d say tasks, initiatives within the product – that we could not have forecasted or envisioned being not up to par with what we want to give to our paying customers – say back in Sept/Oct of last year. So we’re doing things right, and you can’t just add 20 or 30 more people to this type of project. You need the time, and everybody feels right about it.

That’s been a sort of a validator for me. It’s not just the founder saying, “It’s not good enough. Go back and finish it.’ It’s more like everybody coming to the table and saying, these are things that we need to improve. While we’re in there let’s do it right and make sure that it’s not just on par with what the old product is but it’s 10 times better. That’s definitely what we’re taking time to do.

Ledge: Yeah. New features and better features, and also probably some technical debt remediation that comes up any time you touch things.

Craig: Oh, man. The technical debt part is probably where, for us, most of the time is coming from. We’re untethering from Backbone for our web app and moving over to Vue. With that, the team has created like a visual UI language from the ground up so that it’s easier, hopefully, moving forward to get this product release velocity moving.

The Backbone architecture that we were kind of intertwined with or dependent on was really slowing us down. Right now, the velocity that we’re seeing just internally with our test releases and product releases internally has been a lot faster.

I’m looking forward to that part of it too. That we have a new language to describe the UI, to describe the product, and it’s more closely bound to the actual code base too. That feels pretty good.

Ledge: I imagine you’re some kind of agile type of arrangement. How did you decide that you had to do a whole – I guess it’s a rebuild, right, in some ways. You would think that if you went to a rapid release cycle, for example you could do, every month or every two weeks even, you’re going to push new stuff and slowly replace the old one.

Now I know that’s very textbook and it belongs in a blog post, so I’m curious why, in your case, could it not be that way? I ask the question because I happen to know that in many cases it isn’t that way but we often think that we can do that.

Craig: My initial instinct is to say, I’m hoping and betting that things will be that way once May rolls around, and I agree wholeheartedly that things should be that way.

To get a product and a team – I’d say more importantly a team – to the point where everybody is so aligned like that has been where most of our effort has lied in the past year. It wasn’t as easy for us to do that.

Initially, frankly this started out as a redesign. To say, let’s brush up some things because it’s a six-year-old tool, and because we did a pretty good job initially we didn’t really have to overhaul so much. But we went through a marketing, kind of a rebranding thing last year and we wanted the product to visually align more closely with what we were doing on the front end of things.

As soon as we got into it, that Backbone thing was like, hey, what’s going on? No. You can’t do that so quickly.

So, Anthony and Grant who were the lead developers, they took a look at things and decided we got to go in a little bit deeper. We got to get away from Backbone and move toward a more modern, flexible framework. So they went through that audit. There’s plenty of frameworks out there and Vue is where they landed. In fact, they’re down in Florida right now at VueCon jamming out.

Anyway, I think for us we couldn’t be the team that we wanted to be – which is probably the worst answer for that question.

Ledge: No. It’s a truthful answer. That I think people take this for granted, that there isn’t an organizational engineering that goes behind it. It’s 80% people engineering. That, how do we build the thing, a group of people, that moves in this truly agile fashion? I think that gets missed.

You’re absolutely right and I appreciate the transparency and honesty of it. I think that gets missed in some of the happy stories of, we just need to increase release velocity and cadence, and if we just follow this… But the reality is that there’s usually one or two heroes dragging everybody else along who maybe hasn’t been steeped in the literature, or hasn’t had that experience. It’s a totally different way of thinking.

We have all been trained that you build and deploy and maintain. You do that in virtually every place in your life. What this new architecture and cloud-first and all these things is really about build, deploy and be willing to destroy and throw things around.

I think people don’t realize that you don’t have that same disposition in other places. Like, software actually turns out to be different. It’s not a building or it’s not a durable thing. Creating for destroying, and rebuilding quickly, is a totally different disposition that just doesn’t apply in regular life.

Craig: There’s also different expectations for the timeframes too. Being on a weekly or bi-monthly release schedule is something, again, that I think we will get to soon but that’s not where our business is at right now. So it’s almost like we’re rebuilding the business. That timeframe is just bigger. Right?

I told the team a couple of weeks ago, and I think I’ve said it a few times prior to that, that I’m glad everybody’s not satisfied with where the work was, where the product was, where what was supposed to be ten times better was. I’m glad that nobody argued with me saying, “No, no, man. We don’t want to go back.”

Right now there’s a files product instead of Kin. So you upload files, you can sign them digitally, create forms or their PDFs. It’s sort of like Google Drive. You store them and all that. You get done with it and everyone took at it and went, huh, well, that’s not good enough. Nobody argued.

So we went back to the drawing board and now we’re getting through design. We’re iterating in InVision. There’s a bunch of other forms of iteration before stuff gets into code that we are realizing. To some degree, a team like ours is iterating just internally, and tools like InVision are really great for that.

Ledge: Which didn’t exist three years ago.

Craig: No.

Ledge: Six months ago it wasn’t as good as now. We’re all on this innovation slope that is so steep that committing to anything. In two years you’re going to be going, “Gosh, I wish we didn’t use Vue because there’s this new Craig.js and it’s amazing.” That’s just going to be true.

Craig: I hope not.

Ledge: Right. Well, we have major customers where Ember was the greatest thing, and now, ah hell, we need to go to Reactor. Whatever.

I don’t think that it’s ever going to change. If anything, it’s going to be like every one year, every six months. So, how do you build in the most granular way that you can replace tiny pieces without breaking everything, and, oh, there you’ve got microservices which introduces all kinds of problems for how do you make that all work together.

It’s a very, very complex set of abstractions, not all of which are technology. I completely resonate with the hidden challenges of that. The iceberg is not very far out of the water.

Craig: The thing that feels really good right now is that everybody is looking at the product from a customer perspective. It sounds contrived to say but everything else, every other decision like that tech stack or what we’re doing, why we’re doing it, is through that lens. It makes me less concerned about Kin’s future tech stack.

Like you said, maybe whatever JavaScript is going to get deprecated entirely and then it’s going to be a whole lot… God help us. But I’m less concerned about that because of the cohesion of our product team right now. Where, no matter what, those decisions are going to be made on behalf of the customer. Whatever’s going to be delivering that value to them, that’s the decision that’s going to get made. Which sounds sort of reverse, but we don’t have anybody really so far removed from the customer’s perspective of our product and they’re only worried about JavaScript libraries or something like that.

Ledge: It strikes me that you have a very unique opportunity to dogfood what you do for your clients. Your product is based around a very cohesive set of new work, or better balance. All the things that you ought to do right.

It sounds like you’re kind of manifesting that through engineering. That you get to dogfood that process that is then represented through the product. The dog starts to look like its owner. Is that intentional?

Craig: That’s the story of Kin, actually, was because we were hiring a lot of remote engineers back in 2011/2012. We created like an intranet – to borrow a term from the past – a homepage for every new hire. That’d give them a sense of who we are, where we are because we had an office at the time. Introduce people to the new hires to our team. Give them a primer on places to go eat lunch and stuff like that.

That became a calling card for what became Kin. A new hire onboarding experience.

Our original charge was to make sure that a new hire comes in on the first day ready to work, and what does it take to do that? All the computer stuff, the paperwork, all that can be done remotely even if you have an office. That’s what Kin has become.

The other things that we’re dogfooding right now that are not baked into the product, but the things that we’re experiencing that we’re kind of in a discovery phase about, would be engagement.

Engagement is different than feedback. When we talk about employee engagement, which gets pretty far away from technology admittedly, but how are we interfacing with folks who are around the country when it’s not purely performance based feedback that they need? If we know that we’re doing a decent job with performance feedback, what are the other ways that we’re learning about how they’re experiencing our workplace?

So, tools like Office, for example, start to scratch that itch a little bit. Now, when you join that together with demographic data that we have inside of Kin, when you join that with patterns and time off utilization. How often are your employees getting out of the office? How are they spending that time? Are they recharging? You can mix and match that with employee engagement data. That starts to get pretty interesting.

The other thing that’s interesting right now is remote workplace compliance. When we have employees all around… We just got through corporate tax season. All the places that we had to send paperwork throughout the year – for workers comp, for just tax returns. Every state. Every county. Every city is a little bit different. That’s another opportunity to improve.

That is not so much employee experience as it is employer experience, but that’s something that we’re finding out about right now. That there is not a tool out there right now that’s automating or even helping with compliance for remote workplaces. Remote workplaces, the companies are doing that. You’re sitting at home right now and so am I, right? So, how are we helping those companies make sure that they’re in compliance with all of those local and state laws? If we have 14 employees, imagine having 70, 80, 100 employees in every different state. Some in Canada. Some in France. There’s a big opportunity there too.

Ledge: Absolutely. You evolved from on-site to remote – or rather collocated to remote probably is a better way to put it – and what I hear from a lot of tech leaders and business leaders is that neither full collocation nor full remote is as challenging as hybrid.

I wonder if that was your experience. That, as you made that migration… Or did you rip the Band-Aid off and be like, “Hey y’all, the office is going to be locked tomorrow. Let’s figure this out.”

Craig: We originally hired people remotely, and our objective or employee experience mission for them was to make sure that their experience working with our workplace had the same fidelity as if they were in the office.

So, we did things the right way to begin with. Making sure that computers were set up. That we had remote access to help get devs set up. Like, where we use .NET] and Windows and we’re on Macs. There’s a lot of work that has to happen and kind of make that work seamlessly.

VPN had to be quick. The paperwork bit that I mentioned before, we always did it right. There are things that we have not always done great, but that employee onboarding thing has always been done well, regardless of whether you’re in the office or remotely. Even when we only had two or three people who were working remote, they always felt dialed in to our culture and I guess sort of plugged in to the vibe.

Right now we’re 100% remote so we’re kind of all used to that at this point. Like I mentioned before when we were chatting, remote does not mean flexwork. Even though we’re in all these states, people sign on at the same time every day, they sign off at the same time every day, because they want to be together. Even though we have digital versions of a physical workplace, people get the sense that there is a community here, and they dial into that.

Broadband has made that easier, certainly. The fact that we no longer have to host VPNs and stuff like that internally at our office has made that easier. Amazon. Back when we started doing this, Amazon, like would be out. It would just go out and then the internet would be off. That’s no longer a problem.

So, all the tech backbone is in place to do this the right way right now. All you need is a will and then you need an understanding. You need to know that, as an employer, all things that make a physical workplace successful, you need a virtual or a digital counterpart to that.

Ledge: Last question. Everybody is thinking about this now. You’ve got to be thinking about this. Top three things that are the most important there.

Maybe you’re trying to solve it with a product. Maybe it’s just encapsulated in the culture. But, I think I’ll be bold enough to say, everybody wants what you’re describing. What are those top things that you think about maintaining such that everybody wants to show up in the virtual environment?

Craig: We started 2018 doing something that we pieced together called employee canvases. We do assessment when people join our team. They’re like desk assessments and thinking wavelengths. Anybody can do these things. We try and join those with almost like a peer review of who a person is. Then we try to get at what a person’s strengths or what their shortcomings are when they’re dialed in as a team member.

Shortcomings being, sometimes your personality doesn’t shine through on Slack, for example. Slack is something that I’m pretty sure all remote companies are using right now. Some people aren’t great at it. Other people are. Acknowledging those things.

Learning who people are and helping them along that route as opposed to always thinking about what’s going to best, what the deadlines are, what our business objectives are. Coming at our business objectives and those OKRs through the context of the person is something that’s helped our company become who it is today.

I say that with pride, but I also say that because we haven’t always been that company. So, for the team that comes to work every day, it’s a mix of autonomy. Knowing that our business objectives are clear enough for them. They know how our work ladders up to our mission as a company. Knowing that we encourage them to take all their time off to get away from work. Work is not everything, you know.

Giving them that sense of trust is important. Exposing them to problems that our clients have, our customers have, that we have internally. Making sure that we’re transparent and letting them know that we want them to help solve these problems.

I’m not a micromanager. I need my space as well. I’m just another person working. I need my time away. I’ve got a family. Work needs to kind of fit into the lives that we’re trying to live. I think my job as an employer is to help people acknowledge that. Make sure that their work life can be as fulfilling as possible and then say, “Listen, work is not the primary goal here all the time.” If your fulfillment in life as a person is a pie, work can only fill up that pie dish about 50%, maybe. The other part of remote work is that, if you’re not happy in Chicago, move to Nashville. If Nashville’s not your bag, move to Portland. You can take your work to go. We’re remote. Just be online at 10:00 a.m.

Ledge: Excellent. Well, Craig, I love it. Thank you for sharing the story and good luck with the never ending launch. You will get there, so keep up the fight.

Craig: We’ll get there. Thank you for having me.