Skyliner's Marc Hedlund on engineering management

To gain some insight into how we can make that transition smoother and more successful, I sat down with one of the foremost thinkers on engineering leadership and someone many of us at Intercom consider a role model, Marc Hedlund.

Marc’s been in engineering management since the mid 90s, and has worked in VP roles at Stripe and Etsy. He’s also been a founder, first at Wesabe, a personal finance company, and most recently at Skyliner. Marc recently broke the news that Skyliner will be shutting down in mid July and is refreshingly open about what he’s learned in the process.

And when he’s not leading engineering work, Marc is leading efforts to open doors for people of all backgrounds to get into tech. He’s on the board of directors at Code2040.

Our chat covers lessons in management, what other founders can learn from Marc’s own startup experiences, how to begin correcting tech diversity problems, and more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice.

Brian Scanlan: Marc, welcome to the show. Many of us at Intercom genuinely look up to you, so it’s great to have you here. What’s the response been like since the recent public announcements that Skyliner will be shutting down?

Marc Hedlund: We have a great group of customers, and the most common response from them has been, “Gosh, I feel bad that I didn’t help promote you more.” What more could you ask for from a customer than taking responsibility for your company shutting down? It was clearly not their fault. They were the ones paying us, so most of the response has been like, “That’s a shame. I wish this would continue to exist.” In a lot of ways, people who got into the product were very excited about it, but not enough people really knew why it was valuable, why they would start to build on top of it.

I wouldn’t encourage entrepreneurs to do what we did and build on top of AWS solely.

The premise was this: we’ll set up a bunch of infrastructure for you, we’ll make it very easy for you to safely deploy changes, and we’ll make it so that anybody on your team can deploy those changes quickly and easily. That premise is really appealing if you have not had those things in a previous job – where only one person was able to deploy and everybody else had to go to that person. If they took vacation, it was a disaster. Then you’re thinking, “Oh, wow, (Skyliner) is so much better.” But if you’re just starting out for the first time or you don’t really appreciate some of the qualities there, the marketing pitch might not be very compelling. It’s like, “Avoid those things that you will wish you will have avoided in the future.” It’s this very strange sentence construction about if you can go forward into the future, this is something you will have wanted to have done. Mostly it was people who had been through bad experiences who were really positive about that, but it just wasn’t a wide enough market to support the company.

Skyliner’s debut on Product Hunt

We also had this unfortunate event where Amazon released a very similar product, Code Star. I laugh about it because it’s like their fourth or fifth product in this area, and I don’t think it achieves what our customers were looking for. I know it doesn’t, because they’re now trying to move to that product and saying, “No, no, no, this isn’t it.”

It’s a bad signal from Amazon to the startup community. It says if you have any success whatsoever, you’re at risk of being knocked off by Amazon. I certainly wouldn’t encourage entrepreneurs to do what we did and build on top of AWS solely. Although I think that was a good technical decision, I wouldn’t recommend it as a business decisions.

Brian: How has deciding to shutdown affected you personally?

Marc: I’ve been through this a couple of times before. I have had startups where it was a bad idea from the start or we didn’t really do market research or we didn’t really think it through. In those situations you think, “Gosh, I better do some of that market research next time.” With Wesabe, which was the startup I worked on for the longest, it was definitely a passion project where I felt like if this works, we’ll make the world just a little bit better. People’s stress about money is so huge. If I can just lower that by even a little bit, that’s such a huge possible impact on the world, and then our support queue would reinforce that. We would hear things from people like, “I just paid off my first credit card and I just bought my first house” or, “I’m going through this bad time and this is the only product that’s helping me right now.” We would read those support messages and say, “We’ll come to work tomorrow. What we’re doing clearly matters.”

With Skyliner it was much more that we saw our market opportunity, and we felt like it was a practical product that had good possible impacts for startups. It was a way to get going quickly, but it wasn’t making lives easier for startups or a “change the world” proposition. It was, what can we build that might give us independence and might allow us to establish a market position from which we could grow?

