From Founder & CEO to Engineering Director at HashiCorp

Marty Haught, Director of Engineering, HashiCorp

I’ve often wondered what it would be like to be an employee again after founding my own business. To find out about the experience, I talked with Marty Haught who founded his own consultancy, Haught Codeworks. He sold the business and is currently Director of Engineering at HashiCorp. We talked about the reason he wanted to be an employee again, what the transition was like, and what he’s learned about navigating organizational culture as a leader.

The last time I saw you was at the end of November, or early December at RubyConf in Houston.

That's right.

Yeah. We had some nice meals together, including one epic one.

Yes. They tend to happen at conferences.

Can you introduce yourself for those who don’t know you?

Absolutely. I'm Marty Haught. I am a director of engineering at HashiCorp, working on the Terraform product there. Prior to HashiCorp, I worked at Fastly, and then before that, I ran my own software consultancy for 13 years. I've been in the tech industry for a bit over 25 years. Before that, I had two mini careers as a professional musician and in the US Army, 101st Airborne, and so very, very three different experiences there, but I settled on tech and I love it here. 

The other piece I'll mention, which most of your listeners that would know me probably know me this way, is I am on the board of a non-profit called Ruby Central that operates two popular software conferences, RubyConf and RailsConf, and I've also done other event organizing outside of that, most notably starting Boulder Ruby, a monthly meetup in Boulder back in 2006. It's still going, although I am not an active organizer. Two others do most of the work, which is fantastic. And then I solo organized a conference in Boulder called Rocky MTN Ruby, which of course, you spoke at in 2011. I did that until I joined the board of Ruby Central in 2012.

Yeah, we go way back. We've known each other for over a decade. We met during my time in Boulder. Lots of folks who know me now don't know I lived in Boulder for a while, and I have an incredible group of colleagues and friends from that time and you are one of them.

Yeah.

I just have a quick diversion. I knew that you were in the Army for a little bit and you said Airborne Division. What does that mean?

Sure, sure. The 101st Airborne is a division in the US Army. It's an infantry division. It's out of Fort Campbell, Kentucky. Airborne means that they jump out of airplanes, which they actually don't do anymore. They're air assault, which means they repel out of helicopters, which is also pretty cool, and a lot more practical from a tactical standpoint for getting troops on the ground and all that. 82nd Airborne is the other airborne division in the US Army. I joined the 101st at the age of 19.

So wait, did you jump out of airplanes then?

I did. I did.

A lot of times, more than once?

Not a lot of times. I did, more out of helicopters, for air assault.

I've never even been in a helicopter. It was just so fascinating because I always think of Army as the ground. Do you know what I mean? And when you say airborne ... Wait a minute.

Well, yeah. I mean, we do primarily work off the ground, but it's a nice way of getting troops into a tough-to-get spot where you might not have roads or wherever you're trying to get.

Was it terrifying to jump out of airplanes and helicopters? Are you afraid of heights? Was it totally fine? Did it get easier?

First of all, with an air assault, I don't know about airborne training because I didn't do that through the Army, I did that as a civilian. With air assault, they test you for fear of heights in air assault school when they start you off. Basically what I learned was that at 34 feet, once you're 34 feet off the ground, if you have a fear of heights, it will trigger by then and if it doesn't trigger by then you're good. 

I was pretty young and I wasn't terrified, but I had a healthy dose of carefulness because you are a fair amount of distance off the ground. Helicopters, you have this whirling blade of death above you that keeps the machine afloat. Things can go badly and hopefully, that doesn't happen and it didn't happen for me or my fellow soldiers that I was serving with.

Wow, very cool. Very cool that they test for that. It makes sense. The last thing you want is someone whose body is having a really serious response in a critical situation like jumping out of a plane. 

Indeed.

You're currently the Director of Engineering at HashiCorp. Before that, you were the CEO of your own consultancy. Can you give a context for what that looked like and what it looked like when you were departing it?

