Lessons Learned from 9 Years at Heap with Advisor & Former CTO Dan Robinson

Yeah, let's get started. I'm Dan. I was CTO at Heap for the last nine years. I'll be sharing some lessons learned while building that company today. And also you can think of these as advice I wish I could give the 2013 version of myself when we started building the company. If you haven't used Heap yet, it's a product analytics platform. It also recently became additionally a session replay platform. Come talk to me after if you want to talk about it. It's not really what this talk is about, so here are some things I wish I knew in 2013 when we were building this the first conversation I wish I could have with a younger version of myself. It's actually really simple, just about what your job as CTO is and more generally what your job is as a leader of a company. Specifically, your job is to make the company win. So you might imagine that in some fundamental sense the CTO's job is to technical or it involves a certain part of the technology or any kind of other way you might attach yourself to the role, but your actual job as a leader is to make the company win. And the reason that's an important distinction is that what the company needs from you in order to win changes constantly. Like in my case, every 12, maybe 18 months, what the company needed me to be doing if we were going to be successful changed totally. So that means you need to get used to constantly adapting, letting go of the thing that you just feel like you kind of got your head around and just kind of got good at because you need to do a different thing now. You need to hire someone else to do that or hand it off to someone else on the team. You need to be doing something new. So you have to get used to letting go. That's often one of the hard parts of adapting as your job changes, but that change is going to be constant. I will say maybe the only piece that didn't change is that at some point your job becomes substantially about recruiting and that never really goes away. So that was a real constant for nine years, but other than that, every year or so the job would change. And it's really on you as a leader to figure out what you need to be doing. Other people can give you input, but it's really for you to figure out what your job should be and what you need to do to make the company win. So I mentioned that one of the hard parts is letting go of something you just got good at. I will share on a personal level some advice that I had that I've seen help a lot of people is to keep your identity, like your personal identity, small and flexible and agile. And the reason I say that is if you attach your identity to any specific aspect of your job, or you get self esteem from writing code well, or writing a certain kind of code well, or being an expert in a certain thing or any kind of particular aspect of your role, if you attach that to your self esteem and your identity, it'll be really hard to let go of it because it will become personal and you can't swing to the next monkey bar unless you let go of the last monkey bar. So that will make it hard. I'll also add that a good coach can help you with this. My coach helped me with it a lot. But if you can recognize this happening psychologically in yourself or in peers, it can help a lot to let go and then do the next thing. That's what the company actually needs. So your job is to make the company win. Try to keep your identity small and adapt because it'll what you need to do to make the company win will be changing constantly. A second conversation I wish I could have with a younger version of myself is about strategy and what strategy means and what good strategy looks like. Strategy for a SaaS company, I argue, should look kind of obvious. Specifically, if you have a clear understanding of the business and the market and what customers are trying to do, the right strategy should seem kind of obvious and simple. And to be even a little more provocative about it, SaaS is checkers, not chess. You shouldn't be thinking of yourself as like a Grandmaster of SaaS. You should be thinking of this as like a kind of simple game with kind of simple rules. And it's more a question of executing them well and understanding the game board. Or if you want to stretch the analogy a little bit, it's like a game of checkers where if you don't have good context about your company, you won't see the whole board and you might make mistakes. But once you see the board, it's a game of checkers. It's not a game of chess. So it should look kind of obvious. When I was younger, I thought strategy meant really rigorous thinking about first principles, fundamentals, and then figuring out what the second order consequences of things were and gaming things out in war gaming. If we do X and a competitor does Y and then we do Z to counter and another company comes in and does W, what would that mean for the market? That stuff can be interesting to think through. It can occasionally be valuable if one of those scenarios does come to pass. It'll be useful to have thought through it beforehand. But I would argue it's not a sound foundation for thinking through your strategy. You don't know what competitors are going to do. They're not going to operate exactly the way you think they are. And even if you don't get sunk by some detailed unknown. Unknown, and any nuance that you're missing about your business or what your customers are trying to do could make your reasoning wrong. Even if you don't get sunk by one of those things you're missing, you might still get the timing wrong. Like you can reason from first principles about what people should want to buy or should be trying to do. And you may just be early by five years and build something that no one wants yet and you're still hosed. So don't think of this as a game of as a complex reasoning process chess type thing. Try to keep it simple. This is particularly a trap I've observed for people like me who come from an engineering background. Engineering teaches you to find really clever solutions that get around a whole bunch of constraints at once. Clever. Cleverness is actually not your friend when it comes to strategy, because cleverness will make your strategy brittle. You want it to be kind of simple and unclever. And if I'm being even a little bit more honest, a lot of engineering culture is about showing people how smart and clever you are via your solution to a problem. And that's really not your friend if you let that mode of thinking get into how you do strategy. Because the goal isn't to appear smart, it's to have something that will work as a business. So be careful. Clever is actually kind of a smell. You can attach yourself to large tailwinds or important trends, but by and large I would try to keep it simple. Play a game of checkers. Focus on the context part. So I used to worry that we would make a strategic mistake because we didn't foresee some second order consequence of the way our market was evolving or something like that never happened in nine years of working at the company. We did make mistakes because we got the context wrong. Because there was some nuance about what customers were actually trying to do and we didn't understand it right. And then we built something that didn't quite solve their problem. It's really easy to make mistakes that way. So I would focus on getting the context right. That's the hard part of strategy. Remember I said strategy should seem obvious given a clear understanding of the business and the market and what your customers are trying to do. That part's. The hard part is understanding that. So, for example, if you're on a leadership team and you do some kind of exec offsite and you come back from the exec offsite with a big, exciting, grand new strategy about what you're going to do to solve all the problems in the company, you should be super suspicious that that strategy is right because you designed it in almost a context vacuum. Like you have eight to 10 people on your leadership team. The other 90% of your company wasn't in the room. None of your customers were in the room. You've designed it in a low context environment. The hard part isn't standing around a whiteboard and being smart. The hard part is having the context. So an alternative, I would argue is a much better way to generate context or to generate strategy is via waves of intensive customer feedback where you're testing specific hypotheses that will flush out the gaps in your context or the gaps in your thinking. That's like a way to optimize around what is the actual hard part of the problem, which is the context. So focus on that. The strategy will be obvious once you do that, if you get that right. Another strategic idea I wish I understood nine years ago is that software is fractal. And what I mean by that is when you look at software, you see features, and if you zoom in on a feature, you'll see sub features, and if you zoom in on one of those sub features, you'll see sub sub features. And it's kind of infinitely nuanced and rich all the way down. And the reason for that is that software mirrors or encodes human needs and business process needs, and those are just infinitely nuanced and complex. And the software grows in complexity to match the needs of what you're trying to do. So this is important for a couple reasons. First of all, any feature that you launch that's successful will generate a whole pile of sub features and additional investment that seem kind of obvious in retrospect, but you might not have foreseen up front. For example, in 2015, we launched a feature that let customers get their heap data set in their data warehouse. It was great. Customers loved it. Killer feature. You can do a lot of useful stuff with that. And then immediately, once we launched that, we found that we needed to support additional warehouses, let people customize the sync schedule. Actually, maybe only want to sync some events and not others. Maybe you want to sync some metadata that we didn't think of maybe you want to customize which properties go through. It's 2022, we're still investing in that stuff because we keep finding new ways to better meet the needs. It's seven years later, so these things are essentially bottomless. So you should expect if you're thinking of your roadmap as we're going to do X and then we're going to do Y, you're probably missing something because if X works, you'll probably want to do more X. So it might be better to think in terms of funding areas rather than accomplishing specific fe, because you discover this as you go. And then a second consequence is that you should expect competitor functionality to have more than might meet the eye. So if a competitor has an important feature and you want to replicate it, you might not recognize all of the sub features and sub sub features because you haven't watched the first thing yet and you just don't have the resolution on it. So it's one thing if you're thinking a competitor does X, but most of the effort went into this piece of it and we have reason to believe that that piece of it is useless or no one cares about it and we only need the simple part. That's one thing. But if you're just thinking, oh this competitor has this thing, we could bang that out in a weekend, probably could bang out a first version of it in a weekend. But you might be wrong about you might be missing whole pieces of what the feature really does. So your strategy should reflect the fact that features are fractal. Software is fractal. And one more note on this is that for most SaaS companies, this is where the technical moat comes from. Your technical mode is not usually some unique specific piece of technology. It's for most SaaS, just an accumulation of ever more nuanced, enriched and detailed handlings of all. It's this accumulation of feature weight and third level investments in these features. That's what your moat comes from. The third conversation I wish I could have with my younger self is about tasting the soup. The idea of soup tasting is that you can't fully understand something unless you engage with it in some kind of direct way or you engage with specific anecdotes in a direct way. For example, let's say you want to know if you are providing good support to your customers. There are metrics for this. You can look at NPS and CSAT and response time and there are standard metrics for this. There are tools that measure those things. They are benchmarkable that will give you some understanding of what is happening at scale. I would argue that is inherently incomplete. And if you really want to know if you're providing good support, you should also look at some example support interactions, read some tickets, look at some email back and forth, make some kind of intuitive subjective assessment of what you know. Is this good? Would I appreciate this as a customer? Were there ways to help them that we maybe missed here? Something like that. If you want to be really sneaky about it, you can make a fake email and file. It's important you can actually truly taste the soup and experience what someone experiences with your support team. But this turns out to be important, particularly because as you scale, you'll get a lot of advice about how the business is adapting. And you need to scale yourself and figure out processes and systems that scale. And you can't run the company at 20 million ARR the way you did at 2 million. And that advice is generally correct. That's all true. But what it usually means is creating processes and systems and layers that create indirection and distance between you and the product, you and customers, you and the object level things in your business. So if you don't figure out some kind of way to stay in touch with that stuff and continuously invest in deep, rich context, you won't have the right visceral understanding of what's going on. You won't recognize, you won't have good strategic thoughts if you don't make that kind of context investment. So that's the idea of tasting the soup. Another way to think about it is you can't understand what's going on in a sports game by looking at the scoreboard only you have to actually watch the game and look at the details. So figure out ways to continue using the product. Figure out ways to continue talking to users. Paul Graham has a great article or a great essay if you haven't read it. I would definitely check it out. Called do things that don't scale. I would add you need to keep doing things that don't scale in addition to doing all the things that do scale. We got so into this that we made it a company value. It ended up being transformative. A particular instance that stuck out to me actually my first project as an advisor for the company after I left the day to day in March was to run a product bootcamp. And what that meant is the engineering lead, the product lead, the design lead, the CEO of the company and the chief customer officer cleared their calendars for a full week and we spent a Whole week in focused ways, using the product, like doing real customer workflows, trying to accomplish things customers try to accomplish in the product. Getting our hands really dirty, actually using it. And by the end of the second day, we were slapping our foreheads and saying, we should have done this thing a year ago. Because it's such a. It's such a helpful way to enrich your understanding and build a more complete, you know, visceral understanding of what the product is good at, what it's bad at, what the opportunities are to make it better, all that stuff. So it doesn't mean you're making your exec team into your UX architects or designers or something like that, that we have a fantastic team that comes to a lot of the same conclusions independently. They're the right people to solve these problems. But to the degree that you as a leader need to understand what's going on with your product and your business, this is an important way to enrich the context you have. A fourth conversation I wish I could have with a younger version of myself is about how energy is more important than time. And I'll actually tell you a short story. A couple of years ago, I had a coworker with whom I had probably more friction than anyone else I ever worked with. And it took us a really long time to work out a functional way of collaborating usefully with each other. We did eventually get there, but a couple months in, he told me something that really stuck with me, which was, and this was in the midst of us butting heads, he told me, dan, you're pretty much always right, and you're so difficult sometimes that it's not even worth it. You're pretty much always right, and you're so difficult sometimes it's not even worth really made me think, because what a weird thing to hear. And actually to really make it hit home. He told me this right before I went on a vacation. So I had like 10 days to really stew on. Like, what does that mean? You're pretty much always right. But I didn't like the but or and whatever. So, you know, I thought about it and he was right in his wisdom. He was totally, totally correct. And the reason he was right is most people end their day when they run out of energy, not when they run out of time. I don't know. I am not this person. I don't know anyone who, you know, productively gets stuff done right up until the moment where they then close the laptop and close their eyes and go. Nobody works that way. And if you do tell me how. What coffee? You're like, no one. I don't know anyone who works that way. What you. What most people actually do is work up until they hit hit some point where they realize they're not useful anymore. They feel like they've kind of gotten enough done today, they're out of energy, they're tired, they don't really want to do stuff anymore, and they'll pick it up again tomorrow. That's like how you make a marathon out of building SaaS or how you make it work as a marathon. So people run out of energy. They don't run out of time. That's important because most discourse, or there's a lot of discourse about how to. About time efficiency and time management not wasting people's time. But I would argue you should care, given that the real bottleneck is energy. You should care just as much, if not more, about not wasting people's energy, because that's the thing that they run out of at the end of the day. So you need to understand the energetic costs of things. For example, let's say there's some annoying chore that people on your team need to do. It might only take like 15 minutes a week, but if it's really, really annoying, it's actually more expensive than it's 15 minutes because it taxes people's energy. Or if there's a really combative person on the team, the cost of that person isn't the time that goes that your teammates spend arguing with them. It's the fact that they're exhausted after and they don't want to do like that person makes everyone around them, like, finish their day earlier. That's really where the cost of that comes from. And it's also important to think about because as a leader, unfortunately, you can be uniquely exhausting because for ways that, for all kinds of reasons that you might not realize and in ways you might not realize, interacting with you for a lot of people will be automatically stressful, which means that. And magnified. So for example, you might might be in some context where you don't understand why we think something is going to work and you're trying to understand why we think this thing will work. And if you're not careful, someone will perceive that as, you know, being grilled or like an interrogate, especially if it's in front of a broader audience like you, you may have an enormous energetic cost impact on them that you don't realize. So you need to be really, really careful about that. Even if you perceive yourself to be like innocuous or like a shy nerd, which is how I thought about myself. Which is another good example of how you need to keep your identity flexible, because these things change. The flip side is that as a leader, you can also be uniquely energizing if you can find ways to do it authentically. What I mean is, if you can channel some kind of authentic excitement or enthusiasm about what we're doing, it can be really infectious and positive. And you can create almost free energy. That means more stuff getting done and stuff going faster. That means, for example, if you're in the midst of a slog, you can remind people why what we're doing is so cool, or why something is so valuable and important to the business or. Or something like that. Another great one is you can praise people publicly and it will have unique weight coming from you. And you can do that all the time. And if it's authentic, it'll mean a lot to them. And you'd be shocked that that means a lot to almost everyone, even people that you don't imagine that it would mean a lot to. So your job is not to be a cheerleader necessarily. And you shouldn't do these things inauthentically because it'll come off. People are smart, they'll know. But just understand the ways that you create energy and can also kill energy or be exhausting, because that's the actual bottleneck in people getting stuff done. The fifth conversation I wish I could have with a younger version of myself is about experience. And I didn't really, you know, when we were building this business in the early days, I thought, okay, we want people who are smart and they get a lot done, and they're reasonable and they're good to collaborate with. They're good collaborative partners. Maybe they're empathetic. Like, those things seem fundamentally important. Certainly we don't want people who are missing one of those qualities. And I didn't really understand why experience was such a thing that people talk about or obsess over. I sort of had this idea that the more experience you have, the more knowledge you accrue. And that's sort of right. But there's actually specific things that experienced people can do that you can't, that are really hard to replicate if you don't have experience. And I wish I understood them. The first is experience building companies gives you pattern recognition. What I mean is, if you've seen stuff before, you will recognize it more quickly the next time you see it, because it will remind you of previous things that you saw and in a kind of fundamental sense, it's really hard to do that if you're inexperienced, because you just don't have the data set. You can't map it to stuff that you haven't seen. So experience gives you the ability to recognize patterns. If you're inexperienced, you might want to complement yourself with mentors who can augment your pattern recognition or working with peers or something like that. But experience makes this easy in a way that is hard without experience. A particular form of pattern recognition that I think is really important is knowing what good looks like for some domain or some attribute or company. And the reason is if you don't have a good historical data set of scenarios that you've seen at different companies, you can make relative assessments, but it's hard to make absolute assessments. For example, let's say your design team and your engineering team are not collaborating well. They're butting heads, something like that. You can recognize the problem. You can get your leaders in a room and the relevant stakeholders and hammer out a new process and a new way design and engineering are going to work together. You can roll that thing. And if you're. You can make an assessment about whether you've improved the situation. Like, if you're smart and you listen well and you're intellectually honest, you can assess, is this better? Is this not better? Is this a lot better? That's a relative assessment. But it's hard to know in an absolute scale if it could be way better, because you just haven't seen what good looks like necessarily. So another way to think about it is you can know something's improved, but you don't know did it go from C minus to C plus or C minus to B plus or C minus to A? If you haven't seen A, then it's really hard to know if you're there yet. So this is something that experienced people can do really effectively. And a consequence of this is you should look for leaders who have seen good and ideally helped create good in the ways in which your company needs to be really good. So you figure out what your company needs to do well. And then if you don't have anyone there who has seen doing that thing really well, you might be in trouble, because how will you know if you're doing it? So pattern recognition is the first thing that experience, it's a superpower of experience. The second thing experienced people can do, or an advantage of experience is that you accumulate playbooks. A playbook is sort of an implicit or explicit way to recognize and solve a problem. And kind of, obviously if you solve the problem before, you'll probably be a lot faster solving it the next time. So the reason this is so important, I would say this becomes really important in the growth stage. When you hit when the company is really early on, you and your team can figure stuff out and use your wits to solve everything from first principles and experiments. But when you hit growth stage and the company's doubling year on year, you don't have time to figure out everything. The problems are coming so fast and from so many different directions that it's hard to stay ahead of the curve of what the company needs. If you haven't, or people on your team haven't accumulated some kind of playbooks for how to solve them. Like you don't have a quarter to recognize a problem, a quarter to try to solve it and fail, and then a third quarter to try to solve it again a new way and succeed. You need to be recognizing and resolving these things intra quarter because the company is exploding and growing so quickly. And you need to. This is where playbooks are so important. Obviously you still need to think critically. Like, you can't just trot out the same slides as last time and assume every exact. Like you need to understand contextually what is relevant and think critically and work hard. Playbooks don't do the job for you, but they help in that you can do stuff faster. And then a third superpower of experience is that experience tends to make people credible. That means that if you hire an experienced leader, either as a manager or an individual contributor, they should level up the caliber of talent that you're able to attract around them because they're more credible. They have a track record. People want to work, people should want to work with them. They should be able to credibly sell that what we're doing is important or that they will help grow people's careers or all that stuff. So experience makes people credible. And in fact, I would go so far as to say if you hire a leader and you don't perceive a change in the caliber of talent in their organization, six months later there's a problem like you may have hired the wrong leader or you should. That's a real red flag because it's so core to, to leading organizations. Well, and it's such an important part of what you get out of experience. So it means you can attract better people. It also means the credibility has an internal aspect. It should make it easier to launch initiatives or create new processes or align on stuff. If you are More credible because you have done it before. And the reason is that a lot of processes kind of work or the degree which they work depends on how much people believe that they will work and then buy into them. So it often means that a more credible person can make something work that a less credible person wouldn't be able to make work even if they had the same ideas. So unfortunately, credibility is just part of the value of experience. And it's something that you don't just get from the fundamentals of being intelligent and critical and empathetic and all that stuff. So pattern recognition, playbooks, credibility, those are the things that you get with experience. You know, you still need to be, or a person you hire still needs to be smart, low ego, they still need to be a soup taster, they still need to be empathetic, all those things. So I'm not saying, you know, make hires based on resume, like don't get fooled by a resume. But these are things that kind of uniquely come from experience. So this is the most. Most of what I wanted to share with you today or advice for my younger self. Understand what your job is and understand that it will require constant adaptation. Get good at adapting to it. It strategy should be obvious. Stop trying to play chess. It's a game of checkers. Figure out ways to taste soup. Make a religion out of tasting a soup. Be suspicious of people who don't taste the soup. It should be an important part of how you operate. Understand that people's energy is more important than their time. It's the thing that actually runs out at the end of the day and then makes them stop working and eventually runs out and makes them stop wanting to work at the company and understand the value of experience and the special superpowers that come with it. And then I will throw in one more thing to share and maybe advice for past self. For God's sakes, please be nice to people. The people around you are trying really hard. They're doing their best to make the company successful, just like you. If you're finding yourself frustrated with someone, if you can just dig deeper and find a little bit more empathy and grace, you probably won't regret it. I can say for myself, I never once in nine years regretted assuming good intent on the part of someone else I was working with. So. So just try to be nice to people. They're trying their best, just like you. You won't regret.