Steve Newman is the Founder & CEO @ Scalyr, the startup that helps your devops team solve more problems in less time with log monitoring and analysis in seconds. Steve has raised over $27.5m in funding with Scalyr from many friends of the show including Susa Ventures, Bloomberg Beta, Shasta and GV. As for Steve, prior to Scalyr, he was the Founder of Writely which was acquired by Google to become the little known, Google Docs. Before that he founded 2 prior startups, Ann Arbour Softworks (acq by Ashton-Tate) and BitCraft (acquired by Macromedia). If that was not enough, Steve also sat on the Technical Advisory Board at Box for over 3 years.
In Today’s Episode We Discuss:
* How Steve made his way into the world of startups and SaaS over 30 years ago? What is the founding story with Scalyr and what was that a-ha moment?
* Why does Steve believe that you should involve customers very early in the process of developing your narrative? Where does Steve see most startups go wrong when it comes to messaging? How does one structure the feedback mechanism? How does one determine between feedback you integrate and feedback you do not?
* Why does Steve believe that you should not focus too much on numbers in the early days? What makes them deceiving at this stage? If not numbers, what should early stage founders be focusing on and measuring? Why does Steve believe that ARR is not the leading metric? What metrics should early stage SaaS founders really be prioritizing?
* How does Steve respond to PG’s “to scale, you have to do unscalable things”? What challenges and nuance does Steve present that founders must be wary of? How does Steve’s thinking here affect his view towards customization? Why does manual input not put a cap on scalability? What are the parameters for manual involvement to be scalable?
Steve’s 60 Second SaaStr:
* What does Steve know now that he wishes he had known at the beginning?
* Who does Steve believe is crushing it in the world of SaaS today?
* The hardest element about the move from tech co-founder to CEO?
You can also take your SaaStr to go:
Listen on iTunes.
Listen on Google Play Music.
Listen on Spotify.
If you would like to find out more about the show and the guests presented, you can follow us on Twitter here:
Harry Stebbings: We are back on the official SaaStr podcast with me, Harry Stebbings and it would be fantastic to hear your thoughts on who you would most like me to have on the show in the future. You can make your suggestions on Instagram @HStebbings1996 with two Bs. I really would love to hear your thoughts.
But to the show today, and there’s nothing I love more than hearing incredible lessons learned from a serial entrepreneur over decades of starting SaaS companies, and that’s exactly the case today as I’m thrilled to welcome Steve Newman, founder and CEO at Scaylr, the startup that helps your devops team solve more problems in less time with log monitoring and analysis in seconds. Steve has raised over 27 and a half million dollars in funding with Scalyr from many friends of the show, including Susa Ventures, Bloomberg Beta, Shasta, and GV. As for Steve, prior to Scalyr he was the founder of Writely which was acquired by Google to be come the little known Google Docs. Now that is quite an achievement. But before that, he founded two prior startups. Ann Arbour Softworks acquired by Ashton-Tate, and BitCraft, acquired by Macromedia. If that wasn’t enough, Steve also sat on the technical advisory board at Box for over three years. I do also want to say a huge thank you to the wonderful Leo Polovets at Susa Ventures for the intro to Steve today. I really do so appreciate that, Leo.
Without further ado, I’m now very, very excited to hand over to Steve Newman, founder and CEO at Scalyr.
Steve, it’s absolutely fantastic to have you on the show. Having heard so many great things from Leo at Susa. So thank you so much for joining me today, Steve.
Steve Newman: Thanks. Really looking forward to it. It’s great to be here.
Harry Stebbings: Not nearly excited as I am, but I would love to kick of today Steve with a little bit about you. So tell me, how did you make your way into the world of SaaS and then really come to found Scalyr?
Steve Newman: Scalyr, I guess would be my second trip into the world of SaaS, the first being a startup called Writely. There’s a connection between the two. So Writely was acquired by Google in 2006 and became part of Google Docs. Winding up at Google, it was a fascinating place to be, I’m sure at any period of it’s existence, but certainly then around 2006 things were growing rapidly and lot’s of fascinating stuff going on, and we wound up working on a database infrastructure project that related to Google Docs and some of the other applications and wrestling with a lot of problems with operations and keeping our code working efficiently and our systems working. Basically we had the problem that we wound up setting out to solve at Scalyr, which is that it was just too hard to get a sense, to wrap our heads around all the data that these systems were generating, understand what was going on, track down and fix problems in an efficient way.
So Scalyr grew out of having that problem and just trying to come up with the best way to solve it and it just clearly made sense as a SaaS solution. Both because all the reasons we know and love SaaS of building something that people don’t have to manage themselves and is available on demand. Also because for this kind of application where you’re working with large amounts of data, there’s actually an economy of scale that you can get by running all your customers worldwide in one central place. That was part of what lead us to the SaaS approach to Scalyr.
Harry Stebbings: I love that element of scratching your own itch and that kind of idea generation process. I do have to ask though, Steve. We obviously mentioned the time at Google there in some phenomenal growth periods. A question from Leo Polovets, what were the biggest take-aways for you from that experience? Maybe how’s it shaped how you think about the building and scaling of Scalyr today.
Steve Newman: So actually, so one thing that we took away from Writely was not to worry too much about competition. If you see an unmet need, even if it feels like a lot of people are circling around that, if it’s unmet then it’s unmet. Writely was like the 10th online word processor, but it was the first, I think maybe, that happened to hit a certain combination of just simplicity and polish and I think that helped us to take off. There were a lot of other products circling around, some which in some ways were very sophisticated but none of which quite managed to scratch the same itch. We went very quickly from–with Writely–from idea to launch, took about a hundred days. Even so, in that hundred days it seemed like a new competitor was popping up every week. For a while we were worried about that. In the end, none of them really affected us because they never quite hit what we were going for or what we were lucky enough to stumble onto.
I think a lot of that actually carried across to Scalyr. Log management is certainly a crowded spaced. It was crowded before we even got started with Scalyr. Again, we felt like there was really an unmet need. A lot of these products were just too cumbersome, too slow, too hard to use, and weren’t getting used. We had felt that ourselves and we’d talk to other people and hear similar stories and think that experience with Writely gave us the courage to say that just because the market is crowded, doesn’t mean there’s not an opportunity. If it feels like something is missing, then there really may be something that’s missing.
Harry Stebbings: Totally, and I’m so with you on the kind of element of running your own race. I love that kind of mindset. Do want to start though on top down approaching of the roadmap, so to speak. The foundational element of any business, really. You said to me before that you should involve customers early in the process of developing your narrative. Tell me Steve, what are the benefits of involving customers early in the process?
Steve Newman: Of course you need to involve customers early, just in the definition of your product. It’s common place to make sure you’re building the right thing and something that people will actually need. I think a nuance of that is that you don’t have a product if you don’t know how you’re going to talk about it. If you have an idea, this is what I’m going to build, but you haven’t figured out your elevator pitch or your crisp explanation of what it is, then you haven’t really finished defining the product. It’s not enough to build something that people need, you need to be able to talk about that in terms that will resonate. In the process of figuring out that description that’s going to resonate, that may come back and actually affect the way you build the product or even what the product is going to be. So you really need to be working with potential customers early, not just to figure out what their needs are, that of course is critical, but also to figure out how you are going to talk to them about this thing that you’re building. You need to iterate on that message up front just as much as you’re iterating on what the actual problem you’re solving is.
This was another lesson really for me from Writely. We thought that the Writely narrative was going to be all about collaboration. This is how we always used to talk about at the beginning. We’re building this tool for collaborating on document creation. That was a little bit abstract for people and really what everyone was interested in was just, “Oh, this is like Word but it’s on the web.” We were very scared of that message at first because Word, of course, is a huge mature product and we didn’t even do 1%. If you look at a feature list back then, even today, Google Docs today doesn’t do 1% of everything Word does. So in terms of a product concept it was very different. In terms of the narrative, most people don’t use most of the Word feature set most of the time. They think of Word as just, “Well, you know it’s where I go when I type out a document.” That’s what Writely was for people on the web. We had to have a lot failed conversations with people, we were trying to get them excited about collaboration before we realized that actually our narrative had to be just about creating documents online. Once we figured that out, that changed the whole way we built the product. It meant for example, that the core editing experience had be really solid.
Harry Stebbings: Can I dive in and ask, we mentioned the deluge of data already. In terms of deluge of data in terms of feedback from customers, how do you distinguish between what you take, what you don’t take, what you move forward with, and how you think about consolidating that customer feedback into actionable progression points?
Steve Newman: That’s a great question, and I don’t know that I have a great answer. This is just one of the classic hard problems of starting company or starting any kind of a project. Some of it just comes down to intuition. There’s this line you have you strike. You start out with a concept in your head of what you’re going to build. You go out with that, and you have your early conversations and you talk to people. Some of what you hear is going to fit with your preconceived notion and some of it isn’t. I don’t know that I can say much more than it’s an art. I mean, you’re going to hear things that don’t fit with your idea. Sometimes that’s a distraction that you need to ignore because the person you’re talking to actually isn’t the customer for your idea. They’re a customer for some other idea, and that’s fine. You don’t want to get distracted by that.
Sometimes what they’re telling you is really important, that your idea is 20% off, you need to adjust it. I don’t know a scientific way to approach that. For me, it’s just talk to a lot of people and then try to be very honest with yourself. If everyone is telling you the same thing and nobody resonates with what you’re saying, everybody is telling you something else then you need to respect that. If you’re hearing as is more common, a jumble of different opinions, you just try to need to expose yourself to enough different perspectives that hopefully you’re going to start to see the forest for the trees and recognize the patterns. Okay, there’s this group of people who are not my customer and I’m going to disregard that. Then this group of people who are my customer and I need to listen to what they’re telling me that this part of my message resonates and this part doesn’t.
Harry Stebbings: Totally. I think that kind of intellectual honesty and mental plasticity is the key to success there. Once we have some product out and we have those users engaged, there’s the element of analytics and growth, hopefully. If we do couple the two, what I noticed and we chatted before, you said to me that numbers are great, but small numbers deceive. I’ve got to ask, Steve. Can you unpack this to me and how you think about that and how timing of analytics and the life of a company influence the prioritization of it and how one should view it?
Steve Newman: So the problem with small numbers is just that there’s so much noise. There’s so much happenstance in there. In one month you acquire 500 new customers, and the next month you acquire 1000 new customers. That’s real. You can go in and try, why did that happen, did we change our advertising approach, what did we do? Clearly a real thing happened there. Doubling from 500 to 1000 is a very solid thing. If in one month you closed one new customer and the next month you closed two. Or in one month when you’re getting started you closed no customers, and the next month you do close a customer. That can be anything. That’s happenstance. If you start looking at that jump from one customer closed to two and try to back-propagate that into, “Well, clearly this ad campaign was 30% more effective and clearly this messaging …” You’re just making things up. You’re reacting to random chance.
It can be hard to discern that dividing line. There are statistical tests you can apply and so forth, but truth is it can be easy to get those wrong a little bit. Even without trying to figure out exactly where the dividing line is, and of course it’s not a sharp line. It’s not yesterday we don’t have data and today we do. The data goes from random to noisy to solid in a gradual fashion. I think without diving too deeply into that, it’s easy to get caught up in numbers. We have so many tools today that will make numbers available to us from every direction. There’s so much conventional wisdom about how you have to respect the data. It’s just important to have this sense in your head that in the early days, when the numbers were small they’re potentially incorrect. It’s actively because there are so many things that push you toward paying attention to the numbers, it’s actively dangerous because you can start chasing random … You start believing them much more than they’re actually able to tell you.
I think there’s two things that you do about that. The first is especially in the very early days, you have to go past the numbers and really get into the qualitative data and experience. So if you have a … Let’s say you are trying to close a sale and you succeed or you fail. So you get one number out of that. One sale or zero sales, but there’s so much other information that you got through that interaction. As you were talking to the prospect, what resonated with them? What didn’t resonate? What did they say? During the demo, what were they excited about? If they gave you feedback about the product, what were they talking about? If they used the product, how did they use it? You should be able to write five pages about that interaction with that sales prospect and there’s so much more there than just the one number of one sale or zero sales. The real point about this small numbers is not to let them distract you from this mass of qualitative data.
The qualitative data is harder to work with. You can’t roll it up into a spreadsheet. It’s going to play to all your cognitive biases. It’s going to be easy for you to pay attention to the data that agrees with your idea and ignore the parts that don’t. This is why once you have large scale data, that’s a tool you really want to rely on. When the large scale numbers just aren’t there, it’s all the qualitative stuff is what you have and you just have to try to be as diligent about gathering it and as honest with yourself about avoiding biases as you look at is as you can.
Then the other thing is there are a lot of different numbers that describe different parts of your business, some of them achieve significance before others. The stage where any given month you’re bouncing between zero and one deals closed, you may be bouncing between five and ten prospects and 100 and 200 leads and 1000 and 2000 impressions, visitors to your site. So those earlier stages of the funnel where the numbers are a lot bigger become statistically meaningful a lot sooner. So a simple thing you can do is just ultimately you’re going to need to optimize every state of your sales pipeline but the earlier stages go quantitative much sooner because the numbers are so much bigger up there early in the pipeline.
The one danger there, though is if you’re trying to optimize for traffic to your website, but you’re not able to ground that numerically all the way down to customers closed. Then it’s easy to see whether a certain ad campaign or a certain message or a certain whatever activity is going to bring more traffic to your site, but the numbers won’t tell you whether it’s useful traffic. It won’t tell you whether it’s people who are actually valid prospects. Therefore you still need to be careful to not rely on just the numbers, but continue using your common sense and whatever qualitative data you can gather to make sure that the number that you’re optimizing for is actually one that’s ultimately going to be relevant to your business.
Harry Stebbings: Yeah, absolutely. I always think back to it when you say that half of my marketing budget’s wasted and half of it’s effective. I’m just not sure which half is which. I do have to ask then, Steve. In terms of those kinds of numbers, for you today, if you get up and look at one guiding metric that suggests the direction of your business, is there one which leads in terms of prioritization? Be it ARR, be it number of customers, be it usage, be it …
Steve Newman: That’s a great question. Of course all those are important in different contexts. I guess for us we focus on the numbers that bear on the things we need to work on. In our case, we don’t worry much about usage because we know it’s really strong. Once we get people onto our platform, they use it, they love it, they don’t leave. We can’t get too complacent about that, but we’re a startup and we need to focus. So that’s not where we focus. Ultimately we focus on ARR, but as you always want to try to find … ARR is a pretty trailing indicator of all the work you’re doing. Obviously it reflects the closed deals which happen after all the steps along the way that you’re trying to optimize. Really what we’re always trying to look for is which metrics can we point to that are going to be the best leading indicator of ARR. So in particular leading indicator of being able to close new customers. So we look at things like the number of good trials and POCs that we’re getting into because that’s both deep enough into the pipeline, but it clearly reflects something very real but it’s early enough to be more of a leading indicator than ARR.
Harry Stebbings: Totally. No, absolutely it makes sense. Speaking of the metric that you look at to define growth, Paul Graham stated that in order to scale, you’ve got to do things that don’t scale. I have to ask, Steve. How do you personally feel about the do things that don’t scale element?
Steve Newman: I love that quote because I think especially when he first said it, it was so contrarian and it’s absolutely true. I think his point was people get too focused about how am I going to make this work five years from now. If that’s all you worry about you’re never going to last five years. So fundamentally it’s outstanding advise and it remains just as valid today. I think one of the interesting things that we learned in the ride here at Scalyr was it’s great advise until you outgrow it. Eventually you are scaling and you need to do things that do scale. Spotting that turn is interesting, and it’s not one moment. In the early days you’re doing 100 things that don’t scale and they’re all going to reach their boundary at different times. So something that we use … Somewhat belatedly learned is that all these things that you’re doing that don’t scale, you need to really be keeping a weather eye out to figure out where are you at the point where actually this needs to scale now.
A lot of it boils down to do things that don’t scale mostly means do things manually. Don’t automate it and do it yourself, don’t hire for it. Beginning, you’re three people or whatever your founding team is, and you’re all doing everything manually. Scaling is going to be either automating things or hiring a team to do those things, or sometimes outsourcing those things. So you need to look at all these things that you’re doing manually and recognize obviously which ones are starting to really eat up my time. A little bit more subtly which things are we giving short shrift to because we know we don’t have time to do them. So we [inaudible 00:19:00] to just start putting things off or under serve certain functions because you don’t have time and you lose track of the fact that, “Oh wait, actually this is solvable, I just need to hire someone to do it.” Or you need to automate it.
Because it creeps up on you bit by bit by bit, pretty soon you’re letting something completely drop on the floor, but because you got there bit by bit by bit you don’t even realize that you’re doing it until suddenly it’s a big problem. So it’s looking for those things that you’re starting to outgrow.
Harry Stebbings: That’s the value of VCs, seeing around the corner for you.
Steve Newman: Yeah. That’s true, actually.
Harry Stebbings: I always believe that. I just had a guest on the show that told me we would not have VCs in two years time. So I’m pleased there is still some room for VCs in the market. I do want to, before we move into the quick fire, discuss another element that’s crucial to the scaling success story is the element of the success of your customers. The customer’s success, obviously one of the hottest topics over the last few years. When we spoke before, you said to me maybe delay building your customer success team. This maybe goes contra quite a lot of what I hear on the show. Why do you believe this, Steve? What were the benefits to delaying the building of the customer success team?
Steve Newman: That’s the approach we took at Scalyr. I was the entire customer success team until about a year ago. We were quite far along in the growth of the company. We had well over 100 customers at that point. Customer success as a function, of course, is critical. So when I talk about delay the team, I don’t mean delay customer success, I just mean delay breaking that out into its own team. I think there’s two reasons for that. One is customer success is a critical input channel for you to understand how your customers are succeeding or not. Where is the product working for them? Where is it not working? Where are the rough spots where you can improve things? So you want to be careful not to hire that team too early and let them … When you do hire them, they need to not become a communications barrier. By having other core people on the team, such as my case the CEO. Doing that work directly with the customers, you’re absolutely ensuring that you’re hearing all of the feedback directly.
The other reason is, we talk about customer success being critical, of course what we really mean is happy customers and successful customers are critical, but having a big team of people devoted to that is the wrong way to accomplish it. It’s critical that the role of customer success is not just to make the customer successful, it’s to provide the product feedback so that the customers are successful without help. If you scale that team too quickly, if they’re too good at their job, they will make up for a lot of failings in the product and you won’t develop that organizational muscle of having to constantly improve the product to stay ahead of what customers are tripping over. So it’s a critical function, it’s a critical team, but you want to make sure that they are not strong enough to carry the organization and hide flaws in the products.
Harry Stebbings: Absolutely. I agree with you there. I haven’t thought about being too good that they actually hide flaws in the product. So that’s the internal dynamics of the team there, which make customers successful and make customers happy. You also said before to me about the structure of startups and how they can take advantage of the nimbleness that SaaS enables to amaze customers. You did leave me on a bit of a cliffhanger there. What are those two ways and how can you break down that power in maximizing customer satisfaction, so to speak?
Steve Newman: Yeah, so the two things I, and these are both things we really just stumbled onto as we were developing Scalyr. One is when you’re working with a customer or a prospect and maybe especially with a prospect, sales prospect. They don’t know you, they don’t know the product too well yet. They’re getting their first impression of you. You’re working with them, demoing the product, getting a proof of concept going. Inevitably they’ll stumble onto some issue. They might encounter a bug, they might encounter some missing functionality in the product. Might just be that they’re looking for a feature and it’s there, but they don’t find it. That’s, of course, very common when someone’s getting up to speed on any new tool. That’s your opportunity to remove a thorn from their paw. To give them a just really quick turnaround on whatever that problem is.
Obviously that means responding to them and helping them, but it can also, because it’s a SaaS product and you can update the software so easily, you have the opportunity to go in and say, “Oh yeah, sorry you couldn’t find it. Actually, we do do that and here’s how you do it, and by the way we’ve already updated the documentation to reflect that,” or, “we’ve updated the messaging on that screen that you tripped over, so hopefully the rest of your teams that’s coming on board, they won’t have the confusion that you had. “Or, “You’re right, that is a bug, and by the way we’ve already fixed it.”
Even if it’s something tiny, even if it is just a change to some wording to make something less confusing, it may be very easy for you, but people really appreciate that. They’re impressed. It sends a message that you really care about that success. Then the other side is people sometimes talk about concierge features. A $2 word for you’ve got some function in your product that involves a human being taking some action, not fully automated. We’ve built that into Scalyr in a few paces. One is though our product, we’re ingesting logs from people’s servers and there’s a step where we parse those logs. We look though them and take that plain text and extract the structured information that’s hiding inside it. That means these rules have to be set up in our product to define where that information comes from.
So we’ve built a little language to define this. Our customers can go in and use that to define these parsers. Often our support team will also just do that on the customer’s behalf. We actually put a button in the product in the place where you would go to create a parser. The button says, “Do it for me.” That sends a message to our support team, and they go in and create the parser. We could also enable that experience just by having customers reach out to our support line and ask for it, but just by putting the button in, there’s virtually no extra work for us. In some ways it actually makes our job easier because that button automatically supplies all the information that we’re going to need, or otherwise there might be a couple of back and forth rounds between the support team and the customer. So that actually made our life easier, but also customers love it because they don’t feel like they’re bothering someone. People will feel bad about reaching out to support, even though you want them to do it. It’s also just quicker and easier for them. So it looks like we’ve got this great thing, it’s ever better than artificial intelligence. There’s a natural intelligence feature in the product. You push this button and a human being does something for you. At the same time it’s a very easy thing for us to provide.
Harry Stebbings: Can I ask, can I jump in and ask is that doing something unscalable?
Steve Newman: I say no. People talk about always you scale, you can’t things manually. You can if they’re efficient. When you’re 100 times the size, it’s going to be 100 times the work, but you should have 100 times the revenue to pay for it. It may be a silly analogy, but no one goes to GM and says, “How can you give cars to all your customers? When you scale you’re going to have to make so many cars.” But people pay for them. If you’re doing unscalable things up front that are not sustainable, where you’re doing huge work behind the scenes to make it look like you’ve built a thing that you really haven’t built. That won’t scale. But if what you’re doing is efficient, if it doesn’t cost too much, if it doesn’t take much time, if the economics are positive, then that scales just fine. So I think it’s important to distinguish between manual effort that is efficient and sustainable and economic and manual effort that is none of those things and makes sense only in the early days when you’re in the fake it until you make it stage.
Harry Stebbings: No, I totally agree with you there. I think we sometimes get lost in this, “Oh, it’s customized,” terrified vicious circle when, back to your other example’s actually very brilliant. I do want to dive though, Steve into my favorite really of any interview being the quick fire round. So essentially I say a little statement, and then you give me your immediate thoughts in 60 seconds or less. Are you ready?
Steve Newman: Sure.
Harry Stebbings: Tell me the hardest element of moving from tech co-founder to CEO.
Steve Newman: Managing people. Building an organization. It’s just a completely different skill set and it’s a lot of fun, it’s very exciting, but building a team has nothing to with building technology. So it’s been a lot of on the job learning for me.
Harry Stebbings: Sure. Tell me a moment in your life that served maybe as an inflection point and changed the way you think.
Steve Newman: I would point to my, really the time I spent at Google which was a huge education in working at scale. There’s a lot of things that make Google different and interesting, technology they’ve built and so on. But underlying all of this, and this is something you really feel when you’re there on the inside, is the scale of everything that’s going on. You’ll hear people say, “We’re launching a small experiment, it’s just one million users at this stage.” And things like that. I used to really get vertigo, almost literally in my early time there. We sat next to the Gmail team when we came in, and they were already at something like 50 million users back then, so just the scale [inaudible 00:27:50] was going on was astounding, but eventually you get unafraid of it and a big number is still just a number. That’s what really taught me that it’s okay to tackle something at really large scale. You can still do it.
Harry Stebbings: What’s the top lesson to selling to developer orgs successfully?
Steve Newman: I like to say that selling to developers is just like selling to anyone else, except they don’t want to talk to you and they don’t believe anything you say. So basically, you can’t tell them things, you have to show them. Demos, benchmarks, videos, maybe customer testimonials, things that they will feel that they can evaluate themselves and directly understand instead of having you feed information to them.
Harry Stebbings: Yeah, I love that assessment. Tell me, when I say success in SaaS, who is the embodiment of this to you, Steve?
Steve Newman: The company that leaps in my head would be GitHub. They just came seemingly out of nowhere and became the default option for an entire category. I think it’s one of these nice examples of they picked one thing and did it very well. One of the key things about SaaS is simplicity, and they nailed that. For whatever features that did or didn’t have, it had a pretty good base set of functionality just from Git and it made it very easy, even if it didn’t add every value you wanted it to add, it did nothing to get in your way. And then they’ve only improved and improved over time.
Harry Stebbings: Then final question, and probably my favorite of all, and you can choose here, there’s a bit of optionality. What do you know now that you wish you’d known at the beginning? This can be your beginning time at Scalyr or your beginning time at Writely. You can choose, but what do you know now that you wish you’d known at the beginning?
Steve Newman: I’ll go with Scalyr, and it’s very simply, when you’re growing rapidly, you need to make all of you’re hires three months before you think you should. This goes back to that doing things that scale or don’t scale question and spotting the turn. During rapid growth, things get ahead of you so quickly that by the time you’re starting to realize, “Oh, it’s a little bit too much work for me to handle this myself.” By the time you go and put together a job description, and go and find people, and interview, and get someone to come on board, and they start, and they come up to speed, you’re way behind where you needed to be. So just, you really have to be looking ahead and when something is a quarter time job for someone, by the time you then go and hire for, it will have become a full time job and so it’s time to start.
Harry Stebbings: Steve, it’s been such a pleasure having you on the show. As I said, I’ve been talking to Leo for months about how excited I’ve been about this. So excited for the time I’ve had with Scalyr. Thank you so much for joining me today, Steve.
Steve Newman: I thank you. It’s been great.
Harry Stebbings: I have to say, I really could not be more excited about the next chapters with Scalyr, building an incredible product and I can not wait to see the next chapters there. I do want to say if you would like to suggest names and questions for future episodes, you can on Instagram @HStebbings1996 with two Bs, it’d be fantastic to see you there.
That’s all we have time for today. I cannot wait to bring you a very special episode next week with Dan Reich, founder and CEO at Troops.ai.