#193 - The Path to Becoming a Great Engineer: Insights from a CTO Perspective - Milan Milanović

[00:01:26] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. I’m very excited today to have Dr. Milan Milanovic today. So for some of you, maybe you have known him by following his newsletter, a very popular newsletter, Tech World with Milan.

You might also find him on LinkedIn with a lot of number of followers. So Milan is a very experienced engineering leader. He’s now a CTO and also a scholar, you know, published a lot of research. And he’s also a coach at the same time. So I’m really looking forward to this conversation. So hopefully, we can learn a lot of things, how to become a better engineer or great engineer in summary, right? So Dr. Milan, thank you so much for this time. Welcome to the show.

Milan Milanović: Thank you, Henry, for the invitation. I’m following you for like a few years, your work. So I’m very honored to be a part of this journey.

Henry Suryawirawan: Right. Thanks for that.

[00:02:14] Career Journey

Henry Suryawirawan: So Dr. Milan, I always love to ask my guests first to maybe tell us a little bit more about yourself. Maybe, in particular, your highlights or turning points that we all can learn from that.

Milan Milanović: Yes, like I have like more than 10, 20 years of experience. But I would say my experience came much before that, because my dad was also software developer for more than 40 years. So from my early days, I recalled all the things regarding software development and all the, those tasks were always all over the place in my house. So when I started to study, of course, it was a natural path because from time to time I really was intrigued. Well, what is like inside, what is happening? Some.., to me, like some really creative stuff are going inside. And I started to study and then finished my high school and the faculty, and then started to work in the industry. But I, in the same time, while I was starting to work in the industry, I continued my work on the university, because I also liked that work. And I was undecisive back in that point of time. Should I stay in the research, or should I go in industry?

So I chose both, which is very rare. Usually people select only one of those, but I tried to stay on both tracks. It was not easy, but I stayed on both tracks. So I made my PhD at the University of Belgrade at the Computer Science and Artificial Intelligence Department. But at the same time, I worked as a software engineer for one of the biggest companies in Serbia. After that, I moved to some like middle sized Swiss German company where I worked for five years. In the meantime, I also worked a lot of as a freelancer for some projects, which also helped me a lot to develop some skills that I could not, maybe, in my primary job.

Then like two years ago, I moved to this, uh, US startup where I work as a CTO, and where we work on one kind of a product for transportation industry. So like in these 20 years, I’ve worked in really big enterprise companies with more than 30,000 employees. I’ve worked in middle kind of sized companies, and now I’m working in startups where there is like 30 people only. So I really saw everything, I would say, from that point of view how big companies work, how small companies work, how things…

So I really, really learned a lot. And as you said, a few years ago, I started to write about this on, uh, different social networks and different channels like my newsletter and other. Why? Because I think… During my PhD studies, I learned to write, I learned to research stuff. And then I used all of these skills later to transfer my knowledge to more and more people. First, inside my company, I did this inside my company, primarily. Then from one point of time, I started to work and write externally also. And I saw that like, okay, people like this. There is a lot of traction happening. And somehow from that point, things just went on and on.

Henry Suryawirawan: Wow, thank you so much for sharing your story, right? So I think it’s really inspiring. So you have done a lot. You have seen a lot, I guess. And I think in particular, when you mentioned that you tried to stay in both the academic part and also the industry part, I think that’s pretty rare, for sure. Typically, like you said, like people will just choose one side or maybe juggle from one and then change to the other. But to stay on both sides, I think it’s really, really commendable, right?

[00:05:50] Attributes of a Great Software Engineer

Henry Suryawirawan: So you have done a lot of research in your journey, right, in your career. I think today’s topic, we’ll try to narrow it down to talking about how to become a much better engineer or a great engineer, right? So I know you have published a couple of research and maybe newsletter as well, right, on how someone can become a greater engineer. So maybe let’s start from there. In your point of view, what do you think are the attributes that we should hone in order to become a much better engineer?

Milan Milanović: Yes, exactly. What I saw from my work, when I worked, like as a software engineer and later as a team lead and a mentor, and also when I was mentored by some other people who were like really top performers in their area, I found some characteristics of those people, which I use later also and try to follow the similar path. Uh, the first thing was like you need to master like one or few programming languages in depth. So you need to have some kind of a core expertise. And besides this, you need to be like very good in those, all of those primary engineering concepts like algorithms, data structure, system design, patterns. Similar stuff which are here, like some kind of a base. You need that base to grow, because everything stands on this base in this industry.

And of course, after this, the next thing that I found, which is really important, is that you understand the whole software development lifecycle. So from requirements to deployments. And to become, especially if we are talking about full stack engineers, in general, that we call like T-shaped, in general, there are some kind of variations of these shapes. But like, the most basic one is T-shaped that you like, that you are good in the whole of software development life cycle, like from requirements phase, front end engineering, back end engineering, and different. But you are really, really good and have deep expertise in at least one field. It can be, of course, more fields, but at least one field.