It started very small just me going independent in 2006, and the goal was I was tired of working on terribly run software projects and I was pretty sure I could do a better job running them myself and that turned out to be true. What was interesting when I started is my goal was really to create that environment to build better software, but what my goal wasn't, which probably should have been, was how do you run a great business, which I eventually stumbled into after making plenty of mistakes, but I was more focused on the tactical, building great software, working well with clients and all that versus how do you build a pipeline and grow a company and all that. I also was very much interested in work-life balance and the notable thing about Haught Codeworks was we were remote from the beginning. So in 2006, it was very important that I didn't want to commute anymore. I felt like this was not necessary. It was a waste of time. I didn't like it. And the work, the servers, everything was not local, so why do we all need to be local? Of course, back then, we called it telecommuting, which is hilarious.

We did. That's right.

It's true. I definitely prefer the term remote over telecommuting. I think that was what got me going on that and it worked, but I also purposely kept us small. For instance, the largest we ever got was 13 as a consultancy and I did all the non-technical stuff. I didn't have any salespeople, I didn't have anyone doing operations. I pretty much did everything else. In the beginning, I did everything, but as we got larger, then I deferred writing code and I was more client management and project management and all that.

What made you end that chapter and go back to working for other people?

One, I probably did it too long. 

There was a point where I was wondering, "Why am I doing this exactly? Is this just a lifestyle? Is this going to be my career for the rest of my life?" And the answer was, "I want to do some different things. I want to solve different problems." 

When you run a small consultancy, you're essentially solving the same problems over and over again, it's just with different clients, and that's interesting and every client's a little bit different. Of course, the people are different and that's the rewarding aspect, but I got to a point where I don't know if I want to do all these things over and over again every year and there are other things that I want to do with my career that I can't do with running this consultancy. So essentially, once I came to that realization, I'm then like, "Well, gosh, I should have an exit," because I've built this thing up and it's worth something so I should see some reward for that and find a way that that value can be transferred to someone else, of what we built.

What was it like to lead while exiting? How transparent were you with people? How did you communicate about that? How did you think about that change and the people who are involved?

Absolutely and it's the only time I've ever done that, so I didn't have prior experience to lean on, but you have instincts. The whole process took about a year and there were two different potential suitors that we considered. One was a consultancy and we spent about eight months with them which turned out not to be a good fit for both sides, but it took a long time to realize that. The thing is, one, that we did a partnership for most of that time, so we worked with their clients. And to our clients, they aren't aware of all the different clients we're working with, they know it's multiple clients, and so that wasn't really a problem.

There came a point where, okay, this deal's about to happen once we talked to Fastly.  So Fastly is where we ended up going, that was a very big change because they have zero interest in consulting and so that means completely handing off the consulting business entirely and transitioning and that as we were discussing that, you can't do anything until it's resolved. 

There's this period of limbo where you're wondering, "Is this going to go through? Am I making the right call here? Should I negotiate harder? Am I missing something?" And ultimately with Fastly, it went incredibly fast. It was two months from the first conversation to everything's a done deal and transitioned. So that was pretty fast, but it also felt really good and there were no regrets about that. I guess the only regret would be that I couldn't tell my current clients until a certain point. At that point, the timeline was pretty accelerated.

We were at 10 total when that happened. Three were1099s that were not interested in going to work full-time at Fastly, so they essentially stayed behind to transition our clients and I found peer consultancies that would take over the clients. They were, of course, all too happy, "Oh, we'd love to take your wonderful clients, buddy, and we'll take good care of them," so that was great. I oversaw that, but at that point, I was working full-time at Fastly, so I wasn't spending ... It was in the evenings just to make sure things were going well and checking in, but ultimately it handed off that transition process.

It sounds like there was uncertainty for a while.

For sure. And all the folks at Haught Codeworks knew what was happening. I was pretty transparent with them about, "Look, we're going to consider this, this is why I'm doing it." They understood and of course, there was a point where, "Okay, who wants to come along and who wants to not come along?" And again, we had seven total that went over, so they all knew, but they also knew that what if it fell through? And so the uncertainty isn't great, you don't love it, but ultimately, hopefully, the reward of the deal is worth it to live through uncertainty.

