Photo of toddler at the bottom of stairs by @tateisimikito
Time to adopt a growth mindset (Source: unsplash.com)

Shifting Your Mindset

In this episode of Emily Omier’s “Business of Cloud Native” podcast, we talk about the startup journey, how to transition from engineer to founder and the critical importance of sales and management, among other things.

Below is the transcript, edited for clarity and brevity.

• • •

Emily: Welcome to cloud native startup. I’m Emily Omier. Today. I am chatting with Tobias, the CEO and co-founder of Glasnostic. Tobias, thank you so much for joining me!

Tobias: Thanks for having me.

Emily: So I always like to start with a simple question, which is: “Walk us through your journey as an entrepreneur a little bit, like what was your first company?”

How has your entrepreneurial journey been?

Making the Jump

Tobias: I think if you ask anybody, you’ll probably get a very similar answer. It’s always a jump in the deep end. Right? You’re leaving a cushy job. By definition, you’re doing something new, something you’ve never done before. So it’s always a jump in the cold water.

Apart from that, it’s nothing but gratifying if you are comfortable making this jump. I think no matter the outcome, it’s always highly, highly rewarding.

Emily: So going back to this, the first time you jumped off the deep end back in 2008, right? With Makara.

Tobias: Yes, a little bit before that, actually: 2007.

Emily: And so I always want to know, at what moment did you know or how did you know you’d jump?

Tobias: I think the way you know when to make the jump is probably pretty standard—at least, I imagine it’d be pretty standard. There is something you have a keen personal interest in, but it’s challenging to attain due to something else. So you see a clear need for a solution that can overcome this “something else” so people like you can attain the “something” you are so keenly interested in. And then the question really becomes how deeply you care personally about the “something”—how deeply it touches you personally. That is, are you going to be okay just limping along with whatever is there, or do you make the jump and give it your full attention? That’s the “jump.”

At that point, you say, “OK, I’m gonna do this.” You don’t know how long that’s going to take, but you’re going to jump anyway. And you’re not going to do anything else.

Emily: I feel like there’s actually almost two patterns, and maybe we’ll touch on this.

For some people, it definitely is the case that you’re not really looking for a company, but there’s this problem that you noticed, and it just starts becoming an obsession and then eventually you can’t ignore it any longer. But there are also people I talk to who are searching for something that will be a business.

Tobias: Yeah, that’s true. There is the question of who are you going to be? In the tech world, are you going to be an “engineer” founder, or are you more of a generalist?

I feel I am an engineer by training—I’ve done software more or less my whole life. And I believe that engineers can be both tech founders and generalist founders. We’ve been trained to tinker with things, to discover issues and things we want to fix, no matter the domain. And frankly, a lot of engineering is entrepreneurial. You discover a problem, and you fix it, right? You don’t take “no” for an answer. I always like to think about the difference between an engineer and a scientist like this: the scientist tells you that anything heavier than air can’t fly. The engineer makes a plane. And that’s a fundamentally entrepreneurial attitude.

So I think there’s a natural affinity between engineering and entrepreneurship.

But clearly, generalists who come, say, from the marketing or the finance side can be entrepreneurs, too! The question is simply: “Do I want to apply myself?” Yes, as a generalist you can have doubts, like “Oh, I’m not a deeply technical person. How can I get this started?” But if you look at the other side, on the engineering side, most engineers are also blissfully ignorant about anything beyond engineering! And I’m sure we’re going to talk about this later, but, as an engineer, you need to get yourself out of that engineering mindset. And similarly, If you’re more of a generalist, you need to get yourself into the tinkering mindset. Which is difficult to do if you have a good wall street job. But that’s a different story, I think.

From Engineer to Entrepreneur

Emily: And how did that sort of process play out for you? The process of going from engineering to thinking more entrepreneurially and sort of educating yourself about everything else that goes into running a business, even if it is a very engineering-focused business,