And then, especially for product companies and for startups like we are, you need to have like this, I call it, a product mindset. Or to be like product minded, in general. What this means? This means that you really try to understand whys from the customer side, like from client side, and to follow this path to implementation and later to, uh, running all of this stuff live. Not like to be just on the implementation side of things, but really to be involved in all of this parts of software development lifecycle and to really understand the customer, what is going on? Why is it, why are we following this direction? And really to be in the place that will improve our product.

Other group of skills are, I call them, maybe some people call them soft skills, but I would say those are like more communication and prioritization skills. And there is a bunch of skills there, which are very, very much important, especially for some, uh, engineers to become senior, lead engineer, staff level, and etc. And those include like, of course, communication, all of kind different kinds of communication from written emails, public speaking, different. Then critical thinking, understanding biases, understanding mental, different mental models. All of this stuff related to soft skills, of course, dealing with people, uh, working with people, mentoring them. All of these kinds of skills which are non-technical, but very, very much important for one senior engineer to do.

Henry Suryawirawan: Yeah, thank you so much for outlining all these different attributes, right? So maybe just to recap a little bit, you mentioned in the beginning that someone needs to master like one or few programming languages that’s like the core skills. You know, pick any language, maybe the one that you use at work, right? And try to be good at them. And also don’t forget about the base, right? Some of the fundamentals like algorithm, data structure, design patterns, maybe object oriented programming, functional programming, and things like that, because that’s gonna be the one who can propel you even further. The base and foundation in computer science mostly stay the same, I would say. But of course there are many frameworks and, you know, maybe flavors of how you implement something that change. And after that you talk about being product minded, right? So, try to understand the customers. Also understand SDLC. And the last thing is about soft skills.

[00:10:28] Common Lacking Attribute

Henry Suryawirawan: So maybe from your experience in your career, right, seeing a lot of engineers. Where do you think that most engineers actually are lacking?

Milan Milanović: Most is in this part of the soft skills. So most of the engineers deal very well with technical stuff. They’re really good at this and they become better and better during the years. But in all of this, like I would say beyond the coding stuff, the things lack. And as you go more senior, these stuff are more important than technical stuff. Why? Because the technical stuff with the like knowledge of programming languages and all of these things. There is a limit of knowledge, I mean, I would say usually, which is good enough for you to know. Because after this point, there is something called law of diminishing returns that just, uh, it’s not needed to go further and deeper in this. Or if you are like some kind of a mentor or tutor on this language or this technology, then okay. But for a general, software in general, it’s good enough to be on that level.

But all of these skills, other skills, as I mentioned, need to be grown, because you need to impact… as you grow in all of these roles, you need to impact a large number of people, a large parts of organization, and you cannot do this only by coding. I mean, it’s not possible, because there’s many people coding, you cannot sit now and write something, you know, something that never is like seen in this world and that will solve all our problems. You need to be, you need to create some kind of a leverage and bring other people on the surface and enable them to produce like better and better results. And all of these things you can do only if you have all of these skill set.

Henry Suryawirawan: Yeah, I tend to agree from my experience as well, looking at the different engineers, at least from my career, right? So I think soft skills, maybe the people dealing with people part, right, I think seems to be, we need a lot more, I don’t know, coaching or maybe even like practice in order to become better. And especially like you mentioned, as we grow more senior and even becoming a engineering leader, you know, like VP or CTO or engineering manager, these soft skills tend to be much more important rather than technical skills, right?

[00:12:48] How to Learn New Skills

Henry Suryawirawan: So maybe soft skills is definitely one area, right? The other part that you mentioned is about learning new technologies. Because these days, I mean, we can tell that there are so many advancement, you know. AI/ML is probably one of the latest. But before that, there are plenty, right? So what is your advice for engineers to deal with the rapid change of technology? How should we keep up? How should we update ourselves? Maybe a little bit of tips, maybe from your point of view as well.

Milan Milanović: Yes. I think we should always learn intentionally. So when we have something in front of us, like when we say in front of us, this is like something we will need like in three to six months, we should start and research about this and start learning it. Of course, the best learning is doing. So there is no other way. Everything else, this is a learning pyramid. I published this in my newsletter, where the retention of, uh, learning from different methods differs. So the best retention is by doing. So when you take a look at some kind of a tutorial and you do really something, this will retain in your head. For all the other things, uh, like reading books, learning from conferences, other stuff are good, because you broaden your vision with this. You know what’s there, so you know how to tackle maybe some things in the future.

