From Startup Weekend to YC to startup success with Matthew McDonald

Transcript

Ledge: Matthew, great to have you. Thanks for joining the show.

Matthew: Hey, Ledge. Thanks for having me on. Appreciate it.

Ledge: Cool. Could you give your two or three minute intro story, just for the audience to get to know you a little bit?

Matthew: Sure. I’m from the Midwest. I went to university in Missouri. Worked for a online mortgage company for several years out there. Did a little bit of consulting afterwards.

At a weekend event, I bumped into this group of contractors that had this burning desire to change how equipment rental works. There was just a really compelling problem, and we ended up actually making a sale for placing a skid loader on over the weekend during that event. It was great validation and so we kept working on it.

A few weeks after that one of my previous coworkers, Wade Foster – who actually ended up going on to one of the founders of Zapier – convinced us to apply to Y Combinator. Which they went through that program as well. I kind of wrote it off and I was like, “Y Combinator, that’s something for Silicon Valley people. That’s not something that construction tech companies in the Midwest – it’s not really for them,” which I was wrong.

We applied, got in – much to our surprise – and a few weeks after that I gave notice at my consulting job that I was going to quit.

This was all happening right as my wife had taken a job to move us out to Maine, and so our engineering team was remote from Day 1 and I was jumping in head-first and doing it with these other people that I had only known for I think a month-and-a-half, at that point. But they had just totally convinced me that they were some of the most genuine, hard-working people that I’d ever met.

After that, we worked at Y Combinator. Originally we were very peer-to-peer, much like Airbnb, where we’d link up a contractor that owns a machine like a bulldozer and one that wants to rent a machine. We just put them touch and have them figure out the logistics of it. That went really poorly just because of communication issues. Where, think of your real terse communicating contractor, and you write them like a two-paragraph email detailing a specific problem and you get an answer, and the answer is yes. I’m like, well, it wasn’t a yes or no question.

But that, compounded with the fact that they’ve got their own really chaotic businesses and they don’t have time to do logistics for someone else’s contracting company on top of that.

We fairly quickly figured out that we have to have centralized rental yards. That means that if you are lending machines out on our platforms, then they get dropped off at the yard. Our mechanics service them, maintain them. Our delivery drivers can facilitate deliveries. It just lets us control things and make sure that the customer gets a really good experience all around – from first contact, to final delivery, to billing, to everything.

It was really important for everything to be consistent and better than our competition in pretty much every way. In the construction industry, it’s pretty conservative about making changes and new choices. If something goes wrong and someone gets burned trying this new startup for something, they’re probably not going to give you much of a second chance.

After we pivoted to that centralized model we started to open up new yards, and the next thing we realized is that we just couldn’t do this without accurate and up-to-date information on where the equipment is and how it’s being used. We tried to reuse other companies’ telematic services. Weren’t happy with the quality of the data that we were able to get, and the fact that we were relying on their other services whenever there was downtime or outages and things like that.

So we actually built our own telematic service from the ground up. Now we can tell where everything is, how it’s being used. We can actually look at engine failure codes. Our data science team is working on the ability to predict when machines are about to fail but haven’t fully broken down yet, so we can dispatch techs, get them out there on sites and minimize the downtime.

At this point, we’ve added several more products along the way that all of them have a ton of synergy. We have an insurance company that we can look at where the machine are being used. If they’re on a rental, we know it’s insured by another company, the risk profile changes a bit. It all comes back to that accurate data on where things are, how they’re being used. It all ties back into the needs of the construction companies.

Ledge: That’s so interesting. It’s all the business stuff that goes in. You kind of think, oh, we’re a SaaS company. We do technology. Then business gets in the way and all that stuff.

Off-mike before, I thought this was really interesting. You and I were talking about your own journey from founder in the engineering scale of just a massive startup on a vertical growth curve.

Love if you’d tell that story because I think a lot of the audience will resonate with it.

Matthew: Sure. This was definitely my first time even leading a small team. Starting out, I was CTO and co-founder and was building a team around that. If there’s one thing that I think I did really well from the beginning it was to surround myself with people that are better than me in some way, and that always added to the team and brought something new that would raise the team up.