Did you know that you wanted to be an employee or did you think about starting something else like a product company? 

Yeah, that's a great question because I had thought about that. One of the things that I was interested in is, what is it like to scale a company up? I had an opportunity later on to become a VP of engineering of a smaller startup, around 15 or so, and I chose not to go that direction because the thing that I wanted to work on next was, what it was like to take a company from, say, 20 or 50 engineers to 200 or 500 or something like that? And you can imagine the rest of the company is much larger, so what is that like?

So when I joined Fastly, they were already in that process. They'd just gone public. The engineering org was a decent size, so I got to plug in as a director there and work, really, in that middle layer, which was something that I hadn't had a chance to do. Before starting Haught Codeworks, I was not a leader.  I was not a manager at all, so I was just an engineer shipping code. I was interested in that experience and if I had started my own thing, it would've been a while before I would've gotten to that stage. Also, I'd be making mistakes in my own company, whereas I can go and learn from others and be right in the middle of it and have that experience immediately. So one of my motivators was wanting to move beyond the theory crafting and into, "This is actually what's working or this is not what's working," and being at a different scale, seeing how things play out.

Going from software engineer to manager and leader is a pretty good-sized jump. You hadn't done those things before you had your own company. I imagine it could be a steep learning curve or an exciting one.

Yeah, definitely. I mean, the one thing I had done before I started Haught Codeworks was I had led as a technical leader of software projects, so as an architect, as a systems designer, I had done that work. And so people management, no, not at all, and I had to learn and I made plenty of mistakes along the way.

Yep. Haven't we all? (laughs)

Right? (laughs) I think the point is that you're learning. You're intentionally trying to get better. You want to do the work, you want to do it. I think that one of the things that is unfortunate is when people are forced into leadership that are not interested in being leaders because the reality is it's going to take a lot of work and if you're not willing to put the work in, then maybe reconsider that direction.

Yep. I don't think everybody wants it and I think that's okay. It's a very particular career trajectory. It sounds like for you, you did like it. 

Yeah. I'm not sure those listening to the podcast out there, where they are, I'm sure it's all over the place, but the thing you have to realize when you run your own business is, you have total ownership. You get to decide everything and that is both awesome and terrifying.

And you know this, Suzan, but there are plenty of times when I worried so much that I have people counting on me. Their paychecks count on me making the right decision. There are moments where I'm like, "Gosh, is this the end of us? Are we at that point where things could fall apart if this one client leaves?" That's very stressful, but also, you can move so fast. You can make a decision, especially if you have a good network, if you're well connected and you have good coaching or mentorship, you can make those changes and it's amazing. That is not true at a larger company, I would guess, rarely true. That the reward of running your own business is yes, it's all on you, it's both good and bad, and I didn't mind that. I liked the ownership piece and I think maybe that's the thing that when you go to a larger place, you do not have ownership. You might be accountable and you might be responsible for something, but ultimately, someone above you is the owner and they can make a change and you have to be okay with that.

Both good and bad.

Both good and bad, yeah.

Let's talk about where you are now at HashiCorp. Can you just talk about what was different and what was the same? 

One thing that is the same is that you need to know what matters and how you measure success. So owning your own business, you're likely going to know that. One, we're making money, we're not running out of money. We can meet our cash flow needs and all that stuff. You understand what matters and how you measure success. Hopefully, you do. Maybe you don't. Maybe you're just sleepwalking along and it's just working out and you're not being intentional about your business, and that could be. I certainly was that way early on, but at some point, I figured that out. That is still true at a larger company. What matters it's super critical that you understand that at a detailed level. And if you don't, you’ve got to ask. You ask your boss, you ask your leaders. What matters and how do you measure success? I think that those things are not different.

What is different is now you're part of a larger organization. It's filled with complex relationships. You have to navigate those relationships, you have to understand politics, and you have to understand agendas. All that becomes very critical because if you're not aware or if that's not informing how you interact and the decisions you make, you're likely to be surprised in a probably very bad way about something when you cross someone that didn't like that or you go against their agenda and they could be well-meaning, but you have to deal with that.

