How Engineers Build and Lead in the Age of AI | Gregor Ojstersek | Glasp Talk #54
This is the fifty-fourth session of Glasp Talk!
Glasp Talk delves into intimate interviews with luminaries from various fields, unraveling their genuine emotions, experiences, and the stories behind them.
Today’s guest is Gregor Ojstersek, a seasoned engineering leader and the Founder of the Engineering Leadership Newsletter. In this conversation, Gregor explores what it means to be an engineer in the era of rapid AI advancement—not just building technology, but leading with thoughtfulness and intention.
From his early career experiences to growing his newsletter to over 150,000 subscribers and advising startups on how to build high-performing engineering organizations, Gregor shares rich insights grounded in experience.
He reflects on the risks of over-reliance on AI tools, explains the ideal role of a CTO in startup environments, and emphasizes why hiring “scrappy builders” often matters more than polished resumes when forming early-stage teams.
This episode offers a rare look into the mindset of someone at the intersection of engineering leadership and the fast-changing AI landscape. Whether you're an engineer, founder, or lifelong learner, Gregor’s reflections on vision, resilience, and long-term thinking will leave a lasting impression.
Read the summary
Transcripts
Glasp: Hi, everyone. Welcome back to another episode of Glasp Talk. Today, we are excited to have Gregor Ojstersek with us. So Gregor is a seasoned engineer leader, an engineering leader, and the Founder of the Engineering Leadership newsletter, one of the fastest-growing newsletters for engineers and managers with over 150,000 subscribers. And he's currently a fractional CTO and tech advisor, helping startups and companies build high-performing engineering organizations, and has led teams in various roles, from CTO at Zorion to Head of Engineering at ready2order. So Gregor also teaches a top-rated course, "Senior Engineer to Lead" on Maven, empowering engineers to thrive in leadership roles. With a passion for innovative problem-solving, mentoring, and remote team management, Gregor has made a significant impact in the tech world, and today, we will dive into Gregor's journey, his leadership philosophy, and how he's shaping the next generation of engineering leaders. And thank you for joining, Gregor, today.
Gregor: Thank you. Thank you for having me and for such a kind introduction.
Glasp: Thank you. So yeah, we are huge fans of your content and you and so on. And you have the fastest-growing newsletter, Engineering Leadership Newsletter. And it's so inspiring. But could you tell us what inspired you to start it at the beginning? I think I remember it's been almost three years, right?
Gregor: Yes, definitely. You know, it's always like me personally, I always like to have some challenges and some goals for myself, right? And, you know, as soon as I grew in my career, in my full-time career as an engineer, and then also to senior software engineer, team lead, engineering manager, head of engineering, I kind of knew that there's a cap to where you can grow in the engineering industry, right? And I knew that I would eventually become the CTO one day. And then I was thinking, okay, what's going to be next for me, right? And I always enjoyed helping, you know, people inside my company, inside my teams, to get better and to coach and mentor others. And I said to myself, why not help, like, also people that are outside of the company that I'm working with. So that's kind of like how I started with posting on LinkedIn, two times a week on LinkedIn, and then once a week on my newsletter. And, you know, the first six weeks were, really, really bad. So I kind of probably grew really, really slowly. It was almost invisible. But after six months, I couldn't be happier with how things are going.
Glasp: And did you choose Substack at the beginning, since the beginning, or did you choose others, like a newsletter platform?
Gregor: Yeah, it's a really good question. Because, you know, we as engineers like to build our platforms, right? So that's how I also started, right? I built my blogging platform. It was built with React and Gatsby. And, you know, I thought that that is the play, that is the way to go, right? And that was also like one of the mistakes that kind of, like, brought me to being invisible first six months, is because I was doing more coding than actually writing, right? So that happens, right? And, yeah.
Glasp: But you were writing, but you were writing code, right?
Gregor: Exactly. I was more focused on creating the best platform instead of creating the best articles, right? And also, like, I always like to go back to see, like, my old articles and see, like, how I progressed over time, right? But, you know, I also had Substack as, like, I had, like, my main platform to be React and Gatsby. And then I had also Substack as a kind of email platform. So it's kind of like, okay, I have this blog that is online. And then I also sent the newsletter to the people, right? And the blog didn't have a subscription, but Substack had a subscription. But then down the road, it was kind of like for, I think it was more one year towards the road of starting writing online. I then decided to move full into Substack. And that was one of the best decisions I made. And because of that, Substack is a social media platform. It's not only a writing platform. It's not only an email sending platform, but it also helps a lot with getting additional visibility. And you can write the best articles in the world, but if nobody is going to know about them, it's going to be really hard for anyone to perceive them as good. So, yeah, I'm happy to have the newsletter to be in Substack. And that's also my recommendation for everyone starting. Pick a platform that is actually proven. And you focus on writing. Don't focus on developing or other side quests. Focus on actually doing what is important. Focus on quality, make sure that you write articles that people are going to resonate with, that they're going to be helpful. And that is the key. Try to write something that people might get value from, and good things are going to happen.
Glasp: Yeah, that totally makes sense. Yeah. And, but you have now like around, you know, 150,000 subscribers, and how did the growth look like? Did you post something that went viral so that you got, you gained so many subscribers, or is it more like a steady, you know, grow over time?
Gregor: It's a good question. And yeah, first six months, I was basically being a lone wolf. I was just kind of like posting an article and then closing everything, and then went to do everything and focused on my work. And I didn't do any social media. I didn't do any, you know, I didn't do any promoting and any distribution of the articles. I did, as I said, I did two times a week on my LinkedIn, but I did the same thing. I posted, and then I just closed LinkedIn, and that's it. Right. But it doesn't work like that. It's, you need to you need to build a community with like-minded people around you. So after six months, I decided to connect a lot more with people who are on the same path as I am. Also kind of like writers being active on LinkedIn, and we kind of started to help each other. We learned from each other. We were doing collaborations. We started to do, you know, also podcasts, any kind of live events, and stuff like that. And people started to resonate a lot more because we were all helping each other, and we were all kind of like uplifting each other. And that's also like one of the lessons is don't try to compete with others, but try to collaborate and learn from each other. That's how you progress a lot faster. So that's how, after six months, when I started to collaborate and learn together with many other people who are on a similar path to I am, that's where I started to see a bigger progression and a steep growth curve. Because yeah, it's when you're working together with more people, you will learn together faster and more, and more visibility for everyone. We are all growing. We are all progressing. Is that the best way to grow?
Glasp: Yeah, so very, yeah. Community is important. Also, collaboration is important, but just curious, like, you know, many people trying to start a new thing, so they will quit, you know, before half a year, before six months. So, you did it. Yeah, you completed, like, you keep doing it. But what is the motivation, or why could you, you know, continue over six months?
Gregor: Yeah, you know, it's hard, especially when you start and you don't have any specific, you know, visibility of any social media, it's tough. And you need to get over the hurdle. You need to set up a goal for yourself, and you need to stick to it. Sticking to it is the best way to go. It's not going to happen just by, you know, one article, two articles, three articles, even 10 articles. You need to stick to it over time, and people need to see that consistency. And that builds over time. So even if it doesn't see the results immediately, over time, you know, if you're gonna be writing for two years consistently every week, there's going to be some progress. So I always try to look at it not as I'm looking just to get, achieve a certain goal, but how can I have a certain process that is manageable for long term, long period of time. The same is right now as well. How can I consistently put out two weekly articles that I can do over a long period of time? It's always like that, right? Anything that you start is all about repetition, learning from what you're posting, you know, just publishing, just actually posting out and getting your thoughts out there. And then you see what is working, what is not working. That is crucial. Without this iteration, you can't guess what actually is going to resonate with people. But as soon as you see something like certain articles, certain topics, certain things that are resonating a lot more with certain people, you try to write about it, and so on. And you only achieve that by having that repetition, consistency, and continuous learning, and so on. I like to kind of like match it within kind of like figuring out the most efficient tactic in any kind of game, right? It's very similar. You need to learn, like how to do this, how to do that, how to level up here, how to level up in this place. It's the same with writing, you know, progressing, growing as a newsletter, growing as a newsletter author, as a writer. How to write is going to be very easy for people to read, and so on. And the only way to do it is to be consistent and have good systems in place. Don't be just looking for those quick, quick wins and hoping that you're going to get like a bunch of subscribers in a short amount of time; it really doesn't happen that way.
Glasp: Yeah, it usually will never happen. And usually, yeah. And it happens to some people, so that some people expect, oh, it could happen to me. But you know, yeah, no, yeah, that makes sense.
Gregor: Exactly.
Glasp: But, you know, you said, you know, you do like tiny experiments, and based on the results, and you're okay, maybe I will, my audience is resonating with these containers. So then you write about but in that sense, like, how do you balance, you know, things you want to write and things your audience expects? Do you have some balance?
Gregor: Yes, definitely. That was also one of my motivations for starting the newsletter is because me basically growing from engineer to manager, basically becoming a first-time team lead. I had I did, I did a lot of mistakes. And because back in the day, when I grew to become the team lead, there weren't a lot of different resources to actually guide me through the transition. So it's kind of like winging it. And I thought that what is what what made me a great engineer is also going to make me a great team lead. But it doesn't work like that. So I needed to, it's actually a different role. And I was like, I was reading a little bit like different books, and so on. But I didn't have that guidance that is going to take me to the next step, right? But, you know, one of the things I want to solve with my newsletter is how I can help people who were in my position that are in my position, like growing from engineer to team lead, and so on. So a lot of the articles I read about is I read about is, what would like my younger self like appreciate to read that is going to be, you know, helpful, helpful for me growing to become a team leader, and also progressing as a team and growing to engineering manager, and so on. And I like that that's something that gives me energy, and it gives me, like, some sort of like, also motivation, and so on. Because I know, if I've struggled with something, I can help, let's make at least a couple of people avoid some of the mistakes that that is that is always energize me. And also, another thing that is really, really important is you can't just write things that are going to that are expected by your audience, right? But by your people, I also intentionally intentionally pick the articles that I want to learn more about, for example, I want to learn more about the specific, you know, how how people are using AI to increase self development productivity, how engineering leaders are using AI and stuff like that, I want to make sure I balance it, right? Things I want to learn, and I want to get better at, I want to see how other people are thinking about this topic. And also, we want to do research on a really detailed particular topic, and I will do that. And I will write about it. Because the best way to learn is to actually write about it. And also teaching is the same way. If you can teach, you teach something, and you understand it. And the best way to learn is to actually either write about it or teach it to someone.
Glasp: Yeah, learning by doing, learning by teaching. And that's the best strategy, it's like a Feynman technique. And yeah, so yeah. And, and, but I was curious about, you know, and what's, you said, you know, you are writing about AI. And I recently read that you're like 51% of engineering leads, you know, leaders, and new AI is negatively impacting the industry. And I was, that was a really interesting article. But, but could you tell us, you know, like, since you are doing research on AI and the impact of engineering, can you tell us what's happening? What's the impact of AI on engineering or leadership, and so on?
Gregor: Yes. So this was the recent trend that I discovered by checking through a bunch of different data that was recently collected, with 617 engineering leaders responding to a survey. And this, this, this was very interesting to me, and was like 51% of engineering leaders actually perceive AI in a negative way. And then also this trickles down to, to actually teams, engineering teams being less motivated, because of that as well. So this is, this is all connected. And I was thinking about it. And, you know, the reason, the reason is a lot of sensational takes, over the industry, right? Especially when we see Microsoft, we see Amazon, we see, we see meta about, you know, mid-level engineers not, not being needed anymore. We see Microsoft saying that they have 30% of AI-generated code in, code base. We see Andy Jassy saying that they're going to, in a couple of years, see Amazon to be a lot less people there and stuff like that. And those, those kinds of hot takes are sensationalistic takes, I like to say, are then trickles down to company leaders actually feeling that they're missing out on AI, that something is wrong, that they're doing something wrong and they have expectations through the roof because of such, such claims and such, such takes. And such takes really, really negatively impact, obviously, you know, the people who are actually doing stuff are going to feel the impact the most. And those are engineering leaders and engineers, and of course, the whole teams that are actually doing and creating stuff. So, that is an interesting pattern, right? And I think it's going to, unless something, something really happens, it's going to be really harder for engineering leaders and also engineering teams to manage the expectations the right way, because fear of missing out is really, really huge, is really something that a lot of people think that if I don't adopt AI at this time, is we are going to lose out to the competition. And you guys know, you guys are from San Francisco, and probably a lot of the talk is about, okay, how can we utilize the AI the best way? There are new startups going on every single day, new AI startups, and so on. And a lot of people feel like if they, if they don't do something about it, they're going to miss, miss a wagon. And this negatively impacts the people who actually do stuff. And the right approach should be to actually think about it from the business perspective, what is the best way to go for the business? Don't try, don't just try to go, and include a shiny new AI technology, but think about what is actually going to be the best for the business. And that's where engineering leaders needs to be very, very firm, needs to be very confident, needs to build a good credibility, needs to build trust with their leaders, and needs to, needs to push back to, to prevent any such kind of like effect where, you know, we need to use this tool, we need to use that tool, we need to use AI for that. And all of a sudden, there's, you know, people less motivated, less driven. And they just show up to actually do the work, they don't go any kind of extra mile or anything. Those kinds of things, things happen because of enforcing factors and, you know, people feeling, feeling that they're missing out.
Glasp: Yeah, so they are totally 100%. And I was talking with my friends, and founder and an engineer. And so, and we were talking like, so, because thanks to AI, non-technical people can write code, and they can build something, seems working in five minutes, 10 minutes, so that, I would say, like a business side, you know, like in the past, before AI, the business leaders don't know what's going on. They can't even write a single line of code. And so they get engineering, you know, engineering part, like engineers do engineering part, but now they can write something and, oh, okay, I could build something in five minutes. Why can't you do it? You know, why it takes three days, five days, five days. And so it becomes a kind of weird pressure. And so, yeah, that's kind of, I see this in, yeah. And I think it sometimes brings issues to like how to say, a lot of pressure, and they motivate teams and engineers. So I think, I think business leaders need to understand, yeah, we could build something, but engineering is not only like, you know, we have, you know, we should think about security and so on. So, yeah, I totally resonate and understand that.
Gregor: We can just, you know, build something with web coding as we like to talk about and hope that it's going to be a long-term solution that is going to be scalable, that is going to make sure that we are going to be able to get a lot of users that are using this particular tool or a service or whatever. And you can have like, for example, you can have teams and you can have multiple people working on that thing. If you just don't care about the quality of the code base, how it's actually done, the consistency with the other systems in place. And there are a whole bunch of different things. And I hear a lot about, like, for example, you know, some, let's call it non-technical people, create MVPs, but then as soon as they want to scale it, they have a whole lot of problems. And that's where, you know, that's where people like me have an advantage because I get messages and I get calls from people telling me, okay, we need help with this specific thing. We need help with this, that specific thing. We see this being a problem. We are trying to do this, but this doesn't work. But then it gets to a point where, you know, people see how important it is that you have a good understanding of engineering concepts and, you know, systems and how to do scaling, how to do actual team management, how to organize work between engineers and stuff like that. You know, I think the more, the more time passes, the more important it is going to be for engineers to have a deep, deep understanding of particular topics, especially for new people, new engineers coming to the industry. I see this pattern a lot, where a lot of entry-level engineers have a more shallow understanding of engineering topics, do they like a lot of different tools, including AI tools available. And, you know, it makes a lot, a lot of the work easier, but it also makes you a little bit lazier because you don't go the extra mile to go a level deeper. And the people who are going to go deeper are going to have a much better time in the industry. But I think people who are just going to have that shallow understanding of engineering topics are going to have a worse, worse time in the industry.
Glasp: I see. Yeah, totally understand. But so, thanks to AI, AI reflects human engineering, then, you know, if new grads or new engineers, junior level engineers, you know, enter the industry and want to experience engineering in deep, but so AI reflects it. So, meaning, new engineers, junior-level engineers, will have fewer opportunities to experience it. So, yeah, how should they do?
Gregor: Yes, they need to be proactive, is the only way, being proactive and taking ownership of your career, taking ownership of your work, and looking for work yourself. That is one of my biggest advice for entry-level engineers, because we can see, based on the recent survey that I've taken a look at from SignalFire, they have noted that there is around a 27% decrease in entry-level engineers looking for, for example, in big tech and also startups. They have decreased the entry-level roles. They're more looking for two plus years of experience, and like five years is kind of like the optimum level that big tech and also startups are looking for. So it's going to get only harder for entry-level engineers. And the only way to go is to take ownership, be proactive, and look for experience, look for things to learn yourself. Don't wait for work to come to you. Don't wait to just apply for the roles and hope for the best. You need to showcase experience, and you need to show actively that you can bring value to the table. You need to showcase what you can actually do, what the future employer can expect from you, what kind of things you know, and also what kind of tangible results you have. So building any kind of side projects is very, very crucial. Any kind of product is even more important if you can scale a product, if you have sales and marketing as well. That's only going to expand your knowledge base. And because one of the hardest things to do with building a product is to actually advertise it, marketing and sales. And you guys know this as well, right? It's really hard to do that. Building is the fun part, but you need to find opportunities and so on. Also, like for example, freelance work is really, really, it's been crucial in my career. I wouldn't be growing from engineer all the way to CTO if I weren't doing freelance work while also doing full-time work. So I did like different websites, different applications, mobile applications, and desktop applications, mobile applications. I learned so many different things because I just took on projects that someone needed. They came to me, okay, we have this problem. And then I started just doing it. I started learning on the fly, and I built it. And the best way, as we talked about before, the best way to learn is to build it, is to actually build it. And you learn the most that way. So that will be my same mentality, family and friends always need a certain website, needs a certain application. You have ideas that you see around the world. Maybe your colleagues have a certain challenge. Maybe your friends have a certain challenge. You can solve that with coding, with programming, and so on. And while you do that, you also learn the concepts of programming concepts. You go into deep into particular topics and so on. That is my recommendation. Be proactive, learn. Don't wait for opportunities to come to you. You need to increase your luck surface and look for opportunities yourself.
Glasp: Yeah, totally. But to me, it's a little bit tricky part because as an engineer, I write code. At the same time, every day I see on Twitter, LinkedIn, oh, sorry, LinkedIn. Hey, oh, there's a new model that comes out, and new 5AA coding tools come out. So, oh, should I, okay, let's say I'm using CASA. Oh, I need to add, you know, for some people, oh, I was coding on VS code, but I need to switch to, should I switch to CASA? Or now, oh, Windsurf? But, oh, they got acquired. So, and, you know, Cloud Code or, you know, Gemini command line launched yesterday, and what should I use? And, you know, but then, oh, I let them write code so that, oh, I have less experience coding. So, if I don't use AI tools, then I will be behind. So, it's kind of, you know, balancing formal fear of missing out and also understanding tools. But to me, I realized the best way is first, I try to write code or a component or something by myself. Then later ask AI to optimize or improve my code so that I can understand, oh, this is the best way to do X, Y, Z, or build this code, or something like that, so that I can learn from AI, also using AI tools. Yeah, but I don't know what to take or what advice.
Gregor: Yeah, it's crazy right now for new people starting. I think, you know, in my situation, when I was growing as an engineer, we had a different problem, and that was the problem of shiny new JavaScript frameworks. And there was a new JavaScript framework every, every, every, almost every day, right? And it was like, okay, if you're not using this, you're missing out and you're not going to be not be growing and your application is going to be less performant and so on. A lot of people kind of jump ship and actually use a new shiny JavaScript framework. And then what happened was there was a new shiny JavaScript framework, and then that old JavaScript framework got deprecated. They needed to refactor the whole application to the new JavaScript framework. So that happens when you're trying to hunt the shiny new thing, right? So my approach is to pick something that works for you and use that. Don't look for the latest hype that is, you know, using cloud code, using cursor, using Vint Cerf, using various other different tools. You know, there's so much hype over the place. And the reason is that people are selling their products, and that is what they're trying to do. They are all fighting for attention. And we, as consumers, are looking at that attention, and then we are figuring, okay, I'll show you, should I use this or that? And my colleague is using this, and so on. But, you know, pick one thing. I use the cursor a lot, and that is kind of like my go-to. And I use Perplexity for any kind of deep research I'm doing for my articles, any kind of topic. And then I'm using ChatGPT for more kinds of, like a more question-based things. And if I need to search for any kind of documentation or stuff like that, I use ChatGPT for that. And that works for me. Those three things I use, I don't try to go into the latest hype, and just try to change my next ID, and so on. But I stick to these three, and that's my recommendation as well. Use something that is working for you. And I think these days, anything would work, right? But you just need to pick one thing that works for you and focus on the fundamentals, focus on those timeless skills, focus on actually understanding stuff on what's happening when the cursor does this, when you tell the cursor to fix this thing, what's happening. Don't just be lazy and say, Okay, fix this. And then you don't actually see what's actually happening. Learn from it, understand it, and that's it. So shiny new tools are something that we as engineers have kind of struggled with for a long time. And what I like to say is boring technology is a lot better than building the wrong product. So boring technology and a good product are a lot better than shiny new technology and a bad product. So boring technology is what is running a lot of different amazing products these days. So there's no, there's, you know, shiny new tool is not going to build a new product, a great new product by itself.
Glasp: Yeah, totally. But at the same time, some people come to you and, oh, hey, Gemini Deep Research is way better. You know, there's a famous quote, you know, that, you know, people who win are actually the people who adapt to new tools or new things. And, you know, that always distracts my mind.
Gregor: Got it, got it. I think I would say, unless you are really at the cutting edge, like being an ML space, AI engineering space, then, you know, it's not worth it to go into and really, really go into and always try to go into the next new thing, next new thing. If you're building, as a software engineer, you're building a product, like you guys, for example, if you're building a product that you guys want to scale, you know, that hype is not something that is sustainable, right? But if you're really in the cutting edge, like AI, ML world, and you're building models, you're building, like you're actually building AI products that really are using a whole lot of like custom models or any kind of like, you know, you're using really deeply any kind of statistics calculations that uses like a lot of different models and so on, then maybe it's worth to take a look a little bit more into that. But if you're building a product and you want to scale it, I think it's, the hype is not the way to go.
Glasp: Yeah, absolutely, yes. And also I had a question, like, you know, regarding the engineering leadership roles, because, I mean, engineering leaders are kind of someone between, kind of middlemen, you know, or like someone between the CEO kind of executives and, you know, the engineers doing the coding. So how should, because, you know, in your newsletter, you were writing about how to become an engineering leader and leaders, and how should engineering leaders play in this, play the role in this space? And how should they set expectations? How should they communicate with both sides?
Gregor: Yes, this is a good question. And also, I want to just mention, you know, being an engineering leader is not only about a title. It's not only like being a manager or being a middleman. Any engineer can be a leader. And that's also like one of my messages is that, especially in the AI world, human skills, human-related skills are going to be more and more important. And everyone can be a leader, no matter what title, junior engineer, mid-level engineer, senior engineer, they can all be leaders, but they just lead in their own way. So engineering leadership is kind of a mindset, right? How can I make everyone around me better? How can I make the product better? How can I make the business better? How can I provide the most value to the business? And at the same time, how can I help the most people possible in my team, across different teams? And how can I provide the most value to the team as possible and also to our organization? But yeah, to get back to the specific role. So obviously, there are different roles when it comes to engineering leadership. And these are the roles that are more associated with actually not the true individual contribution anymore, but you actually being a multiplier for others. You guys know about staff engineers, principal engineers, and distinguished engineers. Those are all engineering leaders because they are not primarily here to write code, but they are here in the company to make everyone around them better, to create systems, to do stakeholder management, to finish successfully high-stake projects, to lead from start to finish, create a good technical specification, get all the teams on board, on board it, get everyone on board to the same mentality, to the same concepts, understanding how are we going to approach this project, making sure that every team is working together to achieve these goals and so on. So I like to say that if you make 10 people around you better or 20% better, there's so much more value than you getting better by 20%, like for example, in coding. That is the essence of engineering leaders is how can they make people around them better? And obviously, managers are also managers. Then we go to the team leads, engineering managers, the director of engineering, VP of engineering. The same thing is, how can we make the teams better? How can we remove the blockers? How can we make sure that the teams are being as efficient as possible, and that operationally, we are doing great work in general? Being a leader for all of the teams, being kind of a go-to person and also kind of a mentor coach for others and helping others to level up, make sure that they know exactly what business problems are we solving, are there, are currently available, making sure that priorities are known to everyone and so on. And I like to say that we look at engineering leaders to be translators between tech and business because a lot of times, engineers, we like to talk about technologists, right? But business likes to talk about business, right? And we need the people who are going to connect the technical world and the business world. And then you need the people who can speak both languages. It's how can we actually translate this particular project to business value? Business value is either that we're getting more users, we're increasing the revenue, we're increasing the NPS score, we are getting more signups, we are getting more paid users, and so on. Those kinds of things are very important. And I think as time goes on and human-related skills are going to be very, very, very crucial. I think the role of engineering leaders is just going to get more combined with engineers in general, right? And I see this trend a lot is like staff engineers and engineering managers, kind of like being on a similar level, and kind of like one versus the other being expected to take additional responsibilities by the other person. Like, for example, a staff engineer could potentially take the responsibilities of an engineering manager and also manage engineers, for example. And also an engineering manager, being able to take responsibilities of a staff engineer, and also being able to be deep in technical aspects, and so on. And that's how I see the engineering leadership role kind of moving forward is like getting closer to the team level. And I think the roles are going to get just closer together.
Glasp: Yeah, totally makes sense, yeah. And since you know, we are in the startup world and I was always wondering, but do you think, you know, thanks to AI, you know, we could do some things. As engineers, we could do more. And as you mentioned, we need, you know, someone who understands both business and technology. We understand everything, but in that sense, what should we look for in a CTO, let's say? Especially in the early-stage startup. Do we need a CTO or even a CTO? What are your thoughts around CTO? What is a good CTO?
Gregor: It's a really good question. And I'll ask you guys first, how many engineers are currently employed, and how big is the company?
Glasp: We are a team of two. You mean the whole team?
Gregor: Yeah, yeah, yeah, exactly. Team of two, you know, you guys don't need a CTO at the moment. You know, you guys need to figure out what is going to be the product that the market needs and the people want, right? That is your goal at the moment is fast iteration and getting the product out and getting feedback, and getting, doing marketing, sales, and stuff like that. That is your goal at the moment is how can you guys get additional visibility? And obviously, with this podcast and also with the newsletter, you guys are exactly doing that. And that's what you guys should be doing. And you guys need to do fast iteration and see what is working, learning really, really fastly, and adjust based on what users are saying. And after that, after you have that kind of a proven model, proven business model, you see that, okay, after one month, we can expect to achieve this amount of new users. After three months, we can expect to achieve three times the number of new users because we have a proven model that we can use to get new users this way. That's when you see that you are going to need to potentially scale to maybe have like a, get more users on board, get more security, have like better stability of your application, because maybe it's not working. Maybe the uptime is not really optimal, and so on. But until you get to that route, right, you need to iterate as much as possible. But once you get into achieving that product market fit, then it's time for scaling. And then you need more either, you know, either one of you guys like takes more and more responsibility and takes on more of a manager role and being more and more of a manager because at that time, as soon as you're scaling, you need to put your role last being of individual, individual contributor, contributor to how can you actually hire people and build the team around you that is going to scale. That is very important. You can't be coding yourself like two guys and have like a really, really huge amount of users and expect that everything is going to be working. You need people who are going to do customer support. You need people who are going to do sales. They're going to do marketing. You need a good engineering team that you can rely on that you guys can take some time off, and things are not going to get broken. And that's where you need additional help. But until you get to that level, just trying out really fast iteration, and obviously, marketing and sales are really crucial at this time.
Glasp: You mentioned for us, it's not a good time to hire a CDO, but so in general, when is the best time to have a CDO? Like, for example, when an engineering team has 15 members, do you have any like criteria or thresholds?
Gregor: Yeah, I mean, obviously because you guys are technical, because you guys are technical, you don't need to like another person that is going to be also giving more kind of a technical direction, right? You guys can hire me. You guys can hire consultants, but you don't need a full-time CTO right now. That is one of the reasons, right? Because I mean, if you guys were more kind of business people, then obviously the way to go would be to hire a CTO, and that potential CTO would also hire, like maybe two or three engineers that are going to help and build this application. Or maybe like you guys would hire a founding engineer, and that founding engineer would also help with building that application, right? So, because you guys are also technical, right? Then you guys are having an advantage already, and you guys can use any kind of help, any kind of assistance that is very, very good. But the best way to look for a CTO is when you're scaling and when you have a proven business model, when you know, for example, hey, in one month, in three months, this is the amount of users we expect and we need to grow our application. We need to build new features. Maybe we get additional funding. Maybe we do like 100K, maybe 200K, maybe we do 500K, maybe 1 million in funding. That is a good time to hire a CTO, and then that is a good time to actually scale the team and create more robust processes. Until you get that funding, it's all about how much value you can provide, right? The CTO is not going to be that helpful if you don't can't build, if you don't find a product that is going to fit the market, and you can't get the users.
Glasp: I see. Yeah, totally. Makes sense. And regarding the first hire, like since, you know, people use AI tools and what's the best way to figure out, oh, what trades we should look for in the first, first engineer or first funding engineer? Should we test, oh, hey, can you use Casa or can you use this, that, and use AI? What's the best way to hire?
Gregor: It's really good, this is amazing. Question. It's a really good one. And, you know, a lot of people are kind of like thinking the same, same thing as you guys do, right? And one of my recommendations here is to look for a scrappy person who has a track record of building any kind of startups, any kind of products, any kind of projects, and past failures are a good thing. You know, the people that has failed the most in the past have had the most learning experience. So I would look for that, that kind of person, that has been building, that is, that is actually been a builder for some time, that is trying out things, that is, that is moving quickly, and so on. The, the least thing you want to do is to hire a really savvy person from big tech, like for example, a staff engineer or someone that is really, you know, that is really used to more robust processes that is going to be very heavy on, on the, on the budget. And they're not used to fast iteration and a startup environment. So you need to look for a more scrappy, more kind of a fast-paced person that is going to be like, also kind of like self-managed, that is going to look proactively for ideas. That is not just going to wait for, for you guys to provide them with, with specific tasks or, or, or, you know, why you need to do this, but they're going to themselves look for, okay, let's do this, this functionality, because I see this, this particular users are having issues with that particular part, that, that kind of like builder mentality. And also let's, let's use this, let's create this feature because this is going to, this is, let's, let's quickly try this, this quick test. If this feature is going to increase our revenue, it's going to get us more users and stuff like that, those kinds of mentalities. And you only have this kind of people that have like experience with either building products or, or they're, they're, or they're maybe like very excited, very motivated, very, very driven to learn new things and to create stuff that that's what you're looking for, drive motivation for, for learning and improving and stuff like that. And also kind of a good balance between not just, you know, building and, and just, just, just doing and doing that. And don't worry about any kind of security or any kind of code quality or any kind of, you know, the way, any kind of guideless guidelines and style guides and stuff like that. You don't, you don't want that as well, right? You need a kind of also a balanced, balanced person, but I would lean more towards a builder and the person who gets stuff done. That, that'll be a good, good, good candidate for a first, let's say, for a founding engineer.
Glasp: Yeah. And you said, you know, someone who failed, failed a lot in the past, but, and learn something a lot, but, but not people who are failing and not learning and just,
Gregor: They need to learn, they need to learn something. They're just failing all the time. And, and, you know, they don't have any learning experience that they can say, okay, I have learned this from this, from this project, from this product, you know, because there's also like a lot of people are, you know, Indie, Indie, Indie, how is it called? Indie, Indie culture is very popular. Like just building, Indie hacking culture is very popular. Just building, building, building, building, like you need to build 100 startups, right? But the problem is that the people normally just, just they build something and then they lose motivation and they lose discipline to move forward with it and try to go the extra mile. They just built it, and they expect miracles to happen. But as we talked about, the hardest thing about the product is marketing and sales. And you need to put yourself in the community, put yourself out there on social media, on X, on LinkedIn, on, on newsletters, on Substack, you need to write about it. You need to make sure that people get to know your product and get to know what the product is all about. And without doing that, it's going to be really hard for you to know if that product is useful for people. And also one of the reasons is if you're in a community for some time, for example, me being in a dream leadership community, and I'm always learning new stuff, it's a lot easier for me to write a newsletter and get people to, to, to become paid subscribers as well, because I write relevant topics that people are resonating with. It's going to be harder for me to do that if I were outside of that community. So you need to spend time to really understand what the pain points of the product are and not just build something for someone because you heard something there and then, okay, it's just going to get a million users in, in, in short amount of time. It doesn't work like that.
Glasp: Yeah. And that reminded me of a funny tweet I found recently on X. So, a guy is a kind of indie hacker and building a lot of things. And sometimes indie hackers show in the profile, Oh, this product makes 10K per month, or this project makes 5K per month, or something. Then they show one is 30K, one is 20K, then whatever, then that is the main product that makes 1K per month. And some people tweeted, Oh, wait, you are making your main project making only 1K, but you are setting how to build the product. And that is, you know, making more than like a 30K per month or something. But you don't know how to build a product, but how can you teach and make money? Yeah, that's kind of.
Gregor: Yeah, you need credibility. That's also what I say to a lot of people: it's going to be hard for you to sell something without credibility. You need to be, you need to be a good advertiser. If you need to, you need to address hype. If you don't have that credibility in the industry, right? That is, you're playing more to the hype and actually like your marketing skills, but credibility is what is going to build good stuff long-term, right? That is how you can really, really put yourself in the community. Take, take the time to really find out the problems, what people, what people want to actually, what, what problems people have. And you, you put your best foot forward to learn as much as possible about it. And then you actually find the right users that are going to say, yes, this product is exactly solving my problems. And you need to find those couple of people that do that and build for them. And that, that's where you're going to get the value, but it's going to be hard. You know, same thing with engineering leaders. It's hard to push back to company leaders who have like fear of missing out regarding AI. If you don't have good credibility as an engineer and also engineering leader, if you don't have a good track record of successful projects, if you don't have, you know, people and your team respecting you, people around the company respecting you, it's going to be hard for company leaders to also respect your opinion as well.
Glasp: I see. Do you have any tips around, like where's the best place to find a fast engineer or funding member, funding engineer? Maybe LinkedIn or Indeed are not a good place to find, you know, those funding engineers, right? Do you have any tips around it?
Gregor: Yeah. Are you guys looking on-site or remote?
Glasp: I think site. But you know, yeah, we are open eyes, you know, but not actually looking for it. Yeah. Got it.
Gregor: Yeah, of course. Of course. There's a difference between on-site and remote. You know, a lot of, a lot of companies, especially in San Francisco, I know that they are looking also into offshore opportunities, because obviously, you know, a founding engineer in San Francisco is a lot more expensive than going offshore. And people like in Poland are very, very good, Poland, and also obviously in other countries as well. I know people in the Philippines, I know, obviously, people in India as well. And that works as well. But you know, as a founding engineer, if you get just one person, then probably I would recommend being on-site with the company, with the team. It's hard to have fast iteration if you have a person who is remote, that is especially in a new country with a different culture, that has a different time zone, you need to move faster. I would look to get a person and give them a good, a decent amount of equity and, you know, a bit of kind of like, I would also kind of, more equity and kind of less, like less, less monetary benefits at the beginning, because obviously the, the liquidity is a problem as you start as a startup and you're not profitable yet, maybe you're not getting a lot of users. So you need to, you need to be kind of like pretty, pretty varied with the spending, right? But that'll be my go-to is kind of like looking for an on-site person. Obviously, LinkedIn is one thing, but a network is the biggest thing. Network is what I found out to be the best way to go, you know, people recommending me to others. That is, that is how I found the best people, because I always, like, if I'm, if I'm part of a certain team, I always ask my team, hey, do you know someone that, that, that will be a great fit for us? And then I would get two or three recommendations, and one of them is going to be great for the team. So networking is, is really, really great. Any kind of events, any kind of local meetups, that's really, really a big deal. LinkedIn is hard because you get a lot of, a lot of AI-generated resumes and AI-generated submissions. You guys, you guys know, there's also a lot of different companies and products out there that are automatically submitting for different goals. And also, the problem is then some people try to do deep fakes, with a kind of like using AI to actually pass the technical interviews. So it's, it's, it's a lot of time wasters for that. So I think on-site is the way to go for a first funding engineer. LinkedIn is, is harder. Networking is the way to go. Asking people, hey, someone that you recommend to do that, someone you know, people that you trust, that will be the way to go. I think San Francisco is a lot smaller than than the, the kind of, kind of like, is a lot smaller, smaller than we think, right? So everyone kind of like knows almost everyone, right? So that, that, that would be my advice.
Glasp: Yeah. And at the same time, how, how do you know as a, as a startup and also as an engineering leaders and manager, how, when to know, oh, we should let this engineer go, you know, what's the tiebreaker, what kind of thoughts, you know, things we should, should be looking in or looking for?
Gregor: Yeah, it's, it's a really good question. And I, for example, work with a lot of contractors as well. As I'm working with my newsletter and also with a lot of other stuff, it's really important. And then also what I learned throughout my experience, both as an engineer and as an engineering leader, is that the problem is when what you tolerate becomes a new standard. And if you have other people, other high performers in the team, and you have one low performer in the team, the other high performers are going to automatically be either decreasing their performance, or they're going to be feeling left out, or they're going to be feeling that something is not fair to them, because they're putting so much effort, and another person is not putting that that much weight. And people see that, and they're going to get less motivated. That is also the a lot of times that is also the root causes of people leaving the company is that we tolerate people who are not doing a good enough job. So what you need to do is you need to spot that into into spot that as soon as possible. And you need you need to give feedback, you need to give feedback, and you need to give you need to set expectations to be in a good way. And obviously, the first thing that I for example, if a new engineer starts with one of my teams, I always set my expectations to be very clear. Okay, this is what the expectation is of the first week, second week, third week, first month, third quarter, and so on. And also, these are our core values that we believe in inside the company. For example, helping others is a lot more important than your individual contribution. Team results are a lot more important than your individual contribution. Providing value, anyone can have a say in the direction. It's not about us, you know, you versus the other person. It's about us working together to find the best solution, and stuff like that. And if I see that someone is not aligned with our core values, and what we want the vision to be for our teams, I'll be giving that feedback immediately. And if I see that the second time, I'll be giving them a reminder. And then the next time I'll be giving them a lot more, a lot more different reminders. And if I see that, again, probably it's a good, good situation that that person would not be a fit for my team, and might be changing the teams, or we will need to, unfortunately, say goodbye to that person. Because the more people you have inside the team, the more you tolerate either bad behavior or behavior that is a lot worse than low performance, right? If someone is really being disrespectful to other people inside a team, that is something you need to give feedback on immediately. And there's zero tolerance for any kind of bad behavior. So that's kind of like my approach. In bigger companies, you guys probably know a performance improvement plan, like, you know, in big tech companies, it's called PIP. And they have, like, a lot of times, there's a process in disguise that they actually want to let go of that person. But in kind of like 80% of the time, I believe that is kind of like my estimation. But yeah, in small startups, you mostly give feedback. And if you don't see improvements, you need to look for another person. It's, it's just the way it is.
Glasp: Then let's say you decided to let the engineer go. And what, how should we, how should managers or leaders do, like, hey, just let them go right away? Or do you have some tips?
Gregor: Yeah, yeah, definitely, need to be professional as much as possible. You know, you can't put any subjectivity or any kind of personal feelings. You need to be straight to the point. And you need to be very clear. And, you know, and also direct ways the best to go. You know, you can't just, you can't just talk about different stuff and joke around and then, and then you throw them with, okay, hey, we don't need you anymore. No, no, you set up a call. Normally, in normal companies, there's also an HR representative present. And you bring that person to a call, and then you're being very professional with it. And we appreciate the value and the work that you did. But unfortunately, we decided to move different different ways, something like that, very professional. That is the way to go. And that works the best. You should not be, you know, any kind of emotions, any kind of stuff that is just making things worse.
Glasp: I see. Yeah. Thank you. Thank you for the tips and advice. Yeah. Sorry, switching the topic back to your newsletter. And I find many interesting insights and articles in your newsletter. And I was, Kay and I were talking, hey, we were really wondering how and where you find this interesting information or ideas? And also, where do you keep the ideas?
Gregor: Yes. It's a really good question. And, you know, I have a, I use Notion a lot and I use Notion basically for, for everyday notes and it's, I can't live without it anymore. And yeah, it's really a big deal for me because everything, all of my ideas and everything that, that I, everything that, that comes to my mind, I store in Notion in my system. So what, what I, what I do have is for every particular subject, every particular thing, I have like a special page, for example, for articles. I have more than 1000 ideas for articles on my Notion page. And every time I see something, maybe I read some, a certain article, maybe I read a certain LinkedIn post, maybe I read a certain LinkedIn comment. Maybe I heard about a certain issue from one of my coaching clients. Maybe, maybe one of my people, from the course that I teach, I make sure to always write down the idea inside this, this page. And it's, it's never going to run out of ideas. And then as soon as you have that, you have so much material that you can you can write about. And then it all comes down, it all comes down to selection. How do you select articles? And a lot of times, you know, I, a lot of times, I post something on either LinkedIn, on X, or any kind of other platform. And I see what is, what is going to be the engagement, and what is going to be the feedback from other people that are reading that LinkedIn post, for example. And if I see that a lot of people are interested in that particular topic, okay, that is kind of like a good sign for me that, okay, there's also a lot of readers that would be interested in that article, right? And the same thing is, for example, for Reddit, I post on Reddit all of my articles. And like, like we talked about that 51% of engineering leaders are perceiving AI negatively. I posted that on Reddit, and I saw a lot of engagement from people, and they resonated a lot with that article. So what I did was on, on, on, on the recent article, I created more kind of a guidance for, for engineering leaders on how to manage expectations, because I saw that a lot of people were interested into actually finding out the root cause of why so many people are feeling negative way. And then I wanted to provide more kinds of insights to people on how they can manage this and meet expectations the right way. So those, those, that, that is kind of the mind process. And I, I'm very, I'm talking with a lot of people, with a lot of engineers, with a lot of engineering leaders, and we're always asking questions, and what, what kind of problems do you see? What kind of issues do you see? What kind of issues do you have at the moment, and stuff like that, that, that, that always helps me. And, you know, it, it helps because I love what I'm doing, right? I always want to get better as an engineering leader and stuff like that. So it's automatically like I'm involved in, in really understanding the people and getting to know their problems. And then also like me, providing feedback and providing the articles that people, people need, that people are looking for.
Glasp: I see, I see. And I saw your GitHub led me, like how to be, resources for, you know, how to be a good engineer. And I see a lot of, you know, lists of books and articles and people who you support, you should follow, or something like that. And that's really resourceful and really useful to me. And also I think so many engineers, but at the same time, I wonder since you're, you're an engineer developer. So have you thought about building kind of AI chatbot using like a lab, like, you know, like a retriever augmented next generation and thought about building your AI chatbot that answers to any engineering related questions and also share, recommend people, recommend books, recommend content so that people can easily, you know, extract your knowledge, access, access to your knowledge and information you think is important and so on.
Gregor: Yes, definitely. It's, I had this in mind for, for some time, you know, kind of connect that chatbot with any kind of either LinkedIn posts, X posts, YouTube or YouTube videos, all of the articles, everything that I write about, all of my notes as well, that I have a notion that that would be amazing, right. That I can, if I were to have that one day, that's something I have in mind. I haven't yet utilized it or created it. But yeah, I think, I think the future is going to be more that way. How can you actually create articles in a way that others are going to be easily find them with either chatbots or find them via ChatGPT or any kind of other models. That is, that is kind of going to be the future, right? How can you create, you know, SEO is kind of like less popular because a lot of people are using, you know, chat GPT and Claude and, and whatever else, and, you know, building for being easily understandable by LLMs and writing that is going to be easily understandable for LLMs, that is probably going to be the new, the new SEO, right? So yeah, definitely. I have this in mind and that, that'll be, that'll be a good thing. And I think a big value add, if you can connect all of my af thoughts, into that AI, that'll, that'll provide answers to people.
Glasp: Yeah, I would look forward to using it, for sure. And I think you have many subscribers for your newsletter, right? And you also have many, you know, paid subscribers as well, I guess. And so, when did you start a paid newsletter, and do you have any tips or thoughts around it? So like, you know, or I should have started earlier or later?
Gregor: Yes. Yes. I think it's about close to two years since I started the paid subscription. I think it's more like a year and a half, something like that. And I think, yeah, I should have started already sooner. I started with around like 8000 subscribers. And I did it like really, really soft in a soft way. Because you know, that's also the problem that I had in the beginning, I don't want to feel like I'm selling something, I don't want to be like a sleazy salesman. And that is what I see problem with a lot of engineers is they don't want to market, they don't like to sell things. And they feel that they feel that everyone is going to look at them differently if they're going to be selling stuff to others. But the learning here for me is that I should be, you know, giving this paid subscription sooner. And that will be a lot better if I do it sooner. So I started very, very simple, just like I started with an archive of articles that are more than one month old after being published. And that became kind of like paid art articles. And yeah, after that, it slowly started growing slowly started growing and I was growing my paid subscriber base. Then I decided then this work that I decided to also create a kind of template for people that are going to be helpful for them. I have like around 20 different templates and guide guides and templates that are going to be great for engineers and also engineers to be able to do good work in their in their day to day roles and also grow in their careers. And then also I started to do infographics that have also been recently added to the benefits for paid subscribers. And that started growing reasonably. But the most significant growth of the paid subscribers I saw was when I stopped doing a full-time role. So that was a time, it was that was about about nine months ago, when one of the startups that I was a part of, actually, we decided to not continue with it. So then I was actually that I was actually at the crossroads, either should I look for a new full-time role, or should I focus on more fractional time, more coaching and mentoring, and also focusing a lot more on my newsletter. That's where that's when I decided to start with the paid newsletter every Wednesday. So before that, I had a kind of like free newsletter every Sunday. And then after one month, it became a paid newsletter because of the archive, right? And I saw the biggest growth was when I started that paid newsletter every Wednesday. And I think it's been around like, nine months, nine months ago, I started that. And I'm close to tripling my paid subscriber base. And also my revenue from the newsletter after that. So that that's been, that's been a big growing factor for me. And yeah, I'm really happy that people resonate with that.
Glasp: Yeah, we are happy for you to answer. Yeah. Thanks. Yeah. Good, good tips. Yeah. Thanks. Also kind of different topic. And do you have any like AI favorite AI, you know, code generator tools? There are like Copilot, Gemini, so code, code, and you know, which one is your favorite? And so, which one will last for five years, 10 years? Yeah. Do you have any opinion?
Gregor: Yeah, it's a good question. And, you know, I tried, obviously, I used GitHub Copilot was kind of like the first one available out there, and kind of like a really easy integration with VS Code. I've been a VS Code user for quite a while. And I've been kind of like really having a great time with VS Code. I also had my own, my kind of like ID colors and everything, and also fonts, and so on. And so I started with that. And it was a good, good thing for some time, it improved over time, you know, the first iteration was really, really kind of like a funny, funny thing, because a lot of the generated code was something completely different than I would expect it. But it was fun. It was kind of like a new experience, a new experience for me, it made coding a lot kind of like, you know, what, what is called GitHub Copilot going to output, kind of like that. But over time, I saw, you know, especially right now, Cursor is being my go-to, my go-to ID for any kind of coding, any kind of things I'm doing with any kind of projects. And, you know, it's, it's, it's really good. It's like, I like the, I like the, the, the agent mode as well, it's, it's great. You can get, you can get very, you can get very, you can get very lazy with it, if you, if you kind of like just rely on it too much. But it's kind of a downside with it. But yeah, it helps a lot. It helps a lot to be more productive. If you can use it, especially my go-to tip is if you use it with your voice as well. I use a whisper flow is kind of like to kind of like, give comments to the cursor automatically so that I don't need to write about it. So that automatically puts that text in the text box. And that's what generates automatically, what I'm looking for, right, and I can move fast with it. So, cursor, and then obviously perplexity is for any kind of deep research. And Chai GPT is mostly for any kind of problems, more detailed problems like with maybe, for example, if, if I can figure out something inside cursor, I will go with Chai GPT and I will paste that, that problem in there and I will look for additional approaches with it or maybe like I need a certain documentation of a certain API of a certain, you know, if I'm looking for how to do this in React, or maybe how to do that in Python, I would look for Chai GPT for that. But yeah, for about five years, I think it's really hard to say which tools are going to be here for five years, because it's a battle between different companies and, and it's, you know, it's a battle for who is going to take the most kind of like, revenue across different businesses. And it's all about, it's all about politics. It's not about the best product, right? Obviously, who is going to use it is important. But, you know, who can spend the most money is probably going to be here in five years as well. So, yeah, it's hard to say at the moment, but at the moment, I like Cursor a lot. And I like what you're doing. But they're also like a small company. So there are a lot of bigger players down the road. And I'm, I'm, I'm very, I'm not sure about how things are going to go one year, two years, three years down the road for them.
Glasp: Yeah, sure. And I got an interesting advice from other founder friends that, you know, you should build something that the first growing companies are spending the most on. So, meaning, if you build something that the first growing company is spending on, and so that you can be chosen at some point. And I think that's an interesting thing, but yeah.
Gregor: Yeah. It's definitely a good way to look at it.
Glasp: Yeah. So, yeah. And so, about the advice, do you have any advice for aspiring engineers or aspiring engineering leaders, or managers? And also, you know, someone who hates to use AI tools.
Gregor: I think, yeah, you know, it's, they're not going to go anywhere. You need to, you need to embrace them, and you need to, but also don't, don't fall into the hype as well. Human related skills are going to be, get more and more important, you know, as things, as tools are getting better and better, it's going to be very, very important for all the engineers to become good communicators, to become also to be able to be very clearly articulating things on what, what needs to be done, how it needs to be done as well, getting more closer to the product and the business. That is, is, my key advice for engineers and also engineering leaders to understand the business side, understand the product side, become better leaders, become better communicators, become good at writing, and also become good problem solvers in general, that is, obviously utilizing different AI tools. Don't fall into trying to need to understand that specific framework, like really, really, that, and just focusing on that. Because after some time, maybe that framework or that technology might not even be used, you know, because things are progressing so, so fast. Like, for example, people used jQuery like, or maybe Angular, Angular 1, they use it a lot. And, you know, right now, there aren't a lot of people using Angular 1 anymore. People are using Angular 20 or Angular 21 or whatever the latest version there is, but it's totally different than Angular 1, right? So people who spend so much time actually understanding it have lost the time that they actually can spend on many other things, on the timeless skills. So being good at being good at problem solving is going to be the biggest, the biggest thing moving forward, being resourceful, having a good network that you can ask people, you can, you mentioned founder friends, you need to nurture that you need to build that you need to have people that you can ask questions and they will, they will provide you with their expert opinion. For example, you need a person who is good in cloud, that is good in systems, that is good in, that is good in Kubernetes, that is good in Docker, that is good in that particular technology. You can ask them questions, and you don't just know that they will provide you with a good, good opinion on that, right? That is going to be worth more and more. So yeah, but also, you know, utilizing tools, whatever is helpful to you is really good, really, really important to be part of that problem-solving toolkit that you have.
Glasp: Makes sense. And also if someone is listening to it, you know, like writing something like a blog and so on, and as you mentioned earlier, they should trust in the process and keep doing it, and be patient, and also because they believe in the compound effect, right, eventually. And the biggest thing, the biggest thing is just starting that, that is the, that is biggest hurdle that a lot of people have is just putting yourself out there.
Gregor: And you know, still, to be honest with you guys, I still myself feel sometimes okay, if I publish that, how are others going to think about it? Is it good enough? Is it good enough for others to read it? And that is just our perfectionist mentality telling us that that's, but at the end of the day, it's really good enough. It's good enough to publish it. And you can't really know until you actually publish and get feedback from people. You can't know if that is good enough. But a lot of people don't go over that hurdle. A lot of people say that, okay, I would like to write about it. But I'm, I'm afraid what my friends are going to think, what my colleagues, what the manager is going to think about it. But that is all in our minds. Like we do, people have their own problems. And they might not even see what we will be posting what we will be posting on LinkedIn, on X, on our newsletter, and so on. And we put so many, so much time and our mental energy into thinking of what are others going to think about what we are doing, just need to go through that, through that hurdle and just do it, just publish this, publish this LinkedIn post, publish this article, it's going to get a lot easier over time, but it's never going to get completely away. I think, I think it's always going to be something in our minds. But you just need to get over it. You just learn to become better at it.
Glasp: Yeah, totally. And I forgot the name of the person who said this, or the concept of this, like the name of this concept, but you know, if you publish something, then if you are wrong, maybe someone will, you know, correct you eventually. So, yes, you need to ship something publicly so that someone will correct you if you're wrong. And if you're not wrong, and that's okay.
Gregor: Yeah, exactly. You learn, learn that way. You learn that way. Everyone learns, the people, the people who are reading, and also you learn because someone provided a different opinion, and so on. I greatly increased my perspective on my knowledge, because of writing online and meeting new people. And so many opportunities just came, came because of only good things happen because I was putting myself out there, and too many people are being skeptical about it and afraid of just publishing. But at the end of the day, just a lot of good things happen if you're, if you're putting yourself out there.
Glasp: Totally. Yeah. Thank you. And then last question. So as we talked about before the talk, but, you know, since Glasp is a platform where people share what they're reading, learning as their digital legacy, I want to ask you this question. So what legacy or impact do you want to leave behind for future generations?
Gregor: Yeah, it's a really good question. And you know, if you had asked me this three years ago, it would be different, or maybe like four years ago, five years ago. And I think, you know, it's really hard for me to say like a really deep thought, really, something that would be, you know, very inspiring. But, you know, my number one goal is to help as many people as to become great engineering leaders. That is what I am focusing on the most these days. And this is what I like to do. This is what drives me every day to get up and provide interesting insights to everyone who is reading, and also everyone who is learning to be a better engineer, a better engineering leader, on how to thrive and grow in their careers. Every time I receive a message from a person that either they have improved themselves, they got a promotion, they got a new role, they've been, they've done better in their position, because reading my article, or maybe something I said, on one of the podcasts, or maybe on one of the YouTube videos, that that always makes my day. And that is a personal satisfaction that I really enjoy. And I don't see myself, you know, stopping that, me getting better as a leader and also sharing, sharing that with everyone else that that is, that is something that I see myself doing in for long term. And I hope to help as many people as possible along the way.
Glasp: Yeah, very beautiful. And yeah, thank you. And thank you so much for all the you know, like, like, you know, and lessons and advice. Share with us. Thank you.
Gregor: Of course, it was really great. Great speaking with you guys, and really great questions. Thank you.