Seeing that the market didn’t respond as positively as we wanted, and seeing that the premise of it was not clear to enough of the people that were naturally in the market, we said, “Okay, we gave this a shot. We thought that this would be compelling. It was compelling to a few but not to enough so we should wind it down. Let’s not spend more of our time on this, let’s not spend more money on this.” It was more a rational decision and less an emotional decision.

With Wesabe it hit me really hard. I was so sad when I had to close it down. With this one I thought, “Okay, we gave it a go, we thought this was a good idea, and we did our best work.” I learned how to be a sales person, which was hilarious. It was tragic.

As a team (at Skyliner), we got a lot of interest from companies that wanted us to join. We found a great place to land, we’re joining MailChimp, and we’re really happy about that. The people that we talked to were all really supportive so it was, to some extent, an easier choice.

Brian: It sounds like the denial phase wasn’t too long then.

Marc: There was certainly a long phase where I was convinced that I could be a salesperson so that might be denial. Dan McKinley, who’s on the founding team at Skyliner, is a wonderfully rational, observant person who will call it as he sees it. He said, “Okay, this is not working”, and then we would try this other thing and say, “All right, there are signs of hope. Can we build on that sign of hope? No, we cannot build. Great. What are we doing here?”

Dan and I, as we were going through this, we would start to say the same sentence in Slack at the same time. We were very much in sync, so that made it easier. If you have two or three people who are really divergent it can be a lot harder.

Focus on making users happy, quickly

Brian: After Wesabe shut down you wrote a refreshingly open retrospective about what went wrong. One of the lines that sticks out is, “Focus on what really matters – making users happy with your product as quickly as you can and helping them as much as you can after that. If you do those things better than anyone else out there, you’ll win.” Does that still apply?

Marc: Oh yeah. The lead-up to that quote is that there were these very hoped-for, positive outcomes from using the product – that if you really understood your money and if you invested a good amount of time in getting set up, your long-term outcomes would be much better. But it took so much effort for a new person to get to the point where they could start to see those benefits that somebody had to be very much in need and really successful at getting going in the product before they would start to see those benefits.

Our main competitor, Mint, did nothing like that. They said, “Put in a username, put in your bank password, and here are a bunch of graphs.” Immediately there was this endorphin rush. “Wow, I can see everything now. Before it was just numbers, now it’s pictures. I can clearly see it.” That feeling was one that really benefited them. They ignored, and continue to this day to ignore, the long-term benefits that we had hoped we would be able to get from Wesabe, but that kind of didn’t matter. For them, that first experience was so strong and so positive. People felt such uncertainty around their finances that having clarity from that first thing was such a positive emotional response. Whereas our first thing was like, “Oh, your bank sync didn’t work.” Not the same positive emotional response that we hoped would be the case.

Help somebody do something really, really quickly that benefits them.

That first step – help somebody do something really, really quickly that benefits them – every time a company does that well, they have a shot at long-term success. One of the reasons I joined Stripe was the online demos, which gave you this immediate euphoric feeling of, “I can charge a credit card.” It’s such a potentially complicated, imposing, off-putting process, and they do such a good job at making it not that.

Then you have these longer-term, complicated things like risk management. You might be the best at risk management, but if you’re terrible at that first experience, no one will ever know that you’re the best at risk management. Having both sides of that really well executed at Stripe means this is a company that has the potential to be really great in the long term.

If you have only one of them, you’re not going to get there. Mint did the first really, really well. I’d like to think Wesabe did okay on the second, but only one of them doesn’t get you there. You have to have both. The companies that focus on these short-term wins, where we get that first out-of-box experience to be great and then the thing breaks down on third use, that’s not going to get you there. You have to have both sides work, and there are too many products that only focus on one.

Offering a helping hand to young engineers

Brian: I recently saw on Twitter that you’re involved in a somewhat successful outcome where you helped place interns whose internships had fallen through due to a company falling into financial difficulty. Why did you take action here, and how were you in a position to do so?

Marc: It’s not yet a positive outcome, but I think it will be. The group is still going through interviews. (Note: in the time since our conversation with Marc, all the interns have been successfully placed)

I knew from a couple of my past jobs that oftentimes tech industry internships get decided in the fall of the year before the summer when they are actually going to occur. It’s this longer interview process – people will talk to a bunch of companies, they’ll choose one, and then months later they’ll show up in the summer and actually do the internship. This was a circumstance where a group of interns heard they were not going to be able to attend their internships a couple of weeks before they were planning to show up.

