You can't make money selling to developers! The bottleneck of getting business requirements and creating business value used to mean waiting for the next waterfall release. That’s not the case anymore in the venture community. There’s programmatic access to infrastructure and DevOps/agile developments that offer super-fast cycle times. Now, the bottleneck is about how fast your developers can move and how much they can get done.
Today, we’re talking to Joseph Ruscio, general partner at Heavybit Industries, which is an accelerator for seed-stage companies and focuses on developer-first products. Tools and products that get you more leverage out of your developers are incredibly valuable.
Some of the highlights of the show include:
Measuring maturity of startups’ engineering teams by looking at SaaS list - what products they have in place and how many are using out-of-house vendors
Customers don’t care how curated or artisan a piece of your stack is, they only care that it works
Not all claims (scales infinitely or never fails) are true when it comes to products on the market, so people are skeptical
Heavybit focuses on helping businesses build a bottoms-up, grassroots community around its products and a disciplined inside/direct sales motion
Build vs. Buy: Whatever people try to do themselves is a costly, pale imitation of something they can buy
Advice for New Entrepreneurs: Never compete with AWS on hosting compute because it will obliterate and Amazon is great at plumbing, terrible at painting
AWS’s version of your product won't be as sophisticated; continually work on it to deliver a more seamless product and customer success experience
Measure downtime/outages in terms of dollars by using monitoring tools that deliver more holistic, integrated, comprehensive experience than CloudWatch
Starting a company is easier; even if you're the 800-pound gorilla in the category you created, keep innovating and building or Amazon’s coming after you
Azure, unlike GCP, has ability to meet customers where they are, rather than telling them where they should be
Understand the problem your customer is trying to solve and understand how far out of their current comfort zone they're willing to go to solve that problem
Software exists to create business value; it doesn't matter what it's written in or how it's hosted, so some systems will be around for a long time
Full Episode Transcript:
Corey: This week's episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out their biases for different things. Some bias for having every feature you could possibly want, offer this amount at various degrees of maturity. Others bias for, "Hey, I heard there's some money to be made in the cloud space, can you give us some of it?" DigitalOcean biases for neither.
To me, they've optimized for simplicity. I told some friends of mine who are added DigitalOcean supporters about why they're using it for various things and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, IP addresses, DigitalOcean makes all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed price offers. You always know what you're going to wind up paying this month so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It clicks a button or makes an API call and you receive a cloud resource.
They also include very understandable monitoring alert and lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try it out. That’s do.co/screaming. Thanks again to DigitalOcean for their support with Screaming In The Cloud.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn I'm joined this week by Joe Ruscio who's a general partner is it at Heavybit Industries?
Joseph: That's correct, yeah.
Corey: Perfect. There are general partners, there are limited partners and I don't understand why there is a third tier called unlimited partners but that's probably one of those finance things I'll never fully understand.
Joseph: Yeah, it's surprisingly complex for what is honestly a fairly simple thing when you get down to it.
Corey: So Heavybit Industries is an accelerator for seed stage companies as I understand it. I'm simple and I think in terms of cartoons. So I'm going to more or less equate that to a venture capitalist. Am I wrong?
Joseph: No you're not, you're not wrong. So yes, Heavybit is an accelerator and I use that term, fortunately these terms are kind of thrown around without a lot of distinction but unlike a lot of what I think of as incubators that start with basically brand new companies. I mean Y Combinator being the canonical example. We focus on taking seed stage companies that are companies that have achieved some basic product market fit and have raised some seed capital which in this day and age means typically somewhere in the realm of one to even if it's what we call mango seed rounds like a $4 million and are a really starting to think about how they go to market more broadly than just having their friends that they get coffee with from other tech companies buy the product.
Corey: If I take a look through the list of member companies that you've been involved with, it's sort of a who's who in some respects. With respect to various companies that you've been behind, Serverless Framework, PagerDuty, Stripe, Circle, LightStep, LaunchDarkly was highly used on the first episode of his podcast. Treasure Data, Replicated and the list continues onward. These are interesting companies, what ties them together?
Joseph: Yeah, that's a great question and so in addition to these stage focus, we have another very intent for focus on what we call developer first products. It's a fairly broad definition but fundamentally, we founded the firm around this notion that a lot of the technological changed now in the last I would say 10 to 12 years. I guess really more like 10 years we look at Amazon AWS coming of age is kind of like a really big inflection point.
But historically in the venture community, there was always this now a canard of you can't make money selling to developers and that was because historically, the bottleneck of getting business requirements because fundamentally everything developers do at a good company is about creating business value. Everything kind of measured and should be measured to that lens.
But historically, the bottleneck in creating business value by taking the new requirement for the business and getting them into running production code was not your development team, it was like procuring servers, procuring space in data centers, racking and stacking and then there's what your quarterly release schedule. So you have to wait for the next waterfall release to go out.
Fast forward 10 or 15 years and this has now all been turned on its head. We have programmatic access to infrastructure, we have DevOps an agile developments breaking things down into super fast cycle times. Now, the bottleneck of implementing new business requirements into running code and production at a high performing organization is literally just how fast can your developers move.
Exacerbating this is that every company that's going to be an enduring company is becoming a software company at some level and by that I mean not like online media or ecommerce or anything but I mean really like companies like Coca-Cola and John Deere and Maersk Shipping are all fundamentally becoming software companies. What that means is I don't think as much work is going into which is great and we should continue but it's much work is going into like broadening the pool of developers that are available.
I don't think there will ever be enough and that means not only is your success going to be limited by how fast your developers move but how much they can get done because you won't be able to hire as many as you want in almost all cases. And so if you believe in all that which I do, it follows that tools and products that allow you to get more leverage out of your developers are incredibly valuable now. We have a thesis and focus on products and companies that do exactly that.
Corey: The challenge too that I found as I've gone through my own business is that historically, when I'm talking about business level concerns like the AWS bill has grown to stratospheric proportions. I haven't found the developers for this market or many other markets are good customers. First, it starts with I guess a healthy level of skepticism. From there, it turns very rapidly into a world where you are talking to people and their response is, "Oh, I can write a script that does that in the course of the weekend." and that's never true have but it does seem to be a somewhat enduring reality in that people underestimate how much work it is.
To the point where you finally wind up winning a developer over to become a champion, it turns out that their signing authority for budgets rounds to zero. So it seems like an awful lot of work to convince a developer to necessarily buy something only to wind up discovering that they can't. Yes, I realize I'm speaking and very broad generalities and painting with an extraordinarily broad brush. But that's historically been the theme that I've seen tend to emerge. Instead, you fundamentally have taken an accelerator and built exclusively towards companies that cater to that exact market. How does that work?
Joseph: Yeah, that's a great question and I guess there's a couple of things. First of all, my background before I came full time into actually on the investor, adviser, mentor side earlier this year, I spent effectively 20 years as a technologist, a first engineer and then an engineering leader and then an entrepreneur building actually a company in this space with this kind of similar goals.
So I've seen all sides of that, both as a buyer and as a vendor and now as an investor. You're absolutely right. I mean this is something where there is fundamentally I think a maturity level for development teams and organizations and I often tell people when I come into a company and not just kind of investing but like any company, whatever the hottest new startup is. I can generally measure the I think maturity of their engineering team just by taking a look at their SaaS list like what products do you have in place for starters and how many of those are you using out of house vendors.
Going back again if you believe as I do and I've seen that you fundamentally can never hire as many developers as you want. One of our customers once referred to buying this kind of products as hiring by API. what they meant by that is, if you look at products like Twilio or Stripe, you're replacing historically you would have needed a whole team of developers and a product manager and QA and some operations engineers with an API that you make programmatic calls to. Amazon’s AWS is a great example.
And so, I think it's one of those things that's more senior engineers who have been through a couple rodeos and have seen what happens when you spend all your time on things that Warner refers to it as undifferentiated heavy lifting and I think that applies to all levels of the stack. I think high functioning teams and I know I tried to do this is as an engineering leader, look really aggressively at everything on their list and ask like, which of these are competitive differentiators to us, which of these increases the core value we deliver to our customers that no one else can.
I used to tell my team obviously, the customer literally does not care how curated or artisan this piece of our Stack is, they don't care. All they care is that it works. So why spend our time there? One of the things we do at Heavybit and I think one of the things we help our member companies with specifically is we do believe and why we believe there's value in us focusing in this area is that we do believe that there are a set of best practices to take these products to market and one of the reasons for that is because the, I won't even necessarily say the buyers because it varies.
But many times especially in smaller companies, developers are actually the buyers but in large organizations say they often aren't the final buyers which you alluded to. This initial set of champions, our audience is extremely discerning and as people with technical backgrounds, you understand that everybody is very skeptical of all the products with all the market actually claiming to do all kinds of crazy things, scales infinitely, never fails and we know that's all not true.
We focus in on companies on exactly how you do two things, you build a bottoms-up grassroots just community around your products but then you also have to pair that with like a very disciplined inside or direct sales motion depending on the kind of go to market you have that can capture that and knows how to identify and qualify which companies are going to spin their wheels for a while and try to build this themselves.
I mean earlier in my career as a vendor, I used to get very upset when somebody would tell me like you said, I will build a script in the weekend and then as I became more experienced, I stopped letting that bother me because I knew an inside my head it was that those companies will be back in six months, those projects would fail in almost all cases and they would be back, and they would have learned their lessons and they would buy.
Corey: Yeah, if you legitimately can solve a problem in a script over the course of a weekend, maybe that's not a particularly defensible position to build a product around.
Joseph: Yes, yeah. I mean you obviously as an entrepreneur and a vendor, you have to be secure in knowing that whatever people try to do themselves is going to be a pale imitation of what you're doing and also that the ongoing maintenance costs, I mean that's the other great thing about hiring by API is unlike most of your hires, you don't have to budget or account for turnover and loss of institutional knowledge and retraining and shifting priorities because those products and those API's will always be there.
Assuming obviously that company is healthy but will always be there and will always work the same way and that just takes a big load off your shoulders. It's all these hidden costs in internal. The build versus buy, there are absolutely cases where build makes sense but it's usually much more expensive than I think you're naive or kind of more junior engineers often thank.
Corey: As you find yourself building companies that turned into in some cases runaway successes, do you find that there are certain tells early on that differentiate I guess winners from losers? I'm not asking for secret information on how you went on evaluating companies but I guess I'm wondering if you're starting to see a recurring theme that differentiates the companies that build something that can endure versus companies that build something that AWS releases a feature the week later that winds up effectively destroying their entire value proposition.
Joseph: Yeah, and so it's interesting. There's actually a couple good questions in there. so just to focus on, there is particularly with developer focused or IT or infrastructure focused products which we cover all those especially in the last say, I don't know, I want to say like five to six years because my company, so I founded a company called Librato which was the first hosted telemetry company, there's a bunch of other great companies in space now.
We started that 2011 and I actually built previous products there in 2009. At that time, AWS was very basic, object storage, a small number of easy to instances not the like infinite alphabet soup that they have now, load balancers, RDS was MySQL only.
Corey: Oh yeah, looking back I still remember feeling like this is a lot of services I need to learn, I'm never going to be able to wrap my head around all of that. I look back 10 years and laugh at myself.
Joseph: There's like eight or 10. Literally, it's like man, there's 10 services, how can I remember all these. At the time, there was this Cambrian explosion of all these different—there were like five different companies that were doing Host at Redis at the time. It's just like an absurd example, a pathological case. But then as we all know now, AWS started moving up the stack. The other cloud providers have followed. And so now they're offering all kinds of managed services, very sophisticated managed services in some cases and then basically any kind of flavor of hosted open source that you would run on some server somewhere. If it reaches a sufficient enough market size, I fully expect re:Invent I think will be done by the time this podcast is out. The information is reporting that they'll have a MongoDB host.
Corey: Yeah, I've heard that rumor a lot myself. Frankly let's be honest, Mongo is a terrific choice to store your data. Not my data that’s valuable, but for your data absolutely, go nuts.
Joseph: Yeah, but Amazon, as you, know is "Customer obsessed." and that's definitely a project that I think has passed the threshold. But it's a great example, you can be guaranteed that Amazon will continue to roll up higher and higher level of functionality. A lot of times, we do spend a lot of time talking about and with our companies because again, the point of all that was several years ago, it was fairly easy, relatively speaking to build a small business because you just provision some EC2 servers, ran something on top of it and then charge people to manage the thing you're running on top of EC2 instances. That is effectively gone. I mean, I don't know. You might be able to run a lifestyle business with a particular niche flavor of something.
Corey: Yeah, click a marketplace button, receive a configured running WordPress or equivalent. There's always going to be a niche market for that but it's not exactly the growth industry of the future either.
Joseph: Right and so then, you have to look for okay, what is the value you're going to bring. I gently tell new entrepreneurs me at least two high-level things. One, is kind of the equivalent of like what's that line I think from the Princess Bride like never start a land war in Asia, right? Well never compete with AWS on hosting compute. Whether it's like some VPS service or again hosting, whatever like do not compete with AWS on hosting compute because they will just obliterate
Corey: Asher, this does not apply to you.
Joseph: Yes. The main exception being if you have $1 billion war chest and 30 to 40 years history is this of software development. But outside other companies that are already doing that, no one else should. The other thing which is probably a little more subtle but think I primarily is much more important because not hosting compute is kind of an easy one. AWS I've heard the saying which stuck with me four or five years ago, Amazon is great at plumbing, they are terrible at painting.
And so I think what that means is usually we talk about 80/20 solution. I think Amazon and the way they develop software, they're very good at identifying basic needs of users. They're very good at putting out a serviceable basic solution. They've historically not been great at supporting documentation, the UI and UX to drive it. So we tell all of our companies there's this room and there still is and I kind of especially now believe there probably always will be for what we call premium solutions.
You pick your niche and you go deep on it are then you can be certain that AWS will have a version of it at some point. But if you're doing your job and you're executing, it won't ever be as sophisticated as yours because you're going to continue working on it, you're always going to be ahead and you can deliver a just better more seamless product UX and customer success experience.
And so again, taking watch LaunchDarkly as an example, I expected Amazon at some point will have a feature flagging service. I expect it will be basic and if you're a tiny company with simple needs, it will be more than fine. I don't think LaunchDarkly will lose a lot of their enterprise customers to it if that makes sense.
Corey: Absolutely. I think that you'll see a basic version of everything I mean you have gremlin for advanced chaos engineering or you can use the basic service and just run your stuff in US-East1.
Joseph: Yeah exactly, I mean that's like the original managed service. Which by the way I love the tee shirts. I got mine in the mail the other day.
Corey: Well, thank you.
Joseph: I thought the subtle US-East1 on the side of the dumpster was a…
Corey: It used to be much less subtle and to be clear, I don't blame the tee shirt vendor for any of this but they wanted to take the arrowhead off of the Amazon logo and they wanted to sort of fuzz the US-East1 in the interest of not getting sued and I don't believe that AWS would ever sue something like that for a charity tee shirt that benefits kids with cancer but by the same token they said, "Cool. Great, we're onboard with that. Can you get Amazon to commit to that in writing?" and yeah you can imagine how the conversation went from there. So I fuzzed the logo and called it a day.
Joseph: Yeah, I think that's a very pragmatic decision.
Corey: We do what we must. So one thing that I find fascinating as you continue to look at the ecosystem, it's not just the relatively basic features that initial service launches wind up bringing along but there seems to almost be a sense of I don’t want to say delight because that's too strong but inevitability.
Where there's a big keynote at re:Invent which again as of this recording is next week where they announce a whole bunch of services and then my favorite macabre game that I play at re:Invent is walking around the expo hall and look at who just had their business model sure locked out from under them.
Joseph: Yeah. It was a good example going back. I mean last year when AWS announced not just one but two flavors of Kubernetes, right? EKS and Fargate. I'm not going to name anybody but there were I think at least two or three vendors on the expo floor who were literally selling a managed Kubernetes service on Amazon. They provision EC2 instances, they run Kubernetes on it for you and you push in their containers.
And so it's some form of a platform as a service. I never had a chance to talk to those people before but had I prior to that, I mean that's exactly what I would've told them would happen at some point.
Corey: When you look at technology as how Kubernetes showing up in the New York Times and the Wall Street Journal you can pretty much bet that all the big players are going to be there. It's also the olden days of webhosting. When you talk about the small web hosting shops with the rise of things like Rackspace and later in time Amazon and DigitalOcean. The answer became very clear, how are you going to compete and their answer was always the same, "Excellent customer service." which means we don't really know how we're going to compete but that's an answer no one can argue with.
Joseph: Yeah. There's two answers that come up like that's one and then the other one is multi cloud which is also not a real answer. Yeah going back, the answer has to be it has to be something that through product and UI/UX, you can significantly differentiate. I think for instance taking another area, my background can probably do some ice there but monitoring is a great example. I mean when we first launched our product, cloud watch was extremely primitive. It was two weeks of retention at one or 5-minute resolution, extremely basic UI, and not all the services had…
Corey: I didn't realize that you launched three weeks ago.
Joseph: Well I've heard at least that it's made dramatic strides especially the last couple of years. But then you compare that to again and they're doing a great job and for I think basic entry-level people, that's fine. But then if you compare that to products like even New Relic or Datadog or the work SolarWinds has been doing and it's night and day.
Again if you're measuring your kind of downtime and outages in terms of dollars, it is well worth investing and good observability in monitoring tools that deliver like a far more holistic, integrated, comprehensive experience than a cloud watch does. I actually know some people in the cloud watch team and they're great.
Corey: As do I after the article I wrote a couple of weeks back that that more or less savaged them. To be clear I hope and trust that in the not very distant future, I'll get the opportunity to write an article or blog post or similar with the theme of, it's better now. I really hope it is. There's always going to be a place for monitoring vendors. if for no other reason than you need to have something outside of the platform, your production environment runs upon in order to tell you when it's experiencing issues. There's just that philosophical story there. But yeah right now, there's so much more that needs to happen. I'm not convinced that cloud watch is ever going to provide a comprehensive story around. But there is at least as of the date of this recording, a lot it could be doing that it isn’t.
Joseph: Yeah. but again, it just all comes back down to as an entrepreneur and founder, you need to be obsessed with products, you need to be obsessed with user experience and you need to make sure that you're always delivering some value above and beyond what's a kind of basic 3-letter service from Amazon does and you have to make sure that for the majority of customer use cases, release customers with real purchasing power, what you're offering above and beyond is real value or the thing that you're building has the opportunity to provide that because again going back to platform as a service, or hosting compute, or even databases there's not really a lot. Like Amazon, if the primary interface of your product is a simple API and there's not really a lot of need for any kind of management or orchestration layers, you're probably going to be in trouble.
Corey: And that's really I think the lesson that we can take from a lot of this where basic building blocks even to services have always been Amazon's strength. Now they're trying to move up the stack into higher level managed services that solve specific business problems and on the one hand, it's really neat to see. On the other, it's not historically in their core DNA and if you have sophisticated requirements, I don't see that there's necessarily going to be something coming from AWS that takes the market by storm.
If you need a basic thing to check the box for some random higher level service, yes, there's a great chance that AWS will release that. Will it wind up being a nuanced exploration of the space? Probably not on day one and as a result, I feel like there's room for a wave of innovation I guess. The waves breaking ahead of the bow of the ship that is Amazon. There's always going to be to some extent a story for partners and vendors in that space. That said, I think that anyone who's taking what they're building today and effectively not iterating on that in any meaningful way, will not have a business in five years. Do you think that's a fair characterization?
Joseph: I think so, yeah. I think honestly if anything would have happened, it's just that the bar has been raised so the two things have happened. One, it's become much easier to actually start a company. Trying to hire engineers in Silicon Valley aside. But other than that, it's much easier to start a company that's ever been particular with things like Stripe Atlas for example. Where it's basically like AWS for starting companies. But on the flip side, I think particularly again in this niche nation of infrastructure, developer-oriented products, I think the bar has been raised for what you need to not only initially deliver but also like the continued kind of execution on product and just continuously improving your product.
Especially with consumers, that's fundamentally a good thing. I just think whereas historically, it was probably a little easier to rest on your laurels once you had created your category and established your leadership there. Now you know, even if you're the 800-pound gorilla in the category you created, if you don't keep innovating and building, they are coming for you. I think as long as you're aware of that, that's not a bad thing.
Corey: I feel like we spent a fair bit of time talking about AWS specifically which I think is fair but something that has been on my mind lately since I just got back from a trip outside of the bubble of the Bay Area which is a good thing because as of this recording, that bubble is full of smoke. I encountered something that sort of surprised me in that if you'd ask me a month ago to say, "All right, what is the second cloud if not Amazon that's going to I guess continue to win in the market?" I would have opened with GCP.
Having been outside of this ridiculous technical echo chamber, I've completely done a 180 on that. At this point, I firmly believe Asher is the second cloud not necessarily from a story of technical capability which is where I went wrong before. I fell in the engineering trap of believing that capabilities are going to define the future, but rather in the ability to meet customers where they are rather than telling them where they should be. Is that something that I guess has risen to your level of attention as you explore various multi-cloud stories as you go through the world and see I guess what real companies are using?
Joseph: Yeah, absolutely. By the way, you're 100% correct and I mean there was actually literally just some earnings results where it's not even close. I mean I forget Microsoft is like 4X or 5X. Asher four or five exercise of GCP. GCP is "only" I think it was 1.6 billion. Like you said, you spend time on AWS a lot but I just kind of mentally substitute that for viable cloud computing which I want then absolutely Asher and also Google with and as someone who was a buyer from about 2008 until really the last 10 years.
So for the whole ride up, I remember initially being very excited when GCP first started coming out. And with the continuous load balancers which could do crazy things at that time, ELB couldn't do and so there's a lot of promise on techno capabilities. I think meet customers where they are. I saw someone retweeted something just recently which just really resonated where it said, it's a customer talking to GCP and says, "We want X." and GCP says, "Great, but we're going to sell you Y because that's a better way to do it.
Then the customer says, "Great, we're going to go by X from Microsoft." And I think there's this concept called I believe it's overtone window where I think what Google has always struggled with and becoming like less and less, they had a very recent obvious executive shakeup I think trying to address this, Diane Greene is on her way out. They've brought in someone from literally Oracle which is like the least Google Company you can think of.
Corey: True. Their cloud is going super well so that was absolutely a smart move. Smart and cynicism aside, it probably is the right direction.
Joseph: Yeah. I think the problem is and I mean if you look historically, so when GCP launched, it launched with Google app engine which is a great example of something way ahead of its time. It literally is like a platform as a service. not only way ahead of its time in terms of saying, "Hey you can just ship us your app code and we're going to run it in these things we call containers which nobody knows about yet and just obstruct way all of the infrastructure, servers, instances everything also it only runs in Python because we as Google have decided that's the best language."
I think there was some surprise when two years later, Amazon was roundly trouncing them just by selling Linux, hosted Linux servers. I think they've gotten currently better but I think it's very hard for an organization that large and that ingrained and being literally and I'm not saying but they are like the smartest people in the room. If you look at things like Spanner and again like the load balancer they have and this other piece of technology, they have by far the best cloud tech.
They just don't crack fundamentally as an organization and I know they're trying to get there as to how to sell the enterprise which is you have to understand the problem. There's two things, one is which everybody knows, it's understanding the problem your customer is trying to solve. That's number one, that's I won't say easy but a lot of people get that. The second thing is a little trickier. You have to understand, this goes back to the overton window, how far out of their current comfort zone they're willing to go to solve that problem.
I think that has been Google's Achilles heel is because they've got the most crazy science fiction best way to do this that is decades away ahead of what their customers have been thinking they've tried to pull them from the huge legacy stacks directly fast forward 20 years and all the learning schools had into the new thing and a lot of people just can't make that jump. And then on the flip side, you have Microsoft not only that I think more deeply understands that but has just this massive enterprise sales channel with all the relationships in place that they've built up over decades with just the windows and office franchises.
What Microsoft has done the last couple of years I think is just incredible. The executive team there is I mean, between things like .net core, Quire and GitHub running Linux. I mean there is literally a Microsoft Linux distribution for some of their IOT stuff. I'm old, I was in on Slashdot in the fed wars the great fed wars of the late ‘90s. I mean if you told me the moves that Microsoft is making today, I nowhere would have believed it, not in a million years. I think the window is rapidly closing on Google being able to—I think they’ll be fine but in terms of being like a massive cloud player, they need to figure it out quick.
Corey: They do. I think you're right when you said that window is closing. Also, a certain lack of awareness that I'm picking up on from understanding how their customers view the world. Google historically has always been much more interested in what it's building than what it's shipping. As a result, they tend to deprecate things relatively haphazardly from the outside world that scares the crap out of enterprises who were in many cases running 30 or 40-year old systems to solve certain things.
No one is going to build something that has the potential of lasting that long on top of a cloud provider that has shown a willingness to change directions mid course. I don't think that there's fully an awareness of that culturally at Google at this point of how damaging that is to their reputation. There's also, of course, the whole separate argument of when you're trying to sell something to someone and you imply that they're incompetent because they don't see the world the same way that you do, that’s sort of a really crappy sales speech.
Joseph: Yeah. In one way, it's kind of fascinating because Google the consumer company because for instance, I don't think they've actually shut down or cancelled any cloud services really.
Corey: There have been a few. I have a list somewhere, I don’t have it at the top of mind but there have been I think three or four so far.
Joseph: Yeah. Well, I guess actually just a random question, is SimpleBB still running?
Corey: Yes, you can still get it on new accounts even. You have to request it I believe and they will do their damndest to steer you away from it but you can get it.
Joseph: Okay, well there's a good contrast right there I guess. but I think even more kind of interesting is I do suspect that now their proclivity which in isolation is probably the right thing but to shut down consumer services whether it's Google plus, or Wave, or RSS feed, you can't help but have some of that just because the way brands work in people's mind. You can't help but have some of that carry over to the cloud side.
Joseph: Where people are like, regardless at the highest level this is a company that is super comfortable to just do things that are better for them and shut these things down rather than have a handful of engineers continue to work on RSS feeds. If there are already examples of them shutting down cloud services, that just even makes it worse.
So yeah, I think I do think that's absolutely a problem that they're going to have to fix and they're going to have to be really explicit with their customers. Treating your customers or implying that they're in some way incompetent is absolutely the worst sales tactic. I think the best salespeople understand the problem that’s trying to be solved. They're not pushing a product, they understand the problem that’s trying to be solved, they positioned the way their products solves that problem and they sell it but they also again understand how far out of the current comfort zone they can pull the customer before it's just not tractable.
Even if it's technically the best solution, if you require the entire or like human—there's just some basic lizard brain stuff here for perpetuation of the species, we're only going to go so far out of our comfort zone at any one instance in time. the interesting thing being though is, you can and this is why I think the most successful companies do, even if they know ultimately the customer needs to end up that place they're not comfortable enough to move to now, you build your product and sell in such a way that you get them in and then over time you get them more comfortable and you move them over.
I think what AWS has with EC2 instances and then ECS and then EKS and they can bring in a lift and shift customers in the EC2 and over time, they can—any of the cloud providers can do this, sell in pieces but you can bring them into instance compute with lift and shift and slowly get them dipping their toes into containers and Kubernetes. Before you know it, they'll be doing serverless stuff. I think everybody wants to do the new things it's just it's what's within…
Corey: Throw away your 15-year-old billing system and rewrite the entire thing using this new paradigm. That makes us money, it becomes a different story.
Joseph: Yeah. You can never lose sight of the fact and it's tough especially like you said in the bubble because yeah, in Silicon Valley which absolutely is a bubble. I mean people are like, "You're using tech that's 18 months old." the vast majority of the world and I think this is the right way to look at it too like, software exists to create business value. If it's doing that, it really doesn't matter what it's written in or how it's hosted. If it's creating business value, I mean switching costs is a real thing. And so yeah, I think you have to expect that those systems will be around for a very long time.
Corey: Last question for you, how do I get you folks to fund Twitter for pets. The most innovative social network for four-legged animals.
Joseph: Yeah I've heard even refining your pitch there. I guess for us like I said, Heavybit has a very developer infrastructure-centric approach. I guess you would need to be API first, we need to understand the Twitter for pets API and how it's going to glue every consumer app on the planet together and then probably need some kind of understanding about how we'd not take the same path Twitter did with their API.
Corey: There's probably a very unfortunate story to someone there somewhere. The fun part about a lot of this is that it also turns out being I guess an ongoing battle not just to get noticed and discovered. So if people want to hear more of your sage dots, where can they find you?
Joseph: Yeah, that’s great. So I mean one of the things we do at Heavybit also in addition to working with companies and accelerators, we do a ton of work just around trying to level up the entire community on this, whether it's our companies or not. So if you go to heavybit.com we have just an incredible curated library. Basically we are constantly having speakers come in one off events. We run targeted conferences, we've call Dev Guild on things like pricing, or product marketing, or enterprise readiness of products. But all these we do very high fidelity recordings and transcripts so you can come in and it's literally I think at this point hundreds of different things.
Anybody who is building products in the space, go check it out, it's completely free. We have a regular newsletter you can sign up for in the site for both Heavybit and Dev Tools Digest which we kind of get weekly updates for essentially things in the space. And then finally I guess more kind of personally, I've recently entered the wonderful world of podcasting. And so, I have a brand new podcast we just launched the first episode a couple of weeks ago, it's called High Leverage and it's really just a series of conversations focused on the kind of culture, and processes, and tooling at the highest performing software teams use in this day and age. And if it can tempt any of your listeners, I would be fortunate to record an episode with you.
Corey: Perfect, well I look forward to seeing that come out. Thank you again for taking the time to speak with me today. I know that you're a busy person.
Joseph: Pleasure is all mine, it's great, great chatting.
Corey: Likewise, this has been Joe Ruscio of Heavybit Industries, I'm Corey Quinn and this is Screaming in the Cloud.