There is one thing called circle of competence. I also wrote, uh, recently about this, where in the center you have the circle of your competence. So these are things that you know, your skills, like your technical skills, let’s say. There is other layer outside, there are skills that you know that you don’t know. So for example, you know there is a React framework, but you don’t know it. So you can easily start learning. But there is a much outer layer. There are things that you don’t know that you don’t know. Or some people call them unknown unknowns, and this is the area where you can grow the most. And what are those things? Those things are, for example, some of these skills I mentioned to you, which are, uh, usually not visible, not clearly visible to developers. And also other skills like product knowledge skills, like marketing skills, sales skills, all other things which we don’t have in, in our mind when we are doing this job.

Of course, there are ways how we can go that. For example, one fast track is to find a mentor who will say to you like, okay, there is this thing you don’t have this at all in your mind, but there is this thing, go and learn it, you know? So this is one way. There are other ways, of course, how to go to this part, because when you go to this part and you find some things that you, uh, never saw, thought that, uh, they exist, this will bring you the most growth in your career and life, of course.

Henry Suryawirawan: Yeah, I saw your newsletter, right? You publish a lot of articles and you went really deep into the topics for every of the articles, right? So I think this is also probably coming back to your background as a researcher, you know, a scholar, right? So you did a lot of research.

[00:16:02] How to Become an Expert

Henry Suryawirawan: So for people who want to become an expert in a particular topic or domain, or maybe even like a particular technology, right? How do you recommend us to become much, much better in the domain or an expert, maybe, even one day?

Milan Milanović: Yes. There are a few ways, like a few ways how we can do this, but I like to do this in a structured way. Why? Because when you do things in a structured way, it’s easier to follow. For me, it was always easy to be a scholar, because you have the path that you just need to go to this path, you know. If you don’t have a path, it’s really hard to follow something. This is good for creative stuff. But if you have some job to do, it’s much better to have like a defined path where to go. There are two frameworks that can be used in this area and in learning a new stuff.

One framework is called Four Stages of Competence. And this means then when we start to learn something, we go through these four stages. So the first stage is unconscious competence. This is, as I said, those are like those unknown unknowns. So we don’t know that some things exist at all. So maybe they exist. We don’t have any knowledge on this. And so at this stage, we need to find them out first. So as I said, there are ways how to find those stuff.

Then there is conscious incompetence. This is where real learning begins. So at this stage, you know that there is this thing, but I don’t know. I’m not like knowledgeable about this, but I know now, okay, I know that this thing exists.

The next thing is to take and learn this stuff. Okay, I now take it, I go to some tutorials, I read some books, I talk to some people. And now I’m at the level of conscious competence, so now I have some skills to work with it. I may be really good in some parts, in some parts, I’m not good. So it’s some kind of a third level.

But to be an expert, we need to go further on the fourth level. It’s called unconscious competence. This is where the skill become natural to you, or like where the skill go in the unconscious part of the mind. Like when you drive the bicycle. So you don’t think when you drive the bicycle like, okay, I need to move this leg, or this leg, or this hand. So this is the same with all other skills that we can develop. And we want our knowledge about the stuff to be at this level. And when we are at this level, we then can be called an expert, because we don’t need to think about this. What are some examples of it? Like when you learn Git? When you know Git so well, you don’t need like any checklist, you don’t need to remember yourself, um, how, how I need to do like branching or rebasing.

So this is all natural to you. And how we go, how we went to this level is just with a massive amount of practice. So a massive amount of practice, many hours. There is this book, Outliers from Malcolm Gladwell, where he said to be an expert in some field, you need to work 10,000 hours in some area. So it’s five years of full time job, let’s say. And he gave, uh, also an example, uh, with violinists, where he showed that the best violinists are those who practice it the most. And I believe that this is the same, probably, with software engineering.

Then, there is another framework called Bloom’s Taxonomy, which is a bit more granular. So these four stages of competence describe how we should go in which kind of a direction. But if we have concrete thing that we want to learn, we can use this Bloom’s Taxonomy, because it gives us a nice structure how we should do this. And there’s like six levels of knowledge. For example, I will give an example of clean code, for example, learning clean code with this, uh, Bloom’s taxonomy.

The first level is remembering. So we just, on the first level, we just learn about clean code. So we just read about this, we learn some kind of principles, and okay, we kind of get some things from this. Then the next level is understanding. At this level, we need to prove understanding of this material by explaining these concepts in our own words to some other people. There is also one Feynman technique for learning, which also use the similar concept by famous physics professor Richard Feynman. When you can, like, explain in simpler words, some concepts to someone other, you understand it very well.

And now, on the third level, is applying. So now, let’s apply these things. So now you need to apply all of these like clean code concepts. You have understanding of this. You can then now use it in everyday work. You can really really apply it. Then, on the next level, you have analyzing. Now you can understand better when you take a look at the code. Hmm, is this code good? Are there any issues with this? Like okay, this is clean code, this is not clean code. Okay, I need to, like, refine this variable name, I need to extract this method, so you are now really, you know, in the flow.

