Ep. 519 w/ Tobias Kunze Briseño CEO & Co-Founder Glasnostic
Intro / Outro: Welcome to building the future. Hosted by Kevin Horek with millions of listeners a month. Building the future has quickly become one of the fastest rising programs with a focus on interviewing startups, entrepreneurs, investors, CEOs, and more. The radio and TV show airs in 15 markets across the globe, including Silicon valley for full Showtime past episodes, or to sponsor the show, please visit buildingthefutureshow.com.
Kevin Horek: Welcome back to the show today. We have Tobias Koons he's the CEO and co-founder at glass Gnostic. Tobias. Welcome to the show.
Tobias Kunze Briseño: Thanks for having me, Kevin.
Kevin Horek: Yeah, I'm excited to have you on the show. I think, well, you've done a ton of really interesting stuff and with glass plastic, I'm actually really fascinated to learn more about that selfishly. Before we get into that, let's get to know you better and start off with where you grew up.
Tobias Kunze Briseño: Oh yeah, sure. I grew up in Germany more specifically in the south in Bavaria and Munich, born and raised. There went on to study in Berlin. I actually did not study technology. I did study music, classical music composition and conducting.
Kevin Horek: And.
Tobias Kunze Briseño: Yeah, to me, it's a straight line into tech as music. There's a lot of, it's a lot of mathematical aspects to it to some degree and went on to do cloud, not sorry not cloud went on to do sound synthesis and that was a straight shot from there into the computer world.
Kevin Horek: Okay. I find it's interesting that I find like a lot of people in tech, like we're a musician still are a musician or heavily into music or all of those things.
Tobias Kunze Briseño: Yeah. It's the abstract mindset, but it teaches you to form a mental landscape of what are your playing, what are your composing? What are you listening to even by, and that's the same thing you're doing programming. You need to visualize, create a mental model of, the program you're creating the code and the functionality that you're creating.
Kevin Horek: Sure. Well, and I think too, just creating something out of nothing right. Is so similar. Right. It's fascinating. Very cool. Walk us through your career, getting your PhD and then I want to dive into glass Gnostic.
Tobias Kunze Briseño: Yeah. As I mentioned on the sound synthesis side, digital synthesis side there, when I did it, there was a lot of programming involved. We did the still at the university with as is on the, on old VAX computers. There was of programming to be learned in particular, then coding in city and stuff like that. I started collaborating on in algorithmic composition software that actually came out of Stanford and then ended up, spending a year at Stanford, simply being a visiting scholar there. The decision was, am I going to do a PhD and back in Berlin, or am I going to do this and stand for it, ended up applying at Stanford and got accepted. Right. Okay, cool. And so ended up doing this here. I actually did not finish it because the sucking sound of Silicon valley was pretty loud. A bunch of internships worked at Silicon graphics in the, when it was a crazy cool company on the working on the OTU workstation.
Tobias Kunze Briseño: Again, digital media audio stuff, very exciting work. I remember there was a one day mode to Skywalker sound where were able to, in real time transpose things in certain channels to keep other channels constant. And that was a great effect, obviously. So that was exciting work. Got sucked when, when the.com boom happened, got sucked into internet startups and really have been in startup land ever since.
Kevin Horek: Interesting. Okay. Walk us through, coming up with the idea for glass Gnostic and what exactly is it?
Tobias Kunze Briseño: Yeah, really good question. As nasty as my second company, the first company, I was a, co-founder the technical co-founder of a platform as a service technology, think of this as a heroic circle, but behind the firewall that was acquired by red hat became open shift, ultimately. And yeah. Spend a couple of years on that side, looking at how do you optimally support the building of applications that support the developer. Essentially you write your code are going to run it with all the enterprise abilities built in with all platform abilities built in. And, but then notice that, who's writing these simple applications anymore. Back then, those used to be like two tier, maybe three ETL applications there's clearly before, but it already became apparent that these little two tier deployments really were a part of a much larger application landscape. There was a much larger architecture around it in the abstractions, in the platform as a service that we built, didn't really address that.
Tobias Kunze Briseño: It became clear that the interplay between these application pieces ultimately are the important thing to manage and not exactly what we do at class Gnostic, because what people do in cloud production today still is something goes wrong. Something happens in production where you need to do what do you do? You've got back, you analyze it and you, then you go back and you've changed code. Or maybe you change configuration, you change something static. It gets, that's what we grew up and what we learned to do. So something doesn't quite behave, right? You go back, you'll fix your code, you've redeployed, and you hope that it's gone and he fixed it. So you released patches. That's not only that doesn't take a lot of time and so one hand, but it's also very unclear whether it's actually going to fix it. What we do at close Gnostic is take almost an air traffic control approach to that problem.
Tobias Kunze Briseño: We go in and fix things as they happen in production. Simply by changing how the network works, simply changing how applications and services and functions interact with each other in real time.
Kevin Horek: Okay. Interesting. No, totally fascinating to me because, okay. But like, how do you do that? Because like, I understand, I very much understand the problem that you guys are solving, but how do you do that? Because we all know that you patch one thing, you patch one thing, it breaks 30 other things, or, that's the running joke, right?
Tobias Kunze Briseño: Exactly. It's experience, you'd apply it multiple times a day. One out of two or one out of three times, something else breaks, seemingly unrelated, you don't know, is it correlation? Is it causation? You have no idea. And you know what? Most of the time, it's not even worth finding out because the situation is different half an hour from now because something else gets deployed. Something else scales in, right? It changes all the time. It's not just requirements that are changing runtime behaviors change. We take the view that most of these runtime behaviors are not practically. It's not practical to fix them and cold. You just simply need to have a way to control them. If you zoom out, that's exactly what air traffic control does, right? It's easy to, it's an airspace problem, right? You, it's very easy to run 10 planes in an aerospace.
Tobias Kunze Briseño: You can see each other, you can read each other. It's not an issue. If you have hundreds, you need somebody that sees everything. That can't be anything you don't see. At a very high level, make sure nobody affects each other unduly. That's what we do. All the calls, the pilot, we change things on the wire.
Kevin Horek: Got it. Okay. Okay. So let's well, okay. First off, I guess, does, are you language agnostic then? Because you're so high level or how does that work or how do you actually connect into the code base?
Tobias Kunze Briseño: We do not connect in the code base and it's extremely important that we don't do that because in most situations, unless you're a small startup or you actually don't own everything, it's not your goal,
Kevin Horek: Right?
Tobias Kunze Briseño: You depend on things, you don't own things. You don't even have the chance to change the code. We sit in the wire between applications and services and, functions, whatever, and SAS services. We'd simply change how much, how many requests we allow or how many requests would allow for parallel. We shaped the latency, we, and we shape and calibrate bandwidth, very high level. Like again, the air traffic controller, we don't care. Is it that helicopter? It a plane is whatever it is, UFO. We simply tell the pilot, this is your possession. Go to this altitude, take this direction and fly at the speed. Okay. That's the level of management that's required to run production successfully today?
Kevin Horek: Sure. Well, especially big, big companies, right? Because there's so much happening. I'm assuming even from a security perspective, you guys can handle. If somebody is getting like trying to get hacked, or you can like redirect traffic, like Zack, can you do that kind of stuff?
Tobias Kunze Briseño: 100%. Yes. Security is one of the big aspects of what we're doing. It's flow controlled. It's a lot of, it's data flow control. We can act as a zero trust control, blame, don't allow systems to talk. Attack, vector it before the connection is accepted, we can interrupt that connection. Right.
Kevin Horek: Okay. How does a company actually integrate your technology into their platform then?
Tobias Kunze Briseño: We are what network people like to call a bump in the wire.
Kevin Horek: Okay.
Tobias Kunze Briseño: I always prefer calling this a brain and the wire, because we're more smart than just a bump, right? We insert ourselves in the data plane in modern speak and how we do that is environment dependent. We are not a single technology company in that regard. We are not an EBP F company wide. We are not in Cuba. Nita's only company. We are essentially an SRE platform and that works in all major environments. We simply inject ourselves into the network, into the data plane in the data path. And then we can take control. We can calibrate, we can regulate, we can shape. We can deny.
Kevin Horek: Right. It just a software play, a hardware software play, just a hardware play.
Tobias Kunze Briseño: It's just the software play.
Kevin Horek: Okay. That's what I guess, but yeah. Okay. Okay. Interesting. You're working with the company then to help, like, is it customized per company then? Or do you kind of have like a, here's generally what we do and then people have like, ad-ons for lack of a better term for it, or how does that kind of work?
Tobias Kunze Briseño: The technology is agnostic. It's not specific to the company. Every company has the, every larger company has these issues and the essentially complexity issues and how we are being used though differ slightly from company to company. There's a lot of cultural aspects to it. How is the team organizations, how many business units are there? All these things play a huge role. What are the sensitivities? The primary use cases. It is more security focused. Is it more performance focus? It more cost management focused is more of reliability focused. These things determine how people use our product, but the product itself is very horizontal.
Kevin Horek: Okay. Interesting. This might be a stupid question, but could you use it for user testing then to, or like to see what features are popular or what pages are popular or what's not being used to, or like that kind of stuff or not really?
Tobias Kunze Briseño: We can show this at a very high level. Keep in mind, we are really much more like a radar screen and air traffic control, but you don't see the full plane and how many people there on the plane and what's happening there. You just see a dot on the screen.
Kevin Horek: Okay.
Tobias Kunze Briseño: We don't look into the workload because again, most of the time you don't own it, but we can show you how it's utilized. We can show you that a certain service gets overloaded. It gets runs too hard. We can show you hotspots, these kinds of things.
Kevin Horek: Got it. Okay. So yeah. So I guess, yeah. Okay. Maybe user testing is a dumb way of putting it, but yeah, that's what I was getting at. That's interesting. Actually, that's really fascinating,
Tobias Kunze Briseño: But low testing of course fight. And how do these components work together? What's the capacity relationship? There an impedance mismatch between those things? Those are the really thorny problems in operations. It's not do I call the API correctly? That's something that you get during integration testing, but what is the load testing? How does it behave when it hits a certain limit? Right? Everything today in these architectures run in some form of degradation all the time, right? Most of the time you don't even notice nothing bad comes of it, but every now and then something bad happens. There's a Negress that you didn't, that shouldn't be there. Why is the system targeted this other system, right? Maybe misconfiguration, malicious, benign doesn't you don't know, but it's important that they detect these things rapidly or something gets overloaded and then it slows down. It's always nonlinear teams of events, right?
Tobias Kunze Briseño: Of slow on is over there. Maybe even a CPU issue, right? Turns into a latency issue on the next system, and then turns into a retry storm and so forth. It's a cascading chains of events that if you don't take control of them, ultimately will cause a great deal of damage can be very disruptive. Here, take this out of the equation just by adding a modicum of control.
Kevin Horek: Got it. I could be monitoring, like if I have 30 different pieces of software, you can monitor all 30, right. From my dashboard. Is that fair to say? Okay. Yeah. Like, well I have the interface up in front of me right now, but I'm curious, how would you describe it? Because there's, it's very cool. What you're showing people with your interface. How would you describe it without a visual?
Tobias Kunze Briseño: I keep coming back to the reader screen. Everybody gets access to our product mostly, almost 100% through the visualization piece, which is essentially an auto-generated service map. Okay. If you can see, what is Ryan running? You don't know what's going on.
Kevin Horek: Right.
Tobias Kunze Briseño: In particular, since we focused on the behavior, the aggregate behavior of services, not the threat of execution, right? We're not looking at the tracing of things we're looking at, do the systems behave, how to components behave. That is the first step to understanding. Understanding is always the first step to doing something about it, right? Whether it's your own, runbook, it's your own operational skills, your SRA skills, whatever it is, then our customers discover that some of these skills are much better played through our product. What you've automatically applied. Right. There's a learning curve behind it. It's an novel way of doing SRE.
Kevin Horek: Right.
Tobias Kunze Briseño: It's essentially how we feel as though you should be done, but it takes a week or two. Yeah.
Kevin Horek: Yeah. That's not that long, especially with how complicated, the stuff that you're, what you're doing is really complex. If you only have to learn it in a week or two, that doesn't seem like a long period of time at all.
Tobias Kunze Briseño: Yeah. Ultimately you grow with a part over time, but you started to, what is he doing? Coming back to the, into the thought from earlier, do companies use it differently? Yes, absolutely. They're try to achieve their goals in some people, for instance, that teams realize at some point, oh, we can actually do by exerting back pressure. We can do a whole lot of things now that were much more complex before. They do back pressure essentially for a few weeks and then discover, oh, we can either quarantine new deployments, which is just a different variation of the same idea, but outing control to the, to system behaviors. It was a learning evolution behind it.
Kevin Horek: Sure. So is the product web based then?
Tobias Kunze Briseño: There's two parts to the product one, I mean, call it the data plane where that's the piece that gets kind of deployed in people's VPCs if you will, on premises, the, the new on-prem or even on premises as well. The control plan is something that is delivered as a SAS. Right. That's simply consumed and most of the time, less gnostic.com.
Kevin Horek: Got it. Okay. How does, obviously the working remote factor into all this, did you have to modify some stuff? Did it really matter or walk us through that because obviously you potentially have people like in the office and then not in the office wherever, right?
Tobias Kunze Briseño: Yeah. It, technically, it didn't affect us because I would, data path, piece always runs in your VPC, your cloud environment in your on-premise environment, in your edge locations, whether people work from home or not.
Kevin Horek: Right. Okay. That's kind of what I figured. Okay. But there's a bucket.
Tobias Kunze Briseño: Yeah. People working from home really accelerated complexity in companies, environments. Right. That is a big driver for our tech shakers. We thrive on complexity ultimately.
Kevin Horek: Sure. Okay. Fascinating. I'm curious then, like, so how, or I guess how long roughly does it take to actually implement into my company? Because it sounds like I could probably get started pretty quick and then kind of gear up as I learn more and choose more and more to do, or how long roughly does it take to get going?
Tobias Kunze Briseño: That's exactly how it works. Everything we do with every customer is always, we start in a small environment and the first environment we installed there, let's say the first VPC, but the first Kubernetes cluster. It's the experience is always, well now the load switch has been turned on, right. The next teams look at that and says, oh, we want to have this tier. So now we run into clusters. So two BPCs or 20. So it's an expanding motion. The initial deployment, it re it depends on how standardized the environment is giving you this cluster. Literally it's a 32nd install in VMware. It may take a couple of minutes if you have something on premises. There's a weird firewall rules that need to take half a day. Right. The install, our soul, our install itself, it's always doable, I think within five or 15 minutes.
Kevin Horek: Oh, wow. Okay. Really quick when people can get started. Yeah. Interesting. Okay. I'm curious to dive deeper. Like how do you manage your roadmap compared to feature requests because you probably get that all the time or is it not really because you're so high level,
Tobias Kunze Briseño: Most of our feature requests are integration based and automation oriented.
Kevin Horek: Automation stuff. Interesting. More.
Tobias Kunze Briseño: Automation, ease, easier automation applying some of these remediating or preventive patterns, control primitives more automatically is a huge topic always. That's almost a hundred percent what we're working on these days. Cause ultimately when you run a complex environment, cloud production, you don't want to sit in front of, nobody wants to sit in front of a console all the time. So you get notified quickly. You want to be able to set a preventive control primitives. Thurston, certain issues can't even arise in the first place you want to set up auto micro-segmentation, which we already do. These kinds of things, make it just much more valuable in a smaller team contexts. Like not the large enterprises, which have ops groups anyways, but the more the SOE automation mindset around it, that's really what we're focusing on these days.
Kevin Horek: Sure. That makes sense. Nobody wants like the thousand notifications. They want the like one notification that they really need to deal with something, right? Yeah,
Tobias Kunze Briseño: Exactly, exactly. That's really where we can shine because if you imagine, but as developers, we used to put print ups in our code, now we still do the same thing. It's just better stuff these days. It's like, we have an intelligent monitor in there. We have a, we have observability in there, but ultimately the alerting is always coming from a deep, from a very finely green metric. If something happens, that's large scale and nonlinear, as we talked about earlier, you get hundreds of events because all these metrics start to trigger all of a sudden, and now your teams jump on these alerts because, and then they do what they know to know how to do. They don't do what they should be doing necessarily. They know what they think it is. Now you have a whole lot of like headless chicken mode in your organization going on.
Tobias Kunze Briseño: Whereas what we do is look at what's, what really matters, right? What really matters is like, how does a system behave? What's the outward behavior and very simple thought experiment. Even like, if you notice that between two systems, two components, two services, your requests keep creeping up and all of a sudden latency shoots up out of proportion. That's a telltale sign that you're degrading now on the upstream that your, your service component is actually running below peak performance because it's hitting all kinds of internal limits. And we detect this very easily. We can even validate this ad run time, but just pushing back against the request for see, does latency recover little inline experiment within 10 seconds. We have confidence that, yes, that's the case. Now we can throw an alert that, Hey, your scaling doesn't work here. There's an issue. Your peak performance is your past peak performance every single time for a few minutes before you scale out.
Tobias Kunze Briseño: These kinds of degradations are triggers for outages.
Kevin Horek: Right. Well, and that would be very hard to test just from the developer perspective without yeah. Well, yeah, exactly. Yeah. Okay. Fair enough. You can't.
Tobias Kunze Briseño: Because it depends on the exact situation in production right now, and it's going to be different five minutes from now,
Kevin Horek: Right? Yeah. Fair. Okay. Fascinating. No, that's really interesting and cool actually that you guys do that.
Tobias Kunze Briseño: We're the only ones doing that in the industry as far as I can tell.
Kevin Horek: Sure. Yeah. Well, I guess, well, and it's, well, I think the whole thing, what you guys are doing is like pretty complex, but you simple, you simplify it for enterprise. Is that fair to say,
Tobias Kunze Briseño: Yes. We just add a critical functional that's really missing from data centers or from virtual data centers from PPCs right in that is, I like to compare this with, a kindergarten,
Kevin Horek: Right?
Tobias Kunze Briseño: What happens we deployed today. We deploy. I was afterward like, just like if you would put 20 kids, 50 kids in a room and tell them to now, occupy themselves and exactly what happens within 10 seconds. You're not level as, at like 200 decibel and blood and tears are gonna flow, right? Because the kindergarten teacher is missing. There's this management function missing where the teacher says, yeah, Jill, you go on this table, you play with Dave over there. No, you, you use this toy and if five minutes there's other kids get it gets it and so forth. It's a capacity management task. In essence, it's a management capability that's missing. We bring this back to the deployment.
Kevin Horek: No, very cool. But, but I want to get your thoughts and advice on, obviously you've been involved with a lot of really kind of stuff that a lot of people use every day and, and whatnot. I'm curious to get your advice and what do you, cause you mentioned before were chatting about like growth mindset and kind of why it matters. I think, I would say maybe COVID kind of shifted that or what are your thoughts around that?
Tobias Kunze Briseño: Yeah. I think most, a common pattern that I see people fall into and mostly, obviously I deal with software engineers. I deal with DevOps people, and it's like taking the world as granted, meaning I don't have any influence on the world. I need to adapt to the world. And that's true to some extent, right? Of course there are forces that are larger than you are. What people tend to forget is that M not only do we change all the time, because our experiences shape us, we can shape to a large, much larger deal than we think as possible. We can shape our surroundings. We can do something about it. Right. I feel too many engineers, too many SRS feel, not confident enough to learn quickly to change the status quo and to pursue a goal actively. If that makes sense.
Kevin Horek: Yeah. I would agree with that. I would use to put myself in that category perfectly. So I totally get that.
Tobias Kunze Briseño: Yeah. There's somebody on the team, let's say, oh, how has a computer science degree from Berkeley or whatever. Right. Then that's regarding coming from Google. You don't dare to speak up because, oh, that's that a credential, the credential doesn't really matter what matters is what you do, even though smart person is not smart because they are a smart, but it's about what do they do without smartness and the learned behavior? How do they apply it? When do they apply it right into what effect? That's, I think the perspective that's often undervalued, I think,
Kevin Horek: No, I think that's actually really good advice and insightful, but I'm curious. What advice do you give to people to get over that though? Because it's really hard to change that mindset and decide that like, yes, I want to make this change. And it's also really scary.
Tobias Kunze Briseño: Yeah. I'm not a psychologist. I think it gets scarier. If you attach your ego to it, whatever you want to do, you think it's you and your perception self-worth hinges on the outcome of that action, I think is a way more important to simply do get s**t done in French and then reflect back on it. Yes, of course, you're not going to read everything. You're not gonna be perfect every single time. You're not going to reach the goal you want to reach, but you miss it only . You can look back on it and you've already learned. By putting yourself out there by doing something you've actually already changed your reality, you change the world, your immediate surroundings, at least. So I think that experience is important. I think something that Marc Andreessen's had many years ago in some interview doesn't matter is that, strong beliefs briefly held that has of that ring, right?
Tobias Kunze Briseño: Where yes, I'm going to do this. I'm going to put myself out there. I'm going to execute on that. It may be wrong five minutes later and that's fine. Right. I can be a different person. Five minutes later.
Kevin Horek: Yeah. Interesting. I also think too, just people are still so scared of to like fail at something, but sure. Well, your idea fails and you have to do something else or you pivot or whatever. It doesn't matter. Like, I just never understood why that mattered. Like who cares? Right. Like, but so many people get, so, and maybe it's the ego thing. Like I, I look back at my career. Holy cow. I don't even remember all the times I failed. It's been so many times. Like, I'm not saying like catastrophic there all the time, but sometimes it's just like, oh, okay. That didn't work out next. Right. Or it's okay. I got to like regroup and I got to go find a job for awhile or whatever. Right.
Tobias Kunze Briseño: Yeah. Yeah. I think it's, self-worth, it's your self worth is attached to the outcome of the task. As opposed to attaching it to the, the smartness and the dedication and all the other niceties of you executing that task.
Kevin Horek: Sure. Interesting. Yeah, no, I a hundred percent agree. It's fascinating. I'm curious. What advice do you give to entrepreneurs or even developers because I've been in this space a long time. You as well, I feel almost bad for people that are just getting started because it's so complex now compared to, even 5, 10, 15, 20 years ago.
Tobias Kunze Briseño: Yeah. There's so much software. There's so many frameworks. There's so many technologies. Canberra and explosion. Really. I don't have good advice. Other, I think kind of linked to what I just said is like, you start somewhere sure. In starting somewhere, I think the best learning is always by working on a project, but just doing things, try to reach a certain goal, try to implement something in a new language. That's how you learn a language. I've never learned anything different in a different way.
Kevin Horek: Nope. I actually think that's really good advice. I think there's, so obviously there's a ton of paid resources out there, but there's so much good free stuff out there, whether it's YouTube or other sites. Right. I think so many people forget about that. They're just like, well, I don't have the money for that. It's like YouTube is free. You know? Like there's not really an excuse. I think these days in a lot of cases, if you really want to learn something, sure. I get that. Not everything you can find on whatever. If you're trying to learn something new in a new language, you could probably find something that you're interested in that language that you can find it, a tutorial on it, whether it's video or not. Right.
Tobias Kunze Briseño: Yeah. And I think it's, you're absolutely right. It's like the resources are all there. I mean, from YouTube, you can do online classes and from MIT, you can, Stanford has online classes, but all that stuff is there's way more, you can watch on your way in your lifetime.
Kevin Horek: Sure.
Tobias Kunze Briseño: The other aspect there is that you iterate really quickly. If you want to learn a new domain, learn something in the first hour, then revise, how do you see the whole field connected to your existing knowledge? Map it out as quickly as you can. You can judge whether a certain resource, a YouTube video that takes you 15 minutes to watch. It's actually the right thing to do. It worth it, going deep on this as I have now, or is it should instead just watch four or five high-level things that helped me map out the whole space. Like these kind of techniques are really important. I think it's essentially, it's a lean startup for your knowledge. Right?
Kevin Horek: That's an interesting way of putting it and yeah, I agree with you. It's yeah. Like I, I don't know. I guess it's fascinating to me and I, I, I would assume, well, I'm curious do every year, then, or every few months, whatever, it doesn't really matter. Do you try to pick something new to learn? Or how do you kind of stay current with what's happening and how like basically what's next or what's coming.
Tobias Kunze Briseño: I wish I always showed up to pick new stuff. No, I'm running a, in it's every day, you spend 80% of your time doing things. You are not an expert in you haven't done before, at least in this particular shade of gray or whatever. As a startup founder, you're continuously dealing with being outside of your comfort zone. So that's your learning. Isn't actually, I'm not even sure I would call it a learning per se, because you don't, maybe don't get back to a certain thing for another two months. You got to do what you gotta do all the time.
Kevin Horek: Yeah. That's fair. How are we're like how, I guess how, when you don't know something and you need to figure something out, what tools or resources do you use to actually figure those out? Like, are you going to, with other people to try to find it online? Like where do you get that? Okay, I don't know this. Where do you go first?
Tobias Kunze Briseño: Yes. I think that's a super power that most people don't in particular developers don't build early enough. And that's your network. If I have something I can't figure out or feel, I should figure out in more detail, faster, I can call up people.
Kevin Horek: Right.
Tobias Kunze Briseño: I pick up the phone, have a two, three, four minute discussion conversation with somebody who's done it before. Right. It's that's absolutely necessary. Yes. You can read articles. Yes. You can read, do Google research, but you'll find very quickly that it's actually not a good use of your time because it takes you a lot of time to find the right resources. It's yes, you can search. You, an hour later, you still haven't found a good answer, right. Versus somebody who knows you, somebody, so vice versa already has a lot of context where you're coming from, what your situation is, the company situation at the time, how they did this with other customers before and so forth. Right. Super valuable. So the value of network is immense.
Kevin Horek: Any advice, by.
Tobias Kunze Briseño: The way, in engineering, the same thing, right? You today, going back to the camera and explosion, you need to, as a developer, you need to do so many things. You are not an expert in whatever. Let's say you do something GRPC. You haven't done this before. You're on a you're very briefly. If somebody you can call up, who knows how to do that, you can ask them very specific question. And that's what good engineers do. They don't know how to write a file system, but if they need something about Fonzie systems, they know who to call.
Kevin Horek: Yeah. No, I actually think that's really good advice. It's surprising how many people don't leverage that network, especially if they have it. Do you have advice for actually building that network because it's challenging, especially when you're first getting started.
Tobias Kunze Briseño: Yeah. It's a funny, because there's kids, we have no issues doing that. Right.
Kevin Horek: Totally.
Tobias Kunze Briseño: You make friends all the time. We can talk about all kinds of things. That's how it gets learned by talking about random stuff at school. Not necessarily in the lessons, but on the, during the breaks, right? Yeah. It's, it's the water cooler things. It's having common interests with other people and then talk about technical matters. It's I think it needs to be casual.
Kevin Horek: Yeah. That's good.
Tobias Kunze Briseño: Yeah.
Kevin Horek: Interesting. Very cool. We're kind of coming to the end of the show. How about we close with mentioning where people can get more information about glass mastic, any other links you want to mention and yeah.
Tobias Kunze Briseño: Yeah. Like, you know, always glass nastic.com. It's GLA S N O S T I c.com. It's like Glasnost and Perestroika. If you're old enough to remember, like Glasnost really meaning transparency that was, pushed in Russia plus gnostic.com and everything's there. My DMS are open, on Twitter, if you want to reach out or otherwise, I'm just to buy email@example.com as well on email,
Kevin Horek: Perfect to buy. Well, I really appreciate you taking the time and your day to be on the show. I look forward to keep in touch with you and have a good rest of the day.
Tobias Kunze Briseño: Absolutely. Thanksgiving was the pleasure of being on the show.
Kevin Horek: Thank you. Okay, bye.
Intro / Outro: Thanks for listening. Please visit our firstname.lastname@example.org to join the free community. Sign up for our newsletter or to sponsor the show. The music is done by electric mantra. You can check him email@example.com and keep building the future.