1 Main challenges of hypergrowth
2 Measuring success and failure
3 Organizational agility & remote collaboration
4 Future challenges
What happens after a startup finds product-market fit, achieves some early success, and starts scaling? A period of hypergrowth can breed communication problems, slower decision-making, and a loss of the agility you had at an earlier stage. But savvy startups have developed frameworks to overcome these challenges. We talked to Des Traynor, co-founder and Chief Strategy Officer at Intercom, about the methods and approaches that helped the company thrive as it expanded to 600 employees worldwide.
Overcoming common hypergrowth challenges
What have been the most challenging points of Intercom’s growth?
One big challenge was scaling and moving from one product team to multiple product teams, plus a marketing team located in a different office. Then, we had a couple of launches where we just got stuff wrong. For example, when we first launched our website live messenger product, Acquire, we realized we didn’t have a way for existing customers to use it. Our website team was building a way for new people to start using it, and our product team was building the product itself — but no one thought about our existing users.
A few different things were going on there. It was the first product we released where we had a large existing userbase, so we needed to include them in who we were building for. It was also the first time we had to make sure our marketing and our product were in sync, telling the same story on the marketing site and in the product itself. So if we said, “Click here to add a messenger to your website, ” that really had to go somewhere and really add a messenger to your website. Getting that connection right was challenging for the first time. If I had to do it all again, I’d be more aware of these friction points between different organizations.
We had another big challenge. For the first two or three years, we were our own target customer. We were exactly like companies that used Intercom. If something worked for us, it worked for our customers, and that was great. Once we got to a certain number of sales, we were much bigger than our tiny customers, and way smaller than our bigger customers. We needed to rethink how we make intuitive decisions about our product process, knowing that we ourselves are not the only customer that we need to build for.
That puts a lot of pressure on product research and analytics, specifically because you’re now relying on them to represent a large spectrum of the customer base — from a two-person start-up, to an enterprise like IBM. When we come up with new product ideas, we need to see if it resonates across the spectrum. When we fix problems, we need to fix the ones that are most important across the spectrum.
Making this change definitely improved our success rate in terms of market impact. On the other hand, it does slow you down. One of the reasons four people in a garage are really fast at building software is because they don’t have to talk to anyone. They just build the thing that they know what they want. We are no longer in that mode.
PROFILE
Intercom
offers a business messenger with workflow apps for sales, marketing, and support, connected on one platform. Intercom’s mission is to make internet business personal.
Founders:
Ciaran Lee, David Barrett, Des Traynor, Eoghan McCabe
Founded in: 2011
HQ: San Francisco, CA
Total funding amount: $240.8 M
Market cap: $1.275 billion (March 2018)
How did your role change over the years? As a Chief Strategy Officer, how do you choose where to focus your attention?
My role changed dramatically. I started off working on the product, but ultimately I’ve always worked on the areas of Intercom that no one else was working on. Once we had a product, then we needed customer support. So I went and started customer support. We had no recruiting functions, so I started the recruiting functions. Then after that, we needed a marketing leader, so I became a marketing leader. I think somewhere in between, I hired our people operations function. Then after marketing, I came back to product.
More generally, I would say that I used to work on the product, then I worked on building the team that worked on the product, then I worked on the organization that works on the teams that works on the product. Today, I mostly work on the company that produces organizations that produce teams that work on the product.
So, the distance between me and the product has grown. As a result, my day-to-day has changed quite a bit. Most of the decisions I make are not, “Should we build feature X or feature Y?” It tends to be a lot more zoomed out, as I’m thinking about who our target customer is, what our value proposition to them is, and how we produce software that delivers on that value proposition.
You should never let your organization design get ahead of your thinking
What are the biggest challenges for you when designing this organization?
The biggest challenge in any organization is to solve problems that will exist in the future, but at the same time, don’t fall into a trap of premature optimization. A lot of times I see companies do a reorganization to solve problems that existed last year, but it doesn’t actually prepare them for a new year.
There’s a theory in product design that products are at their best right before they’re killed. For example, when you’ve designed the iPod 15 times, the 15th design is very specifically styled. Similarly, with organization design you can figure out how your org should have been structured last year, but that’s not useful for moving forward.
The most difficult thing in org design is getting the time horizon right. Do we expect this org design to last six months? A year? Three years? If it’s going to last three years, then you need to start asking questions like, “Based on our product strategy, are we likely to release new products? And if so, what teams that we will hire over the next two years will build them, and where will those teams report?” You need to make space in your org structure for future events.
If you design an org to last six months, you don’t have to make that space. But you need to be okay with the fact that every six months you’ll need to reorg, and your staff are going to say things like, “Y’all don’t know what you’re doing!” You choose to either solve problems that don’t exist yet, or to solve problems that already exist, but you’re going through the reorg process more frequently…. so it looks like chaos.
You mentioned that it’s very important not to go too prematurely into reorganizing for the future — what happens when organizations plan too far ahead?
There is a theory about the Lindy Effect. The Lindy Effect says that how long something is likely to survive for is proportional to how long it has survived already. Similarly, when you’re trying to design an organization, you can only really design for a proportion of how long you’ve existed already. It doesn’t surprise me when Google performs a successful reorganization — even though they have tens of thousands of people, they don’t have to worry about existential questions anymore. They know they exist and they know they’re going to be around forever. So they can make an org design that might last five or 10 years, no problem. They’re a 20-year-old company.
The biggest mistake I see founders make is not doing a re-org when it’s clearly necessary — usually because they’re afraid of having hard conversations. Another mistake is designing for a timeline that’s not on anyone’s radar for the company. For us, it would be a mistake to design an org today for 2025, when none of our strategy documents or financial planning roll that far ahead. There’s still too much unknown. You should never let your organization design get ahead of your thinking.
Measuring success and failure
In hindsight, what made Intercom successful?
We released a product that lets businesses and customers communicate in a modern way through messaging. We did that during an era where new software startups were rampant, but there was no easy way for them to connect to their customers. I think we had the best — and we still have the best — way to do that. Once people started using our product, it became immediately obvious that it was what they wanted. No single factor has been more important than what we decided to release, and when we decided to release it.
What are the main mistakes that impeded Intercom’s development?
Whenever we release a feature, we have expectations of how it’s supposed to perform. Once it’s released, we try to get people to use it — and if they don’t use the feature, we kill it. I’d love to give you some beautiful story about how we learned from experience and how there are no real failures. The truth is that with some of these features, we would have spent tens or hundreds of thousands of dollars developing — we would have people work on them, engineer them, design them, release them, support them, and ultimately it was all for nothing. However, I think the bigger failure is to keep a product alive when no one is using it.
The output of achieving your daily or monthly goals should all roll up to you achieving your vision
Speaking of measuring success, how do you define Intercom’s North Star metric and ensure everyone at the company rallies around it?
Intercom exists in the world to make internet business personal. What that means is that we want every conversation between every business and customer to be a good, personal, modern messenger-based conversation. So we track three metrics: first, we look at how many people are using Intercom — currently, this is more than 30,000. Second, we look at how many conversations happen through Intercom every month — I think that’s about 500 million. Third, we look at how many end-to-end users have experienced Intercom, and I think that might be about a billion. Everything we do should either result in more people using Intercom, people using Intercom more, or more people experiencing Intercom.
When we do quarterly planning, we’re usually talking about more short-term metrics. A quarterly goal is likely to be attached to a yearly plan, which might have revenue targets, or it might have product performance metrics, or something like that. The output of achieving your daily or monthly goals should all roll up to you achieving your vision. However, there are teams, as there are in any software company, who are responsible for scalability, security, costs, reliability, permissions. Those are internal workings. Their job is ultimately to build the foundations on which the company sits. Our security team isn’t there to make more conversations happen.
Learn more Intercom’s principles for building product
Des shares guiding principles that help scale a team while keeping them aligned.
Organizational agility & remote collaboration
Do your teams operate in an agile way, and if they do, how do they define agility for them?
If the question relates to the Agile manifesto, I would say no. But if the question relates to just the dictionary definition of the word agile, I would say yes. I define agility as the ability to consume and weaponize new information. The speed at which you can receive new information and act on it is your agility. That’s true if you’re a soccer player and you’re on goal and you see the defender coming after you — how quickly can you react? It’s a question of how agile you are.
I like a concept from World War II called an OODA loop. It stands for Observe, Orient, Decide, & Act. I think that’s generally what you need to be able to do to preserve your own agility. When things happen, you need to be able to see what’s happening, understand it, make your decision about how you react and execute that decision. How quickly you can do that is a measure of how agile you are.
In our organization, we have a principle called ‘Ship to Learn.’ We say shipping software is an act of both humility and confidence. We are confident enough that this should go live, but we’re humble enough to know that once it goes live, everything we theorized about is irrelevant. What’s happening in the market is the only thing that matters now.
As a result, we would much rather release something that’s small early and understand how it’s being received before putting down a 12-month plan for a feature. A long-term roadmap costs you a lot of agility. What can you do in month seven if you realize that something really needs to work on mobile, too? Well, now you need to throw away a 12-month program. Whereas if you release a baby version, you would know and you would be able to react.
The other principle that we employ at Intercom is ‘Think big, start small.’ The idea of that is that anything we do should have a big vision — for example, where this feature will be when it grows up. But we have to start as small as possible so that we know the right way to grow it. With a few exceptions, we don’t let people “disappear for 12 months to work on something.”
The speed at which you can receive new information and act on it is your agility
How do you even define and measure good collaboration, especially when the team is distributed?
There are two ways I think of collaboration. When I think of it virtually, I look at how a project performed when the project was a result of a distributed collaboration. So if we were to bring something new to market — what was the market impact of the work? How successful was it? How much investment did it take us? Did it arrive on time? Did we end up spending way too much time with it? Did we end up deadlocked in dozens of pointless meetings? Lastly, how did the team feel about the project?
I prefer to measure effectiveness on a case by case basis. How was the collaboration on this project? Because some projects lend themselves well to distributed collaboration because they carve up neatly. You can look at the various components and say, “Okay, you work on this side of things. I’ll work on the API.” Other projects don’t, because everything is interconnected.
The other way I measure or think about collaboration is employee happiness and engagement, workplace satisfaction. We survey our employees every quarter or two and we have questions that we ask all the time. One of them is, “Do the tools and processes that Intercom have help you get your job done?” Or, “What is it like to work with people in different offices?” When we look at the scores of those, that’s a very direct measure of how much better or worse it is to work at Intercom because of the fact that we’re a distributed company. If it’s better, why is it better? If it’s worse, why is it worse?
What are the biggest downsides of having distributed teams across your organization?
When we’re designing and planning new features, it may last for three or six months. You are deep in the trenches working on something really complicated with somebody you’ve never met or had a coffee with, and that can be tough. For all the magic of hangouts and Zoom and Miro, there is still something raw about human-to-human contact that lets you understand and get to know somebody.
There are some things that are just faster to do in person. If I wanted to explain five different ideas that I had and walk you through them, often it’s just quicker for us to be in a room beside a whiteboard drawing it.
Another challenge is making work fun. We have a big mission and a big vision at Intercom, and it’s a long journey. It has to be fun. But it’s hard to have fun through a web browser, no matter what way you look at it. It’s just genuinely hard. It’s easy to have fun in the same room as somebody. It means that some of that kind of get taken out, and that’s painful.
Looking for a tool to align your remote team around a shared goal?
Try Miro free
Future challenges
What are the biggest challenges that you see right now that might impede Intercom’s growth?
The biggest challenge we have is hiring the best and brightest, and inspiring them to work on our mission. As long as we can do that, we’re good. We have around 600 people today. Of course, growing the company from 4 to 10 people is huge, but to grow substantially now is very hard. That’s part of the reason why we went distributed. That’s why we opened the London office, and that’s why we started building software in San Francisco.
If I were to write my fears for Intercom, the number one fear would be that we can’t build software because we don’t have enough people. Today, that’s not true. But I think we’re never going to run out of ideas, and I think the solution space is only going to grow. But our ability to keep moving at the same speed is going to be entirely a function of how successful we are at recruiting people.
What are the main tactics that help you grow and hire enough people right now?
When you’re hiring for a start-up, you can do it entirely off personal referrals and your own network, and then your most recent hire’s network. As you scale, you need recruiting tactics that actually scale. It’s only worth pursuing ways of hiring that will result in multiple people joining.
On the flip side, you can wait a bit longer, which is useful. It means that you can hire somebody earlier in their career and it’s okay if it takes them two years to get to the same level as a senior person. We use content marketing to describe what it’s like to work at Intercom, we think about hosting events where we give talks on how we build software, what our principles are for building — all in the hopes of attracting people to come and work at Intercom. Whereas I think much earlier on, it was easier to just send an email around saying, “Does anyone know any good engineers?” And see what would come back. That doesn’t work anymore.