Then, the next level is evaluating. At this level, you now make judgments about different approaches. And this is the level where I see that most people don’t go. Because most people are on the previous level, analyzing. They learn clean code, they push it everywhere. But at the evaluating level is where you really try to see, maybe, okay, maybe here I don’t need clean code at all, because performance are much better. Clean code is not performance. But here, I need performance. Or maybe I need to do something dirty here. You know, I will not just now apply these principles wherever I see them.

And then, of course, there is the final level, creating, where you now are able to create new ideas, new concepts. It’s like new strategies, how to work with this. So this is really the final level of knowledge on this area. In front end development to be like creating of new framework or a new, new library or similar, yeah. So something like this. Of course, only if it’s needed.

Henry Suryawirawan: Yeah, maybe for clean code, it will be like a cleaner code. So I think these two frameworks are definitely great, right? So like you mentioned, right, sometimes we need a framework or kind of like a path, a direction, right, to aim for, and kind of like follow in order to become an expert. So I think, definitely, one thing that you mentioned, it takes a lot of practice, right? Or maybe like Malcolm Gladwell said, 10,000 hours.

[00:22:47] 10,000 Hours

Henry Suryawirawan: So do you think for engineers, if they want to become great, maybe for a particular topic, maybe like clean code, does it mean that we have to always programming, do programming, you know, inside of working hours and outside of working hours? Or do you think becoming an expert also requires a multitude of different activities?

Milan Milanović: My boss once said to me, like you become good engineer from 9 to 5, and you become great engineer after 5. So, and I somehow understood it well, because it doesn’t mean, like you should do overtime. But, like, after work hours, you can, like, read some books. I’m a big fan of books, you probably noticed it. And you can do something extra to learn. And with this, you reduce this time to get to this 10,000 hours, you know. Then you don’t think maybe five years, you will get it in three or four years to this level. So I strongly believe that there is something. And even though there are many, many talented people and people who works a lot, I found in my career that people who worked and pushed this extra hours, they were really, really good in their job.

And there is something behind this. I mean, I don’t want to be like that I support like some kind of hustle culture and overtime work. But I think when you do extra… You have this in football. You probably heard that like Ronaldo and all other guys, when the regular training is finished, they go and practice two more hours. I mean, this is in every field. This is not only in our field. So extra time used to practice something is always worth it, in my opinion.

Henry Suryawirawan: Yeah, I think some of the famous sportsmen that I know, like Cristiano Ronaldo, Kobe Bryant, right, they always practice. Like come early and finish late, right? So I think, yeah, it’s not an endorsement to do like hustling work, like you said, right? But I think to become an expert really requires a lot more dedicated effort and intentional learning, right? Not just doing it 9 to 5 or something like that. So another thing that…

Milan Milanović: And focus.

[00:24:52] Dealing with Imposter Syndrome

Henry Suryawirawan: Yeah, so another thing that is quite common when in technology, right? Like they think they will never become an expert. So some people say imposter syndrome. So they always feel that they are consciously incompetent. So maybe any kind of tips from you, how we, as technologists or engineers, overcome this imposter syndrome, right? Feeling that we’re never going to be an expert enough.

Milan Milanović: Exactly. Imposter syndrome is something that is especially present in our field. Why? Because it is so large, and there are so many topics. And if you are like expert in one field, tomorrow, you can be in another company, in some other project or team where there are some things that you don’t know. And then you are immediately hit by this imposter syndrome, and you will tell yourself like, okay, I’m really not good, I’m not expert for, I mean, I’m, you know. And this is a pendulum that goes from imposter syndrome to Dunning-Kruger effect, which is constantly shifting from left to right. Because you now are bad at this, you learn it, and then you say, okay, now I’m really good, I’m really great at this. And then tomorrow, you can again feel like, um, maybe I’m still not good.

So, I just want to say that we, in this industry, need to be aware of this effect. This is the first thing. I wrote about this thing multiple times. We need to be aware of this, because when things happen, we self reflect on this. Okay, now I understand why is this happening. Okay, I’m not bad, this is happening, because there are so many things, so many languages, frameworks, things are going on every day, so I cannot know everything. That’s normal, just normal. What we can do, I mean, we can say to ourselves this, like, okay, this is normal. And then, like, go bit by bit and start try to learn all of these things properly. So there is no magic potion, like, that we can drink and finish it. But the thing is that we need to really, really be deliberate about these things and how we tackle all of new, new stuff.

There is a wording, uh, be brave to suck at something new. And I really believe strongly in this. I mean, especially when you are someone with a lot of seniority and experience, because we need to just adopt the growth mindset. Okay, I know some things, but there are much more. You remember this circles of competences. There are much more things I’m not expert. I don’t know at all that they exist. This is just a natural thing. And then we accept this in this way. Imposter syndrome becomes much, much better in our lives.

