‘Achieving Technical Excellence While Mitigating Tech Debt’ with Miroslaw Stanek, PL Engineering Site Lead at Papaya Global

Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host on ‘Beyond the Code’ by Typo. And today with us, we have an amazing guest, Mirek, who is an engineering director at Papaya Global. And he’s an engineering leader, he’s very unique in his own ways. He not only loves engineering sprints, but he also loves marathons. He has recently completed his OCR. 

Welcome, Mirek. Welcome to the show. 

Miroslaw Stanek: Hello, Kovid. Hello everyone. And thank you for having me. Just, you know, small update. I’m not a marathon runner, I’m a trail runner. It’s still, you know, running, but actually I prefer running, you know, uphill and downhill rather than running through city. But, you know, it’s more or less the same.

Kovid Batra: Great. Thanks. I didn’t know about that. The learning has already started. So today, on ‘Beyond the Code’, we have Mirek with us and he is running a newsletter, which I personally love,’ The Practical Management’. I want to give you a kudos for that, Mirek. It’s really nice. I’ve been following it for some time now.

So, keep writing and I really see that passion of writing in you. So please, we need more people like you in the community. 

Miroslaw Stanek: Thank you. Yeah. So, if everyone would like to check, just go to www.practicalengineering.management, where I put all of the things for fresh engineering leaders, tech leaders, engineering managers, and others.

I was there. I know what kind of struggles I need to face. So, I hope I can share some of my experiences to make your professional life better. 

Kovid Batra: Sure. Alright. So, the format of this podcast is, we have a fireside chat with you where we get to know the real Mirek and then we’ll jump onto the main section which talks about your experiences, engineering, how you handle those challenges, and how you improved on those.

So we’ll move on to that, but a quick fireside before that. Are you ready? 

Miroslaw Stanek: Yeah! I am. 

Kovid Batra: Alright. Alright, Mirek. So, the first question, it’s something related to reading and books. So, if there is one book that you would want to recommend to all the engineering leaders, what it would be and why? 

Miroslaw Stanek: This is actually quite hard question. If I have to pick only one book, I would say it’s ‘Empowered’. It’s written for product managers and product people, but actually it states that engineers, engineering teams are also part of product teams. And, I think that this book explains very clearly what’s your role as an engineer or engineering leader in the product organization. When working with engineers, I trust with the picks for their technical books because they know what are the challenges for them. But, this is the book, which I recommend every single engineer who would like to make great job building, not just the code, but the working product. So yeah, short answer, ‘Empowered’.

Kovid Batra: Great! Alright, moving on to the next one. Do you prefer to jot down your thoughts old-school style with paper and pen, or you embrace the digital era?

Miroslaw Stanek: You know, I think that we can have like another episode only on the notes taking because I don’t have the clear answer here. I like writing in both ways, either with pen and paper, and digitally. It all depends on the context. So, for example, I use note-taking apps. The one I use most often is Obsidian. It’s a note-taking app, which you can, you know, write and mark down. You can have tagging, you can somehow connect the notes. It’s great syncing across different devices. So, basically Obsidian is a place where I put like everything, my daily notes, my notes from work, my ideas, drafts of the blog posts, and tons of others. I love it. I love doing notes in this way because basically, you can use search, for example. If you work on something which actually you touched half a year ago, you just go to search and you can find your note. So, this is why I like using the digital notes.

But, it doesn’t always work perfectly. For example, if I have meetings with people, I prefer not having my laptop during the meeting, if I don’t have to have it. I prefer to make notes on paper, because I don’t want to have this wall between, you know, me and the person I’m talking to. I don’t want to have distractors. I don’t want to have even the screen shining on me or the notifications or anything. Also, I read some interesting scientific papers and actually when you write your notes with pen and paper, it actually puts the thoughts your memory and it roots there. So it’s easier to remember what you were talking about. Also, for me, it’s faster to write, you know, handwritten notes than write something on the keyboard. So, yeah, like I said, no simple answer for the simple question.

Kovid Batra: No, no, it definitely makes sense. I am one of the users of the tool. We are using it for our platform, for typo help docs. We use that. And in general, I really feel the benefit of having something published over multiple devices. Wherever you are, you can update it for yourself. You can share it with them. So yeah, that way is very very productive and helpful. And of course, sometimes you just don’t want to have that barrier of a digital thing in between human and then, paper and pen works best for us. So, totally I think it’s a balanced approach for most of the people. 

Miroslaw Stanek: Yeah, definitely.

