EP064 - How to lead remote engineering teams with Tobias Mende at Unblocked Engineering
About the episode
This episode focuses on leadership in engineering teams in a distributed environment. Working with developers and integrating them with other company parts can be challenging. In a remote setup, the basic principles of daily standups, meetings, and coding might not work or would work differently. To discuss these challenges and possible solutions, Tobias Mende, who has led remote engineering teams for years, joins the talk.
About the guest
Tobias Mende is a software engineer, architect, tech lead, and product lead. He is the founder of unblocked.engineering, a consultancy for organizational development, engineering leadership, and developer experience focusing on remote companies.
Since he started his journey in software engineering over 20 years ago, he was naturally attracted by challenges around improving the workplace, improving the developer experience, and productivity as a side-effect. This made him dive into leadership, company culture, and organizational development. He sincerely believes that happy people do better work and that there isn't a conflict between people, purpose, and profit.
He is also the author of "DevEx Nuggets," a weekly newsletter on developer experience and engineering leadership.
Connect with Tobias on LinkedIn.
About the host
My name is Peter Benei, founder of Anywhere Consulting. My mission is to help and inspire a community of remote leaders who can bring more autonomy, transparency, and leverage to their businesses, ultimately empowering their colleagues to be happier, more independent, and more self-conscious.
Connect with me on LinkedIn.
Want to become a guest on the show? Contact me here.
-
Welcome, everyone. Welcome to the Leadership Anywhere podcast. Today, we will discuss a much important topic, which is rarely discussed in that sense that we will discuss today. We are talking about developers and engineers but not in the sense that how to find the talent, how to find and attract the best developers and engineers to your team to your company, but rather than how to integrate them and how to work with them, how to provide a productive culture that is beneficial for both the company and both the teams of the engineers. To discuss, I have Tobias Mende with me. Hi, Tobias.
Peter. Happy to be here.
Lovely, lovely that you are here and thank you for your time. Please. Tell me a little bit more about yourself. I know precall we discussed that you are originally from Germany, but right now you're calling from Pisa in Italy. And you're living a nomad life and also working with engineers a lot. Tell me the whole journey. How did you end up here?
Yeah, I started my journey as a software engineer probably 20 years ago during school when I started to work for smaller clients. Eventually, I went into computer science because I thought that I will learn how to properly develop software. Spoiler, I didn't learn it there, but I learned it on the side projects. And I learned it in my first job, of course. And throughout that, I always was also in a leadership position, sometimes officially, sometimes not officially, sometimes as the most experienced engineer on the team, sometimes as the tech lead or product lead. And I eventually went into a remote company or into a company that wasn't remote, but where I was starting the first remote software team that was 2018. And from that moment on, I had the opportunity to work from everywhere I wanted. And I gave up my apartment in Germany in winter 2019 after an inspiring stay in South Africa. And I realized that I'm so much more productive when the sun is shining. And since then, I already spent a winter in Germany then I moved on to a full remote company and worked there as the tech and product lead for a developer experience team that had the goal to improve experience and productivity of other engineering teams. And then finally beginning of this year, I did the jump to full freelancing as a consultant and coach for engineering leaders who want to improve the experience for their teams, have less stress and more joy with developing software.
This is a really nice journey, by the way, where did you come from? From originally from Germany.
Originally, I'm from the north where winters are the worst because rain and snow. I'm from Lübeck close to the Baltic Sea. We have rain and snow, but no mountains. The snow is completely useless there. And that's why I had to leave.
I completely understand. So it's not something like Bavaria or something.
Yeah. Yeah. Yeah.
Totally get it. Cool. This is a really nice journey. And by the way, just one thing that I wanted to highlight that you are one of the few people from most of the guests on this show, they already started their remote working journey before the pandemic. Most of the people in general they started the remote work journey during or after the pandemic. And you started way before that. So that's great.
2018 already. Yes.
Yeah. So now you are working with development teams and previously you were product lead and developer team lead for other companies. Let's throw up the ball. What do you think what are the biggest challenges within a development team if they are working remotely and if they are working with other teams as well. So not just development teams?
So the challenges depend completely on the company and how the company understands software development. So software development for me works best when we are working in a cross functional team and when we can own a value stream end to end, when we can own it from a customer as an idea to recreate customer value in that team, and we don't depend too much on other teams, but when we have everybody we need, and that might include people from sales, and that might include people from marketing on the team and we can collaborate closely. So that then it works best, but often the reality is quite different. We have some people in the front, maybe some marketing customer success people who have an idea of what the customers need, they put it into a gyro ticket, and eventually a product manager comes with that ticket or that idea to the development team and then the development team should build it just to hand it over to a QA team or an operations team that then brings it into production. And that's a pain for everybody involved. It's a pain for the developers because they don't know anymore why they are implementing it. And when they see a better way of implementing it, they don't know how to communicate that to the people who came up with the idea in the first place. It's also a pain for the product managers and customer success people, because in the end they often find what the developers build is not what they really wanted. And it was also a pain because nobody really knows when it comes out and when we create the value and the feedback loop until it gets back to the engineers if what they build actually serves the customer is way too long. Reducing this feedback loop is also one of the biggest factors for developer experience. And with that also productivity of engineers, because it is so much more satisfying when you know what we build actually matters and we get feedback from real customers, how they use it, where it doesn't fulfill their needs and where we can maybe deliver the next increment to improve the experience of customers.
I agree with everything that you said. Let me ask a controversial question because I also work with a lot of... so my main clientele is B2B tech. And that's why usually I work with companies where half of the team is comprised by engineers and developers. And the rest of the team is everyone else. And it's really hard to work with this kind of a dual system within a company because the most important problem I think is that, and that's a question, should every engineer be aware of the customer needs of every feature that they are developing, or should it come from only the team leads or the senior engineers? Because sometimes what I felt is that the junior engineer developer who is working on just that simple little feature within the product roadmap, they don't really care too much about the product in general, in the larger sense, right? And from the customer as well usually the team lead is the one, the most senior engineer, usually who is armed with all of those skills, for example, communication, feedback, sometimes even user experience, and some kind of feedback loop from the other team members, like marketing sales and others. So should it be like developer wide, like every developer should have or own these skills or only the leaders or the managers of the teams?
Great question. Let me answer one by one. So the first thing is I think it should not only be the manager or a team lead who is responsible for this because that creates a huge knowledge silo and a huge bottleneck in that one person. And when they're on vacation or when they leave the company or when they are unavailable, people are stuck. The more people can do this on a team, the better the team works. It's redundancy in the end that more people can do that. And also discussing an idea, a problem space and the potential solutions to that in the team with more than just one engineer leads to better solutions because people can ask questions and we ensure that we find better solutions together and have a like creative space where the team comes up with a solution for something and we also ensure in that process that everybody understands why we are doing it. Of course a junior engineer might be okay with just developing I don't know, front end without really understanding why they are doing it, because that's maybe enough complexity and interesting enough for them at that moment. But on the other hand, when they don't understand why they are building the front end, they are very likely to go wrong. Because they cannot answer questions themselves, because they have no connection to the customer value that should be built. But if they understand this, it's more meaningful for them to build this. And they see also when for example something isn't specified in a ticket, but they understand why they are doing it and what the purpose is, they can at least make an educated guess or ask somebody else on the team, how to do it. And that's also why I see that this collaboration is so much more valuable than working in isolation on teams, because as the team together, we can find better solutions. We can discuss the problem. We can discuss the solution to the problem and collaborate on evolving it. And that's more, that's much faster when we know why we are actually doing it and what the customer needs. And it reduces the feedback loop again when we don't have this, okay, somebody specifies the problem and then we discuss the problem. Then we find a solution. Then we build the entire solution. Then we give the solution to the customer. And the customer tells us, no, this wasn't the solution to my problem. You misunderstood my problem in the first place. Then we are going back all that cycle. When we work very closely as a team, we can deliver a small increment, like a prototype, an MVP to solve a tiny bit of the problem of the customer. And then we can ask the customer, Hey, is that improving your situation? And if they say, yes, it's improving my situation, that's already great. They have already some value and we can then iterate on that. And if they say, no, it doesn't improve my situation. It actually, it makes it worse. Now it's more complicated to do my job than before we can change it back without spending weeks or months of development time.
Perfect. And also I agree everything and one other thing that I want to add is that I think it's important to know that for example, if you are a junior engineer or junior developer the way you can grow as an individual, as a professional is I don't really think that might, I don't know, upset some people from the listeners, I don't really think that you will grow by learning new stuff in terms of like how to develop things. You will grow to add more like human or soft skills to your work because the more you will understand the customer, the more you will understand the teams with where you are playing with, the more refined the code you can produce. And by the way, and I don't want to go into the details that yes, most of the code will produce by AI in whatever years. So obviously the soft skills of developers is a way to grow as an individual from junior to senior to team lead to whatever, and the usual steps upwards, right?
Yes and no. I don't see this as a career ladder or something where people can progress and they don't consider individual Developers so much. I'm only thinking more about engineering teams because in the end, we are not talking about individual developers who close tickets, but we are talking about teams that work together as a team, like really collaborative and figure out what's the best solution to a problem. And on that end for that code is just one part of it. One tiny part of what an engineer is doing is writing code. But the much bigger part is understanding stakeholders, understanding needs, discussing trade offs, figuring out what could be a first attempt to solving a problem and all these kinds of things. And sometimes the team might also find out, actually, we don't need to write code to solve the problem which is also okay. And that's why I think that the social skills of the soft skills, they are not really soft, but the soft skills are...
yeah, I hate the term too. Sorry about that. But I have to use something.
...more important than the hard skills, right? Because it's about collaboration and team effort and talking with people, this is something that the AI cannot really do. If I know exactly what problem I want to solve and how I want to solve it, I can tell the AI or any other AI and they will create a code that is maybe okay ish. But if I don't understand the problem in the first place, then The output is garbage, no matter if I write it by hand or if I ask the AI.
Yeah. In terms of collaboration, so one of the underlying challenges that I also see, and you can correct me if I'm wrong is that the way developers and engineers work together as a team is sometimes fundamentally different how other teams non developer teams are working and collaborating together. Let me give you a very reductionary and super simple example. Developers are usually relying on documentation and the whole confluence, ticketing and the whole project management system defining what they are doing in a documentation space. So it's probably, it's mostly written. Obviously they have sometimes standups and some smaller meetings and whatever, but it's usually writing driven approach of collaboration. Meanwhile, the sales and marketing team. Yeah, I know that you are already shaking your head. It will be a great reply. Meanwhile, the marketing and the sales team, they are usually relying on meetings and collaborating on a bigger meeting, throwing drag and drop stuff around and more creatively. When they need to work together, the engineering and the other teams, how do you shorten that gap or is there any gap between the collaboration types of these different teams?
Great question. So first of all, It might sometimes seem that engineering teams are working more asynchronously and based on documentation and just written things, code reviews and so on, but I don't believe this is the best way to collaborate as an engineering team. Actually, I think it's one of the worst and controversial here, but for me this comes from the open source space where people in completely different countries, completely different time zones that don't know each other, that only have time at very odd times to contribute a bit to the software try to talk together. And of course they are, we need to have a lot of written communication. We need to have asynchronous code reviews because when one person is finishing the code writing the code, the person, whoever is still asleep, these kinds of challenges we have. But that said, those challenges don't make software engineering easier. They make it more difficult. And when we have a team that's roughly in the team's time zone or has huge overlap, there's actually no reason why they should not also collaborate properly. And for example, pair program or team program on a solution, because again, the coding is not the limiting factor, the thinking and finding solutions is the limiting factor and the collaboration can help us to understand each other better, to grow closer as a team, to know how we mean certain things. It also, like when we collaborate in a zoom meeting, for example, and have the cameras turned on, I can tell you something and I immediately see if you based on your reaction, if you understood it, or if you find it confusing, or when we do a team programming, for example, and I'm the navigator and telling you which code to write, I immediately see when you are writing it, if you understood what I told you and communication is very difficult, not only remotely, but also when we are in the same room and usually it fails. We usually, we could say something and resume the other person understood it exactly as we meant it, that's never true. And in asynchronous communication, we only learn that a day later or two when we think I wrote it like this, why are you not doing it like this? And it turns out that the other person understood it differently or didn't read it properly or 1, 000 reasons why the communication fails and we can reduce this chance of failure. And this feedback cycle on our communication, if we really collaborate together. With the remote teams that I was was in, we usually collaborated probably 50 or more percent of the time being on the same zoom room together, synchronous exactly, and that also improved the way how we worked asynchronous, because sometimes, of course, you want to be asynchronous, somebody wants to sleep long, the other person has an important appointment in the afternoon, or another meeting, or wants to take a day off, all these things, we are not always on the same meeting. All together as a team, but that also doesn't matter because then we can drop out. We can do things asynchronously, but we know each other so well that we understand better, even if you write in our communication and also for large parts of our collaboration, we do that synchronously intentionally. And I find that this works much better for a lot of reasons. And it also reduces the need for asynchronous code reviews. For example like when I have something finished, then it lies there and is waiting for review. That's waste, it's waiting there, it doesn't create any value. I'm already switching to my next task and then somebody is reviewing it an hour later or two, and then they have a finding. I need to switch my context back to the old thing to rethink. What did I do there to see what their comment is about? Does it make sense? And only then I can work on it and these context switches, they are stressful, they slow us down and they are not really valuable when we don't have to do them. And when we collaborate, we in the end of the collaboration session, we would just look over the code together and say, does it look good? Yes. Okay. It looks good because we discussed it all the time already and we just check the last time if we didn't commit anything that. It should not have been committed or something, or if he forgot something and that's a super fast and everybody on that session already has the similar knowledge on off that code. And we are sure that we found the best solution we could come up with as a team in that session. So that's quite cool. Then our collaboration with other teams to get back to the second part of the question, it depends what we are collaborating for and what it is needed for. That's really a question because I haven't so often seen the need to collaborate across other teams, only when we happen to have dependencies between teams. And then of course, if those happen more frequently, I would more think about how can we change team structures that we don't need to have these meetings with other teams. So often, for example, maybe we are missing a certain capability in our team. Then maybe for example, an operations engineer on a design expert or a customer success manager, then maybe it's worth to get them into the team and collaborate much closer with them and have like similar schedules, similar routines, rather than trying to fit two very different schedules of two very different teams together for that collaboration. And then in the end, I think if we, if people know why they are meeting and see a value in that meeting. They are usually quite open for meetings. Often the point why I see engineers especially be frustrated about meetings is because it interrupts their flow. It interrupts the deep work and they don't see a value in it. At the same time, engineers are perfectly happy to have a meeting when they see that it's valuable. That's really to reflect about what do marketing teams or engineer teams need from each other? And how could we fulfill that need better in a different way? I maybe can give you an example on that. In one of the last companies we had deployments and they were happening twice a week. And in the beginning, it was handled in a way that they happened twice a week and the customer success managers got a list of changes every time such a release happened now, that's already pretty good in other teams and other companies. I had experienced even worse things where people needed to meet up in order to hand over that list and to discuss that list and so on, which of course, means that two teams need to have time at the same time and need to interrupt whatever they are doing just for the meeting. But when we make this part of the communication more asynchronous by, for example, just giving them the release notes if they only need to publish them anyways, we can reduce that need for the meeting by still giving them the same value that they need. In our case, we even brought it a step further because we wanted to introduce continuous deployments like 20 times a day if we wanted to and of course then you don't want every time to send a list to the custom success manager to tell, Hey, here's another release note. So we switched. We had one meeting with them to discuss why do we have the release notes? What's the value for customer success managers and what's the value for customers. And then we realized it would already be enough for our customers and our customer success managers, if we only have such a note once a month. Our teams were just collecting in a notion page, basically the items that were changed, like new features, bug fixes, everything that we wanted to mention to customers, and then once a month, customer success would just go to that notion page and take the input and put it on a website in a bit better format so that customers could read it. And with that, we removed all the need for all this interaction in between essentially.
So pretty much it's super interesting because your original argument was that asynchronous work, and I don't want to super hardly challenge you but I have to a little bit, sorry. So your argument was that the asynchronous work should be done only if you do have team members in separate time zones. So it's like a necessity of collaboration. But if you can, and if most of the teams are in within the same time zone, that synchronous collaboration is a little bit more faster and more effective way of doing things. Now, I do have a question that you also said that still like 50, 50. Even if you do have the same time zone for the team, that question is that like, how do you decide what should be async and what should be synced even with that, within the 50, 50 section that's also important. But other thing is that I wanted to know that when you have cross team collaboration I think creating value is a little bit different there in a theoretical sense as well. So when you collaborate with engineers only the goal is to create more value for the product, right? Because that's what you do. And usually during the collaboration, it doesn't matter if it's synced or async you collaborate to do something better with the product. And there is a value, there is a clear outcome of the collaboration. But if you do that collaboration with other teams, let's say, for example, sorry marketing, for example one of the biggest problems with marketing in general and in general with the working with the developers with the two teams that marketers sometimes don't understand the product that engineers do so the whole collaboration goal is to understand the product from the engineer's side so engineers can explain how the product is working. What are the features and why they are super important What do they do? This is especially heavy and true if you do have a very complex product like a database, CMS, something like really technology heavy product. On the other hand, engineers should learn what the customers are seeing from the features that they are deploying, and that's only customer success and marketing. The other teams can tell them because they have the information. What I'm trying to get here is that sometimes the value creation is different because the value in a collaborative meeting with a cross functional teams is just the understanding of each other and that's like really hard to measure. There is a not really clear outcome at the end compared to an outcome of a product update that you can collaborate on with only the engineering team.
It might seem like that but I would argue that also product increments and the value of product increments are very hard to measure. When we implement a certain feature what's the value for the company? Honestly, we don't know. Nobody knows. Product managers might guess something customer success marketing and sales might have an idea how much better this product now, but it's just theory. It's just an assumption. It's just like trying to predict the future. And then in the end, we don't know when the feature is done. What is the value? Of course, we assume that it will have value. Otherwise we will not, we would not have built it, but what does it mean? And with other kinds of collaboration, I also think it's pretty much the same. For example, if we have sales or marketing to understand the product better as an engineering team, or as somebody from the product area, we help them to sell it better and to sell it to the right people in the end, which is a win for the company, right? I don't think so much in one department versus the other, but I think we as a company, we have a certain purpose that we want to fulfill and we do whatever our expertise is to fulfill that marketing as a different expertise than engineering. So they do different things, but sometimes we need each other and that's completely okay. And if we know why we need each other and we trust that everybody is giving their best and that we are not just meeting because we want to annoy the other people.
Which happens so often, by the way.
Yeah. I think it's usually more the assumption. Okay. Why do we now meet with them? They are for marketing. We don't have anything to do with marketing. I see this attitude in engineers sometimes, but then in the end that might be something to speak about, right? That might be something to talk about. Why do we need to meet? And ideally, and that's a valid question. Why do we need to meet? And then maybe we find out we don't need to meet. There's another way, or we understand why we meeting and. I think when engineers understand that it's valuable for the company that they meet at some point with somebody from customer success, for example, they are much more happy to do or with marketing or with any, anybody in the company, any meeting, when they understand the value for the company, most engineers are okay. That said it's still valid to look for better ways. It's still valid to look for ways to reduce the number of meetings and to see who really needs to meet with whom, because in the end, every meeting is a distraction from whatever the engineers are doing like from the deep work and when we have one meeting every two hours, then we don't get anything done in between because we don't have any block of three to four hours of uninterrupted time in our days. And that's yeah that's not so good.
Then how do you decide what can what should be synchronous and what should be asynchronous types of collaboration. If you, and if you can give like examples that would be great for the audience, I think.
Yeah. So for me, the rule of thumb is in inside of the team, I would prefer synchronous collaboration over asynchronous collaboration and across teams and especially with other departments, I would usually prefer asynchronous collaboration over synchronous collaboration because otherwise meeting gets so difficult. The team itself, it's on the same schedule. Of course, sometimes we cannot meet because of different personal requirements, which is also fine. But when we try to meet everybody synchronous across the company who might have a question for us, then we have a lot of meetings in our calendar and we won't get anything done. That said when we try to communicate asynchronous and we see, for example, we try it in Slack and we start a conversation and this turns into a thread where we just ping, go back and forth with our messages that we can also just meet and just meet on the spot to discuss it. There's no need to schedule a meeting in two weeks, but then maybe just go there and discuss it synchronously because often we can solve misunderstanding so much faster than we are just talking rather than when we try to write and we are distracted anyways by this conversation. So we can as well have it synchronously of course, inside of an engineering team we are not always all the time collaborating. We are doing it probably for in most companies and most teams for way over 50 percent of the time, actually, but then sometimes there are things that are just, okay, this needs to be cleaned up a bit, and this needs to be cleaned up a bit. And, oh, I have to do this. And I wanted to research this a bit, then sometimes we also split up, but. We are all quite open to jump on a call anytime somebody says, Hey, this is a bit confusing, or it's a bit more complicated than I thought. Can we collaborate on that? And that's really low as the bar for people to say Hey, I would like to collaborate maybe because I need second brain for that, or I need a second opinion or just because I would like some company for the work we're doing here. Those are all valid reasons inside of a team, I would say.
Perfect. I have a pet peeve and I have to ask this. Sorry about that. What are your views about the daily standups? I know it's a trick. Sorry about that.
No, I love the question. And I can tell you that you don't need daily standups when you do collaborate enough. In the last team, we didn't have standups for probably two years and we did not miss them because why do we have the daily stand up? We tell what did we do yesterday? Or actually we should tell what did we achieve yesterday? Not what did we do? Because nobody cares. What did we achieve? Then what are we planning today and why keeps us or prevents us from doing that. But that's completely pointless conversation in a team that is collaborating where we are knowing what we are working on and two or three people work together on the same thing anyways, then why sink in the morning about that we can just give an update and slack and say, Hey we are now starting to work on this topic. If somebody wants to join, here's the link where you can find me or just drop me a message and we can work on that together or, Hey, I finished, or we finished a task is somebody working on something and we can join there. And if not you have a list of things that should be done next, for example, an up next or something. So if you work like this you probably won't miss the daily standup and you will find that daily standup is more a burden than a help. And that's maybe a good point to say the point of address of the development, for example, is to reflect also on our rituals and our yeah, how we work and that means we can also question why we do certain rituals, not just because everybody's doing daily standups. It's not a good reason to do standups. If you find it valuable as a team, then of course, yes, do it. I think for many teams that collaborate, it's not really needed. What we did though, in the last team where I was a tech lead and the developer experience team was that we had a weekly kickoff on Monday, which was a place for us to reconnect and start the week together. So every Monday 9 AM CT, we were coming together and we started like within a check in round for everybody told what, how they feel, what they did on the weekend, and it was like a bit more like drinking coffee together. And then we moved over to, okay let's recap what we did last week. What's still open. And also what we plan to do this week, just to see, do we have clarity that was 45 minutes to one hour. Usually that took to check everything, to check in, to discuss some topics that were coming up that we wanted to discuss like open agenda where everybody could put things. And then after that, we directly moved into collaboration on the most important topics for the team for that week. And then we were already full in deep work and collaboration. And that set the tone for the week. And then we didn't have any standups throughout the week, but we were seeing each other multiple times a day. At least in subgroups of the team, depending on the topics.
I think that's fair. I think that's fair. And I do believe that this should be the norm for everyone. If you're, I love what you said that if you're collaborating enough anyway then why would you do any kind of like extra dailies, just because everyone is doing that. It doesn't really makes any sense. If you can close up with some really great tips on how to work better with engineering teams or within the engineering teams what are your golden standards that you can recommend for others?
Great question. So for me engineers are also humans, just humans. And when you treat them as humans, usually like you for that. And I don't like the separation between engineers and other kinds of people. In the end, I think in the workplace, we need more time for building human connection and relationships. One, like one great way to do this is we did with the weekly kickoff where we just can connect as the team on a personal level where we can also share if something came up, this is in general, a good practice for meetings and especially meetings in a remote context that we start with a check in where people can tell what's going on in their life because they are sitting somewhere else. And we don't know maybe that the child is sick at home and the parent, the partner is at work. And that person currently needs to juggle the job and. the child at home. When we see, hear that in the check in, this makes it easier to understand when they are maybe a bit distracted in the meeting, when they are not at their best. It's just great to accept that people are not machines that always perform at the same level, but that they have their ups and downs and their personal issues, and it is completely okay to bring those to work. Because we can try to keep them out, but usually that doesn't really work. And then we are surprised by our coworker today got angry so fast or got set so fast or offended so fast, or isn't as focused as usually. But when we share that we have the opportunity to build our relationships with each other and to understand each other much better. And that opens the space for being more empathic with each other and really growing together and creating that trustful and safe environment where we can really have high performing teams. And the same like what we can extend beyond the check in is also to have one on ones with each other, like coffee chats, every now and then inside of the team, but also across teams to get to know other colleagues and other teams or other departments just to see who is working there. What's, how is their life looking like? What does their job mean? And this can also create more understanding for, Hey engineering isn't that as easy as I thought, I always wonder why they are always late with their deliveries and why they cannot keep any deadlines or cannot promise any deadlines. And when you talk with the engineers oh, there's so much going on and they had this incident today that completely blew up the schedule and you have my empathy same for sales, for example. You see how much pressure they have sometimes. And that's something that I can just advise companies, especially remote companies to have more time planned in for human connection.
Totally. Totally. I highly appreciate that you pulled that as an example, because that's super important. Not just for developers, by the way, but for everyone else as well.
Yeah. And of course I have more that I can share. Especially in a remote setting communication is challenging because it's so hard to miss something in an office when you talk in a team between two people, other people on the team can just hear it with half of an ear because they are sitting in the same room. This might not be true when you're in a remote setup. So what I really like here is the default to open approach where you always try to have your conversations in a more as open channel as possible. For example, if you have a conversation as synchronous on Slack, and it isn't super personal, super private, don't have it in a direct message, but have it in the team channel or in a channel that matches the topic so that people can reach I want it later on and see what's going on. If you have a problem and ask in a public channel, you also get a response much more quickly because everybody can answer and somebody might know the answer that you haven't thought of in the first place. But if you ask somebody in a direct message, only they can answer and it means interruption for them and so on. So default to open also with documentation and everything can really help to share knowledge and to give other people yeah feeling of what's going on and everybody can join a conversation whenever they feel that's right. And another thing that I really like, which I've seen in some companies as a channel for appreciations where we can just openly in an open channel. So to say thank you to our colleagues. If they did something that really, that we really liked something nice, if they helped us, or if we just had a nice coffee chat with somebody just so that people see that there are personal relationships and appreciating each other is a really great way to feel more connected to each other.
Awesome. Thank you for all your time. I think these were really great insights. And I think, and I hope that the audience could learn a little bit more about how to manage and operate with better developer teams. Where can people find you if they have any questions to you?
Yeah. Thank you first for interviewing me. I really enjoyed our conversation and I love this topic as you might have noticed. People can find me on LinkedIn of course, I am pretty active there. And also on my homepage that's unblocked dot engineering which is the company name under which I'm offering my coaching and consulting. And yeah, I'm happy to have a conversation on this and also talk with your audience on how we can bring that to their context.
Thank you very much. All of this will be linked in the show notes below, by the way, and again, thank you for your time. I really enjoyed it.
Thank you, Peter for having me.