Henry Suryawirawan: Yeah, thanks for the tips, right? I think in the tech world, I don’t think anyone could catch up with everything, all the advancements that happen. Plus, they are just too rapid, right? So maybe one day you can catch up, but almost immediately you will be behind again, right? So I think thanks for the tips.

[00:27:50] Learn Things That Don’t Change

Henry Suryawirawan: Nevertheless, right, I think in one of your articles as well, you mentioned in order for us to become better engineers, right, we should also note things that tend not to change, right? Your title is about learning things that don’t change. So tell us why is this important for engineers learning things that don’t change? And how, and what are topics that we should learn that tend not to change in engineering?

Milan Milanović: Yes, like… I have like more than 10 years experience in this field, and I saw stuff that were here, and they are not visible. Let me mention a few like Flash, Silverlight, different kinds of technology that were here. But there are some things that are here from sixties, like SQL. It’s like for 70, 80 years here, so and it will probably stay much more. And there is some effect called Lindy Effect, which explain us why some technologies are still with us and why some disappeared from the market and from our lives. And this Lindy Effect proposes that the longer a period of something has survived to exist or to be used, it’s longer it remains life expectancy, like for this thing or this technology. This tells me that developers will still use, like SQL when I am retired or like some similar things.

And why is this important? I call this like learn fundamentals and not frameworks. Of course, we need to learn some cutting edge stuff, because, I mean, people in this industry like to learn. There are some advantages, really, really advantages in some stuff that really make us more productive and to create better output. But learning these fundamentals allow us to understand like these underlying principles and concepts across all of these different frameworks, languages. And enables us to have more flexibility and adaptability when working with new technologies and facing problems. Because when you have this base, it’s much easier to understand all of these things.

So what are those fundamentals that we should learn really deep? Like as I mentioned at the start, algorithms, data structures, principles, object oriented programming, design patterns, distributed computing principles, system design. And, like, all of these things that are here for, like, databases are here for many years, and they will stay for many years. Some other things are here just for a few years or like maybe a decade and they will just disappear. And no one will see it anymore.

Henry Suryawirawan: Yeah, so I think the Lindy Effect is something for us to reflect a lot, right? So just to recap again, the Lindy Effect, right? If something stays for quite some time, right? Most likely they will stay relevant for a longer time, right? So you mentioned SQL, I think like TCP/IP, HTTP, networking aspects, I think rarely change, right? And maybe like data structure, design pattern, system design, and all that. So I think for those engineers who listen to this, be mindful about this Lindy Effect, right? So when you pick on new things to learn, right, maybe start from the fundamentals rather than the framework. Of course, sometimes in the job you have to master a particular framework, simply because that’s kind of like expected for the role. But to stay long in the game, in the engineering game, right, you need to master the fundamentals. So I think thanks for highlighting that. So….

Milan Milanović: Exactly, and here I have also one important thing to say. I think we should try to be general software engineers. Why? I often see, you probably saw also, like I’m a React developer. I am Java developer. I mean, okay, this is specialization, some kind of. But I think we, as software engineers, should be generalists. So okay, I’m software engineer. I’m primarily problem solver, so I solve problems. And then in solving these problems, I use some tools. Those tools are Java, React, you know, just you can put anything inside. Just be flexible with all of these things. We also see this trend in big FAANG companies, big tech and other companies, where they just are asking for general software engineers that can work with really different, diverse aspect of technologies and tools. Because those are tools. I mean, if you know all of these concepts and all of these foundations, you will learn any tool very fast, you know. But if you’re just a tool developer, like I’m just a React developer, you are just then really specialist in this field. And it’s very inflexible for you, your career, but also for your employer tomorrow to put you in some kind of other positions and roles and to grow maybe even further.

Henry Suryawirawan: Yeah, so I think that’s a very good tips, good call out, right? So don’t take any particular language, framework, whatever that is as your identity as well, right? Just like you mentioned, I’m a React developer, right? So I think I’m a front end developer probably is much better rather than a particular framework developer, right?

[00:32:52] High-Quality Engineering

Henry Suryawirawan: So I think this thing is definitely very, very important, right? The other aspect of a good engineer is definitely producing a good quality output and deliverables, right? It could be the code, it could be the non functional attributes part. Or you bracket it together as a high quality engineering. So maybe from your view and also in your career experience, right, what stands out for engineers who can actually produce high quality engineering?

Milan Milanović: Yes. As I mentioned a bit earlier, the first thing is like this customer centricity. I think this is very important. As I said, those are people who I like to call product minded engineers. So those are people who really try to understand why are we doing this? Why is this important? Because when they understand this, they can ask better questions, they can challenge some stuff, they can lead this process much better than those who are just waiting for a task to be defined, the user story, and then just to implement it, you know. Because, I mean, AI is much much better now. In a few years, AI will just implement the things from the user story, probably. Or most of it. So we, as problem solvers, need to be more on this left side of the line than on this right side only, like implementers. Then I think that high-quality work, as a software engineer, include good software design. I wrote a lot about this, so I will just try to explain this shortly.