One of the interns in this group was somebody that I had met through Code2040, where I’m on the board of directors. She had asked for an introduction to this company, I knew people there, I introduced her, they interviewed her, they decided to give her an offer, and I helped her negotiate the offer. We had a long back and forth about her process of choosing this internship.

When she got the news, she wrote to me for help. As a result, I went to a couple of Slack groups I’m in with a bunch of engineering leaders and said, “Does anybody have any openings in their internship program? I just heard from this person.” We were able to get her a group of 10-12 companies within the course of a few hours. That was great.

She then said, “By the way, I know one of the other interns. Could I introduce you to that person” I said, “sure”, and then I heard from all of them. One of them was like, “I signed a lease.” Another said, “This matters a huge amount for my income. Is there anything you can do to help?”

I thought about this case a number of years ago, when Stewart Butterfield, CEO of Slack, had been running Glitch and decided they were going to shut down the company. He wrote a post saying, “We have to shut down, I have a fantastic team, they need jobs, tell me what you need in order to evaluate them, and I will get you that thing.” He was very public and open about it, and it’s really unusual that people do that as well as he did in that case.

If you can help place some outstanding eng interns *this summer* in NYC or Bay Area, could you drop me a line? marc@precipice.org— Marc Hedlund (@marcprecipice) May 24, 2017

I thought about that, went to Twitter and said, “Hey, I’m trying to place some interns. If you can consider these people in these locales, can you let me know?” I wouldn’t say it went viral but within a certain community it was well retweeted and because I write about engineering management, a bunch of people followed me for that on Twitter. A number of engineering managers saw it and responded to me. I put together a list of all the interns, where they were from, their resumes and what they were looking for, and I sent out this mass email to what turned out to be about 65 companies.

The fact that it was this group of interns who had already been interviewed and accepted meant that there was a probably a good chance that they were good engineers, so it all worked out. I don’t think you have to be in a special position to do something like that. You can just say, “Hey, this thing is going on, I want help, can you give me some information?” It can be anything.

In this case it was, “Hey, these people need help. Here is the email address to write” and that was all that was needed. It was 140 characters. You don’t need to do much.

Making the transition from coder to people management

Brian: What sort of advice would you give to an engineer moving over to a management or a team lead role for the first time? Should they step away from the code base entirely? What have you seen work well for folks making this transition?

Marc: I wrote a whole blog post about why I think managers should stop coding. It is one of the more popular posts I’ve written; it’s also one of the ones that I get the most angry emails about. The advice I give is this: Just stop coding, pay attention to your team, notice what’s going on between people, be available to them, and make it clear that you’re not headphones on, immersed in the machine. Make it clear that you’re available to be interrupted. Don’t take on deadlines. Your job should be to not be predictable for a shipping deadline. You should have so many things come up that you are the person that responds to, that predicting a longer-term coding contribution should be hard or impossible.

Every time I say that, people reply, “But I got into this for the coding. I like coding.” I like coding too. I still enjoy coding. It’s wonderfully fun to make something and see it come into existence and see it run well and have other people appreciate it. It’s great. It is a different kind of a joy than I get from management.

The transition to management requires taking steps back from the codebase.

The post was about going to this wedding of this guy I had worked with a number of years earlier. I had a name tag on that had just my first name. The groom’s father saw just the name “Marc” and said “You’re Marc Hedlund! My son’s been talking to me about you for years. You’ve had such a huge impact.” Really? I had no idea.

It was great. You live for those things as a manager. You did something for this person that they felt improved their work life and their ability to go to a job and feel good about what they did and feel good about their role and get something done. That can be huge for people. You may not know it. If you’re lucky, they will come to you later and say, “You know what? I didn’t even appreciate it at the time but you turned out to be a great manager. You told me these things that have impacted me for years”, and that’s the pleasure of it. You can’t get that pleasure if you’re shipping code. You are not going to be as observant about the people around you if you’re shipping code.