Tobias: It is painful! There’s no way to put this differently. If you’re coming from the engineering world, it’s really a very cozy world deep down! The problems are more or less deterministic. You’re looking inward into a problem. A lot of people feel comfortable in that spot. Once you do file systems, you always do file systems, and so forth. You become an expert. Computer science educates us to get a master’s degree and then a Ph.D. So, by definition, your focus gets narrower and narrower.

Entrepreneurship is the opposite of that! You need to broaden your horizon. You almost need to forget everything about the engineering side of things. You need to understand how the market moves. You need to understand the importance of marketing, the importance of sales. What is sales in the first place? The number of engineers I’ve met who do not know the difference between marketing and sales is staggering. That’s where you’re going to make all the mistakes.

And there are two ways out of it. Either learn this yourself or spend resources to hire somebody who can do it for you. Ideally, that would be your “sales” co-founder, or you’re going to have to do this yourself. It can be done, but you need to realize how important it is. So that’s, I think, the biggest jump for an engineering founder to realize if you don’t have somebody who is the business person, you need to do this yourself.

Becoming a “Businessperson”

Emily: And how did you become a businessperson?

Tobias: Almost naturally. It feels kind of weird. I still wouldn’t call myself a business person, but I guess that’s what I’m doing these days! It feels weirdly natural because if you do engineering for a long time, you have thought about engineering problems from many sides. You’ve thought through the technical issues, and you’ve found solutions for them. Then you start thinking more and more about, “How can we maximize the value of what we’re building here? And how can we get this market?” And once you start asking these questions, you’ve already left the field of engineering.

So, after many years in engineering, how to fit something in the marketplace is a much more interesting question than how to engineer something. I mean, both are very interesting, but it’s like once you’ve kind of solved a lot of engineering questions, the next really interesting question is, “How can we get this to market?”

There are no Learnings

Emily: I’m curious, what changed between your first and your second startup? What did you do differently, or what are you doing differently now? Because you feel like you learned something.

Tobias: I think you really never learn fast enough. And one of the biggest learnings this time around is that there is very little I can apply from the prior experience. We started in 2007 and sold it off in 2010. And the world has changed dramatically since then! So, when I catch myself thinking, “Oh, I’m going to just do this like the last time,” it’s probably wrong.

And mostly, it’s wrong because the marketplace—including the startup ecosystem itself—has changed drastically. It’s much more global. There are many more startups around, and there’s much more money. The physics of getting a product to market has changed massively. So I would say there’s almost nothing you can learn from the past experience, even if that experience lies just a couple of years back.

Emily: To what extent do you even feel you can apply the lessons you have learned in this startup, like, the lesson you learned last year? Can that even be applied to a problem you’re facing right now?

Tobias: It’s a difficult question, I think. Because whatever you’ve learned last year is going to inform you this year, no matter what you do. I don’t think we are mentally flexible enough to disregard that and put ourselves in totally new shoes. So I think the learnings from last year always influence you this year. But the question is, are they truly “applicable”?

If you look at what has changed in the past year. COVID and how we’re maybe getting out of it soon, how enterprises buy very differently today, the pace of technology that is so deafening these days: you may even have to adjust how you talk to customers every month now!

Except to Aim for Speed

Emily: And what would you say was your biggest challenge with your first company? What would you say is your biggest challenge now with Glasnostic?

Tobias: I’m going to contradict myself a little bit here because I’ve said earlier that there’s nothing to learn from what was 10 years ago. But it turns out that some high-level things remain pretty constant!

And I think the area where we always fall short is getting sales kicked off early enough. I think ultimately, there’s no such thing as getting to the first dollar too early. And in both cases, we’ve done this a little bit too late for my taste, and it’s not just because we didn’t know that that’s important.

It’s just, it always takes longer until you’ve got the market dialed in. You don’t know how the product will fit in and so forth. But unless you sell a well-understood product— essentially a product that everybody is selling—it is very unclear at first who your target audience is and how you get this to market.

So there’s learning involved. And you think initially that learning will take three months, but it invariably ends up taking a year or more. And that’s something where I wish there was a better way of doing it. Having your ear very close to the customer is good, but even that takes time. Design partners need to be found, relationships need to be built, and then you are still beholden to their time schedule.

