Interview with Ian Chan, Employee #25 at Branch
If we are looking for a
This interview is part of a series revealing the stories of early employees from the most successful tech companies of the past few years. You’ll walk away having learned about what these individuals experienced, what they wish they knew, and the advice they’d give to others joining high-growth startups. Key takeaways are at the top and you can find the full interview below.
This interview is with Ian Chan who joined Branch in 2015 as the 25th employee. He spent over 5 years leading the engineering team and helping the company grow to over 500 people and a $4B valuation. Ian previously spent time as an Engineering Manager at Twitter and is currently the Head of Engineering at Compound.
Note: If you’re looking for an all-in-one solution to manage your personal finances, Compound can help. We can help you diversify concentrated stock positions, optimize company equity, plan asset allocation, and more. Sign up here and we’ll be in touch.
- On finding scrappy startups – “[Branch] was a scrappy, early-stage company – I remember showing up for the interview and thinking that people forgot about my interview. The team was maybe 20 people at the time and they were all crammed together in this tiny office designed for a team half that size. I ended up interviewing in a storage closet because it was the only room in the office that had a closing door (a folding screen door at that).”
- On scaling with their first large customer (Pinterest) – “The [growth] line just kept going up to the point where minutes later it was almost like a vertical line going up. And we had to readjust the y-axis because we couldn't see the chart anymore.”
- On competing with tech giants – “I remember the day I signed my job offer, there was a TechCrunch article that came out that Google had just launched a developer toolkit that at the surface level, offered and did everything that Branch did (namely some deep linking features). [...] But I still believed in the team. I believed in the David versus Goliath story that a really scrappy startup can fight against the giants.”
- On being a manager at a startup – “I'd argue that nobody wants to have a lot of managers at a startup. People don't join startups for a management structure. So I was in a tough position where I was the manager trying to explain that managers aren't evil and that some layer of organization that is important and good.”
- On accepting organizational changes – “The folks that succeeded were the ones that recognized that change was necessary and embraced it. They could reminisce positively on the past but look forward and embrace change.”
- On considering starting a company – “Being a founder is a skill. It just has to be there. And not to say that I don't think I can – I'd like to believe that I can have that spark and motivation – but I get the most excited and motivated when I'm working with folks helping execute on their mission. That’s where I've been the most successful. And that’s where I want to continue investing my career.”
How did you discover Branch?
It's kind of funny – and very on brand for me – I was playing at a poker game in Silicon Valley six or seven years ago. I've always been part of this social/professional group of people that play poker and there was a friend (who was a venture capitalist) that was also playing at my table that night.
He knew that I was looking to leave Twitter at the time. I'd been at Twitter for about five years. I'd seen immense growth there and I was looking to leave. I told him that what I was looking for was joining a Series A or B company that was rapidly scaling and dealing with organizational and technological growth. He told me, “well, funny enough, I have a Series A company in my portfolio that just raised a round. And they're looking for engineering leadership.” Of course, he was describing Branch.
Branch started off as a deep linking company for native mobile apps. For those who don’t know, deep linking is when you link from one web page to another. The idea was fascinating to me because it mirrored what happened in the early days of the World Wide Web with hyperlinks. We all take it for granted now, but we have to remember that back in the day, the hyperlink was one of the most incredible technologies. For the first time, it allowed us to go from one place on the internet to another seamlessly.
I saw this happening again in the mobile world. We all have iPhones and Android devices, and each app is this little island of content siloed away from everything else. Branch was this company that was creating an infrastructure layer that allowed people to have mobility between these apps – similar to how hyperlinks allowed people to have mobility between websites. It was fascinating to me.
What were your first impressions of Branch?
Shortly after meeting the CEO Alex for the first time, I went to their office to meet some of the team in a small office in downtown Palo Alto. It was clear it was a scrappy, early-stage company – I remember showing up for the interview and thinking that people forgot about my interview. The team was maybe 20 people at the time and they were all crammed together in this tiny office designed for a team half that size. I ended up interviewing in a storage closet because it was the only room in the office that had a closing door (a folding screen door at that). I had great conversations with the CEO and the engineers and things moved pretty quickly from there.
For me, it was a classic example of the cliche, “if you get asked to join a rocketship, don’t worry about what seat, just get on.” It was clear that Branch was a rocketship and would soon be reaching orbit. I jumped on board and things went crazy from there. It was the most difficult scaling challenge that I’ve ever had to work on in my career.
What was the biggest scaling problem you faced?
One of the reasons I joined Branch was to tackle unique technology challenges. Early on, there was an event with Pinterest that I remember particularly well.
The goal of Branch was to get app developers to integrate with our mobile SDK in order to use the deep linking functionality. Like every scrappy startup, we fought hard for large customers. But at the beginning, it was a lot of solo app developers who weren’t driving significant traffic.
The first scale challenge happened with Pinterest. Branch was part of the conversation because Pinterest is exactly the type of mobile app that deep linking can help. A user would explore a certain category or set of pins on the web and Pinterest was interested in driving traffic to their mobile app. Of course, Pinterest would want the user to continue that experience once they open the app instead of having to start all over again.
Pinterest finally agreed to integrate our SDK and they told us they were going to turn on the integration at 8 am on a Tuesday. So myself and a few other infrastructure engineers went into the office early and put the traffic graphs on our monitors that showed the number of requests per second. None of us were active Pinterest users, so we didn’t know what to expect.
We received a message from Pinterest that they were ready to go and shortly after that we saw a little bump of traffic. We were like, “Oh that wasn’t as bad as we thought, this was going to be fine.” It was noticeable, but it was small.
Just as we started celebrating and high-fiving each other we got another message from Pinterest: “We’ve turned on 0.1% of the traffic. Now we’re going to turn on the rest.” They dialed it up right after that and then we saw our charts just turn into a hockey-stick chart, straight up to the right (which was great for us).
And the line just kept going up to the point where minutes later it was almost like a vertical line going up. And we had to readjust the y-axis because we couldn't see the chart anymore. There were a few scary moments but the system held. It was great for the business because we landed this big customer. It was also great for the engineering team: under very high stakes with one of the biggest players, we were able to make it work. I'll never forget standing in front of these computer monitors at eight in the morning and just being in awe.
Once we opened the floodgates it never stopped from there. We kept adding more customers. We worked with Uber. We worked with Twitter. We worked with Amazon. And each time we brought them on we had one of those moments. Month after month, year after year, we just kept growing. Branch now deals with traffic that's probably 1,000x the amount of traffic that we had when we onboarded Pinterest years ago, but it still stands out as a very fun moment in an otherwise quiet office. It was like watching our spaceship going into orbit.
Was there a moment you thought that Branch wasn’t going to work?
Absolutely. There were many moments when I (or other team members) were worried. I joined Branch right after their Series A and there was a lot of uncertainty at that point. I remember the day I signed my job offer, there was a TechCrunch article that came out that Google had just launched a developer toolkit that at the surface level, offered and did everything that Branch did (namely some deep linking features).
Now I had a fairly nuanced understanding of all of the different features that Branch offered and how they compared to what Google offered in this new release. But it was the day I signed my offer. And of course, I had a moment of panic because, well… it’s Google. The reality is a lot of early-stage companies have a killer feature that they fail to turn into a business, so seeing Google do just that was existentially scary to me.
But I still believed in the team. I believed in the David versus Goliath story that a really scrappy startup can fight against the giants. I quickly realized that this small, scrappy startup in Palo Alto had outpaced and outclassed the product that Google built. And it's not to put down the team at Google that built the features. It's just that it was one of Google’s 1,000 features that they launched during that year. We were a dedicated team of people that wanted to solve just this one problem. The developer ecosystem responded well, chose our SDK and we grew as a business.
Google, of course, is a very easy company to be like, “oh, they're the bad guys now.” But from the day I started, we were in a position where Google knew who we were. They knew what we were doing. I remember reading a couple things in the Google documentation that was close to verbatim to how we described it in our docs. All I could think of was, “wow, they're borrowing language from the docs that we wrote.” It was inspiring to the engineering team to know that these tech giants were looking to us to see what we were doing. It kept us going.
Pretty soon there were smaller, scrappier startups that were doing the same thing that Branch was. Then suddenly we were the incumbents and had to worry about these new players.
The competition was always there and it will always be there.
What were some of the organizational challenges you encountered?
When I joined there were about 25 people. I joined as the first people manager in the whole company and I was reporting to the CEO. Engineering was the biggest department and I took on the engineering team. By the time I left, the company was around 500 or 600 people. So there was definitely a lot of team growth, scaling challenges, and growing pains.
I'd argue that nobody wants to have a lot of managers at a startup. People don't join startups for a management structure. So I was in a tough position where I was the manager trying to explain that managers aren't evil and that some layer of organization that is important and good.
At Branch, we tried to scale the organization carefully. You can't have a 300-person organization that's completely flat with no managers. It’s not effective and it's not doing a good service to the team. But if you do it right, then you can create an environment where team members have a lot of ownership and agency in their work while also having managers that are helping them develop their career, set direction, and help with communication.
We had very standard problems that any scaling org would have. I'm sure you've seen this diagram where if you have two nodes, you have one line going from one to the other. If you have five nodes, that increases the lines exponentially. If you have 12 nodes, there are so many lines that you can barely see the center of this ball anymore.
A lot of people in early-stage startups that are just flying when you have 20 or 30 people suddenly find themselves stuck when they’re 50 people. And they can't understand why. You’re no longer operating in an environment where you could have high-touch communication with all of these people. It's just not possible.
We grew quickly at Branch and we were very conscious of the communication challenges that came with the growth. We did what we could to minimize those communication challenges. We were very thoughtful of how we grew the team, scaled the team, and organized ourselves. But there were still growing pains that we all went through.
The biggest challenge for early employees was accepting change and growth. Whether it was a new process or communication channel, they needed to recognize that the company wasn’t the same as it was when we were smaller. The way we make decisions at 10 people is very different than when there are 100 people. The folks that struggled with that growth were the ones that failed to let go of the past. “It was way better when we were smaller,” is a very dangerous thing to hear. I did my best to remind folks that it was different back when we were in a very different environment, but hearing that too much is toxic and terrible for a scaling team (especially to new employees). We can reminisce on the past but we have to let go and grow the company.
Maybe the new communication methods weren’t as streamlined, but it was appropriate for the size of the org. The folks that succeeded were the ones that recognized that change was necessary and embraced it. They could reminisce positively on the past but look forward and embrace change.
Change at scale is inevitable, and it happens much faster than you might anticipate. The second you become comfortable with the world you're a part of, it's going to change again. “Reorg” has unfortunate negative connotations to it. Because I think a lot of people have experienced reorgs that haven't been implemented well or haven't been communicated well.
But I don't think reorgs are necessarily bad. It means that the organization has recognized that the current structure doesn't make sense anymore. So we need to change. If you're at a startup that's moving quickly, ideally you're not reorging all the time. But if you're never reorging then that means that you're pretending like you're still a 20-person company. You haven't made any changes and that would be much worse.
On the topic of organizational growth, recognizing that a reorg (or any kind of organizational change) is not only inevitable but absolutely essential. And whether you're on a team that's reorganizing or you're in a leadership role that has to implement and execute, you can either embrace the changes or reject them. You can ask, “how do I be effective in this new environment?” Or you can be salty about it. And then you're just a source of toxicity – which isn’t helping the company move forward.
That dovetails into things I would have done differently in my previous company. I don’t think I was super cynical about reorgs because I often was the one suggesting we make changes. But I do think that I was more hesitant about bigger organizational changes than I should have been. By hesitant I mean, that I thought about it for a week longer than I should have or I pondered on it for a few more days than I should have. Or I was suspicious about how a certain team is going to change and how change is bad. I was falling into some of the failure modes that I described and alluded to earlier.
I evolved in my way of thinking and I embraced the change, but I think I could have done a better job of that. I could have done a better job being the champion for change. Paradoxically, I was often the one making these changes, but we all learn from it. As much as I was ready for change, I wasn't. You'd never be prepared for or know what to expect when you're seeing hyper growth at the company, so that was definitely an exciting roller coaster for me.
Did you ever want to start your own company?
I've had this conversation with a lot of folks on engineering because it's a great question – of course, I’ve thought about starting my own company. But my answer is specifically related to my experience and exposure to working with great founders.
I've worked at four startups where I've had the opportunity to work closely with four different founders. I have an immense amount of respect for founders that have a vision in mind and are able to rally a team together and execute on this mission every single day. It was one of the reasons why I joined Compound. Meeting the founders (Jordan and Jacob), I saw that spark and I saw that drive.
I'm impressed with all of the founders that I've worked with and that's something that I'm very motivated by. I would love to continue learning from them. Being a founder is a skill. It just has to be there. And not to say that I don't think I can – I'd like to believe that I can have that spark and motivation – but I get the most excited and motivated when I'm working with folks helping execute on their mission. That’s where I've been the most successful. And that’s where I want to continue investing my career.
So, I have thought about starting my own company, but it is not necessarily something that I am planning to do. I’ve joked to my friend that I don't think that I'm going to do my own startup unless it's a coconut shack on the side of a beach when I retire. That will be my startup.
And again with Compound – just like many years ago – I was at this poker game talking to a VC when I decided to pursue my next opportunity. I was looking for a Series B company that was looking to grow and scale the team and I wanted to work with founders that I saw that clear spark. And here we are.