‘Elevating Developer Experience And Driving Continuous Performance’ with Tobias Mende, Founder Of Unblocked Engineering

Kovid Batra: Hi everyone. This is Kovid, your host at ‘Beyond the Code’ by Typo. Today on our show, we have a special guest who is really adventurous and interesting, Tobias. He’s a founder of a DevEx consultation firm, ‘Unblocked Engineering’. He’s the author of ‘DevEx Nuggets’, which is a very famous newsletter, which I personally like. He has 10 years of experience in software development and leading dev teams. And on top of that, he loves to travel, he’s humorous and loves to drink whiskey. And, so do I. Welcome to the show. 

Tobias Mende: Hi, Kovid. Pleasure to be here. 

Kovid Batra: Alright, Tobias. So, you’re aware of the format, I hope. We’ll have a quick fireside chat with you wherein we’ll get to know about you personally apart from work, and then we’ll have another section where we’ll be discussing about how to elevate developer experience and drive performance in engineering teams. We know that you have experience in driving developer experience because you had created a platform in your previous organization to improve developer productivity by impacting the developer experience. So, we’ll be talking more around that in the main section. And, before that, I would just move on to a fireside chat if you’re ready.

Can we go? 

Tobias Mende: Yes, sure. 

Kovid Batra: Great. Alright. So the first question is, where do you get your daily dose of learning?

Tobias Mende: I’m mostly on LinkedIn at the moment. I’m following a couple of really great content creators. I have subscribed to some newsletters there. So, I get a lot of articles every morning. And in general, I do a lot of reading.

Kovid Batra: Great. I think LinkedIn has become a learning source for a lot of people. Most of my learning also these days is happening on LinkedIn itself. 

Great. Next question. What is your preferred mode of learning? So, people do it with experiments. People do it with an online course. What’s your preference? 

Tobias Mende: Usually a lot of trial and error. I’m definitely a hands-on person. I like to experiment. And, that’s usually how I understand things the best. I might, like, join a small online course before I skim through some tutorials briefly, but then I need to try things out. 

Kovid Batra: Cool. I think hands-on experience is something that really gives that dent in your head, where you learn something. Just doing an online course won’t really help. So yeah, it makes sense. Doing some theoretical learning is great. But then, some experimentation is definitely needed to learn something in a better manner.

Okay, the next question. Can you describe your feeling in one word when your code really works?

Tobias Mende: Yeah, I would say when the code finally works, that I’m definitely, I’m satisfied. 

Kovid Batra: Cool. And, this is something I wanted to know, which one’s your favorite brand when it comes to whiskey? 

Tobias Mende: Oh, I like Mackmyra, which is a Swedish scotch actually, which is quite interesting and really has nice flavors. And they have one that’s called Vinterglod, which is tasting a little bit like mulled wine from the Christmas market, which I, coming from Germany, definitely like. 

Kovid Batra: I think I got to learn a lot more things from you than just engineering and leadership. 

Alright. Alright. So, moving on to the main section where we talk about developer experience, leading high-performance teams. This is your area of expertise, but before jumping onto that, you have been into the engineering space from last almost 10+ years. You have been a software developer, senior software developer, tech lead, a DevEx expert, and a founder of a consultation firm now. So, this is quite a journey. And, you have seen a lot of different working styles, different teams. What I want to understand from you is, there have been multiple challenges that you have seen in different teams; give me a few of those experiences where you were into a situation, you faced the challenge and then you actually overcame it. 