I think the other piece here is you're likely to encounter leaders that span the spectrum from good to bad. They're going to be bad leaders. They'll be out there. You also will find folks that were effective when the company was 50, but are actively harmful when it's 500. We hear this all the time, especially in the startup world, because you're starting from, "It's just three of us. We're going to make it happen," to "Oh my goodness, we're on a rocket ship and we're growing and now things are falling apart." Well, because as the organization changes and grows, what works and what it needs change. And so if you've never done that before, how would you know? How would you even recognize that? And so I think that that's all very different. When you run your own small little thing, then you know how it all works, but once you get plugged into something larger, that changes.

It reminds me of something, I think we talked about it a little bit at RubyConf, and I've written a bit about it, which is this idea of the director sandwich. I think that the director role is really hard. I mean, obviously, the size of the business matters. How big is HashiCorp now?

I think 2,400, 2,700 total.

I think the director role can be very challenging because you are between these two layers. You are a leader and you are seen as a leader and you have to work more organizationally, but you are sometimes not in the rooms where the decisions are happening, but you have to help the company execute that decision and help your managers and the engineers execute on that.

I'm curious how you found that, especially since you were a CEO and founder before.

Yeah, absolutely. I think it's definitely true. I mean, I don't know. I haven't been a VP yet, so I really can't speak to that level or the CTO level at a really large company, so I can't speak to the challenge there, but I do think being a director is very hard. One of the things I think that might be a little bit surprising is that if you're a director, you probably were a manager just prior to this. And the thing is, as a line manager, someone who's directly interacting with ICs, what you do and what is successful changes as you move into a director because if you do the same things that you did as a manager as a director, that's micromanagement. You're overruling and you're reaching into teams and you're doing things. The knobs and levers that you should manipulate are different as a director. You probably, maybe don't even know that, or maybe some of them, but you don't know others. In a reactive mode, you might go into manager direct leading type mode and that's not what you should do. You need to work through your EMs.  You need to work through your product managers, and not be too close to the work.

At the same time, you've got senior directors and VPs above you. They may be inclined to reach too far in, so they got to work through you, but do they work through you? Generally, what I've seen that works a little better is that you're very outcome focused. You're like, "Let me worry about the implementation details. You tell me what the outcomes that you're seeking and I will do the best I can," so I think that it is hard. 

As a director, you are this communication conduit both ways and if you're not good at that, that's going to be bad both ways. People need context both ways and they probably won't get the full picture, so they're going to start making assumptions about all kinds of things and they'll make judgments, especially VPs will assess how things are going, and they don't know what's happening. They're probably going, I won't say assume the worst, but it's very fraught if you think about it that way, and so you've got a lot where you're in the middle.

I also think the director role for me is interesting because I think of autonomy versus collaboration. I find a lot of the newer directors struggle with that. How were you with autonomy versus collaboration? Was that at all challenging or was that pretty okay for you? 

There's this thing I learned from the consulting world, which is called the trusted advisor role, which is where you are looking out for the other person, the client, whoever you're talking to. You are not emotionally attached. You're just being honest with them. You’re helping guide them. I approached my role as a director many times as a trusted advisor, and I think that helped.

The other piece and this is also something I think I got from running my own company, was I know how to make things happen. A lot of things with directors is who needs to talk to who? Where are things breaking down? As a director, you probably had the best vantage point to see that and you can say, "Look, oh, so and so isn't aware of this or they got other priorities, so what are our options here?" We need to recognize what's happening and maybe we need to have a larger conversation, where someone doesn't understand priorities, maybe someone doesn't understand current limitations or constraints. And so a lot of that is if you can see it, you can communicate and pass that along and all of a sudden now, we can make decisions holistically about what's going to work and what's not going to work. Sometimes it's not going to work and you'd rather know right away that this is not working and we need to change direction, let's reevaluate, and hopefully, your leaders both up and down recognize that and they appreciate when you bring that awareness to their attention and then we can collaborate to make those decisions. I think I brought that from the consulting world and it's helped.