What is great software design? This means that we should start always simple. We should not start like with some big fancy architectures and big fancy project structures and such stuff. Why? Because there is something called project paradox. It means that the number of essential decisions we need to make at the line of the project decreases while we work on the project. And we need to make all of these big decisions at the start. And at the start of the project, we have the least knowledge about how the project will go, how it will be structured, how many users, etc. So we want to decrease the number of important decisions at the start, and to put them later in this timeline working on the project.

So I always say good quality is to start simple and then develop this further. What this means? This means like we can start with modular monolith architecture at the start. And then if we need it, like if we will grow so much with many users and we need more scalability, we can always transform this architecture to microservices or some event driven architecture and so on. Then, of course, there is a code level, where we need to have really good quality. What is good quality? This is also a wide subject, but I like this definition from Kent Beck, who has said like, good code passes tests, reveals intention, has no duplication, and has the fewest elements to do what it needs to do. On the other side, what is bad code is really hard to say, but we have these code smells, so we need to learn like these code smells to know, okay, this is not good, this is good. So we need to have these principles in mind, but also to be knowledgeable about all of this different kinds of code smells that can happen in our code.

Then we need to be part of the good engineering culture. What this means? This means like we have good psychological safety to experiment and fail. If we are stuck, for example, for two hours, we can ask someone to help us. That we do code reviews, pair programming, that we have possibility to have these stretch roles, like, to be on this line of, of T-shaped developer, to constantly learn new stuff, to have like mentors, coaches. And in the end, you work in a happy team. So the team where developers are happy and like to work on the team.

Also this include good engineering practices that are present there. Like you have source control. You have tests on all critical levels, like on the test pyramid. You use properly patterns where they are needed, like use TDD. You are checking for YAGNI, DRY. KISS principles, SOLID principles. You have automatic code analysis, linters, all of the stuff inside. You document all of the important decisions in close to the code also. And this is really, really one important part, because this is our surrounding that can make us to produce high-quality work.

Then, of course, we need to have this quality-first mindset, where we need to cover everything, and to have all of these proper kinds of tests and also including probably QA roles and all other roles, depending on the, of course, on the structure of the project. When we want to produce only high-quality software without bugs, we also use in our company like a zero bug policy. We don’t have any bugs in backlog. Why? Because your software can be really great, users don’t like bugs to see. When they see bugs, they will lose confidence at some level to your software. So this is something we don’t want to see in high-quality software. We don’t want to see bugs. So I think every extra effort there is really good to have.

Henry Suryawirawan: Yeah, so I think there are many, many things that you mentioned just now, right? I’ll try to mention a couple again just to recap, right? The first is most importantly, customer centricity, right? So always put the customers in mind, try to understand the requirements, challenge the assumptions and things like that, right? The first thing is to make the customer or user happy. Second thing is about the software design, right? Use a great software design. You mentioned a couple of things just now as well. Good code quality. So I think I like the one that you mentioned about Kent Beck’s principle, right? So pass the test, reveal intention, fewer duplicates and things like that. And good engineering culture and principles, which probably also relies a lot on the engineering leaders and the culture within the team and the company, right? So not solely responsible by the engineer. And then the quality first mindset, which is probably is something that we all need to be conscious about, right? Because sometimes due to pressure from externals, we tend to kind of like relax the quality in order to deliver faster. So definitely, these are good high quality engineering for people who would like to learn more. I mean, do check out the articles.

[00:39:28] Becoming a More Productive Engineer

Henry Suryawirawan: The last thing about great engineer that I’d like to talk to you about, which I think you are also like seem to have a lot of expertise, right, is to become a more productive engineer. So one thing that I noticed, right? I think great software engineers do not just master a technology part, also the customer centricity and all that. But they seem to be able to produce more. So tell us maybe some secrets that you think that makes engineers much more productive than the others.

Milan Milanović: Exactly. I wrote a lot about productivity and this is not like because I want to be a productivity expert like, like much more a productivity expert who are famous. But I found that this thing is something that like no one teaches us. And during my, all of my roles, I never had like any session with someone like my boss or my mentor or someone who came and said to me like, okay, now you need to improve this regarding your productivity. Or like okay, now you need to use this technique, like you now procrastinate, you need to use… Or try this, or try this. No one said to me. I needed to research this by myself, which was hard, you know. There was a lot of trial and errors there. So after using all of these different methods for many years, I think I got it, how they should be used. And I wrote a few times about those.