Kovid Batra: Moving on to the next one. So again, coming to one of your interests, tech and run, right? This is a match which is unique and made in heaven, I think so. So, what is your motivation? Like, what is your mantra of life that fuels you?

Miroslaw Stanek: Yeah. So, there are a few aspects of that. First of all, it’s like very, very practical, because what I’m publishing on social media, for example, you know, photos from my latest trail runs or obstacle races. It’s kind of the end of the story. And this story begins with me having quite big issues with my health. Basically, two or three years ago, I could barely walk because of the problems with my spine. Why? Different reasons. I had the injury, but also I’m the engineer. So, I spend most of my time sitting. So, the practical thing here is that you need to stay healthy physically. You need to do something. It can be running, swimming, or just moving. Currently, when we are talking, actually I’m using the standing desk.  Yeah. so, we need to find the ways to keep you moving, yeah? But apart from that, because you know, there are like tens or hundreds of different sports which you can pick. For me, obstacle race is something which there’s always the next level like I can reach, you know. I remember watching races, a year or two years ago and was like, “Oh my God, what are those people?”  “How they can do this?”, and today I’m one of those people. What motivates me to that is, mantra, I would say, is, you know, just dream big. Everyone says dream big, but the next thing is make a plan. So, to make your dreams happen, you need to find ways how to make the small steps to accomplish that. And if you have a plan, don’t think about the motivation, but rather about being disciplined, because motivation is when you’re watching those people running and you would like to be like them. Yeah, so this is the motivation. But, when I wake up at 5 a.m. in the morning, I don’t care about that. I’m not motivated at all, to be completely honest. But, I’m kind of disciplined to go to this training like three times a week. It’s not pleasant at the very beginning, that’s why you need to enable your discipline, and motivation comes later. So, this is my kind of mantra for how to make this thing happen. 

Kovid Batra: One great investor here from India. He runs a very big fund. He mentioned one very great thing recently I came across related to discipline. So, he said, “Anyone who lives life successfully has to be disciplined.”  So, living life successfully means you have to be healthy. You have to be mentally healthy, physically healthy, and achieve a lot of professional goals, personal goals. And, I also have started feeling it very recently that discipline is at the core of everything. When you’re young, when you’re a kid, school teaches you all that. But, I think at that time, people really don’t perceive it so strongly as we do when we reach this point in life. So, it is very important to keep yourself involved in some physical activities, some sports to be healthy and keep going. 

Miroslaw Stanek: Definitely. Yeah. 

Kovid Batra: I think let’s move to the main section wherein we’ll be talking about the technical excellence while managing architectural debt. So, this is something that is very cool to you. But before we move on to this topic, I specifically wanted to talk about very basic things, core to your journey. Wherein, I want to understand, there have been a lot of challenges that you might have come across during your engineering journey, right? You’re an engineering director at the company, but whatever challenges you have faced as a leader throughout your journey, can you just put a light on some of the key events which you came across and how did you overcome them?

Miroslaw Stanek: So, you’re asking about the key challenges which I faced during my journey? The one that I’ve been facing all the time is connecting the world of product and the world of the technology. From the technical perspective, there is always something you can do. There is another library that you can do some refactoring. You can increase, I don’t know, the testing coverage, whatever. You can hire a big number of people and you won’t accomplish that. So, the important thing is to be sure that no matter if you are the engineer, I mean, the individual contributor or the leader or director, you need to be sure that you do things in order to satisfy your customers. You build features, not just the code, and it touches many areas. Technical debt is one of them. So, I think we’ll go into details into that. Saying no to some particular activities. So, for example, you would like to migrate from one container solution to another one, only because you heard that today everyone is using Kubernetes, and you would like to use it. Yeah, of course you can do this. It’ll take you, you know, a few weeks, few months, depending on where you are with the company. But in the end, you need to understand, “Okay, what’s the real value for the product you built?” Maybe it will be better scalability, better maintainability, or maybe it will bring you some other challenges which will keep you from providing the real value. So, this is the challenge I’ve been facing on every stage of my career. Either when I was, you know, writing the code or leading the team. It was always easy to find something fun to do, but it was harder to find something which is both fun and useful. 

Kovid Batra: By talking to other engineering leaders during the podcast and otherwise outside of the series, I think this has been popping up again and again, like the connect between the product and the engineering that the engineers do. So, the purpose of doing something is something that should always be instilled while you are working as an engineer. So, it makes a lot of sense what you are saying. But, any specific advice on how we can instill it in the engineers? Because when everyone is talking about it, I feel it doesn’t come naturally to the engineers, at least for a lot of them. So, what do you think worked out well for you when you faced this challenge and you tried to solve it? Any practical advice there? 

