How to Thrive as an Engineer in a World Obsessed with AI | Gregor Ojstersek
Kazuki Nakayashiki
Jun 27, 2025 9:22 PM
Summary
-
Introduction to Gregor Ojstersek (00:08-00:33): Gregor Ojstersek is an experienced engineering leader and founder of the rapidly growing Engineering Leadership Newsletter, boasting over 150,000 subscribers. He currently serves as a fractional CTO and tech advisor for startups, guiding them in building high-performing engineering teams.
-
Inspiration Behind the Newsletter (01:37-02:26): Gregor started his newsletter to help others outside his workplace improve in engineering roles after realizing the limitations in growth within the engineering industry. He began sharing insights on LinkedIn, slowly gaining traction over six months.
-
Importance of Platform Choose and Consistency (03:01-10:13): Initially building his own blogging platform, Gregor later switched to Substack for better visibility and subscriber management. He emphasizes the significance of consistency in content creation and the necessity of a supportive community for growth.
-
Insights on AI and Engineering Leadership Trends (13:38-19:49): A survey revealed that 51% of engineering leaders perceive AI negatively due to rising expectations and a fear of obsolescence. Gregor stresses the need for leaders to manage expectations and focus on business needs rather than solely adopting new technologies.
-
Advice for Entry-Level Engineers (20:50-24:27): Gregor advises aspiring engineers to take proactive ownership of their careers, actively seeking opportunities, gaining experience, and creating personal projects as entry-level roles are becoming increasingly competitive.
-
Leadership Philosophy (30:07-34:10): Gregor emphasizes that engineering leadership is about mindset rather than title. Effective leaders should aim to enhance the capabilities of their teams, manage expectations, and serve as connectors between technical and business aspects.
-
Long-term Vision and Legacy (1:13:14-1:14:38): Gregor's legacy goal is to empower future engineering leaders, providing insights that help them thrive in their careers. He finds personal fulfillment in receiving feedback from those whose careers have benefitted from his teachings.
Transcript
Hi everyone. Welcome back to another episode of Glasp Talk. Today, we are excited to have Gregor Ojstersek with us. 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 a 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. Thank you for joining Gregor today. Thank you. Thank you for having me and for such a kind introduction. Thank you. So, yeah, we are huge fans of your content and you and so on. And you have a 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 like almost three years, right? Yes, definitely. You know, it's always like me, personally, I always like to have some challenges and some goals to 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'll eventually get to 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, first six weeks were really, 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. And did you choose Substack at the beginning, since the beginning? Or did you choose other like a newsletter platforms? Yeah, it's a really good question. Because, you know, we as engineers, we like to we like
to build our own platforms, right? So that's, that's how I also started, right? I built my own blog, blogging platform, it was built with React and Gatsby. And, you know, I thought that that is the play that that is the way to go, right? And that that was also like one of the mistakes that that's kind of like, brought me to being invisible first, first six months is because I was I was doing more coding than actually writing, right? So that
happens, right? And, yeah, But you were writing, you were writing, but you were writing code, right? Exactly. I was more focusing on creating the best, the best platform instead of like creating the best articles, right? So and also, like, I always like to go back to see like my old articles and see like, how I progressed over 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 kind of like a email platform. So it 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 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, 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 to, to, to anyone to perceive them to be 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's that is actually proven. And you focus on writing, don't focus on developing or, or other side quests, focus on actually doing what what is what is the important stuff is to focus on quality, the 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, try to try to write, write something, something that people
might get value off and good things are going to happen. Yeah, that totally makes sense. Yeah. And but you have now like around, you know, 150,000 subscribers. And how did, how did the growth look like? Did you post something went viral so that you got, you gained so many subscribers? Or is it more like a steady, you know, growth over time? It's a it's a good question. And yeah, for 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 to do everything and focused on on my on my work. And I didn't do any social media, I didn't do any, you know, I didn't do any promoting any, 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 that are on the same path, then 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 we were doing collaborations, we started to do, you know, also podcasts, appearing, 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 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, with many other people that are on the similar path than I am, that that's where I started to see a bigger progression, and a steep, steep growth curve.
Because yeah, it's when when you're working with together with more people, you will learn together faster and more and more visibility to everyone. We are all growing. We are all progressing. It's that that's the best way to grow. Yeah, totally. Yeah, good community is important. Also, collaboration is important. But just like, you know, many people trying to start a new thing, but so they will quit, you know, before
half a year before six months. So but you did it. Yeah, you completed like you keep doing it. But what is the motivation or why you couldn't, you know, continue over six months? Yeah, you know, it's hard, especially when you start and you don't have like any specific, you know, visibility of any social media, it's, it's tough. And you need to get over the hurdle. You need to 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 you need to stick to it over time. And people need to see that that consistency and that that that builds over time. So even if it doesn't see the results immediately over time, you know, if you're going to be writing for two years consistently every week, there's going to be 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, long term, long period of time? Same is right now as well. How can I consistently put out two weekly articles that I can do this 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 just publishing, just just actually posting out and getting your thoughts out
there. And then you see what what is working, what is not working, that that is crucial. Without this without this iteration, you you can't guess what actually is going to resonate with people. But as soon as you see something like certain articles, certain certain topic, certain thing that is that is 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 same with writing, you know, progressing, growing as a newsletter, growing as a growing as a newsletter author, as a writer, what how to write that is going to be very easy for people to read, and so on. And the only way to do it is to be to be
consistent and have good systems in place. And don't don't be just, you know, looking for that quiz. quick wins and hoping that you're going to get like a bunch of subscribers in short amount of time. It's it really doesn't happen that way. 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. Exactly. Yeah. But you know, you said, you know, you do like a tiny experiments and based on the results and you okay, maybe I will, my audience is resonating with these containers. So then you write about the post. But in that sense, like how do you balance, you know, you think you want to write anything your audience expect? Do you have some balance? Yes, definitely. That was also like one of my motivations for starting the newsletter
is because me basically growing from engineer to the manager, basically becoming first time team lead. I had I did, I did a lot of mistakes. And because by back in the day, when I grew to become the team lead, there wasn't like 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 to be a great engineer is going to also made me to be 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, what one of the things I want to solve with with my newsletter is how can I help people that 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 to that that's something that gives me like 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 at least a couple of people to avoid some of the mistakes that that is that is always energizes 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 how other people are thinking about this topic. And also myself, we want to do like a research on a really detailed particular topic, 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, you understand it. And the best way to learn is to actually either write about it, or teach it to someone. Yeah, learning by doing learning by teaching. And that's the best strategy, I think. Yeah, exactly. 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 lead, you know, leaders believe AI is negatively impacting on the industry. And, and I was, that was really interesting article. 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? Yes. So this was the recent trend that I discovered by checking through a bunch of different data
that was recently conducted with 617 engineering leaders responding to a survey. And 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
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, code base, we see Andy Jassy telling that they're going to in a couple of years, they see Amazon to be a lot less people there and stuff like that. And those, those kind 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 they're actually doing and creating stuff. So that that is an interesting pattern, right is, and I think it's going to unless something something really happens is 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 I probably a lot of the talk is about, okay, how can we utilize the AI the best way? Obviously, there are new startups going on every 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 from the business perspective, what is the best way to go for the business? Don't don't just try to go and and include a shiny new AI technology. But think about actually what is 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 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 kind of things, things happen because of enforcing factors. And, you know, people feeling feeling
that they're missing out. 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 do something seems working in five minutes, 10 minutes. So that I'll 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 single line of code. And so they
get engineering, you know, engineering part, like engineers to 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 takes exactly three days, five days, five days. And so it becomes a kind of weird pressure. And so, yeah, that's kind of I see the same. Yeah. So and, and I think it sometimes like, brings issue to like, how to say, like, a lot of pressure
and it motivates teams and engineers. So I think, yeah, I think business leaders 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 understand. We can't, we can't just, you know, build something with wipe 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 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 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 creates 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 get 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 that how important it is that you have a good understanding of engineering concepts and, you know, systems and how to do scaling, how to actually 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 is going to be for engineers to have a deep, deep understanding of particular topics, especially like new, new people,
new engineers coming to the industry. I, I see this pattern a lot where a lot of like answer level engineers have more shallow understanding of engineering topics, do it to like a lot of different tools, AI tools available. And, you know, it makes a lot, a lot of the work easier, but it also makes you a little bit more lazier because you don't go the extra mile to go, to go a level deeper. And the people that are going to go level deeper are
going to have much better time in the industry. But I think people that are just going to have that shallow understanding of. topics are going to have a worse, worse time in the, in the, in the industry. I see. Yeah, totally understand. But so it's thanks to AI. So AI reflects human engineering, then, you know, if new grads or new engineers, junior level of engineers, you know, enter the industry and want to experience engineering in
deep, but so AI reflects it. So meaning so new engineers, junior level engineers will have less opportunity to experience it, experience it. So, yeah, how should you know, they do? 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 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
from signal fire, they have noted that there is like around 27% decrease of entry level engineers looking for, for example, in big tech and also startups, they're there, 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 only way to go
is to take ownership, be proactive, and look for look for experience. Look for look for things to learn yourself. Don't wait to work coming 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 you need to show actively that you can bring value to the table. You need to showcase what you can actually, you know, what what the future employer can can expect from you what kind of things you know, and
also, what kind of tangible results you also have. So build any kind of side projects is very, very crucial. Any kind of products is even more important. If you can, if you can scale a product, if you have like sales and marketing, as well, together, that that's, that's only going for you to expand, expand your knowledge base. And because one of the hardest things to do with with building a product is to actually advertising 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 you need to find opportunities and so on. Also, like, for example, freelance work is, is really, really, it's been crucial in my career, I wouldn't be growing from engineer all the way to CTO if I wouldn't be doing freelance work while also doing full time work as well. So I did like different websites, different applications, mobile applications,
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 build 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 the my same mentality, you know,
family and friends always needs a certain website needs a certain application. You know, you have you have you have ideas that you see around the world, maybe maybe your, your, your, your, your colleagues have a certain certain challenge, maybe your friends has a certain challenge, you can solve that with with with with coding with programming, and so on. And while you do that, you also learn the the concepts of programming concepts, you go into
deep into particular topics, and so on. That that is my recommendation, be proactive, learn, don't wait for opportunities come to you, you need to, you need to increase your luck surface and, and look for opportunities yourself. Yeah, totally. And but to me, it's a little bit tricky part, because as an engineer, I write code. At the same time, I every day I see on Twitter, LinkedIn, or sorry, x or LinkedIn that day, hey, oh, there's a new models
comes out a new yes, by the coding tools, you know, comes out. So, oh, oh, should I? Okay, let's say I'm using Cursor. Oh, I need to, for some people, I was calling on VS code, but I need to switch to straight to Cursor or now Windsor. But oh, they got acquired. So and, you know, Claude Code, or, you know, Gemini command line, yes, launched yesterday, and what should I use? And you know, but then, oh, I let them write code so that oh, I experienced
coding. So but if I don't use AI tools, and I will be behind. So it's kind of, you know, balancing for more fear of missing out and also understanding tools. And but to me, I realized the best way is, first, I tried to write code or 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 XYZ or building this code or something so that I can learn from AI.
Also using AI tools. And yeah, but what's your take? What advice? Yeah, it's, it's, it's crazy right now for for new people starting, I think, you know, in my in my situation, when I was growing as an engineer, we had, 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 going to be not be growing and your application is going to be less performant, and so on. So a lot of a lot of people kind of like 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 that's that old JavaScript framework got deprecated. They needed they needed to they needed to refactor the whole application to that new
JavaScript framework. So that happens when you're you're trying to hunt the shiny new thing, right? So my my approach is to pick something that works for you. And use that don't don't look for for the latest hype that is, you know, you know, using using Claude Code using Cursor using Windsurf, using various other different tools, you know, there's so many hype over the place. And the reason is that people are selling their products. And that is, that is what
they're trying to do. They're all fighting for attention. And we as consumers, we are, we are looking at that attention. And then we are figuring, okay, I'll show you should use this or that. And my colleague is using this and so on. But you know, pick one thing I use Cursor a lot. And that is kind of like my go to. And I use perplexity for any kind of researching deep researching, I'm doing for my articles, any kind of topics,
and then I'm using ChatGPT for more kind 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 that works for me, though, those three things I use, I don't try to go into latest hype and just try to change my next ID and so on. But I stick to this tree. And that's my recommendation as well use something that is that that is working for you. And I think these days
anything would would work right. But you just want you to 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 what's actually happening when when Cursor does this, when you tell Cursor to fix this thing, what's happening, don't just don't just be lazy and just say, okay, fix this. And then you don't actually see what what's actually happening, learn, learn from it,
understand it. And that's it. So shiny new tools is, is something that we as engineers are kind of struggling for a long time. And it's never, you know, what I like to say is boring technology is a lot better than building a wrong product. So boring technology and a good product is a lot better than shiny new technology and the bad product. So, you know, boring technology is what what is like, 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. Yeah. But 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 course, you know, that you know, people win is actually the people adapt to new tools or new things. And, you know, always distract my mind. 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 like 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 that hype is not something that is sustainable, right. But if you're 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 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.
Yeah, totally. 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 coding. So how should engineers because, you know, on your newsletter, you're writing about how to become an engineering leadership 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? Yes, this is a 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? Is 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 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, 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.
And 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 team leads, engineering managers, 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 efficient as possible, that operationally we are doing great work in general?
You know, 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, you know, I like to say that we look as engineering leaders to be translators between tech and business,
because a lot of times, you know, engineers, you know, we like to talk about technologists, right? But business likes to talk about business, right? And we need people that are going to connect the technical world and the business world. And then you need the people that can speak both languages. It's how can we actually translate this particular project to business value? Business value is either 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, you know, 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 together 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, staff engineer could potentially take responsibilities of an engineering manager and also manage engineers, for example. And also 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 like the engineering leadership role kind of moving forward is like getting more closer to the team level. And I think the roles are going to get just more closer together. 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 an engineer, we could do more.
And as you mentioned, but we need, you know, someone who understands both business and technology. Who understands everything. But in that sense, what should we look for in CTO, let's say, especially in early stage startup? Do we need a CTO or even CTO? What's your thoughts around CTO? What is a good CTO? It's a really good question. And I'll ask you guys first, what, how many engineers currently, how big is the company?
We are a team of two. You mean the whole team? Oh 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 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, 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 like a proven model, proven business model, that 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 amount of new users because we have a proven model that we can 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 onboarded, 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, 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 less being of individual 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 that are going to do customer support. You need people that 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 maybe 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 sales is really, really crucial at this time. I see. 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? For example, when engineering team have like 15 members, for example, do you have any criteria or thresholds? Yeah. Yeah. I mean, obviously because you guys are technical, right? Because you guys are technical, you don't need another person that is going to be also giving more kind of a technical direction, right? You guys can hire consultants, but you guys don't need like a full-time CTO right now.
That is one of the reasons, right? Because I mean, if you guys would be more kind of a 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, but because you guys are also technical, right? Then you guys are having 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 of funding. That is a good time to hire a CTO. And then that is a good time to actually scale the team and create a 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 much helpful is if you don't find a product
that is going to fit the market and you can't actually get the users. 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 Cursor or can you use this, that and use AI? Yes. What's the best way to hire?
It's a really good, this is an amazing question. It's a really good one. And, you know, a lot of people are kind of like thinking the same thing as you guys do, right? And the one of my recommendations here is to look for a person that is scrappy, that has like a track record of building any kind of startups, any kind of products, any kind of projects. And past failures are actually a good thing, you know. The people that has failed the most in the past
have the most learning experience. So I would look for that kind of person that has actually been building, that has actually been a builder for some time, that is trying out things, that is moving quickly, and so on. The least thing you wanna 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 the budget. And they're not used to fast iteration in 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 you guys to provide them with specific tasks, or, you know, why you need to do this, but they're going to themselves look for,
okay, let's do this functionality, because I see this particular users are having issues with that particular part. That kind of like builder mentality. And also let's use this, let's create this feature because this is going to, this is, let's quickly try this, this quick test, if maybe this feature is going to increase our revenue, is going to get us more users and stuff like that. Those kind of mentalities.
And you only have this kind of people that have like experience with either building products, or they're maybe like very excited, very motivated, very driven to learn new things and to create stuff, that's what you're looking for. Drive motivation for learning and improving and stuff like that. And also kind of a good balance between not just, you know, building and just 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 guidelines and style guides and stuff like that. You don't want that as well, right? You need kind of also a balanced person, but I would lean more towards a builder and the person that gets stuff done, that will be a good candidate for a first, let's say, for founding engineer. Yeah. And you said, you know, someone who failed a lot in the past,
and learned something a lot, right? But not people who are failing and not learning, and just- Yeah. They need to learn. They need to learn something. They are just failing pretty much all the time. And, you know, they don't have any learning experience that they can say, okay, I have learned 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- Indie hackers. 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 actually move forward with it, and try to go the extra mile. They just build, and they expect miracles to happen.
But as we talked about, the hardest thing about the product is actually marketing and sales. And you need to actually put yourself in the community, put yourself out there on social media, on X, on LinkedIn, on newsletters, on Substack. You need to write about it. You need to make sure that people actually get to know your product, and get to know what's the product all about. And without doing that, it's gonna be really hard for you to know actually
if that product is actually 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 actually get people to become paid subscribers as well, because I write relevant topics that people are resonating with. It's gonna be harder for me to do that
if I would be outside of that community. So you need to spend time to really understand what are the pain points of the product, 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 a short amount of time. It doesn't work like that. Yeah, and that reminded me of a funny tweet recently I found on Next. And so a guy is kind of an indie hacker
and building a lot of things. And sometimes indie hackers show in their profile, oh, this product makes 10K per month, or this project makes 5K per month or something like that. Then they show, oh, one is 30K, one is 20K, then blah, blah, blah, then that. His main product makes 1K per month. And some people tweeted, oh, wait, your main project is making only 1K, but you are setting how to build the product.
And that is making more like a 30K per month or something. But you don't know how to build product, but how can you teach and make money that way? Yeah, that's kind of funny. You need credibility. That's also what I say to a lot of people. It's gonna be hard for you to sell something without credibility. You need to be a good advertiser. You need to be addressing hype. If you don't have that credibility in the industry,
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 put yourself in the community. Take the time to really find out the problems, what people want to actually, what problems people have. And 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's where you're gonna get the value. But it's gonna be hard. You know, same thing with engineering leaders. It's hard to push back to company leaders that have like fear of missing out regarding AI if you don't have good credibility as engineer and also engineering leader.
If you don't have a good track record of successful projects, if you don't have people and your team respecting you, people around the company respecting you, it's gonna be hard for company leaders to also respect your opinion as well. I see. Do you have any tips around like where's the best place to find a fast engineer or founding member, founding engineer? Maybe LinkedIn or Indeed are not good place to find those founding engineers, right?
Do you have any tips around it? Yeah. Are you guys looking on-site or remote? Either is fine. But you know, we are open eyes, but not actually looking for it, yeah. Got it. Yeah, of course, of course. It's a difference between on-site or remote. You know, 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 for an offshore. And people like in Poland are very, very good. Poland and also obviously in other countries as well. I know people in 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 this one person, then probably I would recommend to be on-site with the company, with the team. It's hard to have fast iteration
if you have a person that 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 a bit of kind of like, I would also kind of more equity and kind of less monetary benefits at the beginning because obviously 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 be kind of like pretty varied with the spending, right? That'll be my go-to is kind of like looking for a on-site person. Obviously LinkedIn is one thing, but network is the biggest thing. Network is what I found out to be the best way to go is people recommending me others. That is how I found the best people. Because I always like, if I'm part of a certain team,
I always ask my team, hey, do you know someone that will be a great fit for us? And then I would get two or three recommendations and one of them are going to be really great for the team. So networking is really, really great. Any kind of events, any kind of local meetups, that is really, really big deal. On LinkedIn is hard because you get a lot of AI-generated resumes and AI-generated submissions. You guys know there's also a lot of different companies
and products out there that are automatically submitting to four different- One quick up, right? Yeah. For different roles. And also the problem is also then some people try to do deep fakes with kind of like using AI to actually pass the technical interviews. So it's a lot of time wasters for that. So I think on-site is the way to go for the first founding engineer. LinkedIn is harder. Networking is the way to go.
Asking people that, 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 the, kind of like, is a lot smaller than we think, right? So everyone kind of like knows almost everyone, right? So that would be my advice. Yeah. And at the same time, how do you 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 be looking in or looking for? Yeah, it's a really good question. And I, for example, I work with a lot of contractors as well, as I'm working with my newsletter and also with a lot of other stuff. And, you know, it's really important. And then also what I learned throughout my experience, both as an engineer and also as an engineering leader,
is that the problem is when what you tolerate becomes a new standard. And if you have like 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 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 cause of people leaving the company is because that we tolerate people that are not doing good enough job. So what you need to do is you need to spot that, you need to spot that as soon as possible. And 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, this is the expectation of the first week, second week, third week, first month, third, three months, and so on. And also these are our core values that we believe 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 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 being aligned with our core values and what we, what the vision is 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 reminder. And if I see that again, probably it's a good situation that that person would be 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 more people you have inside the team,
the more you tolerate either bad behavior. Behavior 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 immediately. And there's zero toleration for any kind of bad behavior. So that's kind of like my approach. In bigger companies, there's like a, you guys probably know performance improvement plan, like a, you know, in big tech companies,
they have a, it's called PIP. And they have like, a lot of times, there's actually is a process in disguise that they actually want to let go that person. But in kind of like 80% of the time, I believe that is kind of like my estimation. But yeah, in smaller startups, you mostly give feedback. And if you don't see improvements, you need to look for another person. It's just the way it is. Okay, then let's say you decided to let the engineer go.
And what, how should we, how should managers or leaders do that? Hey, just let them go right away. Or do you have some tips on this? Yeah, definitely, definitely. You 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 very also direct way is the best to go.
You know, you can't just, you can't just talk about different stuff and joke around 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 like a HR representative also 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 ways.
Something like that, really professional. That is the way to go. And that works the best way. You should not be, you know, any kind of emotions, any kind of stuff that is just making things worse. 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 on your newsletter. And I was, Kay and I were talking,
hey, we were really wondering how and where do you find these interesting information or ideas and also where do you keep the ideas in? Yes. It's a really good question. And, you know, I have a, I use Notion a lot and I use Notion basically 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 I, everything that comes to my mind,
I stored it in Notion in my system. So 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 comments, maybe I hear about a certain issue from one of my coaching clients,
maybe one of my people from the course that I teach, I make sure to always write down the idea inside this page. And 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 write about. And then 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 on any kind of other platform.
And I see 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 into, that article, right? And same thing is, for example, for Reddit, I post on Reddit all of my articles.
And like we talked about that 51% of engineering leaders are perceiving AI negatively. I posted that on Reddit and I saw a lot of engagements from people and they resonated a lot with that article. So what I did was on the recent article, I created more kind of a guidance 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 kind of more insights to people how they can manage this and expect expectations the right way. So that is kind of the mind process. And 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 kind of problems do you see? What kind of issues do you see?
What kind of issues you have at the moment and stuff like that, that always helps me. 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 really understanding the people and getting to know their problems. And then also like me providing feedback and me providing the articles that people need, that people are looking for.
I see, I see. And I saw your GitHub lead me, like how to be resources for how to be a good engineer. And I see a lot of list of books and articles and people who you should follow or something like that. And that's really resourceful and really useful to me. And also I think many engineers. But at the same time, I wonder, since you're an engineer developer, so have you thought about building kind of AI chatbot
using like a lab, 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 extract your knowledge, access to your knowledge and information you think is important and so on. Yes, definitely. I had this in mind for some time. You know, kind of connect that chatbot
with any kind of either LinkedIn posts, X posts, YouTube videos, all of the articles, everything that I write about, all of my notes as well that I have on Ocean. That would be amazing, right? That I can, if I would have that one day. That's something I have in mind. I haven't yet to utilize it and actually create it. But yeah, 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 it with either chatbots or either find it via ChatGPT or any kind of other models. 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, ChatGPT and Claude 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 SEO, right? So yeah, definitely. I have this in mind and that'll be a good thing. And I think a big value add. If you can connect all of my thoughts into that AI that'll provide. it answers to people. Yeah, I look for to use it. 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 paid paid newsletter? And do you have any tips or thoughts around it? So like, you know, oh, I should have started earlier or later? Yes. Yes. I think it's 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 was, I don't want to feel like I'm selling something I don't want to be like a salesman sleazy salesman. And that is that is what I see problem with a lot of engineers is they don't want to market that 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 will do it sooner. So I started very, very simple, just like started with an archive of articles that are more than one month after being published. And that became kind of like paid art articles. And yeah, after after that, it would slowly
started growing slowly started growing and I was growing my paid paid subscriber base. Then I decided then did this work then I decided to also create kind of like templates 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 in their day to
day roles and also grow in their careers. And then also I started to do infographics that also has been recently added to the benefits for paid subscribers. And that started growing in a reasonable way. But the most the most growth of the paid subscribers I saw is when I actually stopped doing full time role. So that was a time it was that was about about nine months ago, when I when I 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 cross 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 a free newsletter every
Sunday. And then after one month, it became the paid paid newsletter because of the archive, right. And I saw the biggest growth is when I started that that paid newsletter every Wednesday. And I think it's been around like, nine months, nine months ago, I started that. And I I'm close to tripling my paid subscriber base. And also my revenue from 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 that people resonate with that. Yeah, we are happy for you to. Yeah. 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 the code code. And yeah, which one is your favorite? And so which one will be lasting for five years? 10 years? Yeah. Do you have any of
you? 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 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 own kind of like ID colors and everything and also fonts, and so on. 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 a lot of the generated code was actually 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 is called GitHub Copilot actually going to
output. It's 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 really great. You can get you can get very, you can get very, you can get very lazy with it. If you if
you if you kind of like just rely on it too much. That is 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 my go to tip is if you use it with with your voice as well. I use a whisper flow is kind of like to kind of like give comments to Cursor to automatically so that I don't need to write about it. So that automatically puts put that text in the in the in the
text box. And that's that generates the automatically the the what I'm looking for. Right. And I can move really, really fast with it. So Cursor and then obviously Perplexity is for any kind of researching deep research. And ChatGPT is mostly for any kind of problems, more detailed problems like with maiming. Or for example, if, if I can figure out something inside Cursor, I will go with ChatGPT and I will paste that
that problem in there and I will look for additional approaches with 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 in Python, I would look for for ChatGPT for that. But yeah, for about five years, I think it's really hard to say which which tools are going to be here for five years, because it's a battle between different
companies. And it's, it's, you know, it's, it's, 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 they're doing. But they're also like a small company. So there's a lot of bigger players down the road. And 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. Yeah, sure. And I got an interesting advice from other founder friends that you know, you should be something that the first growing companies are spending the most. So meaning, if you
get something that the first growing company is spending for so that you can be chosen at some point. And I think that's interesting thing. But yeah. Yeah. It's definitely a good way to look at it. Yeah. So, yeah. And so and about the advice, and do you have any advice to aspiring engineers, or aspiring engineering leaders and managers? And also, you know, someone who hate to use AI tools? Yeah, I think, yeah, you know, it's, 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 that is my 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, really that and just focusing on that. Because after some time, maybe that framework or that technology might not be even used, you know, because things are progressing so so fast. Like for example, people used jQuery, like or maybe Angular, Angular one, they use it like a lot. And you know, right now, there's not a lot of people using Angular one
anymore. There are people using Angular 20, or Angular, Angular 21, or whatever the latest version there is. But it's a totally different than Angular one, right? So people who spend like so much time to actually understand it have lost the time that actually they can spend on many other stuff 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, you can ask people you can you mentioned founder friends, you need to nurture it, 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 that is good in in in Claude that is good in systems that is good in that is good in Kubernetes that is good in in Docker that is good in 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, utilize tools, whatever is helpful to you is really good, really, really important to be part of that problem-solving toolkit that you have. Makes sense. And also if someone listening to is, you know, like writing something like a blog and
so on, and as you mentioned earlier, and they should trust in the process and keep doing and patient and also because believe in the compound effect, right? Eventually. And the biggest thing is just starting. That is the biggest hurdle that a lot of people have, is just putting yourself out there. 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 perfectionism mentality telling us that, 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 we actually publish and actually get feedback from people. You can't really know if that is good enough, but a lot of people don't actually 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 my manager is going to think about it. But that is all in our minds. Like we, 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, on, 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, just publish this LinkedIn post, publish this article. It's going to get a lot easier over time, but it's, 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, you just need to get over it. You just, you just learn to, to become better at it. 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 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. 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 so much increased my perspective of my knowledge because just of writing online and meeting new people. And so much opportunities just came, came because of only, only good things happened because I was putting myself out there and too many people are being skeptic about it and afraid of just, 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. Totally. Yeah. Thank you. And then last question.
So as we talked 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? Yeah, it's a really good question. And, you know, if you would ask 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, really deep thoughts, really something that would be, you know, very inspiring. But, you know, my, my number one goal is to help as much as people to become great engineering leaders. That is, that is what I am focusing the most these days. And this is, this is what I like to do. This is, this is what drives me every day to, to get up and provide interesting insights to, to everyone who is reading. And also everyone who is, who is learning to be better engineer,
better engineering leader, how, how to, 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, they've been, they, they, 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 Monday my day. And that, that is a personal satisfaction
that I really, really enjoy. And I, I don't see myself, you know, stopping that, me getting better as an engineer leader and also sharing, sharing that with everyone else that, that is, that is something that I see myself doing for, for long-term. And I hope to help as many people as possible along the way. Yeah, very beautiful. And yeah, thank you. And thank you so much for all the, you know, like, like insights and lessons and advice share with us. Thank you. Of course,
it was really great, great speaking with you guys and really great questions. Thank you.
Share This Audio Transcript & Summary 📚
How to Thrive as an Engineer in a World Obsessed with AI | Gregor Ojstersek
00:00
01:14:53