The most important thing maybe is like multitasking. Multitasking is a myth. It is the biggest productivity killer. And I saw this, that many people get it wrong. Like they try to work on multiple things at the same time and to context switch. This is just a killer of productivity. So to be productive, you must focus on one thing. So pick one thing. Block the time in your calendar, like two or three hours to work on it. Turn off notifications and work on it in the focus mode. There is a good book by Professor Cal Newport called Deep Work. I recommend everyone to read it, uh, because it goes much, much deeper into this deep work. Why we need deep work? To be, because we, as software engineers, need this thing called flow state. To be in flow state. Why? Because we need to work with high concentration levels to solve problems. And to be able to do this, you need to be in this flow state. The only way to be in this flow state is to work in these deep work periods during the day.

How I organize my day is usually I move all meetings in the afternoon, so no meetings before two o’clock. And then I use this 3-3-3 method. I use like in the morning, I mean, it depends from different people have different timings, but usually in the morning you have the most energy when you start working. And I use the first three hours to tackle the most important thing I need to do today. Then afterwards, I also (do) some three shorter tasks, and then afterwards, three, some maintenance activities like sending some emails, some documentation stuff, and then similar. And this is really important.

The other thing is prioritization. I recently wrote a mini book on this. Because, uh, there is different levels of prioritization. Now we are talking about personal prioritization of productivity, there is also team prioritization and then leadership prioritization also, but this is some other topic. Regarding the personal prioritization, we can use something like Eisenhower matrix where we need to understand that not everything which is urgent is important. And why is this important? Because we want to work on non-urgent and important stuff. If you are working on urgent stuff, that’s not good. Because urgent things should happen from time to time. If you are constantly in an urgent mode, something deeper is not good, you know. So you are, you want always to focus on the important but non urgent stuff. This is where you produce the best results. Of course, if things are not important, not urgent, you just don’t do them. Remove them.

Then, of course, many developers are big fans of some kind of a personal organization. I needed a lot to figure it out what works for me. And I found this great framework. There is also a book by the author of it called Getting Things Done, GTD framework, which you can also actually use in any like to-do app. There are some apps like Todoist that have already this process integrated. Then you have like a process how you take all new ideas in part. Then you have next actions that you can do any moment. If you need to do this, if you can do this for less than two minutes, do it immediately. There is also waiting-for column, so if it is something kind of blocked. Then you have projects that have more than one action. And then someday things that you will do someday. And there is this process how you transfer things.

There is this second brain concept, also. Why is this important? Because all of us take notes, but notes are usually chaotic in most of the people, you know. And I think this is also a really important part. Why? Because some wise people said mind is to have ideas, not to store knowledge inside, like especially unnecessary knowledge. And we want to offload this knowledge into some kind of notebook. And second brain concept, you have also a book by Tiago Forte here that enable you really to transfer all of your knowledge into these great notes. And you can then find them really quick, you know, when you need them.

Then also, one big topic here, is procrastination. Of course, there is always things that we don’t like to do. I mean, we cannot always work on things which we are really, really happy to work with. And there is where Parkinson’s Law have impact. It says that the work expands to fill the time available for completion. What this means like, if I said to you, you have three days to complete. And you maybe can complete it in one day, it will probably, you will probably do it for three days, because you have time, you are given that time. And here, we can use some kind of techniques like Pomodoro technique. There are some variants of this technique where you work in 50 minute blocks, and etc. As I said, variants, there are some variants where you can work in larger blocks, not to interfere with this flow state we want to achieve.

Then what is also important for personal productivity for on personal perspective, but I think on team perspective, are these weekly plans. Not daily plans, because day is a short period. Everything, anything can happen in a day. But these weekly plans. So on Monday, I plan to work and finish something. I have goal to finish something until the end of the week. And then at Friday, in the afternoon, after my work, I sit 50 minutes and reflect on this week. What did I do good? What didn’t do well good? Why? How I can this improve for the next week? And then when I, I usually on Sunday evening, create the plan for the next week. I then incorporate all of this knowledge from the previous week to improve for the next. And then with this weekly plans, I clearly know what impact I want to achieve this week. And of course, what I don’t want to impact. And this, of course, should be also connected to monthly, yearly goals. I also have a book on setting and achieving goals on this, like short books, 60-70 pages. Because people who don’t have goals don’t get so far away. So you need to have some kind of goals to get to somewhere. So this is like in the most shortest explanation of how I see developer productivity in this part.

Henry Suryawirawan: Wow, I feel like really overloaded with all these productivity tips and hacks, right? So you mentioned a lot of good techniques and tips for us to be more productive. Things vary from, you know, like the get things done, Pomodoro technique, Parkinson’s Law, which I find really, really effective. Sometimes if you just want to make things happen, right, you limit the time, because, you know, the time actually will be the factor how someone actually completes the work. Of course, you don’t give like a very unrealistic time, but sometimes by giving a much more aggressive timeline, things get done much, much faster, right?