The other one is also, I don't need the credit. I mean, I like getting acknowledgement and all that, but I don't need to be the one who gets the credit. And that again plays with the trusted advisor angle. I don't care. I want you to be successful. I'm looking to empower you and to just get things solved. I want the company to win and I'm willing to do things to help that. I think when you remove the ego aspect that all of a sudden, one, people love working with you, and two, things just happen a lot more easily because then they're like, "Oh, Marty's just helping out. Cool. Oh, we love having Marty help us with this," or "He brought an interesting point to our attention and now we're going to be able to make a better decision because he got involved."

That’s so great. I think ego is hard for everybody to let go of. I mean, everybody has some form of ego.

That's true. Yeah.

It's just human nature, right? When you're under high pressure and have lots of responsibility, I think it can feel the weight of that, it can drive your ego up. What I hear for you is you just are very conscious about removing that ego.

Yeah. I mean, I've been doing this for a long time. It's all right. It's no big deal. I mean, I think if you were talking to 20s Marty or early 30s Marty, it would've been a different deal, but not now. It's okay. It's fine. I'm glad for someone else to be in the limelight and have that success and that's fine.

Has anything surprised you about the experience of going from founder to director and employee?

An ongoing theme is that I'm not in control, and so there are times when I think I have ownership and when I really don't. When that changes, that feels bad. I have had to work through, "You know what? That's their call," and it is. If a VP wants to change direction, that's their call. It may be a terrible call and you may personally hate it, but you have to come to terms with it, that is just business. That's how it's going to go. I've noticed that I've struggled with that a bit more than perhaps others. Maybe someone who comes up to the ranks in a larger company is just used to this like, "Of course, this is how it works, Marty. Why would this bother you?" I'm like, "Yeah. I mean, you bring up a good point." I maybe need to look at myself again and just see, "Am I okay? Why am I not okay with that?"

I think the other piece with this is it can also change so quickly. I had an experience where there was a change in leadership and it was shocking to me how quickly the culture shifted and it was not great. It was terrible. The reality is top-level leaders, they can come in, they can kill projects, they can shift people around. It happens a ton of the time and it's a little sad, but that's, I guess, the nature of the game.

Well, yeah. I think it is. It's a fair point, too, how much leaders can shift a culture and how quickly a leadership change or even a change in a leader can have a massive impact on a culture.

And the thing is it's not, well, I don't know if I can really say this to be true because I don't know if I have enough experience, but it seems like it's so much easier for things to go downhill, and go terrible and toxic versus improve. I mean, I think morale is a fascinating subject to delve into in thinking about how you help morale and there are things that can really boost it, but boy, once you start losing trust, it is hard to earn that back. 

I think that's the thing that surprised me, I think, also in engineering leadership, is that you'll have a lot of really brilliant technical leaders that are terrible people managers and they underestimate how important relationships and people are in this. It's so key. I think you can make a brilliant technical decision, but making a poor people decision will have way larger ramifications than then seems like it should be.

That's been my experience and that informs how I approach things, where I take care of people first. You ultimately have to. There's a bottom line for your team, your organization has to shift something, something of value, where and whatever your team charter is, you have to know what that is and you have to meet that, but you can do so in a way where we treat people like humans like we would want to be treated and we take care of them. You can do both. You don't have to sacrifice relationships in how you take care of people because you need maximum performance or you need to build a technical system a certain way. Those aren't mutually exclusive.

This is such a good, rich conversation. I think it's true for anyone with technical expertise who then has to deal with people. We can talk about engineers, but it could also be people who have marketing expertise or whatever expertise. When we move into a role, I think often we're like, "They're good at this role. They have functional expertise and they're good at this function," and then now they're in a leadership role and we forget that it's no longer just about being technically good at the function. It's about the org and navigating people and all those other things. As you said, agendas, and politics matter, in my opinion, more when you are in a leadership role than just, are you good at functional expertise?