So I think the learning from both startups is: delays add up, and you can’t be early enough on the first dollar.

Emily: And if you were to do this again, what would you do differently to get to that spot sooner, to get to the first dollar sooner?

Tobias: I don’t think there is a silver bullet, so it’s always a little bit of an unknown. But yes, trying to sell the solution before you have it is pretty much the only thing you can do.

Of course, you need to do this in an ethical way. You can’t sell something that clearly doesn’t exist. But you need to start the sales cycle on day one, or maybe even before day one. Get early interviews, get immediately into a sales conversation. “If we would get this to you two months from now, would you buy it, and how much would you pay for it?” I think there’s ultimately no substitute for going after the first dollar.

Emily: How uncomfortable do you think that is, particularly for someone from an engineering background?

Tobias: Massively so. Almost insurmountably so. The number one entrepreneurial quality you need to learn is being OK with always being outside your comfort zone. That’s a muscle that needs to be trained. It’s extremely uncomfortable to ask somebody for money, particularly if it’s a warm intro through somebody else. Nobody likes to get rejected, and nobody likes to hear, “No, we’re not going to pay for that.” But it is a critical conversation to have.

“The number one entrepreneurial quality you need to learn is being OK with always being outside your comfort zone.”

By the way, also with your co-founders! Have the money conversation. Don’t push difficult conversations aside before you start the company. Be very clear about who owns how much and who makes the decisions. It was never a problem with my startups, but I’ve seen this in other startups. These uncomfortable conversations need to happen at the earliest possible point. It’s a very healthy conversation, and it’s the same thing with customers.

Becoming a Better Salesperson

Emily: How did you learn to be a better salesperson or even do founder-led sales?

Tobias: It’s work-in-progress! I don’t feel like I’m a first-rate salesperson. The only aspect where I think I may be first-rate is in my appreciation for sales.

I think sales is obviously essential, but being a true salesperson who can convert deals, who understands the customer, who can be consultative, listens to customers—which is extremely hard to do, particularly when you’re high on Kool-Aid—you only learn these skills after 200, 300 or 500 enterprise deals. It’s a learned art, and we should be under no illusion about it.

Thankfully as a founder, you get a lot of credit in the sales field, but you’re not a salesperson. You’re the founder. The other side knows that. So it’s not as difficult as you think it is. But I like to surround myself with people from the sales field, ask them questions and ask them for advice. It’s a constant, everyday learning process.

Emily: And in fact, that’s a good thing to ask about as well. How does a founder know it’s time to move past founder-led sales and start hiring a salesperson? And then how would a founder sort of evaluate if someone is a good salesperson or not?

Tobias: I don’t know. I haven’t hired that person yet. We are mostly still in the founder-led sales stage, I would say. There are glimpses of this fantastic stage when you realize that somebody else can talk to a customer and move the ball forward. That’s a great experience because not everything has to come from the founder anymore, but I haven’t hired somebody in that role yet.

People Management

Emily: Aside from sales, what do you think are some of the other core skills that an engineer has to really cultivate to make the leap from engineer to founder of a growing and successful startup?

Tobias: Management, no question about that. People management. I was lucky I was in a management role before starting my first company. I wasn’t a great manager by any means, but I was an okay manager. And it’s always striking if you look at engineers, individual contributors, how little appreciation there is for the importance of management! On the technical side, they understand this very well: If you want to build a bridge, it is super easy if I just have to bridge a trench—I just put a plank down and can walk across it. If we are talking Golden Gate bridge, though, it’s a whole different ball game. From a civil engineering perspective, absolutely every engineer understands this. If you want to build a Golden Gate bridge, at that scale, you need planning. You need an insane amount of management. There are risks to be managed. It is a huge project. So, anything larger than what a single person can do needs management. And there is very little understanding of that key insight in the engineering community. So that is the number one after sales in my book.

