Intercom on Product: Why making every day count is key to progress
As Muhammad Ali once said "don't count the days; make the days count". Today's podcast looks at how to ensure you are doing just that.
On this month’s Intercom on Product myself and Paul Adams (SVP of Product) get to grip with speed and the importance of having principles and processes that reduce friction for your team, rather than creating barriers to good work.
Key to this, according to Paul, is the idea of making every day count. By having clear goals on a daily basis – that feed into your team’s weekly or quarterly goals – you’re best placed to achieve that collective success.
If you’re short on time, here’s a few quick takeaways:
- It’s important to make every day count, rather than just counting the days. Paul argues that people should embrace this as a state of mind rather than just accepting it as a principle.
- Good work isn’t the sum total of hours spent in the office. It’s ensuring that teams put in quality effort when they are there.
- Having a clear and consistent strategy creates a frictionless environment for people to achieve goals at speed.
- Evaluate and re-evaluate the ROI of principles at appropriate junctures. Their value can change over time and what worked for a 10 person startup might slow you down when operating at scale.
You can listen to our full conversation above, or read a transcript of our conversation below.
If you enjoy our discussion, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Making every day count
Des Traynor: Welcome to Intercom on Product, episode nine. Today, we’re going to talk about speed. Not the drug, but the idea that your company needs to move fast. Paul Graham once wrote that, “A startup is a company that is designed to grow fast and the fast bit is what’s most important.” I’m joined by Paul Adams, our SVP of Product.
Paul, let’s talk about speed. One of the guiding principles in Intercom is simply thus, make every day count. Why?
Paul Adams: Yeah, it’s a great value and principle. We’ve used it in both ways. The value being, every day counts. And the principle being, make every day count. And when I explain this to people, I often tell the following story. When every employee of Intercom comes up the elevator, or lift if you’re here in Ireland or-
Paul: But when you hop up the floors to work and go into the office, you can be in very different states of mind. And “make every day count” is a state of mind, in my opinion. And that is that you’re going into work, you know exactly what you’re going to do that day. You know what a good day looks like. You have goals for that day. And at the end of the day, you kind of reflect on that state of mind and that place you were in, whatever, eight hours before, and decide to have a good day or not. And that should inform how you feel the next morning going into work.
Des: Is there a tension there in that you are thinking day-to-day, or how do you build up from that?
Paul: Yeah. Well, I can tell you what we have here at Intercom. We’ve a whole goals framework. We’re big, big, big into goals. I’m personally also big into goals, I really believe in them. I think that anytime in my life that I’ve had goals written down, whether that’s personal goals or professional goals, I’ve just tended to be better and achieve more. So we’re big into goals. We have goals at lots of different timeframes. We have annual goals, we have quarterly goals, as I’m sure most listeners out there have. We have cycle goals. In our product engineering team we work in six week cycles, so we split the quarter into two. So we have cycle goals every six weeks, and weekly goals, and then daily goals.
Des: And can you describe maybe what is a goal in that regard? Is it achieve something, ship something, do something? What’s the makeup of a goal?
“Making every day count is the idea that you work hard in a focused way with goals. And if every single person on every single team makes every single day count, the results you will get are incredible”
Paul: Well first of all, that they’re SMART goals using the SMART framework, which people may be familiar with. Obviously, you have good goals and bad goals and the SMART framework is a really useful way to set good goals. Notice that a goal is specific, measurable, achievable, relevant and time-bound. And so, the goals themselves we would hope are always SMART goals, that they’re good goals, but they can be about different things depending on what the team is working on or the individual person is working on.
So it might be ship something, it might be achieving a milestone. A designer, for example, might have a milestone around some design thing that they’re trying to get done in a certain space of time. The goal should always connect as a kind of relevant piece. All these goals aren’t individual goals, they all add up to a big picture. So the team would have weekly goals. Typically, the people on the team have daily goals and then in aggregation it all adds up and they hopefully achieve what they set out to.
Des: So it follows that every Intercomrade (Intercom employee) has some sense of what you’re trying to achieve every day and that’s kind of the essence of “make every day count.” I want to say it sounds easy. Why wouldn’t you work this way? And yet at the same time, I do know a lot of people would join Intercom or a similarly minded startup and they find themselves somewhat shocked by the speed of execution. Why is it that when that happens? What’s going on in larger companies, do you think that slows them down?
Paul: Yeah, there’s a lot to this, because you kind of start tipping into culture here as well. Intercom people that do join typically say that it is very fast and then say “Geez, I thought it was going to be fast, but it is very fast here.” But that brings onside an intensity too. And so, “every day count” is the idea that you work hard in a focused way with goals. Again, literally you make every single day count and if every single person on every single team makes every single day count, the results you will get are incredible. But people should then also go home and not work crazy hours. And so, what I see often when I go visit other companies that friends work in or colleagues work in is that people don’t have that focus. They could be big institutions, like banks or even other startups.
Quality over quantity
Paul: I’ve often been to startups, I’m sure you have too, where people honestly just screw around all day. They’re not focused, they’re not thinking about goals, they’re not thinking about a good day, they’re not thinking about going home at a reasonable hour. They’re just honestly messing around, playing table tennis and all this random stuff.
Des: It’s funny, there’s so many different Twitter wars we could accidentally tip toe into with this topic.
Paul: Oh, god.
Des: I don’t have any contrarian opinion here, but I do think that hard work matters. I do think that lots of work matters, but I do also think that doing lots of hours is often used as a cloak to hide the fact that you’re not getting a lot of things done. And I think that’s where work/life balance and the like really suffers. Because one of the best definitions of burnout that I see frequently is when the work that you’re doing doesn’t matter. When you describe people goofing around at startups, you might be tempted to think that you’re just reading Hacker News all day, or you’re just talking to your friends on WhatsApp, or whatever.
But actually, equally meaningless work could be designing something that’s probably never going to ship, that’s not really that important for the company, but spending a lot of time trying to get it done and working in the office til 9:00 on something that realistically no one really cares about, it’s everyone’s P3 and it’s a P0 project that’s actually high-impact. And I think that’s the aspect of focus that gets missed whenever people say, “One of our values is we value people who work hard or stay focused with a sense of urgency.” And the wrong way to read that is that we’re doing these 70, 80 hour weeks all the time.
It’s not at all about that, but it’s like Muhammad Ali said, “Don’t count the days, make the days count” I think that’s the piece I’ve always indexed on is, just how do we make sure that when you choose to work, you’re set up to work really, really impactfully? And I think people don’t obsess about that as much. And if we brought in a bunch of bean counters from a McKinsey-type to analyze performance and productivity, they’d probably look at things like the door fobs swipes or something. “How many hours is the average employee spend at their desk?” And it’s actually not that. It’s when they’re at their desk, do they have everything they need around them to move without friction? And I think that’s … If I could choose to get an extra 10% of time output or 10% of quality output from anyone in Intercom, I’d take the quality eight days a week.
Des: I wouldn’t even ask them to do eight days a week. To be clear, we actually work five days a week, while we’re on this topic. What’s the best way to think about the ingredients if something is to work at what the opposite environment is? So if you have to make a team work really, really badly, and slowly, and inefficiently, and I know you have probably seen or observed throughout your career teams in that pattern. What are the ingredients of a bad team or rather, a bad set up for a good team? How do they get so slow?
Paul: It’s very easy actually. Before I get into that, one quick thing that’s kind of interesting to me is, someone said to me recently, I was talking to them here about every day counts, make every day count. This idea that it’s a state of mind. They were saying to me, “Okay, hang on a second. All of our product engineering teams have daily standups. So surely by definition … With goals. Surely by definition that means that they make every single day count.” And my response is, “No-”
Des: Wrong.
Paul: “It’s a state of mind.” Those people can come up the lift or elevator, meander into stand up. “What’s going on?” “Oh yeah, my goal is blah, blah, blah.” Back to their desk, go for a coffee. It’s a state of mind. It’s walking with purpose to the standup. Saying, “Here’s my goal, here’s what’s going to happen.” And this is the kind of intensity you need, but it’s very positive intensity. And then, like you said, we work very normal hours here, Monday to Friday, eight/nine hours a day. And people do not work weekends here at all. Obviously, our support team do and so on, but generally the product and engineering teams don’t. And you leave the intensity behind you and you go on about your life. So, the state of mind I think is really important for people to kind of consider – the symptoms and causes are quite important to play out.
But to answer your question more directly, one of the things that strikes me is that a lot of this starts at the top and comes from the top. And you kind of alluded to a lot of this already, but the first way to get people to move slow is to give them a poor strategy or no strategy or unclear goals or at the strategic level and so people are just going around in circles, you’re work hard-
Clear and consistent strategy is key to maintaining speed
Des: You’re dropped in a desert and told run fast and you’re like, “Which way?”
Paul: Absolutely. You just don’t know where you’re going and you don’t know what the outcome is. And you can sense that some people in the company just don’t really think what you’re doing is important. And so, strategy’s a big one, an unclear strategy is one of the kind of prerequisites to moving fast, I think. You must have a sharp, incisive, clear strategy, and that has to go all the way down.
On the podcast before we’ve talked about the company strategy, the product strategy, right, and get that into the team levels, and they could have their own strategy and all this stuff should connect together. It should be a system that just connects right from top to bottom. That’s one way. That’s the kind of first thing that came to mind as you were talking there. What would you add to that?
“Another thing I think is people don’t interrogate is principles and processes. We’ve talked about principles and processes a lot. We’re riddled with the things, right? But I think they all have to sing for their supper”
Des: I think strategy’s a huge piece. People ignore how painful any flip flopping on direction really is. Ideally, you wouldn’t have a strategy where it kind of changes with the wind every time you read a new tweet or whatever. Right? But I do think something I see even at times internally, but certainly in other companies, whenever we justify a change, you accumulate a lot of costs of swirl. It’s almost we’ve been running across in this direction after changing the direction and some of the decisions we made along the way are now no longer valid.
When you want to make a significant change, you almost need to do a form of like retrospective archeology of, “Hey, if we hadn’t known this all along, would we definitely have still started engineering this way. Would we have built this feature in that way?” And sometimes you need to go back to root and say, “All right, it turns out our last seven assumptions were wrong based on what we think we know now.” So I think any sort of flip flopping there is quite expensive.
Another thing I think is people don’t interrogate is principles and processes. We’ve talked about principles and processes a lot. We’re riddled with the things, right? But I think they all have to sing for their supper. If you’re carrying one of these things along, like, “Oh well there was, we have this whole ritual where we do blah or like you’re not allowed to do X until you do Y,” or whatever.
All of those things are scar tissue. They are baggage, and the only reason they’re worth their weight in salt is if they actually guarantee you a level of consistency such that you can continue to move fast because you depend on things happening, or if they speed you up. But when I reference like the bureaucratic treadmill that other people will end up on in larger companies, it’s one of those like the mystical TPS reports of the Office Space movie or whatever.
It’s like, “Hey, there’s a lot of things I need to do but, but first I have to do is other whole heap of meta space things, which are not valuable but they’re things you do as part of trying to get things done. Right?” And I do, I frequently try to interrogate what’s going on, whether we have principles or processes that people don’t believe in? The best sign you can find that they don’t believe in them is they don’t do them, or they work around them or they give them lip service, right?
We have a document called an Intermission, which is how you begin every project here at Intercom. We have a written culture where you try to communicate what you’re starting to do at the start of every project, and just occasionally we’ll find, hey, people have stopped filling out the section on whatever. It could be like what’s the story to our customers, what’s the story to the press, what’s the revenue impact? But whenever people stopped doing it, and you’re assuming best intent that like this is a good person, a good PM, a good EM, whatever, then you have to assume the process is isn’t worth doing. That’s the only alternative.
But I do think there’s processes and principles. They enter this sort of haloed land, where no one wants to go. Because if I want a question “every day counts”, I’m actually questioning our SVP of product, Mr. Paul Adams, how dare I, right? But at the same time, if you’re Joey Bag O’Donuts, the new engineer walking in here and you’re like, “This whole thing makes no sense. I have a much faster way to get things done.” I want you to question Paul Adams.
Paul: Yeah, absolutely.
“It is dangerous to just assume that the company’s perfect and it’s the people that aren’t working fast enough. It’s almost always the other way around”
Des: He/she wants it too, so I do think it’s very easy for the bosses to say “We all need to work harder, crack the whip more or whatever.” But actually maybe you just haven’t set them up for speed. Maybe it’s bad principles, bad processes, potentially bad relationships with other people, maybe it’s collaborative bottlenecks that you haven’t acknowledged. Maybe you’re incentivizing people the wrong way. Maybe you’ve taught people the way you have most impact for your company is to do this, but the way you get promoted is to do this other thing, and if those two things aren’t the same thing, that’s a real big problem.
You’d be shocked how often that happens though. I’m trying to think of other examples. I’d say there’s a lot of low hanging fruit around, that I think our listeners would be way more familiar with, especially if they’re in a smaller company. Like yes, having a design pattern library helps, because it means you don’t have to reinvent the wheel every time we want to incorporate a new Salesforce integration. Yes, having like a velocity risk register helps and actually we should probably get our engineers to talk more about this, but this is our engineer’s document.
In it we examine anything that is basically slows them down from getting code to production. Is it a test suite? Is it Amazon? What is it? All of our technical steps. So, they’re all the ingredients of stuff that will just slow you down. And every single one of them was worthy of investigation because I think there’s so much low hanging fruit that people otherwise ignore.
It is dangerous to just assume that the company’s perfect and it’s the people that aren’t working fast enough. It’s almost always the other way around. If you’re hiring good people, which generally you’d like to think you are.
Speed is good decision making
Paul: It’s interesting when you were talking there for principles and process, one thing that struck me was what is speed about or what, to your earlier question, how do you generate speed? And it’s sort of like you can say it’s just decision making basically, and the question is what do people have to make decisions about? And the best thing or one of the best things about having a great set of principles, which I’ll get into in a second, and a great process is that it takes away a lot of decision making.
“The way we generate our principles is that we take what we’ve learned over the course of the years, and we encode the successes to repeat them and then try to avoid the failures”
So for example, we want people just to be making decisions about the product, like the thing we’re making, not about like how do we do this? Like you say, if people have better ideas, we try encode them. But you want people making decisions about the product and not having to think about all the stuff that surrounds it.
And that’s one of the big things, we’ve been thinking about internally at the minute in terms of our principles and processes. The way we generate our principles is that we take what we’ve learned over the course of the years, and we see successes, we see failures, and we try and encode the successes to repeat them and then avoid the failures, try to encode them in our principle that we can then teach the people. And the process is simply a set of steps taken in a sequence that helps people follow the principles. But you have to also understand that time moves on, and you start to learn more things and you start to have to revisit these principles, revisit this process and then encode the new learnings into it.
So, there is a balance here but for the most part we want people to have certainty. So if we have nine stages in our process and they’re at stage four , it’s clearly documented for them. You don’t want them thinking about it and interrogating it, you just want them to do it. Which by the way, for the most part, if you buy into the principles is the way to win. People would much prefer to talk about their work.
Des: How do you think about the ROI of a principle or a process? When’s it worth keeping? I was trying to work out what’s the calculus around it? Is it like the cost of this going wrong is pretty high, therefore it’s worth inserting a step. Every step in every principle, if we ask people to follow it, they all cost something, right? Nothing’s free in this world.
If we have a stage called show your designs to your design director or whatever, that costs us in time. It’s at least half an hour on a calendar, it’s going to slow you down. Right.? So why do it? Well, it’s what stops substandard design going live. We’re very into design, like design that doesn’t follow brand guidelines or something like that. Right? But how do we think about, is that worth it? Are we trying to maximize upside, limited downside? How do you think about. this given you’re in the middle of this right now. You’re going to delete some processes and probably add some processes. How do you decide?
“If we don’t do this, there’s a small chance that we lose a month. If we do it, there’s a guaranteed chance that we lose a half an hour. And you’ll take the guaranteed loss of half an hour over the marginal chance of the month”
Paul: I like there’s art and science to this. I’m not going to pretend there’s some kind of hard coded or hardened mathematical way to do it. The design director thing’s interesting. By the way, our stages are kind of higher level and up, but if it was a thing that said, “Hey, at this point in time you must go to your design director as a designer, show him your work etc.” The reason that we would do that is because we’ve learned that that’s the right thing to do at the right time.
So, there’s kind of two dimensions at play. One is time, like as a project moves along in time, the type of work changes. You get into the details and unknowns move into knowns or whatever. Then there’s zoom level, so there’s up and down from design or to design manager to design director to VP. You’ve got to marry the right zoom level with the right timeframe. I’m sure most of you would agree with this, you don’t want the design director reviewing the design work late in the process.
Because then you get back into some of the stuff you’re talking about at the beginning which is flip flopping. Major course correction.
Des: Yeah.
Paul: You’re trying to, again, encode what you’ve learned about things like flip flopping into the process so that the right things happen at the right time.
Des: So the decision there, it sounds like, I know you’re giving me the whole art and science lark, which to me usually just says don’t ask me for any science, the scientific part you might be appealing to there is actually the relatively low cost of a quick check in with the design director versus the relatively high cost times whatever the probability is of it going wrong.
Paul: Yeah.
Des: The trade off is worth it. Right? Because if we don’t do this, there’s a small chance that we lose a month. If we do it, there’s a guaranteed chance that we lose a half an hour. And you’ll take the guaranteed loss of half an hour over the marginal chance of the month, right?
Paul: Yeah. Exactly. The art side of it is interesting because-
Des: I have a bugbear with that phrase because whenever somebody hits me with art and science, I think, “you don’t really want to justify what you do is that what you’re saying?”
Paul: That’s why I said it to you like that. Please don’t ask me that. It’s kind of funny though now that we’re on it because I actually think our principles and process and how we’ve come around them is actually quite scientific. It’s kind of like the classic, the way you kind of prove anything. You kind of make observations and then synthesize what you see, and deduce patterns from that and then try to apply something that will make you utilize those patterns in the future. So all of our principals and all of our process is based on observation. It’s based on a dedication to learning, and this new stage we’re in the midst of now, where we’re having a rethink. I’ve said to the team, “this is like evolution, not revolution”. We’re not going to radically change things, but we do need to evolve a little bit. It’s based on observations.
And you know Lauren, our PM team who’s driving this at the minute is interviewing people. She’s surveying people. So it is actually interestingly quite scientific now that we’re on it.
Des: Here’s a harsh take on it. You introduce process to work around the variance in people. So if you’ve got like lots of people who are of extreme spectrum of ability, you’ll have to do lots of process. If all your team are just A players you need less process, right? Some amount of that feels like it’s true, as in we don’t have a principal called or a process called, ‘It’s really important at this stage in the product that we don’t do bad work’. Generally speaking, we try to believe that we’re doing good work.
Don’t scar on every cut
Des: How do you distinguish between something that’s worth a conversation with an individual to say that’s substandard versus something that’s worth saying, we actually need to tell everyone this. Let’s process-ize it so it never happens.
Paul: Yeah. These are basically questions. Another way to kind of think about this space is that you’re minimizing risk, principles and process exists to minimize risk. What’s risky? Oh, like people going off track, bad people doing bad work, or you hire the wrong person. They’re not for us, all sorts of myriad things. So I don’t really know how to answer that question.
“I guess what I’m trying to avoid is that you scar on every single cut. Every time something goes wrong, you create a new principal or a new process”
Paul: For the most part it’s here on a case by case basis, there’s a lot of judgment required. If someone doesn’t follow a stage correctly, let’s just continue with a designer example, if a designer does some bad work, there’s a whole host of reasons why they might’ve done bad work. For a start, we might not have taught them well. Hey, here’s how we think about this stage, here’s what to expect and here’s what good looks like.
These are actually real things that come up. So for example, one of our principles is think big, start small. And for think big, and you mentioned Intermission as our project brief, we actually call everything inter. Inter-concept is our think big. So you know conceptual design, I’m sure lots of people are familiar with it. You think big, design some kind of concept car. And the thing that constantly comes up is how big is big? And unless we teach people well, and we’ve done that well and poorly over the years, unless you teach it well, here’s how to think big, here’s too big, here’s not big enough, with real examples from real projects. Unless they’ve been taught well, well of course they’re not set up to succeed. Someone else could have been taught really well and then they just can’t do it.
Des: I guess what I’m trying to avoid is that you scar on every single cut. Every time something goes wrong, you create a new principal or a new process. Then you end up with crazy employee onboarding costs because it’s, ‘Welcome to Intercom. Please read these seven epic tomes’, each the length of a Game of Thrones book, all about how not to make mistakes. By the end of it, I think if you close the error bars in so tight, the probability of anyone doing anything good, goes away pretty well as well, right?
Paul: Yeah. There’s all sorts of things. I’m drifting off into all sorts of spaces here, but as you talked there as well, another thing that strikes me about this is we believe in the growth mindset that people can grow and learn, and anyone really can come in the door and can adapt and change and we give everyone that license to do so.
And this is kind of the topic du jour – growth mindsets and open transparent organizations, etc. But the flip side of this is if you really believe in growth mindset, you have to be quite resilient because you’re right, you kind of scar every time. If you’re constantly getting feedback about how to work, how these principles work, what’s right, what’s wrong, not this, this is big, that’s too big, that’s too small, you need to be incredibly resilient to embrace all those things. There is certainly interesting dynamics at play where the process and the principles can go too far.
Des: Yeah, I think so. That’s why the way which it goes to sour is it starts to defeat its own purpose, right? If you’re a 10 person company right now, you’ve maybe 2,200 person days in a year. And we’re saying you have to make every single one of them count.
“If people are talking about the process, then they’re not making decisions”
Des: However, if you think of say, how often does this process get applied? Let’s say it’s design review, crit, product forum, whatever each of those is going to be like an hour a week for 10 people? Okay, so that’s 10 hours a week times 50, right? You start this sort of handing back all of the so-called efficiency gains you make, you hand back in terms of finessing your product process, or the manner in which you gets stuff in at the hands of your customers. And I think whilst I’m all in and you’re all in on principles and process, and we’re all in to make every day count, We have to recognize there is a kind of a tension there. And every principle, every process needs to earn its keep. It needs to actually be something that speeds you up and certainly never something that is actually net negative and that’s the thing I’d be most paranoid about.
Paul: Yeah, it’s interesting to connect some of the threads that we’ve just crossed over the last while. One thing that is really fascinating to me always is what do people talk about? Asking yourself the question, what do my team talk about when I’m not there or even when their manager isn’t there, what do you talk about? And it comes back to the idea that speed is decision making, so how fast can you make decisions, and then why do people talk about actually also directly impacts how fast you make decisions.
If people are talking about the process, then they’re not making decisions. And worst case, if people are talking about the process in a negative light, it’s one thing to say, I really understand this process, help me. Right. They’re not making decisions so they’re slower. So the education is really important. But then worst case scenario is that they’re talking about how the process is bad, it doesn’t work or they’re being forced to do it.
Des: A subversion or whatever.
Paul: Yeah. Through your questions how do you know if it’s working earlier, I think the biggest thing is you need to learn what people are talking about.
Des : I really do think it’s worthwhile instrumenting the processes to see how often they are applied to make sure that it’s really worth it because it’s easy to sort of say, “Sure. Let’s agree step 14 is definitely going to be a check in with Des, right?” But when you realize step 14 times whenever, we might have 600 software projects in a year, it’s a lot of time. And the fact that doesn’t happen instantly either, it’s going to be like the whole team is blocked until Des’s calendar is freed up. There’s so many hidden costs to these things, that’s why they need to be really good and really, really solid.
Des: Anyway, we better leave it there. This has been an Intercom and Product and we’ll see you all next month.