Yeah, absolutely. The higher you go up, the more important that savvy and that sense of people become. Ultimately, how do you get a team of teams to function well? At some point as a leader, that's more important than anything technical. Hopefully, you have good people in place throughout the ranks that know how to execute technically and you don't have to come in and tell them how to design a system or how to model a database or whatever. If you're doing that, I'm a little concerned because you really need to think about how do you set strategy, how do you set vision, and how do you get an org to function and collaborate and communicate and go in the right direction? That's what you need to do as you get higher and higher. You should be less concerned ... I mean, you want the results, but you trust someone else closer to the problem to solve it than you.

That's a lot of letting go, too, because we've built our career that way. It reminds me, I never asked you how big is the team that you lead now?

I have three teams that I oversee. I think somewhere between 28 and 31.

So more than double what you'd had before and my guess is also you have other layers, too, because did you have engineering managers before?

No.

That’s what I thought. I think leading and managing other managers or leaders is a whole different skill set as well. You have to work with them very differently than you might with somebody who is, as we call them, an individual contributor.

Definitely.

Was that a learning curve for you, or did you find that to be easy?

Yeah. Yes, I was really interested in that. (Leading and managing others) was one of the things that I wanted to dig into. “How do I help others lead? I've gotten results myself. I know how Marty works and how Marty leads teams and that's great, but how do I help someone else do that? One of the interesting bits about that is everyone's a little bit different, and so I have to coach them and see what's going to work for them because Marty may have been able to approach it this way or that way. They may not be able to do it that way. Okay, so how would they approach that and how can they be successful and really help them find that themselves?

That's great that you knew what you wanted. What advice would you have for other founders, CEOs, and business owners who go to work at a larger company in a leadership role?

Yeah, let's see. 

Recognize you're not the owner, which seems obvious, but I think you should view this as a gift because you can let go. It's somebody else's call and that's okay.

Also, do the best you can in your role, but recognize it is temporary. You have been asked to come in and do this thing. You want to understand your role and what the organization expects from you and that's it. You don't have to do anything else. That's all you got to do and that's great. I think, again, the trusted advisor persona is fantastic. If you haven't seen that, read up on it, there's plenty of stuff out on the internet on it, and you can see from that what makes sense.

Don't move too quickly. You want to pay very close attention to culture and to how things currently work. Recognize what doesn't work, and what does work. You want to ask. The listening tour is the classic thing you start with to really ... Don't come in and say, "All right, we're going to do it my way. Boom." That's not going to work so well. But once you understand the lay of the land, the people, you've built up some trust, then you can start to assess what do you change, what do you do?

I love that. I think that lots of leaders come in and say, here's my new reorg, and here's all my new people. It happens all the time. If we’re used to being in charge and fully responsible, my guess is that that impulse could be even stronger for folks.

Yeah. I think the other thing that is important to note, and this may be obvious, but…

Just because this thing you did over there worked, doesn't mean it's going to work here. There are so many factors that go into why something is successful or not. I think it takes a lot of experience and awareness to recognize how those variables plug in, but that's the whole idea of you listen and you make small incremental changes. It's like the idea of the big rewrite. "Oh, the system is struggling and you know what we're going to do? We're going to rewrite from the ground." And you know how often that works? Very rarely. You have to go in and you have to grok this system. Why is it struggling? What is wrong there? And as you debug those symptoms and you realize what they are, you can start to slowly transform it and at some point, you could say, "I know enough and I think we can make a larger change," but you won't know that right away. 

That's the same for organizations. So just because you were at this startup that did amazing and was a rocket ship and you approached the org a certain way and it was great, doesn't mean that's going to actually stick and work here the same. And so I think you want to move slowly and you want to try incremental changes and make sure that ... It's like you're running a test suite. Did the test pass? Yes, the little change worked. Great. Okay, what's next? What makes sense to change next? What's the next priority and what do you think you can do that's not too big of a change? And you just go from there.

If this piece resonated with you, please let me know and give the heart button below a tap.