Management is the second most important skill you need as an entrepreneur. How do you manage without micromanaging? How do you set the right direction? Because you can’t be there all the time. You can’t be the bottleneck of anything. So, you can’t be looking at everything; you need to trust your team. That means you need to focus on enabling the team to make the right decision in the context of the business. That means you need to look more and more at goals and give direction instead of telling your people what to do step-by-step.

Step-by-step instruction is great if you teach somebody or coach somebody, but to manage your company, you need to get away from that. It is very easy to get stuck in that mode.

So, yes, management is a massive hurdle for many people, I think.

Emily: One comment I’ve actually heard from engineers is that they’ve never had a good manager or that they’ve never had somebody that they would look up to as a manager. So particularly for somebody like that, how would you recommend building those skills in yourself, if you’ve never really experienced it? Being managed in a way that you felt was you?

Tobias: I think that’s absolutely key, and it’s true for everything we do. I think you cannot be a good engineer unless you have a good engineer to look up to.

“You can’t be a good engineer without looking up to good engineers.”

And it’s always been one of my favorite interview questions. When I hire engineers, I always ask, “Who is somebody in the engineering field you look up to?” I don’t need names. It’s OK to tell me, “The person who built the Golden Gate Bridge” or “The person who built the Hoover Dam.” It doesn’t matter. Just point to someone you look up to as an engineer. Only if you have such engineering idols will you know how good engineering may look like, at least in an idealistic way, and only then can you become a good engineer in my book. If you don’t have engineering idols, you’re merely a wage earner in the engineering field.

The same is true on the management side. If you never had good managers, you will have a terrible time becoming a good manager, and the next best thing would be to surround yourself with good managers—read the books. I know it’s painful for engineers because we like to look down on managers, but it starts with having an appreciation for the art of management.

If you are unwilling to do that, I think it’s a cop-out. If you say, “I’ve never had a good manager!” well, there are so many resources you can learn from to cultivate this appreciation for management.

And the same is true for sales. Cultivate an appreciation for sales, an appreciation for how difficult it really is.

Emily: And you bring up a good point. I was thinking, you know, managers are sometimes looked down on and sometimes outright despised. I think the reality, though, of course, is that there are good managers, and there are bad managers like there are good engineers and they’re not-so-good engineers. And you can’t have all managers be above average; that wouldn’t make sense. Some are not going to be so great, but that doesn’t mean as a whole that management, in general, is not worthwhile and that it can’t be done extremely well.

Tobias: I think in particular with management—and that’s different from engineering and sales—there are two sides to it! There is the managing down and the managing up. And every engineer is already a manager who manages up! How do you talk to your manager? Even if it’s not the greatest manager, how do you find out how you can make this person’s job easier so this person can help you more and can be a better manager for you?

That’s where many engineers don’t really want to invest. And it’s a great opportunity to invest.

“You can jumpstart management skills by managing up.”

And you need this later! When you start your business, you need to manage your board. You need to manage your investors. You need to manage up. Those people are your boss! It’s not like you’re the CEO and don’t have a boss. You have a lot of bosses—the entire board. You need to manage up, and you can prepare for this today by managing your manager.

Coming Up With Glasnostic

Emily: Interesting. Well, I wanted to let you talk a little bit more about Glasnostic. I’m curious if you could tell me how the idea came about, and at what moment did you decide, “We’re doing this”?

Tobias: Yeah, it’s interesting because it was really two steps, I think. My previous company was a platform as a service. And when you work on a platform for hosting code, essentially, you focus very intently on how you can make the building of applications better and easier. How can you take certain concerns that complicate the developers’ lives out of the code and put it in the platform, be done with it once and for all? And as we were hosting OpenShift—Makara got acquired by Red Hat, where it became OpenShift—two things became obvious.