I do tell people to step away from the projects, don’t schedule yourself, don’t be the authority, and don’t be the expert. You need to start putting people in the position of becoming the authority, and if they always come to you and ask, “Should I use post codes for MySQL?” And you say, “Well, duh”, then they don’t ever learn from the decision. They don’t ever have a chance to learn from the decision.

You are not going to be as observant about the people around you if you’re shipping code.

Ask them, “How would you make this decision if I were not here? Let’s say that you didn’t work with me, how would you make this choice?” Teach them how to make the decision rather than teaching them to come to you for the decision.

Even if you were the best coder on the team, the overall expert on the team’s focus five minutes before you were promoted, the moment you’re promoted I encourage you no longer to be that expert. Instead, train people how they can become the expert for the team and how they can be the one to have confidence in the decisions they’re making. Usually that involves not coding, not being the one to make the call on technical choices, empowering people, getting them to talk to each other, stepping out of the way, and seeing what you can do to make it their problem and their solution to choose. You help them clarify which problem that they’re going after.

Brian: You were a very influential engineering manager at both Etsy and Stripe and a lot of people flourished under you. A lot of us at Intercom look to you as an example for creating a healthy engineering culture. Who’s influenced the way you think about engineering culture and management? How did you get here?

Marc: Most of the things I’ve decided to do have been based on negative examples. When I became a manager at Organic, there was a period of that year that was extremely difficult emotionally for everybody there. We had a sexual harassment complaint and the company had never dealt with that before most of the people in the company had never dealt with that before, so we had to figure it out and it was very hard.

My team was very upset about how the leadership acted and I felt a real need to protect them and make it so that they could do their job and focus. That desire to be protective was where some of my early good ideas came from. Those ideas would never work for me today because the situations are so much different, the industry is different, the people I’m managing are different. You have to be managing for the context you’re in. If I came up with a good idea early in my career it was because I saw people who were unhappy and I saw people who didn’t have anybody standing up for them. That can be a good teacher too.

Now I do read books and love what I learned from past managers. One of the books that I’ve really enjoyed is this book Turn the Ship Around by David Marquet. I certainly don’t agree with everything in the book, but that’s the point of a book. It should challenge you, it should give you ideas, it should make you think about why you believe what you believe. He was a submarine captain and he talks about this idea of pushing decision making directly to the people who have the most information about the decision. The book is it’s all about the language we use to talk to each other. Things like, I didn’t want people to say, “May I do this thing?” I want people to say, “I intend to do this thing.”

He has this whole philosophy around, “I’m going to make an assertive statement. Thank you for telling me. That’s our conversation”, and how much that difference matters to good management. Somebody sitting down and thinking about word choice for how managers talk to the people that they’re trying to manage is great. You can learn so much from that. You might not choose his wording, but thinking about why he focused on wording choice is a great lesson.

Correcting tech’s diversity problem

Brian: You’ve done a lot of great work enabling people of all backgrounds to get into tech, at Etsy in particular you had success getting women more involved in operations and engineering roles. What do you recommend startups who want to correct diversity problems and build more representative teams do?

Marc: First of all I am winding down in a three-person startup where the diversity was our heights. All three of us are white men, we all have beards, we’re all experienced in the industry, and there’s no diversity whatsoever between us. We had a blood pact that the next person we hired was not going to be a white man, and certainly not a bearded white man, but we never acted on it because we never hired anybody.

We had already made a mistake, which was that our founding team was all white men. If a person of color, somebody from an underrepresented group, were to come to me and say, “What’s my best chance to have a great company that’s very respectful of these issues?” I would say, “Be a founder”, because the likelihood that you’re going to find that in the world is really low.

I don’t want that to be the case, because being a founder is hard and it depends on your ability to have unpredictable or no income for some period of time, which is directly connected to economic privilege. That’s problematic but that’s what I tell people, “Have you considered founding your own company, because then you could make it the way you think it should be.”

If that’s not the case, if the founding team is like ours, then I encourage people to work on it as early as possible. There are women who say, “If you’re more than five employees and none of them are women, you’re already too late and I’m not joining your company. I don’t want to be first again, I don’t want to be the first woman on the team again.”