But one thing that I realized is that, while I was having a ton of fun when the team was smaller – up to around 10 or 12 people – once we hit an inflection point and we grew the team from 11 to 35 in a period of four or five months, when that happened everything just radically changed. Processes broke down. Anything that works really smoothly for a team of 10 just did not handle a team of 35. There were more products that were being built. Inter-team communication wasn’t going well.

At the end of the day, if you’re the CTO you are responsible for everything. The buck stops with you from the technology side. I found myself in a position where I was responsible for everything, but I didn’t have the skills or the knowhow or the ability to influence things in the right direction when I saw that there was a change that needed to be made. Sometimes I just didn’t realize that there was a change that needed to be made because I didn’t have that particular skillset.

What I found was happening was that I was becoming more and more unhappy because people would have problems, and when there was someone that I was responsible for supporting I would fixate on that. If someone let me know they were unhappy I would be unhappy until I was able to resolve whatever their problem was.

That can work when you have a small team but when you have a team of 35 people, I can guarantee you every single day there’s going to be someone that’s unhappy about something. Even if it’s something small and trivial.

I started taking that stress home with me. I was unhappy in my personal life. Basically, what happened is one of my other co-partners came to me and he was like, “Hey, do you want to do this?” I had to stop and think about it because it was just like it had never even crossed my mind that it didn’t have to be me, because that was just the role that I was in at the beginning and this is me. I’m the CTO. This is my job. There’s just that expectation that you just grow into it and you continue on and that’s just what you do.

I’m incredibly thankful that he approached me about it because now I realize, it didn’t take long for me to realize that, hey, I actually don’t like what I’m doing at all and no, I don’t want to continue doing this. So, I kind of side-stepped and I guess abdicated the managerial and morale and leadership responsibilities and just focused entirely on the technical side of things.

My official title now is Principal Engineer, which basically means that I guide the technical direction for a couple of different projects, and sometimes am heavily involved in spinning up a new project or team or something like that – getting them going and then onto whatever the next big need is.

Ledge: I love the personal and psychological awareness necessary. Also the humility to just step back and be like, I know what I like to do and this isn’t it. That it so often takes that peer or mentor-like person to shake you a little bit and be like, “Which seat do you love, and why do you love it?”

What was the transition like? Your fellow engineers would experience you in a different way, and how did you message that? I think for some people it would be like a pride component. It would be hard to communicate that.

I just wonder how you dealt with that.

Matthew: Yeah, there definitely was an aspect of pride. I didn’t realize how much pride I had at that position or that level until we were discussing how to go about it. That was the next thing that we discussed once I realized, no, I’m not going to continue doing this. Was, how do we make sure that everyone understands that this is good thing, this is smooth, and it’s not a catastrophic or a shocking change or anything like that?

I think it was probably easier for people to understand because, at that point, probably a third of the people had been around and worked really closely with me and I suspected that they knew that I wasn’t the happiest about a lot of things.

I essentially had one-on-one conversations with everyone on the team. For most of them, I would try to meet up in town locally, whichever city they were in and just go for a walk. Talk about, hey, this is what’s going on. Explaining to them that…

I told almost that exact same story, basically word for word, to 30 plus people and told that, hey, I’m really not happy with what I’m doing. Here’s what we’re going to do. We’re going to have those responsibilities go to Willy, my co-founder, for a while. He’s an incredibly good person for dealing with people and emotional issues. He’s extraordinarily good at that. Then, this is also tied with me taking a vacation for a bit, and we were also going to start looking for a director to come in and more formally take up that particular role of engineering management.

Ledge: As the principal engineer then, are you able to not have to deal with any of the people issues and you can really stay focused on technology? How does that impact the communication stuff? Are you able to just go, “Hey, I don’t want to talk about your feelings. I really just want to code.”

How does that really shake out?

Matthew: That is not how it works out at all. Every project, every team, every product involves people. If you’re going to try to not interact with humans, you’re probably going to have a bad time.

It’s definitely a lot less in that the number of people that I am supporting is a lot lower. While I interact with a lot of people across a lot of different teams, it’s much more focused on, hey, I’m working on this project, this is the goal, these are the side effects that I expect will potentially affect the systems that you work on a lot. How can we come to an agreement on the best way to proceed with that?

