Paul Adams on avoiding over-corrections and finding balance when problem-solving
When I joined Intercom, we were tiny: about 50 people. We've grown to nearly over 600. Over that period, we've made many, many mistakes – some big and some small.
But when we look back at all these things, we find something interesting, which is that a lot of these mistakes and things we wish we had done differently actually have the same simple pattern.
I spoke on this pattern at the Inside Intercom World Tour because I think it’s a very common one. The transcript of the talk is published below, and you can also listen on our podcast or watch my talk here.
The swing of the pendulum
Here’s the pattern: You find yourself in an undesirable state. You realize that there’s a problem: something’s broken, and you want to fix it. But in fixing it, you often over-correct. I’ve experienced this myself. I’ve done it many times, lots of people around me have done it many times, and the metaphor that I use to describe it, is that it’s like a big pendulum swinging back and forth. You see a problem, and you correct, and then momentum changes, and it swings back the other way. Sometimes you can’t re-correct, so you need to move things back into the middle and try and find some balance.
I’m going to share five stories. These are stories that I think will resonate with people. When you hear these stories, you’ll see yourselves in them, you’ll see your company in them, and you might just think: “Wow, that’s us. We do that.” Hopefully, it’ll help you think about it or think about doing things differently. These pendulum swings are emotional for people – for the people who swing the pendulum and for all the people that are connected to that person.
First swing: big or small projects
The first of the five stories is trying to balance doing big projects and inventing, or doing smaller projects and iterating. At the end of every calendar year, we look back and look at all the product we shipped in that year. It’s a sense of pride for us in the product team. We care a lot about how often we ship and the cadence of shipping and getting things in front of customers. We look back at the year and evaluate the year based on how many things we shipped.
At the end of 2015, we shipped over 100 things. Through one calendar year with a product measuring team of about 30 people, we had shipped over 100 things. That was the source of my pride. But we realized that most of the things we shipped were small.
We were very hard on ourselves. We concluded that we just weren’t inventing. We shipped 100 things, but they weren’t new things, necessarily, and we consider ourselves to be a company that brings new things into the world.
We decided 2016 was going to be the year of invention. We started to swing, we started to correct, and we solved this problem of the lack of invention. We had three big projects, and at the end of 2016, we looked back and realized that we had shipped, with double the staff, 50 things. We had halved our efficiency. There were big projects in there too, but it didn’t necessarily feel good.
At the start of 2017, we decided we were going to swing the other way and actually have small projects again. When I was trying to figure out what was happening and evaluate what was going on, I started to realize that this imbalance and this swinging had been happening for years.
In 2013, we shipped many, many, many small things. In 2014, we shipped some bigger things. In 2015, small things. In 2016, big things. In 2017, back to small things. You might say, “Oh, big projects, small projects – it doesn’t really matter.”
“The switching cost between doing these big projects and these small projects is actually really expensive”
The problem is that the process you need for big projects is different than the process you need for small projects. The great product companies I’ve observed certainly obsess over that process, and they obsess about being operationally efficient and excellent.
When you have projects that swing between big and small, and the process changes from project to project, people have to think. They have to change how they work. It’s emotionally exhausting for people. People start to ask questions like, “Is this the way we do this?” Or, “Is that for the bigger project or the smaller project?” It’s actually really intense.
The switching cost between doing these big projects and these small projects is actually really expensive. We didn’t think about that. We would literally just say: “Hey, we need to construct. We need to invent. We need to iterate more.” And we would set the goals in motion. But we never, ever considered the emotional intensity associated with the switching process. That’s the first big swing: we do big or small projects.
Second swing: squashing bugs
The second of the five stories is whether we should have a buggy product or not have a buggy product. It sounds obvious: you should clearly not have a buggy product. But actually that’s not our experience; that’s not what we found.
It was summer 2014. Intercom was buggy, and it wasn’t just a little bit buggy, it was embarrassingly bad. As people who have some pride in our craft and the things we make, we wanted to fix it. Because it was so bad, we – the leadership team of the product in engineering – started to swing the pendulum.
We said, “We’re going to make Intercom as close to bug-free as possible.” But the people we hire don’t come in to work to fix bugs, they come in to work to build things and make new things. So we knew this was going to be crap, and we knew that people weren’t going to be excited about it. So we gave the project a name. I’m even embarrassed telling you what this name was. The name was “Project Awesome.”
And you know, Project Awesome wasn’t awesome. It sucked. It was terrible. If you talked to people who worked at Intercom at the time, I don’t know if anyone actually left because of it, but I think it came close. It was a dark time. It was miserable. It went on for like two or three months, and it was just miserable.
People were coming in to work, and we were looking at these charts that told us our bug cache was rising, rising, rising. And people were thinking: “Oh, they’re working on bugs. Working on bugs is part of Project Awesome.”
The bugs were going down, but new bugs were coming in, so the chart was wavering. Two or three months in, we thought: “Wow, this is just not attainable. This is a terrible name and a terrible idea. This just isn’t going to happen.” So we tried to swing the pendulum the other way and ask, “What have we learned?”
Well, we learned that you can’t do this, and we weren’t good at naming things. But we also learned that it’s about nuance. The picture is nuanced, and like a lot of companies, we had some version of prioritizing bugs that come in, like a P1 or P2 or P3 and you fix your P1s before your P2s. That was a thing we were tracking.
“The absolute numbers don’t matter as much, and it’s more the perception of our customers and whether they actually think Intercom is a high-quality product or not”
But we realized that that actually wasn’t the full picture at all. We created a new way of prioritizing our bugs and we called it CS1 and CS2. “CS” stands for customer support. Our customer support team is an incredibly strategic asset to our company. We consider our customer support team as invaluable insight to what our customers need. They’re the direct line to our customers – the people at the front lines of understanding what our customers do.
Our product team talks to our customer support a lot, and when they talk to our customers through Intercom, they tag conversations with a feature request, a bug or the team that owns that part of the product. CS1s were issues that were happening all the time – almost every day. CS2s were things that were happening less frequently, but still pretty often. We started to see that you might have a P3 bug that an engineer or a PM might describe as not that important, but it was happening every day.
We used to have GitHub issues with just comments of: “Yep. Today, again. Again. Again. Again. Again.” And that was what was making Intercom feel buggy. It wasn’t actually the P2s or the fact that there’s a 100 issues open in GitHub. It was actually the severity of these things for our customers. So we said, “Okay, instead of just codifying these things by how big a product or engineering problem they might be, let’s code them first by how important our customers think they are.” By doing that – by telling teams to just get those CS1 and CS2 cans managed – things actually got a lot better.
Our bug count is still high, but it’s actually high in a meaningful way. The absolute numbers don’t matter as much, and it’s more the perception of our customers and whether they actually think Intercom is a high-quality product or not.
The big lesson for us in during this Project Awesome bad time was that we found balance in the CS1 and CS2 prioritization and realized that the quality of your product is actually relative. It’s hard to pinpoint it on one single metric – and chasing those metrics, whether it’s bug count or absolute bug count or absolute P1s, wasn’t actually as important as we thought.
Third swing: hiring vs. onboarding
The third pendulum swing is whether you should hire fast or hire more slowly. If you’re a growing company like us, the obvious answer is, “Oh, you should hire fast to fulfill your potential.” But when we did that, we hired very fast through the end of 2015 and early 2016. We found we had a problem in spring 2016, and the problem was misalignment.
The problem was that new people who had joined the company didn’t really understand what we were trying to do. The reason they didn’t understand it is because we hadn’t told them. We had put all our effort into hiring; we needed to hire fast with all these grand plans, but didn’t have enough people to enact them. We were trying to swing the pendulum and hire as fast as we possibly can and get all these people into the company.
“In a fast growing company like ours has been, the temptation is just to hire, hire, hire”
What happened was that we didn’t think about onboarding those people. I guess we thought people would figure it out for themselves, and in the early days of Intercom, people did figure it out for themselves, because it was small enough. We had this situation where new people were onboarding new people.
Those new people – the first group of new people – didn’t really understand our mission, our values, our culture, what we believed, or the things we cared about. But they were telling other new people, and we actually ended up having three degrees of people telling people things that we never told them.
This was a leadership failure: of mine and of the other leaders in the company. This was our fault. This wasn’t the fault of the new people. We’d hired these great, smart, ambitious, new people, and we just had failed them. We had not helped them get set up, but we didn’t make them succeed.
So we had to take drastic action. We ran a workshop called “The Intercom Way.” The workshop was for product and engineering folks, and it was a two-day affair. We put it together really fast in a week, and it was great. It was the onboarding people should have had the first time they joined, and people received it pretty positively.
We thought we’d solved the problem with this counter-correction. But we realized that this thing grew legs, and because we only delivered it to the product and engineering teams, the onboarding problem was actually prevalent across the whole company. I started hearing back secondhand from people outside product and engineering that people saying things like, “That’s not the Intercom way.”
In these knowledge gaps, this became shorthand for, “No one really told us what we’re supposed to do.” It was a failing of ours: a big one. It was six-months in the making. So we killed hiring.
That was a mistake. If you kill a hiring pipeline and then try and start it up again three months later like we did, you realize that the hiring pipeline needs to be ongoing – at any point in time the recruiting team is keeping people warm, keeping people interested, chatting with a light touch and so on. If you kill it and just start saying that you’re not hiring for a while, you then have to start this cold again, and it actually takes months in our experience to get that hiring pipeline up and running again.
We learned to not totally kill it. But we did slow down hiring a lot, and we refocused on onboarding. Now I think we have a much better balance: our onboarding is way better than it was, and we have a much better balance between understanding the number of people we can bring into the company at any one point in time. So that was one big lesson. In a fast growing company like ours has been, the temptation is just to hire, hire, hire.
Fourth swing: bringing in specialists
The fourth of the five stories is the one that I found personally the hardest. I’m smirking because I find it so hard. Basically, you can give people autonomy, or you can keep control. As an early employee and one of our leaders, I found it hard to give away control. Yet, I know it’s wrong and that I should give away control and give people autonomy. I’ve had so many internal battles in my mind – you don’t even want to know what goes on in there with people and themes and projects trying to find this balance.
If you are growing fast, and if you are hiring people, you have to give away control. It’s part of how companies scale. As you get bigger, the individual people in the company who might have done a lot of things earlier start to do narrower things. You realize that the people who joined earlier are actually generalists, and you now need to hire some specialists.
“If you are growing fast, and if you are hiring people, you have to give away control”
This has happened to us many times. There was a period when we didn’t think we understood the mobile technology and landscape and ecosystem, so we hired mobile specialists. It also happened with operational efficiency: we thought we were a very intuitive, qualitative type of company, and we didn’t really understand how to be operationally excellent, so we hired people who were historically good at that. A third example was building a third party platform. We didn’t think we were going to learn how to do that, so hired these specialists.
Trying to be a good leader, I was thinking: “Okay, we’ve brought on these specialists with this experience. I should give them autonomy. I should correct myself and give them the space that they deserve. They’ve got great CVs and great experience, so why should I get in their way?”
We gave these specialists all this autonomy but very little support. Therefore, they had very little context. And because there was very little context, they leaned on the things they had done in previous companies.
Everyone who joins a new company brings biases and experiences from their previous companies, and in the worst version of this, it looks like a playbook. It looks like they have a way of doing things that was successful in their former company, so they’re going to just do that in the new company. Often these playbooks are in opposition to the new company’s values or principles or beliefs. What happens is that these experienced specialists are not given support.
Again, this is a failing of ours – a failing as a leadership team, a failing of mine, not a failing of theirs. The other employees around them complained back to me. They would say: “This new person doesn’t get it. I’m not sure if this person is the right person for us.” I started hearing a lot of this. I was hiring these specialists and trying to fix these problems, so I counter-corrected when I heard people were off track in the worst way possible, which is to helicopter in.
I’m thinking, “I have to fix this before it’s too late,” and then I go in and start micromanaging people. Imagine how that feels for those people – who are brought into the company for their main expertise – to be told: “You have autonomy. Go figure it out. I’m over here. But we believe in you.” Then, they get like helicoptered on and micromanaged. That’s shit for them.
The problem is trying to give people autonomy and then wrestling it back to put things back in track. The problem is that in a company like ours, you’ve a lot to lose. Each person you bring in has a big impact on other people. One person joining a team affects all the other people around them, even if they’re quiet. Everyone has an impact on other people.
If people are unhappy or misaligned, that spreads to other team members. So the balance is to try and figure out how you bring people in who are specialists. You give them autonomy, and you give them enough support.
I’m sure this resonates as being hard. I have found this extremely difficult. I think we’re getting better at it, but it’s been really hard. We’ve made lots of mistakes along the way.
The only other thing I can leave you with, other than saying to you that it’s hard, is that we’ve had great success growing from within. So rather than just jumping to a solution like hiring somebody from the outside with a certain set of experience and specialties, we’ve actually had a lot of success saying to our internal employees: “We don’t know about this, and you don’t know about this. But we believe in you, and you’ve been an amazing employee and are showing great growth potential. Can you figure this out for us?”
We’ve had tremendous success by taking our best people who are already in the company and giving them a problem to figure out in a new domain space. More often than not, they actually figure it out far more successfully than bringing someone from the outside in.
Fifth swing: the difficulty of deadlines
The fifth and final story is about whether you should have deadlines or no deadlines. When I joined Intercom, we had no marketing team and no sales team. The only dates we had were self-imposed by the product and engineering teams.
Then Matt joined as Intercom’s first marketer (and first Australian). Matt joined, and Matt needed deadlines. He needed them for a good reason, which was to know when to get things ready. If we’re going to build a product and give it to Matt – and if he and his team were going to take it to market – they needed to build landing pages and to figure out how to position it, how to talk about it. He needed to have some idea of timing so that he could plan and we could sequence things.
So we said: “Okay, Matt. We get it. We will have estimates and deadlines for you.” And we did. And we missed every single one of them. I’m not exaggerating. We missed every single one. We were world-class bad at this, like Olympic-gold bad at estimating how long something would take.
The whole thing was broken, and 2016 was the worst year for these big projects. They were all late by months. We told Matt, “Yeah, we’re about a month out.” Suddenly, it’s a month later. Then it’s two months and three months later, and we’re still saying, “We don’t really know.” It was not a good situation. We had swung towards having deadlines, and we needed to swing back and understand what it would look like to have no deadlines.
We told Matt we needed to get back to a place where we had no deadlines. And yet, the marketing team and sales team would say that’s not very helpful because they needed these deadlines – or at least some estimate. We swung back and forth between this, where I’m reading books and trying to get good at it, then having none and finding that it breaks in other ways. It’s taken us years to actually figure this out. Only in the last six months or so have we realized how to do this.
The answer is obvious, staring us in the face all the time. I’ll tell you what it is, and I encourage you to try it. First of all, we knew that we were not going to ship a shit thing on time. We also know that building software is fluid and unpredictable.
“I highly, highly encourage you – if you’re at any scale whatsoever – to bring in program management”
You can take something to beta, give it to customers and think you’ve solved their problem, only to realize that you haven’t and that it’ll take you longer. Beta can take a week, two weeks or a month. It might even take three months, and we accepted this. We said, “Look, this is just a fluid, unpredictable thing.”
But we did figure that we should bring in program management And I highly, highly encourage you – if you’re at any scale whatsoever – to bring in program management. I was hesitant and resistant to this for a long time, I think, because I didn’t quite understand it.
It’s been incredibly powerful. Program management simply looks at the outcomes you ought to achieve and the work that needs to get done, and it breaks it up into milestones and figures out who should be involved in which stage.
Program management can actually be quite lightweight. Just by breaking these things up into phases, you’re actually able to get a lot of predictability – or at least you can start to say: “There are six phases here. We’re at stage three, and we know that stage four will be in this band of time. We don’t know about stage six yet, so it’s okay not to plan for six.” It’s simple, but incredibly effective. That was a huge insight for us.
So that’s it, the five pendulum swings: observing problems, trying to fix them, correcting, over-correcting and trying to find some balance in the middle.
These swings have been the hardest part of our jobs as we grow the company. The thing that I’ve realized is that they’re painful. They’re emotionally intense. They wear on you. I have more lines in my face than I had a year ago, than two years ago, than three years ago, because of them.
“The biggest thing I learned is that you need to be humble”
But you must take them on. You need to observe these problems, and you need to correct them. It’s better to over-correct and learn than to do nothing at all. So I encourage everybody, when you see these problems, to tackle them face on and actually try to correct them, even if it means doing something radical.
But most of all, the biggest thing I learned is that you need to be humble. Humility is a funny thing. I don’t know if there was ever a time when I personally wasn’t humble, though I’m sure there was, and people would tell me 20 examples of times I wasn’t. But humility is just about knowing that you don’t know something.
Many times, I was too dismissive. I said: “That’s not really us. I don’t really believe in that philosophically.” That wasn’t showing humility, and in fact it was showing some false hubris, subconsciously. I didn’t even know I was doing that.
So the lesson is to be humble and realize that when people bring you things and potential solutions and new ways of working, you should try and figure out if they’ll be useful for you. That’s it. Thank you very much.