A lot of times people will say, “I hear diversity matters, I’m going to focus on it”. Then they’ll write to somebody and say, “Hi, you’re a black woman who’s an engineer. I’m trying to increase the diversity of my team.” There’s a thread right now on Twitter of a bunch of people who have gotten the same message from people saying, “I will never work at your team because what you just said is you care about me as a diversity number.”

There are wonderful, talented, senior, extremely impressive people who are not white, straight men in our industry and you can find reasons to want to work with them, because they’re talented, because they have great ideas, because they will push you, and if you’re not talking to them about that, there’s no way you’re going to make progress on it.

You have to make it a priority. If you ask any given company if they value diversity, they will say they completely value diversity. If you ask any given company what they are willing to give up in order to get diversity, people will say, “Oh, no, no, we’re just going to hire the best. We’ll just make sure that some of those people are women.”

The conversation is never, we would be willing to pay people a dramatically higher starting bonus or a higher salary, or we would be willing to completely change our interview process to make sure that it is not biased towards people who are already dramatically overrepresented in our industry.” Or, we would be willing to do these things to ensure inclusion within the promotion process. We would be willing to have descriptions of five or six or seven different success metrics, any one of which could be your focus that would allow you as a person with a different background or different skills or different personality to succeed within our company because we think that if success always looks like the same thing, it will wind up looking like white guys.

Those are conversations companies don’t want to have. They say, “We value diversity. We’re going to work on diversity. We’re just going to make sure we hire the best.” That never produces good effects.

Get to know Code2040

Brian: For more than five years now you’ve been on the board of directors at Code2040. What’s the mission there and how can our listeners get involved?

Marc: The mission of Code2040 is to bring black and Latinx engineers into Silicon Valley companies. Here’s how you can get involved. I will tell you an anecdote that broke my heart. If you ask me if I see hope here’s an anecdote of why I would say no. 2040 has this program called Tech Trek, where they get a bunch of sophomores and juniors with black and Latinx backgrounds to come to Silicon Valley and tour around 10 large, well known companies.

Code2040 creates access, awareness, and opportunities for top Black and Latinx engineering talent.

Towards the end of the week I went to this competition where they were presenting application ideas they had. I was walking around talking to the students and asking, “How has your week been?” They said, “I want to work at Box.” Box? Nothing against Box, but I would’ve expected Twitter or something that’s a consumer product that everybody knows. Box is a successful company, but it’s not as well-known, I would think, amongst college students where I assume it’s not used.

I asked, “Why Box?” and every one of them said, “We walked in there and the employees smiled at us and said, ‘Hi’ to us, and that was not true at any other company.” So what can you do? If a college age, teenage, old, or whatever age black or Latinx person comes into your company, look them in the eye, smile and say, “Hi, how are you doing?” That’s the level that we’re at.

Most of the people in these companies are white guys who look like you and me. If you see somebody who’s black or Latinx, your first thought might be that they’re a delivery person or they’re some lower status person. Black and Latinx people that I’ve hired in a company tell me that people in those companies, after they’ve started and have been through the engineering interview process will say, “Are you part of the kitchen staff? Are you on support? What are you doing here?” Make the assumption that those people that you’re not used to seeing, for whatever reason, could be engineers like you and welcome them and say, “Tell me about what you do.” Or, “I’m glad you’re here, what’s going on?”

Literally Box made sure that its employees knew that Code2040 was coming through and to smile and say hi, and 50 students wanted to apply to Box. Smiling and saying hi could have a dramatic effect on their diversity numbers. Nine others companies that they visited, all brand name, big, successful Silicon Valley companies, didn’t get above that. What can you do? Smile and say hi. Treat them like people. Ask them what they’re doing. Pretty basic stuff.

That and hire them and then promote them. And then make sure that they can succeed and grow and want to stay, because if we get to the point of having good diversity numbers then we have to move on to inclusion, which companies really aren’t dealing with yet.

If you want a deeper answer than smile and say “hi”. Project Include has done fantastic work describing all of the many issues that go into these topics, and I highly recommend their site and their work.

Brian: Marc, we’ll leave it there. Thanks for coming on the show. It’s been fascinating.

Marc: Thanks for having me.

If you’re interested in joining the R&D team to help build Intercom, check out our current openings here.