I guess the biggest change is that I am not the person that people go to if they have either a personal issue or a team issue, or just they’re dissatisfied with something. Having personnel issues or whatever. They generally only come to me now if it’s an issue with a technical solution or they have a question about why something was done in the way it was done. Or they want me to look over their proposal for something and give them feedback.

Ledge: You’ve got this story; the unexpected startup weekend, startup actually takes off and Y-Comb comes in and, wow, things take off and before you know it you’re scaling like crazy.

That’s sort of like the romanticized startup story that people aspire to. I just wonder, what are the learnings from there? It’s not all the romance. So, careful what you wish for and here’s what I wish I knew going in.

It is a success story and you own a piece of something extraordinary. But what’s the both sides of the coin and what do you wish you knew then?

Matthew: First of all, I was probably the most pessimistic of all of the co-founders that it would be the success that it is, and could very likely turn into. I think part of that was just because I had this idea that this wasn’t something that was going to happen to me. It just seems like a crazy thing.

We’ve always focused on, what is the biggest problem that’s blocking us from getting to the next level? Always focusing on identifying what the bottleneck is immediately. Obviously, you want to have some sight down the line so you don’t box yourself into a corner, but that’s probably one of the best lessons that we learned in Y Combinator, was how to identify what’s critically important and needs to be focused on right now, and what can be either sidestepped or delayed or put on the backburner for a while.

Ledge: What’s it like dealing with a customer base that is, whoa, not technical. That’s just not what they do. You have to really abstract that, I imagine, quite a bit of that experience in a customer empathy kind of way because, like you said, they aren’t just going to deal with that. But you are providing critical service, because I’ve seen where renting equipment is expensive and difficult, and it breaks down, and what do you do? Folks are depending on this ability and you really are opening up a market that helps the individual a lot.

What’s it like dealing with that customer base?

Matthew: In the construction industry there’s usually a very low margin. If there’s a delay on a project and time slide, there can be some clauses in contracts that have 10 penalties for delays. So your project that had a 3% margin, if a couple of things go wrong and they cascade, then you could end up working for no money after eight months or a year or something like that. It’s really important to be able to deliver what you promised.

From a design perspective, we’ve gotten a whole lot better about designing UIs that work for our customers and not making assumptions based on what we think. A lot of the original UI was designed by myself or other developers that weren’t really designers, and they were not great. I’ll leave it at that.

Our audience is definitely not the most tech savvy. Sometimes tech averse. We’ve got a lot of people that they use flip phones and they don’t…

I remember a direct quote from an early customer where we tried to sign them up and we were onboarding them with, “What’s your email?” because we had a required constraints that you had to have an email in the system. It was this old-timer and he got a little with us, and I think a direct quote from that conversation was, “I don’t have email and I don’t want email.” That’s just the type of people that we’re dealing with.

Now, I don’t know if I would say we do the best job because there’s always room for improvement, but I’m really proud of how our team comes up with its designs through working with the customers and our employees. We employ a lot of people on the service side, mechanics, deliver drivers. We dogfood all of our own software. Almost everything that our end customers use, we’re also using for something internally.

We have Slack channels that are populated with engineers and product people and delivery drivers and mechanics and everyone from the operations side. They know that when they have a problem or a question they will jump into that Slack channel and we’re able to respond really quickly and help them.

Sometimes it’s just a training issue. Like we rolled out a feature and didn’t do a great job of informing people ahead of time that this is how you need to do this task. Sometimes it’s just a bug, really something that we catch an error. Maybe we’ll onboard a branch that our standard operation flow doesn’t fit with them. Like, down in Midland, Texas there’s a lot of oil work and just the whole sales cycle works completely differently than our other branches and so we had to change some of our business rules to reflect that.

A lot of times, we will get comments from our operations employees. They’re kind of blown away because they’ve never worked for a company where they’re so listened to and not more so than just, “Oh, I hear you. That sucks but you’ve got to do it,” but we’ll actually turn around and deliver new features for them very, very quickly.