Miroslaw Stanek: So, I would say having clarity on the outcomes of your work. I think this is the extremely important thing. So let’s say, you have a project and the deadline is, I don’t know, December 1st, yeah? So, you have two, three months to finish that. And, this is the only message you give to the team. Team is like super focused on delivering feature to production. Period. Yeah? So, you know, November 30th, you launched production. December 1st, your goal is achieved. End of story. And actually, it’s not the end of story for the product. Maybe it’s the end of story for the, you know, very first launch production, but not for the product, because actually, on the December 1st, it’s the very first time when your product reaches your customers. So, this is the moment when you need to understand what’s the stability of it, what’s the adoption, what’s the feedback of customers, what are the biggest struggles and everything. So, you know, if you focus people only on delivering on the deadline, they will put all of the energy and attention into making it happen. And on December 1st, they will be exhausted. While actually you need to be sure that on the December 1st, they are in shape because they should wait for the feedback. They should, you know, continue working. They should continue improving the product. So, months later they can celebrate success. First customers, first paid customers, first conversion, new market open, increased conversion of something. And, if you tell people, “Okay, deadline is important because marketing team is waiting for this deadline.”, “Few other things are waiting for this deadline.” But, the most important thing is, “What’s the value you generate for customers?”, and this is what you should focus on. And how I do that in practice? I try to bring as much data as possible. So, for example, if your work is to enable new market, for example, I’m asking to create a simple chart, which shows me how many new customers signed up in a given country, for example. Another project, if you would like to increase the conversion of your login flow. I’m asking for another dashboard to show you, “Okay, what’s the current conversion?” “How many people open the app or open the website?”, and “How many of them land on the main page after logging in?” And, we can see the percentage. And then I say to people, “Okay, your goal is to increase this conversion by this or that percent, and this will be our success. I don’t care if you release that, you know, this week, next week, this is just first step. I do care what we’ll achieve as the outcome of your work.” 

Kovid Batra: Yeah, this is really, really helpful, Mirek, because accompanying product and engineering goals together would really bring a big change in the mindset how engineers operate. As a product manager, my goal for a particular release is to have that conversion or that retention, right? Whereas for engineers, that doesn’t come directly. But, if the same goals are set up, same key results are set up, then of course, we can see that change, and engineers can also start thinking in the direction of an outcome-based deliverable, not just delivering something. So, it makes a lot of sense. And thank you for this. This really is a practical advice which resonates with your newsletter name also.

Perfect. Moving on to the next question in your area of expertise, which is bringing the technical excellence while managing the architectural debt. So, how do you collaborate the CTOs and VPs to address the existing architectural debt while ensuring that you’re delivering new projects also, right? So, at that time, this is the hardest call to take, I feel, that what to do right now. Whether you’re a startup, or let’s say, a mid-sized company, somewhere or the other, you have this question and how to take a call on that. I would love to hear your thoughts, your experience on this. 

Miroslaw Stanek: Yeah. So, when it comes to addressing tech debt, I think that we need to make, you know, a few steps back, and tell very clearly what the tech debt is, yeah? Because let’s say we have monolithic systems. Is that the tech debt? Sometimes it is, because it blocks the multiple teams working on a single product. Sometimes it is not, because if you are a startup and you have only one engineering team, like let’s say three engineers in the company, actually it’s beneficial for them to have a monolithic system, because they can go live very quickly, they have like a single monitoring system and everything, yeah?

So, first of all, what’s a tech debt, yeah? I would say that tech debt is, it’s something what stops you from reaching your product or business goals. And obviously, some companies are more major than others. In some companies, you have, you know, KPIs or OKRs, like very clear information, what you would like to achieve. In others, you know, fresh startups, you’re still, finding this product-market fit, pivoting a lot. 