Tobias Mende: Great question! So, there are a lot of different challenges, of course, as you can imagine. So, for example, one time I was working with a team of tech leads who were collecting technical risks and, technical debt inside of the system, but had challenges to communicate those to other stakeholders in the business. And therefore, it was always a challenge for them to get time and people to work on those technical risks and adapt and removing those. So, what we did there was, first collecting everything that the tech leads had in their head of risks and opportunities, and weighing them according to how much impact would it have and how much effort is needed, on kind of a diagram to visualize that, and then we prioritized that based on that diagram. And then, I coached tech leads and we worked actually together on making clear what is the business impact behind that and communicating those technical initiatives in a way that business people or non-technical people could really understand why is it so important, because sometimes tech leads and engineers in general are really great at finding the risks and the technical things that need to be done, but they are sometimes not that great at communicating those in terms of money and business value. So, once we got that done, it got much easier to plan them alongside all the feature ideas and initiatives that we had from product management. That was one challenge. Also, maybe a bit more related to developer experience, in the last company, when I joined the company, they did not have continuous deployments, even though it was a quite modern company. And what was even worse was that there was a handover in the deployment process from developers to QA engineers, who then did the manual testing, the automated testing, and ultimately, the deployment. So, that caused a lot of pressure on that QA team. And also of course, a very long feedback loop for the engineers. And, in order to shift that to a more continuous approach, people first need to understand why this is a problem, and they need to feel the problem. And at that point, the engineers were okay with not having that direct feedback because they didn’t need to deal with deployments. But once we changed that, they realized how messy the process was. And, that helped us, first of all, to get the pain to the people who should experience the deployments, how that is, the engineers. But also, the benefit was that the engineers contributed too, with their ideas, how to improve the process. And they asked a lot of questions on the process, “Why are we doing this step?” “Why are we doing that step?” And through that, we were able to automate and improve the process, remove some parts completely, and then arrive at continuous deployments, eventually with like 15 teams and 60 people, who then also understood what the benefit of that is. And, even though people were skeptical in the beginning, in the end, they were very happy that we arrived at that part, because it was better than they could have imagined in the first place.

So, that was something really cool. 

Kovid Batra: That sounds interesting. On the first experience that you shared, I think having a clarity on what is the outcome of any work that you’re doing as an engineer is very important. And there is no denial, a lot of teams face this challenge. Even the tech leads are sometimes not that well subconsciously aligned with what the outcomes are. And, that is what is much needed when you are working on something. So, it is very important. I want to ask a follow-up question on that. How exactly you communicated it? Was this through standups, meetings? What is the channel you use? Because, I want to communicate real actionables. I want people who are hearing this podcast to know, like how to do it.

Tobias Mende: Yeah. So, with the tech leads, we were meeting once a week to get that clarity. And, we worked on a moral board, in a remote setting where we were discussing in a zoom call, basically these topics and refining those. But then, in order to communicate it to the business, we wrote Notion documents where we wrote down, “This is the initiative.” “These are the reasons.” “This is the risk of not doing it.” “This is the risk of doing it.” “This is what we think it will take us.” And then of course, there was some commenting on those documents asynchronously on, “Okay. Could you please clarify what the business value is?”  “Could you clarify if that’s really something that needs to be done now, or if you can push it another quarter?” And then, we had quarterly OKR plannings in that context, in that company. And, we brought those into the OKR plannings. Like the product management would do with their objectives, we brought that in from the technical side as well. Also, to highlight that it doesn’t really matter where the initiatives come from or the objectives, as long as they are aligned with the business goals. Those can be technical objectives, but it could also be, of course, product objectives. And, in the end, we want a stable system, a stable product that will make customers happy in the future. 

Kovid Batra: Absolutely. I think this is one very important point that I have been also discussing with other folks around setting goals for the engineering teams. Even I feel that these goals which are being set up, these objectives which are being set up, of course there are a lot of technical objectives that have to be met, but ultimately whatever they are delivering it’s something that goes out to the customer, they’re using it. So, just like product teams, engineering teams should have common objectives, like NPS, customer satisfaction, retention. All these things are something that even the engineering team should look at when they are delivering something. So yeah, it makes sense. Till the time everything is in line with the business goals, where the objectives, where the initiatives are coming from, it should make sense for the business. 

Alright, moving on to the next question here. While enhancing the developer experience, what’s usually your go-to strategy for identifying, first the bottlenecks, and then eliminating those pain points and the bottlenecks in the development process? You can take one example, and then explain it, so that we have more clarity on how it should be done. 