And we all like to procrastinate as a human, right? And the other thing is I find…

Milan Milanović: Deadlines here are a really good solution. So adding deadlines to things are really good. Or timeboxing things also works very good.

Henry Suryawirawan: Yeah. And also another thing that I find, like, despite so many productivity things that are happening around the world, right, with so many research and maybe people who are following those things. You need to find one that suits you best, right? Because there’s no one productivity technique that works best for everyone. So for example, like sometimes I do want to procrastinate or sometimes I don’t follow get things done simply because there are too many things that I need to do, in order to get, you know, the framework going, right? So I think the key for us here also is to find one that works for us. Don’t be afraid to experiment and maybe give it a try. But sometimes, you know, you might find your own productivity hacks that probably you should share to other people as well. So I think that’s one thing that I learned throughout my journey.

[00:48:53] 3 Tech Lead Wisdom

Henry Suryawirawan: So Dr. Milan, thank you so much for all the things that you have shared. We have come to the end of our conversation. I have one last question for you, which I’d like to check with you to share what I call the three technical leadership wisdom. So from all the things that you have shared, maybe if you can condense into three different advice, what would that be?

Milan Milanović: Yeah, before that, I would like, because I’m, I’m actually doing a lot of education. I mean, I, I see this like writing newsletter, writing on social network, as some kind of education. And in our world, there is a lot of like new joiners, newcomers who are just learning. I want like to share one wisdom for them. For all of guys, like who will be tomorrow with us or who are maybe today are also working with us. There are two most important things is like to learn how to get shit done. So how to finish something. And the other thing is to always try to under promise and over deliver. So this is, this is also very important. With these two things, you can be in really, really good position after sometime.

Regarding some kind of a broader leadership wisdom that we can, uh, share. Like the first thing is to always try to align technology with business. As we said, like this customer centricity is really good. We want always to see, to try to understand business, business requirements, and then to decide on technology. What is so many times that we just like jump on some hot fancy technology? I’m in the club of those guys who said like choose boring, boring technology. And okay, we need to be updated on latest trends. We need to know what’s happening. Maybe there is something really new and good that we can use and that will empower us and make us efficient, but always try to critically think about them. Do we really need this? Or maybe we can really, we can work with the things that we already have. Is this the effect that we want to achieve?

The other important lesson is maybe, I mean, people are the most important part, as we said, of everything, not technology. So as a tech leader, our primary responsibility is to enable our team members to excel, to be that leverage. So try to always empower them in the right way to delegate responsibilities and to trust them. To allow them to work in a psychological safe way, and that they can, like, experiment and fail, and they’re like are happy with the place where they work.

And what is here important, there is some, uh, book by Daniel Pink called Drive, which said like, people need to have autonomy, mastery, and purpose to be really satisfied with their job. So autonomy, don’t micromanage them. Purpose, they need to have some kind of a high purpose. And this is what we see in product companies. Product companies have really good vision and some purpose we want to achieve. And when people see that they are really part of that purpose, they feel much, much more motivated. And of course, mastery. People in our industry like to learn stuff, like to be expert and good in this stuff. And just, we want to enable them. We can enable them in different ways how they can learn stuff. Send them to conferences, buy them books, enable them to learn. Give them stretch roles. There are many, many ways how we can do this.

And the last thing is I want to emphasize, we need to like enable this culture of continuous learning. So our technology evolves daily. So we need to to be able to track those trends and to like develop necessary skills where they are needed. We cannot be like blind to all of this stuff. Of course, as we said, we need to be careful not to jump on things. But we want to enable our people to have the touch with the latest technology and that we know how this maybe can help us tomorrow.

Henry Suryawirawan: Wow. So I think the last one really important for all the leaders, right? The managers who listen to this podcast, right? So definitely great things to be conscious about, right? So enable your people. You know, give psychological safety for them to experiment. Allow them to learn as well, right? So I think really, really great.

So for people who would like to follow you or maybe check out your work, right, and stuff. Maybe is there a place that you would recommend them to find you online?

Milan Milanović: Exactly. They can check my newsletter, Tech World with Milan newsletter. I also write on social networks and some other places. But I tend to move all of the like stuff that have the most traction and which is the most quality to, to my newsletter currently, which is free to read. So anyone can subscribe if interested in all this and some other topics.

Henry Suryawirawan: Right, so I’ll put it in the show notes as well. So Dr. Milan, thank you so much for sharing all these things. I hope this conversation can inspire a lot of engineers to become better at their craft, to become a better and productive engineer as well, and produce high quality engineering at the end of the day, right? So thank you so much for this sharing, Dr. Milan.

Milan Milanović: Thank you for the invitation. And I also hope that this will impact some people to become better at their careers and their lives.

– End –