So, when thinking about what’s the high-level goal here is that there are four essential things all of the businesses or product companies to succeed. One is growth. Another one is expansion. The third one is customer satisfaction. And the fourth one is profitability.  If you understand what’s your current goal. For example, if you do optimization of the login funnel, it’s probably something about growth. If you fix some of the most common problems of your customers, it’s probably customer satisfaction. If you are, I don’t know, migrating from one database to another because of the optimization, probably it is about profitability. If you open your app to another market, another continent, probably it’s about expansion. And if you have this in mind, you can identify, “Okay, what are the biggest obstacles in order to, for example, launch our product?” Let’s say, you are a European company, “What’s the biggest obstacle to launch your product in Asia, to launch your product in the U.S.?” And if you know that, it’s easier to identify what are the moving parts, in terms of, you know, software architecture, for example. Which of the things should be generalized enough so you can start launching to other countries? For example, let’s say you have the sign-up flow, yeah? And, in one country, you just take the name, and first name and last name. In another country, you need to take, I don’t know, the postal code because of compliance rules. Which means, that your sign-up flow needs to be more generic, which gives you some idea that, “Okay, this part probably needs to be quite dynamic.” You need to bring dynamic configuration, whatever. While other parts, a particular screen, like, showing you something. This can be static for all of the countries. So, maybe it’s not the right time to generalize this kind of domain. So, if you have clarity here, you can tell your management, “Okay, if we would like to launch to another country, maybe we can use our current infrastructure, but if we are planning to launch to another 10 countries, those are the moving parts we need to optimize, the technical debt we need to fix, the domain we need to extract, whatever, in order to reach our business goals.” If we want to increase customer satisfaction, we need to invest more in one, bug fixing, but another one may be better SDLC. So, we reintroduce less bug fixes. If we would like to increase the growth of the company, maybe we need to optimize some things. And, what means optimizing? Probably it means launching to production like every day, every week, whatever, yeah? So, you can do quick experimentation. If your SDLC doesn’t help you with launching like every day, this is tech debt, because your company cannot, you know, iterate quickly over the product. 

Kovid Batra: What I understood is that there could be different situations where you have to like, evaluate multiple moving parts and then take a call on how you should move forward, so that you don’t end up creating more technical debt or whether you should handle technical debt right now or just focus on time to market first. One thing that I felt is that it is always, or it should always be driven from the business goals. Like, technical debt, first thing when you’re thinking, “What is your business goal?” And then move on to the next step of thinking what you need to move in your system. So like, maybe clear the technical debt, or maybe at that point you should not care about it much. Just focus on launching for that particular country and that would be sufficient for now. Like, move fast there. Yeah. That’s great insight. 

Perfect. A follow-up question on this. So, this is something when you are in a position where you have to like take a call, like whether to handle it or not. But, when you’re building something, at that point, engineers are writing code, which could be optimized or highly optimized or not at all optimized. What things should be taken care while building things in general, to not have a lot of technical debt for the future?

Miroslaw Stanek: Well, you know, it would be good to know what’s the kind of long-term roadmap for the company, because it will give you at least some clarity. “What are the important technical things, which not addressed now will block us in the future?” But it’s not easy, yeah? Especially early, the startup. They simply don’t know. They don’t know what they will do in next three years. They can have vision, mission and all of the values, but market will check it anyway. I think that another good thing to keep in mind is that one of the book I mentioned is ‘Accelerate’, it’s a set of good practices, mostly in software delivery processes. And, you know, it is with us for quite a long time. And simply there are good practices which we should follow rather than reinventing the wheel. Just see what are the recommendations for the biggest, most successful companies and those recommendations are, how fast you can deploy to production. Because it will tell you how fast we can iterate over product. If you cannot deploy to production every day, I think this can be the sign of the technical debt. And I’m not telling you that this has to be your goal. Your goal should come from product, and being able to deliver like every day is just kind of tool for reaching your goals.

So, rather than telling, “This is our goal to release every day and let’s say in a half a year from now, I would like to see you guys launching every day”, I prefer checking if we can release every day, if our SDLC process is capable of doing that. So, I don’t care if you release like 50 times this month. I do care if this is possible to release when it’s needed, yeah? So, there you have weeks in which you will release like 20 times a week and you will have weeks when you release just one thing, because this is how it is. And I would focus on this, yeah? Releasing very quickly. Automate as much as possible. So, don’t do manual work at all or very little, including testing, for example. Obviously, you need to also try your, you know, core metrics, the usage, the cost of your infrastructure, so you can see how it goes up or down. And yeah, I think it should give you some early indicators in order to learn where is the technical debt of yours.

Kovid Batra: This is a suggestion. This is an interesting topic actually and it can take a few more questions for me to understand and for audience to understand what calls to take when. Can you write something in your newsletter about this, like particularly this topic? In startups, “What to do?”, “What are the best practices to not let any technical debt accumulate over a period of time and simultaneously managing to deliver fast?” That’s just a recommendation because I find it very interesting. 

Miroslaw Stanek: Oh, yeah, I really love feedback. So, thank you for that. For sure. I will. I will try to write something about it.

Kovid Batra: Great. Thank you. And, moving on to the last question of this episode. As an engineering leader, you face a lot of challenges, but one thing that remains common in a lot of teams, which I would definitely want to understand from your experiences that how do you instill a sense of ownership and collaboration within your engineering teams so that they’re always growing and they’re doing that continuous improvement? How do you build that culture?