Tobias Mende: Yeah, okay. So in general, how I do this is by talking with engineers, because developer experience is all about the experience that people have. It can be subjective at times and measurements that we get from metrics like DORA metrics will not give us enough insights on the developer experience. They might show us that we have a problem, but not where exactly the problem is. So, asking people. And, how I usually do this is through surveys because 1-on-1s are great to talk with people and dive deep into some challenges, but it requires that there is a lot of psychological safety and trust in that communication. And, what I recommend to leaders usually is to be careful with that, because as a leader, I might feel very safe and confident in that interaction, but my employee might not feel as safe to tell me what really is a problem, because they might think, “Oh, maybe my leader thinks I’m not capable enough and that’s why I have the problem. So, I rather not tell anything.” But, if you do anonymous surveys, we can ask all kinds of questions around developer experience, for example. Like, “How satisfied are you with the deployment process?” And then, we can have a scale from 1 to 10. 1 is “I’m very unhappy with it.” And, 10 is “I’m absolutely happy with it.” And then, when they click something that is more on the unhappy side, we could add a free text question, “Please tell us a bit more about what bothers you about the deployment process.” And then, people can give also some subjective and qualitative data to that. So, that helps also to get a lot of engineers interviewed, not only the ones that are close to me, because when I’m the leader in an organization, doesn’t matter which role I am in the organization. I have some people who are closer to me and other people I don’t have that much contact. And, we are usually biased towards what the people close to us tell us, or what our own assumptions are. And in 1-on-1s, it’s quite likely that we fall into a confirmation bias, that we just get confirmation for what we already think to know about the developer experience in the organization. 

Kovid Batra: Great. I think that’s a good start for anyone who’s looking at knowing the challenges the developers are going through. But, just to like, bring forth the most common problems; what do you think is the most common pattern, or which are those most common areas that you have seen, the developers are blocked, their experience is dented, and that really requires an improvement? Any, any specific things, any specific patterns that you have seen in the people you have talked to? 

Tobias Mende: Yeah, something that’s quite common usually are problems or blockers in the software development process. This can be that they need to wait too long for code reviews. It can mean that there are flaky tests, flaky automated tests, end-to-end tests, for example. It can also mean that tests take too long or that there are parts that are manually processed, or it can mean that the deployment is done by another team than the team who actually works on the software, so that they have a hand over anything that blocks the software deployment process, between “I commit some code.” to “It runs in production.” That usually is an issue that is quite close to engineers. And, that’s also what engineers are very likely to complain about the first, because they see it on the daily interactions. Some of the things that have usually a much higher impact even, but, a bit more sensitive are things like company culture. “Do I feel safe in the organization?” “Can I collaborate with my peers and communicate freely what I think?” “Can I raise my concerns?” “Do I know how I can influence my environment when I think something isn’t right?” All those things are also important for developer experience and productivity. But usually, less an issue raised first by engineers because many engineers tend to accept the organizational environment as they see it and as they are in that organization, and don’t question how that could be changed. But for leaders, I know that there’s a lot of potential in changing the organization and the culture and the organization to allow for a better developer experience. 

Kovid Batra: Great. I think that was really insightful, and with such kind of services coming into the market, I think it’s already a need. I see a lot of blockers, a lot of things happening. By the way, you mentioned about code review times being high and you might identify that as an issue and then go deep down to understand what exactly lies there. Have you come across any efficient method to identify such problems or is it mostly like, these assessments have to be done or you have to go and talk to them 1-on-1, or you understand these problems first-hand while you’re doing standups and sprint reviews with the team? Have you come across anything of that sort which is more efficient? 

Tobias Mende: I mean there are of course a lot of tools who measure parts of the deployment process from the moment somebody picks a ticket, to the moment it moves to done, and all the stages in between, the ‘merge requests’. “How long are they open?” “How big are they?” There are a lot of tools. The problem is that we can get a lot of data, but without knowing where we suspect a problem, it’s difficult to find that out, because maybe the long code review times aren’t actually an issue for the way how engineers work in the organization for whatever reason. Maybe they don’t care about this, but something else is much more frustrating and we only get that by really asking engineers, “What’s frustrating for you?” And they will tell us. And, the good thing is when we work on what frustrates the engineers, that will improve their experience because they see, “Okay, something that frustrated me before is gone now, and we might get other ideas from metrics.” For example, in the last company, we measured all the big jobs and how long they took with data doc and also had some alerts on certain. It’s increased their build time for an unreasonable amount, just to check, “Okay. Why does this not take twice as long?” “What happened there?” And that helped us of course, to improve things even before somebody noticed, and over time, people were like, “Oh well, this used to take an hour. Now it just takes 10 minutes.” Cool that we have this developer experience team. But, for finding problems in the first case, I find that talking with people or getting kind of surveys out, maybe also automated through tooling, are the most effective ways. 

