This is the second in our Mucker Academy video series, where we invite leaders from the tech community to speak with MuckerLab companies. You can find the first video here.
Kevin Diamond is CTO at The Black Tux, a Mucker portfolio company that's reinventing the tuxedo industry. Kevin spoke about his early days as co-founder and CTO at HauteLook, the relationship between product and engineering, hiring technical talent, customer success, and much more.
Watch the full video right here, or read some of the key takeaways transcribed below.
On the early days at HauteLook and needing to launch quickly:
Kevin Diamond: ...We did what everyone should do - focused on just the customer experience, did not care about whatever we had to do on the back end to make the thing go live, how we were going to ship product out, how we were going to deal with returns, any of that stuff... that was all off the table for launch. Again, just being able to focus because we had such a hard timeline and a hard deadline really allowed us to focus on what was important, and not spend too much time building things that, sure, were also important but would never be seen by the customer... weren't important for testing whether the business model worked, and also just weren't important from the standpoint of being able to prove whether it's a successful model.
On growing fast, and the earliest hires:
KD: We were based in Downtown LA and we were in this little showroom, on the very top floor of a very old building. We were adding people nonstop, so the joke was that we hired 30 people and I had 30 different desks during that time, because I would keep giving up my desk and being like 'you work here, I'll just take the corner until the next desk arrives from IKEA.'
It was about getting people in the door as quickly as possible, getting them ramped up on being productive, and so the things I always looked for was someone really smart and able to get things done. And by having that as my bar, and it wasn't about 'do you know the technology we're utilizing, do you know the ecommerce world,' none of that mattered. You'd figure it all out when you're here cause we're all figuring it out too. It was just about having the brains to tackle whatever challenge was in front of us, and being able to not just be brainy about it, but also to be executable about it.
On the relationship between product and engineering for early stage CEOs:
KD: [As a CTO discussing a product with a CEO], I will never say that something is impossible, because there is nothing that is impossible. But I will always tell you when it is much harder than it needs to be, and that we should rethink it. And so, because we had that open and honest conversation between the CEO and CTO, he knew I would never say, 'no we can't do this, or no we're not gonna do this,' but just as similarly, he knew that I would be the first one to tell him, 'I think that's a dumb idea, I think it's going to take way too much effort to do that, and therefore maybe we put our efforts towards things that are more valuable.'
So, the flip side to that is that both sides have to be open to the consequences of that. So, hearing that an idea that you have might not be the best idea and be willing to be like, 'ok, let me rethink this, and let me think whether this is the right thing to do,' and then on the tech side, if you've raised that flag, and they turnaround and say, 'no, this is really important,' then be like, 'great, OK, we're gonna buckle down and get this done, and we're gonna figure out how to do it in the fastest way possible with the least number of people possible, and push forward.' ...And so, I think as long as you have that understanding from the start, it helps dramatically.
On customer success:
KD: I'm sure everyone has heard this a thousand times, which is 'test, test, test, test,' ya know. It's very important that the product people or your designers are putting together mock versions of what you might want to do. Get that in front of a customer long before you actually have anyone writing lines of code against it. It's sometimes surprising that, 'oh, the person didn't notice that the next button was down there, or the cancel button was up top,' ya know, that that wasn't a given even though I've been staring at this for two weeks, and of course that's where those are.
And that's really where the customer success comes in. Part of that is understanding what that customer success looks like. So, if you're building a feature, what are you trying to get. In ecommerce, often times that relates back to conversion or a registration or a few of these kinds of touch points. But, often times, especially when you're just tweaking something, it might just be as simple as 'I want to see someone get to that next step at a higher rate than maybe we did before.'
And it's just as important for your engineers and your technologist to understand what those metrics are so that they understand what they're building, that kind of 'why' you're building something, and not just the 'what.'
On hiring the first non-founder engineer
KD: Don't try and find someone who is extremely specialized because you want to get rid of that one part of what you're doing. Again, look for people that are full featured, and if they are those things, no matter what you put in front of them, they're gonna figure it out. Sure, maybe it'll take them a little bit longer to do the CSS than if you had gone and hired a strictly front-end engineer, but at the end of the day you're going to have someone who can offer so much more. And, you don't know the balance of what the work really is going to be when you are such a small team. So definitely, go for broad, go for very smart, go for adaptable, because they might be doing one thing today, and doing an entirely different thing tomorrow.
And, you have to find someone that is extremely passionate, and believes in what you are doing. They can't be there just for the paycheck. And that kind of intelligence piece of it is being smart enough to know what the market opportunity is - why you're doing things, not just what you are doing.
On working with off-site engineers:
KD: You can outsource work if you do it one of two ways, and you have to be very considerate not to blend the two models.
First model, you actually interview the person just like you would someone who is gonna be on your team, and you interview an individual. You're not looking for them to provide you a whole team of people, I just want one or two... and they need to be at our stand-up, I don't care what time it is in their time zone... they are fundamentally part of the team just like any other engineer you would possible have. So, that way works great, and you manage them.
The other way that it works is what I like to call the 'black box model,' where essentially you come up with something that you are able to hand over wholly to them, and you are entirely OK with whatever decisions they make in the way that they're going to deliver it to you.
When we launched our first native app on the iPhone for HauteLook, this was 2009, we were one of the first people with an ecommerce native app, and we weren't sure whether people would actually want to interact with us in that format. So, we let someone else build it, they delivered something, and we knew that we were going to take it as an entire write-off if it didn't work well, and if it worked, great...
So as long as you go with either of those two models, it works fabulous. If you try and make it where 'oh, they're handing over an entire team, but I'm gonna semi-manage them, and I'm gonna tell them how to work in our code base and what code they need to touch,' you're just gonna find that's not the way they are used to working, you haven't interviewed any of the people so you might not like the quality of their code... you just run into lots of problems.
Keep up to date on future Mucker Academy videos by signing up below.