Miroslaw Stanek: It’s a good question. If you want people, teams to own something, you need to be very, very clear about what does it mean. So, I put a lot of effort, especially now when I’m the director of engineering and I’m not doing the day-to-day code, I try to bring as much clarity and transparency as possible. So, one of the things is obviously being transparent about how we are doing as a business, what are the core things discussed by management, and so on. Those are like less technical things, but I also try to bring as much data as possible, either from the product, which I mentioned earlier. So, conversions, number of customers, maybe number of issues, but also, technicalities. Because, let’s say I tell people, “You own the quality of your product.” What does it really mean, the quality of the product? Some people will care only about the quality of the code, the performance of the code. Others will care about the full picture and number of bugs, especially the ones faced by customers. So, I try to bring those numbers to light. And I try to discuss them as often as possible. So, if I talk to the team responsible for, let’s say, the website. I try to discuss, “Okay, what’s the crash rate?”, for example. “What are the errors in console?” “What are the issues with the performance?” And by discussing that, I’m also presenting, “Okay, what are the practical aspects of the ownership which I expect from you?” So, this is one side of the ownership. Another one, it also touches the transparency and the clarity. It’s celebrating small accomplishments, because very often, especially if you are like super busy in delivering feature after feature, you don’t have time to stop. So, you have no idea if you did a great job. So, depending on the situation, I do a few different things. So, for example, I write monthly newsletters to the entire company or the entire product organization, which highlights, “Okay, in this month, we achieved this and that. We achieved those product goals, but we also built this part of architecture.” “We implemented this technical thing”, and so on. I try to approach as many people as possible and tell them clearly, “Okay, you did great presentation on performance testing. Thank you for that, because thanks to you, others will know or will have some kind of inspiration how they can do this.” And by that, by simply saying “thank you” and “great job”, you’re showing people, “Okay, this is a very important thing.”  And, I think that you need to do this quite often, either publicly or on one-on-ones, you need to keep reminding people what’s important. You know, when you have CEO or CTO, they often focus on the mission and the vision of the company. It is important because this is something which gathers all of us, the employees of the company, under one goal, but sometimes it’s hard to capture that, especially if you are individual contributor. if you, for example, write the pieces of the infrastructure or you do the database optimization, it’s quite blurry to understand how your work commits to the 5, 10 years vision from CEO.

So, my job or job for every single engineering leader is to ensure that every single person knows how his or her work connects to this high-level vision, and you need to do this as often as possible, to keep reminding people why their work is important.

Kovid Batra: Totally. I totally feel that and bringing transparency, bringing clarity on what they are doing and how things are moving around that, setting up the right goals, celebrating the outcomes. I think all of this makes a lot of sense when you connect it. And, one thing that I feel is that it should be done very often. 

Miroslaw Stanek: Exactly. 

Kovid Batra: You’re doing your work. You actually tend to lose the bigger goal, the vision, and you really don’t connect to what you’re exactly doing. As you mentioned, if you’re doing some infrastructure change, then you don’t know how it is contributing to the mission which was mentioned by the CEO in the last meeting. So, it is the job of the engineering leaders and the engineering managers to come in and communicate that and celebrate every small achievement that contributes to the journey. 

Miroslaw Stanek: I would say like one thing for every single engineering leader, if it feels weird to tell your people, “Great job, thank you.”, you need to do much, much more often, until it feels natural for you. And people don’t look at you like, okay, we’ve some kind of, you know, suspicious, okay, what this guy wants from me.

Kovid Batra: I read one of your newsletter issues, which mentioned about having frequent one-on-ones and I couldn’t get a sense of this, that this is in the DNA of the engineers, probably, or the engineering leaders, that they’re kind of introvert, right? They really don’t open up easily. It might not be true for a lot of them, but I feel that comes in the DNA of an engineer. We’re sitting in front of a laptop, 10 years of coding and then suddenly you’re meeting people. It seems a little weird. It becomes difficult. It’s, it’s a barrier. Right? 

Miroslaw Stanek: Exactly. 

Kovid Batra: And I think, the engineering community will embrace this and they’ll learn and probably have better teams and better culture of continuous improvement. 

Great, Mirek. I think that was a great session. A lot to learn. Looking forward to more newsletter issues from you. Thank you so much. Have a great day. 

Miroslaw Stanek: Thank you, Kovid. Thanks for having me and yeah, have a great day to everyone who is listening to this.