We have an all-hands company meeting once a month and our CEO, Jabbok, has his cell phone number and email address on one of the slides. He always just hits home and talks about, if you have a problem you go to him. Obviously, we don’t want everyone calling him all the time for any little thing that happens, but if you have an idea for an improvement or an efficiency or, hey, there’s this broken process and it’s really painful to keep on continuing the way it is, we want to hear about it and we want to fix it and make things smoother.

Ledge: Last question. I’m curious. You’ve talked about being remote from Day 1. What are the things make that work? You probably take it for granted that you’ve always done it that way, and I can tell you that I deal with more people that are really struggling to think about the new world. It’s, jeez, everything from our environment, to the way we communicate, to all the little details of working together in an office, the hiring environment now just doesn’t support it. We need more engineers and there just aren’t any more engineers, so we need to go remote and we aren’t prepared for that.

Any thoughts on how to restart, if you will, and build a remote engineering culture that works?

Matthew: I think it’s really difficult to have a hybrid remote environment. If you have 80% of the team in an office and 20% of you are working from home, those people are going to get excluded from a ton of information just from water cooler conversations, or people chatting or hanging out, discussing things not in Slack channels or emails or whatever you’re using to communicate with things. Those people, they’re going to miss out on critical information and it’s going to be very frustrating for them.

I think that if you’re going to have a successful remote team, then it probably needs to remote first. Even if you have an office and have people in the office, then everyone needs to be onboard with the idea of communicating using the same channels by default.

We have offices in Columbia and Kansas City. We do have some people that they work in the office every day because they just enjoy having more separation, or they just don’t have a good place to work at home, or whatever reason they just prefer to do that. Even if they’ve got two people there on the same team, in the same office, they’re usually going to communicate with each other over Slack or over Zoom or whatever digital medium that the team is using for something. That, I think, helps with a lot of the issues.

I do think it can be hard to convert a team from in-person to remote. I think that’s a hard thing to do unless you have really good buy-in from everyone.

I think the other big thing is, when we’re hiring people we’re generally going to be a little skeptical if we’re trying to hire someone who is fully remote and they’ve never worked from it before and they’re more junior on the skill side. If someone is really experienced, they can probably figure out the remote side, or if they’re experienced in working remote and more junior on the skills that can kind of work, but we generally will avoid junior employees who have no remote experience.

That’s just because we want to set people up for success, and part of that involves having someone sit next to them for at least a couple of days onboarding them. Making sure that any time they have a question or they get stuck or whatever, we’re able to answer that and unblock them really quickly.

Ideally, someone that comes onboard should be able to work their first feature and open up a merge request by the end of the second day. We really value close feedback cycles and getting people into that group of pull a card, start working on it, go through QA, open a merge request, on to the next thing. Just breaking that down into small chunks.

All that being said, there’s definitely drawbacks to remote. I have not found a substitute for having everyone in the same room with a whiteboard. That is just not something I think exists right now. We’ve tried a lot of different technical solutions.

Sometimes we will have a kickoff meeting and we’ll try to get everyone into the office, or as many people as possible, and have maybe one or two people dial in who are just in other states. We also believe that’s important, to bring the whole team in in-person together, just for some in-person bonding time. Celebrations. Team activities. Build those personal relationships that you don’t get as much when all you interact with someone is through code, or email or Slack or something like that.

Ledge: There’s a lot there. So much to unpack in the whole cultural thing. Maybe if I could paraphrase, and I have seen people do sort of really deliberate hybrid and they’ll even literally set up workstations where there’s an always-on Zoom connection to that person’s desk and you have to walk over there and talk to their Zoom channel.

I think it does take that real intentionality of, like you said, dogfooding. Not only dogfood the solution but dogfood the experience of being remote. Each workstation being a remote office, even if they are all next to each other, you’re right, tremendous change.

I think tech leads now are just simply going to have to deal with that, particularly in places where hiring is off the charts – like in New York or San Francisco. There’s a lot of people struggling with this. It’s like, wow, we never anticipated we’d have open reqs for a year and that we just don’t have enough engineers. So yeah, critical time. Big changes.

Well, Matthew, totally appreciate you sharing your story. It’s really cool. I know a lot of people go through that stuff and maybe don’t express it so well, so I really appreciate that.

Matthew: Absolutely. Great talking with you.

Ledge: Thanks for joining us.

Matthew: Have a good one. Bye.