Kovid Batra: Great. Thank you. I think this really helps bring forth another important point, which I would want to discuss on this podcast. In pursuit of this high performance, teams are sometimes like, there, there is a resistance to change, like they don’t want to go out and change outright, right? So, how do you overcome those resistances, and drive a team culture that is always on a continuous improvement and towards excellence? So, how do you tackle that? 

Tobias Mende: So in general, I think it’s a myth that people are resistant to change in general, because people change things in their life all the time. The difference is that when they do changes in their life, such as getting a child or getting married or any other thing, moving houses, traveling to a place. Those are changes, but why are they not a problem? They are not a problem because people understand why they are doing those changes. So, when we feel resistance in the workplace, then the question is often, “What are people not seeing (why this change is good)?” Maybe they think that the risk of this change is higher than the benefits for them. Maybe they got tired by too many cultural change initiatives in the past that always led to just another culture that has the same problems under different names. All these things are important to understand first.

And then, one thing that I see happens often is when people, leaders normally, see a certain change that they want to see in the company. They communicate that, and why it is a great change and all the numbers and facts and everything to rationalize why this is a great change, but what often completely is missing is the emotional part. We need to connect that to emotions. “How does it feel to work in that new environment after the change?” And, “How does that benefit?” “How would the life look for engineers in that new environment?” And once people can feel that, they are much more likely to support that change because they believe this is actually great for them. I can give a small example. When we introduced the continuous deployments, I already explained a bit about that as an answer to the other question. I showed a slide where I showed them, “Okay, this is the time it takes today from a commit to deployment. And, we have this and this stages and they take this long time.” And I showed them below that, a graph that was only, I think it was roughly a third or a sixth of the usual time. And I told them, “Okay, look, imagine how it would feel if you can get your changes live to production within 20 minutes?” “What would that mean for your database migrations?” “What would that mean for your experiments that you are running with your users?” And so on. And people were like, “Oh, this would be actually quite cool. We don’t need then days anymore to get that life, but we can do it within half a day.” And that was how people got excited, I think. 

Kovid Batra: Right. I think you gave a very good analogy here. Like, when we change in our personal lives, whether it is having a baby, moving places, getting married, whatever, things fall naturally to us that, “Okay, this is going to be good for me.” “This is why I’m doing this.” Right? So here, in the personal space, it’s the culture, it’s the society, your personal happiness, your experience, seeing other people, other couples enjoying their lives; you already have that mindset and believe that, “Okay, all this is very positively rewarded.” Whereas in companies, in workplaces, usually, I think resistance to change comes in those companies where the culture doesn’t appreciate the change. They do not embrace failures and ask people to improve on them. Like every time, there should be something that is imbibed positively within the company culture around these changes. So, I think that also can bring a lot of ease when you introduce something new to the system and people take it, and then do it and deliver what is needed. So, this is my thought. I was just thinking on what you just said, so. 

Tobias Mende: Yeah. Thank you. Exactly. I mean, the thing is when we focus on developer experience by definition, this is we are caring for the experience of developers and we try to make that better. We are not focusing on performance or making them productive just so that the business can make more money. That is a side effect. A very nice side effect, a very important side effect, but when people truly believe that we care about them and about their experience, their work experience, and that we make it better, then people are far less resistant to the change, because they know, “Okay, the last time the team changed something or the leader changed something for the purpose of improving developer experience. That was awesome. So, give us more of that change. We want more of that.” 

Kovid Batra: Right. Great. I think it was a really, really nice talk. We had a good discussion around developer experience, your experiences, your challenges. So, it’s great. Thank you for sharing the experience and the knowledge here. I would love to have you for another episode, talk more around developer experience because I think that is a topic which would be a complete episode to discuss on. So, all the best for your ventures and all the best for your journey in life.

Tobias Mende: Thank you, Kovid. I really enjoyed the conversation with you. And, yeah, whenever it’s the right time, I’m happy to join again.