First, nobody is building these simple, 2- or 3-tier applications anymore, where we have a web app with a database in the back, that sort of thing. Instead, people deploy them as components of a larger whole. So there’s an increasing degree of connectivity between applications; it’s more of a landscape of applications. Sometimes, there may be only two or three applications, but increasingly, there are 10, 20, 30, 50. So, you have one application calling the other application, and there are a lot of concerns that make your development job more difficult because the platform doesn’t help you. So that’s what I focused on initially, and I think that’s very close to what you’d call a service mesh today.

But then I realized very quickly that, while there are some things you could pick up and solve for the developer—better, intelligent routing, metrics around network calls and so forth, maybe even encryption between services. But the key insight really came through talking to early enterprise customers. That’s when it became super clear that the real problems are not on the development side; they are on the operations side. If I have all these applications floating around and changing all the time, there’s a lot of activity and change. I have a dynamic landscape of services at my hands. How do I operate this reliably?

More and more stuff gets deployed, it’s an explosion of applications, and I am no longer in a position where I can guarantee the success of my production environment with “better code.” So, what am I going to do?

That was the second spark for Glasnostic. We said, “Well, it’s no longer really about establishing connectivity, it’s about how to manage what’s happening across these connections. It’s the air traffic control​​”.

What can you do when the inevitable happens: your production environment is degraded, and you are about two to have an outage, or there’s a breach or some other instability. How can I see this as quickly as possible, and how can I do something about it as quickly as possible? And that’s where the air traffic control analogy is so fitting.

As an air traffic controller, I need to see the entire airspace, and there can’t be anything I don’t see. And once I see everything, I can exert meaningful control. I’m not concerned about what’s going on the plane. I don’t care what the food is. I don’t care how many passengers there are. I don’t care about the oil pressure on engine two. Those are developer concerns. I care about, “Does this plane go in the right direction? Is there enough space?” On the operational side, “Do I have enough resources? Does my micro-segmentation work?” and so forth.

So, yes, two sparks to the idea. Number one, connecting systems. Number two, operating these connections.

Emily: Do you feel like there was a moment when you knew this was going to be your next company?

Tobias: Yes. But keep in mind that if you ask any founder retroactively, you’re going to get a lot of rose-tinted perspectives. But, yes, there was this point at the beginning where it became clear that building the application is not the problem anymore. The problem was in the stitching together of applications. That’s when I started the company.

But then it took another six months or maybe a little more until the insight came that it’s not really the stitching-together and establishing of connectivity that matters; that’s also solved quite easily, and there are tons of service meshes that assist with that task. Once everything is stitched together and ceases to be a coherent whole, the operational crisis—that was the second insight. And that’s when we stepped on the gas.

Vendor-driven Open Source is Miles Ahead of the Enterprise

Emily: Excellent. Thanks for sharing that story. Is there anything else that you would like to add about the founder’s journey or lessons learned over the course of two companies?

Tobias: I don’t know why they would call it learning, but I think that, in the tech sector, we live in a really weird time.

Because on the one hand, there are so many great companies these days that build outside of the technology sector, outside of cloud native. So, in a way, technology and cloud native is actually pretty mature already.

At the same time, the noise in tech is deafening, and the pace of progress is staggering. Just look at the Cloud Native Computing Foundation: there are 1,400 projects on their landscape! And the crazy thing is: almost none of these projects are adopted in the enterprise because they focus on use cases that are too narrow and are, by definition, way ahead of the market.

So, in my mind, the problem we are facing in tech today is that, on the one hand, you have to be ahead of the marketplace, but on the other hand, that’s your biggest impediment to sales. Because, how do you pick up customers that are, on average, not just one or two, but three, four or even five technology generations behind you, behind cloud native?

Of course, many companies today dabble in Kubernetes or may even run Kubernetes in production. But that is misleading. Companies have generations of systems, and the fact that they also happen to run Kubernetes in some way doesn’t make them cloud native. So the question becomes: How do you create technology today that helps companies across the spectrum, not only on the cutting edge of things but all the way back, maybe even all the way back to the mainframe? I think that’s the big challenge in tech today.

Emily: Well, thank you so much for joining me. This is a great conversation.

Tobias: Thanks for having me. It was a pleasure.