BONUS: Building High-Performing Engineering Teams | Jochen Issing

Summary

Scrum Master Toolbox Podcast: BONUS — Building High-Performing Engineering Teams with Jochen Ising

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Jochen Ising (Engineering Leader)
Original Air Date: September 20, 2025

---

Episode Overview

This bonus episode features Jochen Ising, an engineering leader from Germany with a background in handball and music, sharing his insights on building high-performing engineering teams. The discussion centers on the importance of team dynamics, psychological safety, moving beyond hero culture, and practical tools for fostering trust and collaboration. Jochen weaves together lessons from sports, music, and leadership, offering actionable advice for leaders and teams striving for excellence in engineering environments.

---

Key Discussion Points & Insights

Origins: Lessons from Handball and Band Experience

• Team over Individual: Jochen recounts that in both handball and music, success is not about individual brilliance but about optimizing for the team’s output.

  “As soon as you start to complain about each other, you're starting to lose.”
  — Jochen Ising, [03:15]

• Building Culture: Sports taught him the dangers of internal blame and the importance of psychological safety (ability to share concerns without fear).
• 10x Engineer Myth:

  “You can be as good as you want. If the team doesn't play well with you… you're not really getting the most out of your company and your team.”
  — Jochen Ising, [05:15]

The Hero Culture: Recognizing and Redirecting

• Problem with Celebrating “Heroes”
  • Companies often reward individuals who step in to resolve crises (the "firefighters"). While their efforts should be appreciated, this can hide systemic issues.
• Vasco’s Reflection:

  “Thanking them does not mean celebrating them. Thanking them means, I'm really sorry you had to do this. This should not happen.”
  — Vasco Duarte, [11:36]

• Team Failure, Not Individual Success: The need for a hero is a symptom that the team and system failed to support continuous, sustainable progress.

Psychological Safety and Non-Authoritarian Leadership

• Creating Space for Ideas & Questions:
  Jochen stresses the need to “read the team” and break down barriers for open discussion, especially for junior members who may fear embarrassment.
  • Leading by Example: He sometimes purposely asks “ignorant” questions to model vulnerability and normalize not knowing ([15:50]).
  • Ritualized Dissent: Assigning someone to deliberately challenge group decisions to counteract groupthink ([20:53]).
  • Value of Disagreement:

    “You should always start with the simpler, faster, and less risky solution … if it isn’t enough, you will have so much more information and then you can build on it.”
    — Vasco Duarte, [22:19]

  • Harmony vs. Challenge: Too much harmony can lead to unchallenged, risky decisions. Teams should deliberately seek input and critique.

Tools & Techniques for Trust and Alignment

• Expectation Sheet
  • A transparent, living document clarifying mutual expectations and communication norms. Jochen uses this tool to foster personal relationships with direct reports and encourage openness:

    “I want to offer that I share my thoughts, my observations as open and honest, but at the same time, of course, respectful as possible, always with the intention that we help each other.”
    — Jochen Ising, [25:17]

  • Manager as Supporter, Not Commander:

    “You present yourself and you're like a supporter of the other person. You're like their coach, like you're helping them, right?”
    — Jochen Ising, [28:32]

  • Openness about leaving:

    “If the person eventually says, ‘Hey, I'm done with this company…’, I would also help them to get out and I would help them to find a new job because I think this is the balance you have to strike as a manager.”
    — Jochen Ising, [30:42]

Aligning Around Team vs. Individual Goals

• Tailoring to Individual Needs: Recognize different motivations—some want to prove themselves individually, others excel in collaborative efforts.

• High-Level Engineers as Multipliers: The role of a senior engineer is to “form tribes”—share knowledge across boundaries and ensure no single point of failure ([37:30]).

• Embedding Shared Responsibility:
  Techniques include:

  • Planning Poker: Building shared understanding ([42:10])
  • On-Call Rotations: Uncovering skill silos and encouraging cross-training
  • Pair/Mob Programming: Ensuring multiple contributors and perspectives on every decision and implementation

• Detaching Ego from Ideas:

  “It’s just an idea … not putting your ego so much into the equation, but much more thinking about the product itself or the solution itself.”
  — Jochen Ising, [45:15]

---

Notable Quotes & Memorable Moments

• On psychological safety:

  “If there is a lack of psychological safety, I sometimes make, I try to make rather ignorant questions. I try to expose myself as being the least skilled person in the room.”
  — Jochen Ising, [15:47]

• On team decision-making:

  “We agreed in five minutes to implement something and it completely blew up.… I knew there was one person in the room who already did something very similar … I asked him, ‘Can you try for us to destroy our idea?’”
  — Jochen Ising, [17:40]

• On culture & leadership:

  “The culture is a combination of how you as a manager communicate your values and what you want from the teams; that you really consider the team as the unit of delivery and not the individual.”
  — Jochen Ising, [36:35]

• On humility and openness:

  “Even if the person says, … ‘I'm done with this company, I can't stand to stay here anymore,’ I would also help them to get out and I would help them to find a new job.”
  — Jochen Ising, [30:42]

---

Recommended Resources

• The Culture Code by Daniel Coyle
  On building high-performing teams and the role of leadership ([46:29])
• The Product Development Flow by Donald G. Reinertsen
  A fundamental book on the science behind Agile and Lean approaches ([47:19])
• The Culture Map
  On understanding and combining different cultural perspectives in a team ([48:06])
• Coaching Agile Teams by Lyssa Adkins
  Key concepts in agile coaching ([48:31])
• Scrum Master Toolbox Podcast
  As endorsed by Jochen: “They’re extremely good source and I don’t just make a joke here … I actually really enjoyed listening to your podcasts in the past.” ([49:28])

---

Important Segment Timestamps

• 01:20: Introduction of Jochen Ising and his team-building philosophy
• 02:20 – 06:58: Lessons from sports and music; 10x engineers and team dynamics
• 07:37 – 14:31: The dangers of hero/fighter culture; celebrating teams over individuals
• 15:20 – 23:25: Building psychological safety; ritualized dissent; simplicity over complexity
• 24:44 – 35:02: The “expectation sheet” for trust and openness; manager’s role as a supporter
• 35:51 – 41:31: Aligning individual and team goals; cultivating shared responsibility among senior engineers
• 42:03 – 46:05: Practical tools for alignment: planning poker, on-call rotations, pair programming, detaching ego
• 46:29 – 49:58: Jochen’s recommended reading/resources

---

Flow and Tone

The conversation is earnest, practical, and sprinkled with humor and warmth, especially as Jochen ties together analogies from his varied background. Insights are grounded in lived experience, failures as well as successes, with an emphasis on humility, experimentation, and continuous learning. The language is direct and conversational, making the episode accessible and relatable to listeners at all levels of engineering leadership.

---

Connect with Jochen Ising

• LinkedIn: Jochen Ising

  “There are no other Jochen Isings yet on LinkedIn, so it should be fairly easy to find me.” ([50:24])

---

This episode is a comprehensive guide for anyone interested in creating environments where engineering teams can truly thrive—beyond individual performance, with a focus on sustainable growth, psychological safety, and authentic collaboration.

Transcript

[A]

Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to a very special bonus episode. For this bonus episode, we have with us from Germany, Jochen Ising. Hey Jochen, welcome to the show.

[C]

Hey Vasko. Good morning and thanks for having me.

[B]

Absolutely. So we're going to talk about the lessons learned by Jochen on running high performing engineering teams. He's an engineering leader who's all about building great teams and better developer experiences. From audio, tech and cloud platforms to monorepos and feedback culture, he's done it all. He's a former bandmate and handball player. Johan brings heart, trust and collaboration into everything he builds with his teams. So, Johan, you've had a fascinating journey. You've been a handball player, a band player, and of course, leading engineering teams these days. Let's explore your origin story in terms of leading engineering teams. Can you share how those early experiences shaped your approach to leadership and collaboration today?

[C]

Yeah, sure. Of course. It's maybe a bit unorthodox to have these combinations, but I think this is also what makes people individuals, their origins, where they come from, the experience they collected over the years. And I, I was thinking about my origins for quite a while, especially ever since you asked me to join the podcast, which I really appreciate. Thanks a lot for that. And yeah, let's start with my little journey in handball. So it might sound a bit like professional ish or like that. I really was investing a lot of time into handball playing, which is definitely true. It was for me a lot of time. But I never played professionally. So maybe if people now start to search for me as a handball player, they probably won't find much, but still like the sport has fascinated me and it also shaped my understanding of what great teams are. And it still shapes also how I read teams on TV when they play against other teams, how I interpret their behaviors and so on. There are a couple of things that I find extremely useful also for shaping the culture and the behavior within teams in an engineering organization. So the first thing that I think is very important in a team, that as soon as you start to complain about each other, you're starting to lose. That's very like very obvious as soon as you play team sports, I think even, and it's even visible in professional sports, if the team starts to complain about each other, they're becoming frustrated. They usually are on the losing end and they make sure that they stay there. That's like the problem mostly, right. But also other things, like something that I find extremely important for team players is that when you're a great team, you're optimizing for the team's output and not for the individual. Which I think is very important for many of like young and enthusiastic and like engineers that really believe in this, oh, I'm a 10x engineer kind of person, that you can be as good as you want. If the team doesn't play well with you, or you don't play well with the team, or you're not well integrated into the team, then you're not really getting the most out of your company and out of your team. And actually you're also hitting a ceiling as an engineer that you're probably not going to overcome unless you actually start to open up and invest more into your team. And usually also my experience is that you don't like the highest skilled engineers. They are not giving their highest individual performance in a very well working team. They are slowing themselves down a bit to pull everybody up, which makes them the whole team faster and which actually like teaches them a good bunch as well as everybody else in the team. So this is I think also very visible in especially soccer, football sports, right? Where you see like teams of like extremely like skilled and extremely good individual players, but they are losing against like more mediocre high quotes, mediocre team when they cannot play together very well, when they're still focusing on themselves. And another extremely important thing for me in, in a team is that we have like a high level of psychological safety which means that players can or engineers can tell each other what their concerns are, what they thinking, that even if they might have like an immature thought or so they don't feel Afraid to ask it because they know that their. Their counterparts will not hold it up to them.

[B]

And this is a little bit what you were talking about when you talked about the complaining or frustrate being frustrated at each other.

[C]

Oh, yeah.

[B]

So. So maybe we could touch on that. Because I think the, like, especially the point that you brought up of the 10x engineer is one that I still hear today in the age where software is delivered by hundreds of people, in many cases, definitely most of the time not by a single individual. And I still hear this mythology that if we just had one person that was good at this, then all the problems would be solved.

[C]

Solved.

[B]

And of course, that's not my experience. And as I said, most software these days is delivered by tens or hundreds of people, not by single individuals. How do you convey to a team, let's say in a team of 10, for example, where you have two people who think of themselves as, or even one person who thinks of themselves as a 10x engineer, how do you convey to them that aspect which you probably got from handball at least, if not also from your music playing and band times, but how do you convey to a person like that that it's not your success that makes our success, it's our success that makes your success happen? Right. Like, how do you deal with this as a leader of engineering teams?

[C]

Yeah. So that's really a journey that you have to take on with the individual that where like, I'm. I'm not really having like a single word or like a single sentence that I can utter, and then everybody understands what I mean, and then we just move on with it. It's more of a, like a shared experience that we have to nurture and that we have to build. And what I try to point out is like, in different situations, to point out cause and effect in situations that really relate to such things. And very often there is this hero culture in companies where the team is working high quotes normally. Right. And they're actually not working on optimizing the team for some reason. Maybe they don't do much retros or maybe they just don't dare to change anything. And then eventually enough problems pile up until we need a hero to solve all this. And then usually there is somebody who is a hero or considers himself to be one and can actually pull the company out of the misery. And then these situations are usually celebrated in companies and that person is very often celebrated. Whereas I think it's also important to understand that addressing the question, why did we even get into the situation like Was it a good problem to have to be in this situation in the first place? And did it make sense to have now one person fixing all of this, having all the knowledge to avoid the situation, to fix the situation and to get the company out of misery? And the rest of the team is practically. And the whole company is practically dependent on that individual person. It might feel good for the person who was doing it, for sure. And I'm also thankful if a person does that. But I think it's very important to then take the next step and make sure. Okay, like, let's assure that we never get into this situation again and that we don't need heroes. That we all have, like, solid rock stars or like whatever stars we want to call them. And they can always keep. Keep our workplace in a normal state. And they can always, yeah. Solve the problems that we have in the most efficient way. And they can also go on vacation or they can also get sick and nobody has to call them in, but the team can just move on. Right. So there is even like an egoistic aspect to it that like Even the best 10x people, they also want eventually to take some time off. And they should.

[B]

Yeah, of course they should, because it's good for them and the team, whether they want it or not. Of course, every individual has their own experience. But one thing that you said that I really liked and I want to highlight it, which is this, as you said, the concept that very often in companies we highlight these heroes and we celebrate them, but we forget to ask, why did we end up in this mess in the first place? So one thing I would like to suggest, and tell me what you think, that we can thank the hero, because it is very often going beyond the call of duty and doing an extra effort. Thanking them does not mean celebrating them. Right. Like, thanking them means, I'm really sorry you had to do this. This should not happen. But thank you for your effort. It is really appreciated. And then turn it to the team and say, why did we fail as a team? Because the hero, in this case, the person who. Or firefighter, that's another term people use. The person who comes in and puts the fire out, they need to be thanked because they really did an effort. Right? And that's important. But when we look at the team, it was a failure, right? When we look at the team and even the organization as a system, it was a failure. And what you just said kind of raised that topic to me, that we can't make the person who did this extra effort feel bad. So we need to thank them, we need to appreciate their contribution. But then to look at us as a team where the hero is also part of. Right. And we have to ask why did we fail? Because we should not need this in a regular situation, in a normal, well functioning, high performing team. We shouldn't need this kind of extra 10x type of efforts.

[C]

Yes, that's, that's a very good point. And that actually also adds to it. So I think it's not only like making sure that we have a common understanding in terms of that it's important to build like a highly efficient team. To explain that to an individual. Also takes this team approach that you nurture a culture in the team that there is a common understanding that we don't want to get into the situation again, that we need one person to fix this. And if you have that culture, it also spills over to the individual that might have enjoyed that situation of being that person, fixing all of the problems, but still getting the impression, okay, maybe we can also celebrate other things much better if we actually finish hard problems together as a team. Maybe that is a better incentive and goal for us to have and to strive for. So that's, that's also a very good point. I think whatever momentum you can get started in teams that nurture such kind of culture, it makes things a lot easier in terms of managing teams and to like shape them. That they're highly, highly efficient. Yeah.

[B]

And talking about themes and how they work, one of the things that, when we were prepping for this, one of the things that you talked about is this idea that in bands and in sports teams there's no space for authoritarian leadership. So of course we want to learn from that and think about how to apply that in engineering teams. So how do you create the space for everybody in the team to bring their ideas so that the team can work better as a set, as a group than every individual separately could do. And how do you build that contrasting psychological safety so that the authoritarian leadership does not have space or there's no need for that?

[C]

Yeah, that's, that's also like a really good question. And I think it's also very versatile. Like the answer is very versatile because it also highly depends on the individual teams, of course. So there are a couple of strategies I think that we can put in place. And it like the first thing I would say it always starts with reading the team, understanding what is the situation in the team and what is blocking the psychological safety. Is it maybe like an extremely strong individual plus some like Rather like junior people that might be a bit afraid of speaking up or uncertain if they can ask certain questions to embarrass themselves, right? That is not something that is very dangerous in a way, because usually, like, even if you have a couple of, I quote, stupid questions, the stupidity will go away very quickly, like, or the ignorance will go away very quickly. Because the best way to get rid of ignorance is to ask the questions. And if there are maybe like more serious cases, when I see that there is a lack of psychological safety, I sometimes make also, like, I try to make rather ignorant questions. I try to expose myself as being the least skilled person in the room. And there I'm relying on the situation that we, as managers, we always suffer from that. Oh, the manager is like the king kind of, and whatever they wish for is command. But if you put it around or if you turn the table around and say, like, hey, folks, like, I have no idea, like, you are the experts tell me, right? Is it maybe like this and that? And sometimes I even make up stupid stuff just to expose myself and say, hey, I have no idea. But it's okay to say that, right? And you just have to then in addition, transfer also to the team that. Well, it's not only okay for me to say it, it would also be okay for you to say it. And by opening the room for all kinds of questions, like leading by example in a way that is already helping a lot to bring the team to think about stuff. Another thing that I find extremely helpful is to build a culture of challenging oneself, which was something that I experienced quite a lot in the beginning of my high quotes automotive career, where we were working in a team and we were just a few people and we had extremely good people. I was really, really impressed by, by the skills that we had in the team. And I was also like a normal engineer, an individual contributor there. And we, we went into planning, we did some design work, we did some refinements, and we so quickly agreed on things. And eventually I felt like this, this is like, it feels too quick. Like we had five minutes and then we discussed something and then we all said, yeah, sounds, sounds sensible, right? Let's do that, right? And we were in a situation where we did exactly that, where we just agreed in five minutes to implement something and it completely blew up. And we sat there together in this room and I knew there was one person in the room who already did something very similar to what we were about to do. And I asked him, like, hey, I know you've been working on Similar things. And I know you have a lot of experience here. Can you try for us to destroy our idea to break our design? Like, what needs to happen, that our design is completely blowing up in our face, just like it did with the previous task. And then he started to speak, like for five, 10, 15 minutes. And I was completely humbled, like, holy cow, you're completely taking the solution apart. And everybody else, I think, had a similar experience there. And then we added a couple of minutes after his monologue about what problems we are likely going to face. And in the end, we agreed on an implementation that was maybe 10 times simpler and 20 times less risky. And we had it implemented after a day or so. It was even much faster, as you can imagine. It's simpler, it's faster. And that really taught me something, that you can have seemingly a situation where everybody trusts each other, where everybody enjoys each other, but still nobody is feel safe enough or not every individual feels safe enough to speak up and say, hey, I think we did a bad decision, or this is a bad plan, because this harmony that people might want to keep in the team can be extremely dangerous, even or risky in many situations.

[B]

I really like that story for a couple of reasons. But the most obvious, of course, is this idea that when you get to an agreement too quickly, that doesn't mean you have a great idea. It just means that people are not either thinking of or don't feel safe to talk about the reasons why they think this is not a good idea. Right. And then the solution you came up with in the second try, which is to have a skeptic in the room, which is a very known strategy for improving the thinking capacity of a group of people to avoid groupthink, which is a real thing and has been studied. I think that's a great technique which is very easy to implement. For example, having the person who is the most familiar with the problem space to have the job of coming up with reasons why the solution proposed does not work. Right. And because you ritualize that descent, that's actually one of the terms that is used for this approach, ritualized descent. Because you ritualize that dissent, that person isn't going to be considered like the. The debit owner or the one who doesn't want to do anything or whatever, because it's their job to come up with ideas of why that solution will not work. And that creates the expectation that it's okay to disagree, it's okay to dissent. And I really like that. And then the second aspect that you said, which is something that I have seen over and over again is that once you start looking at the ideas a little bit deeper, you very often come up with something that is simpler, faster and less risky. And that's one tip that I always tell people, is that you should always start with the simpler, faster and less risky solution. For whatever problem, whatever architecture, design or performance issue you are tackling, start with the simpler version because often that's enough. But if it isn't enough, you will have so much more information and then you can build on it and you can build the next iteration of the solution, which is much better than coming up with a super complex tackles all kind of edge cases solution that probably is very fragile in the end. So two very important topics there. So thank you for that.

[C]

And also maybe to add to it, of course, engineers also like to build fancy stuff in a way. Right. So there is of course like a lot of fun to build something a little more complex or like some vision that you have in your head in comparison to just put something very pragmatic in place. Right. There is not so much enthusiasm behind it usually, but it's actually very often the better choice. And it also doesn't mean that you cannot build the fancy stuff then afterwards. Right. If you actually need it. But if you have the pragmatic solution, first of all, you have solved your problem and maybe also your dire situation. But then you also know if you need the fancy solution and if it makes sense to invest your time into that. Right.

[B]

And there's another topic kind of inbuilt in this psychological safety, which is this idea that we know what we can count on, but we also know what we are trying to do together. And you mentioned a tool that you call expectation sheet that you share with your team members. How do you take that into the way you interact with the team? How do you really apply your leadership philosophy when you're trying to build that trust and that psychological safety?

[C]

Yeah, it's like a technique that I copied from a manager of mine, actually. And what I like about it is that it sets the foundation for the relationship with the individual for me.

[B]

Can you explain what that is and how do you bring it to the conversation?

[C]

Yeah. So maybe first of all, like a little disclaimer. I don't think I'm really at the end of my journey with expectation sheets. It's still work in progress for me. But what I've been using it for so far was to provide my understanding of how I interact with my direct reports or pretty much anyone in my organization. And I would even go as far as to say that this also could be easily translated into anybody else in the company that I want to offer very honest and open communication. I want to offer that I share my thoughts, my observations as open and honest, but at the same time, of course, respectful as possible, always with the intention that we help each other. And that I also requested from everyone in the company or everyone in my. In my organization, at least, that they are telling me upfront what's going on with them. And what I. I try to establish with this expectation sheet is actually this relationship that we have, a personal relationship. It's not. Not necessarily a purely professional relationship. And this is where my approach might differ very much from the approach of others. But I feel I can only really manage people well if we're more talking to each other like individuals than in a professional context. In that sense, that people can tell me if they have issues in their private life, if they have issues with other engineers, that they know that when they tell me something, even if it's maybe in the middle of a heated emotional debate, that I will not use it against them, that I will not share it with anybody that they don't want me to share it with, and that they even tell me if they don't want to stay in the company anymore. I even want to know about the things where they say, oh, well, this is really something that drives me away from this company. This is something there, like maybe some kind of situation, some kind of decision, some kind of way how we decided or how we communicated. Things that I want to know how I affect people, and how do others affect the people that I work for? So I put myself into the service of the team rather than, like, feeling myself as the big leader. And this document is something that I can put in words. We put in a document and we can reread it every time and whenever we feel like we can add new rules to our interactions. And in my experience, this gave me, like, a really good foundation with a lot of folks. So for. For instance, the content was driven by a couple of situations that I have had in the past where, first of all, it's really difficult to establish this trust between a manager and an IC that they are really telling you everything that they think because they always depend on you in a way. They always feel like, oh, you're giving me my money kind of, or you're deciding on my sale, or you're deciding on my promotions. You're deciding on, like, if I stay in the company or if I leave the company. So how, how would I put myself in a situation of vulnerability that I tell you everything that I think, right? So that like this can only be, how can I make this a benefit for the person instead of like an elusive risk or so. And therefore it's really hard, I think. But it only works if you're authentic and if you really stand in for the principle of. In your direct conversation with the person, you're not necessarily representing the company. Of course there are situations where you have to. But in your normal one on ones, in your normal conversations, you present yourself and you're like a supporter of the other person. You're like their culture, like you're helping them, right? And if somebody tells me, hey, it's really like I'm really not happy, I'm feeling miserable in this company, I want to hear it and I want to think, of course, with the person, like, is there anything that we can change? And as soon as I can hear that, the earlier I can react, right? But even if the person says, and this is also what I put in my expectations, even if the person eventually says, hey, I'm done with this company, I can't stand to stay here anymore, I would also help them to get out and I would help them to find a new job because I think this is the balance that you have to strike as a manager. You have to know when you represent the company, which is, I would say even in rare cases. But you have to also know when you are actually like the go to person for your direct report where like you have to, like you have to help them personally to make the company successful. And this is I think the really tricky place or the really tricky thing that I tried to address with this expectation sheet setting the ground that people can tell you everything and never use it against them. As soon as you do it, then of course it sounds like trickery and that, that is the end of the story, I guess if you do that.

[B]

But that's one way to put it. Of course it's, it's a fine balance and there might even be some conflict of interests there. I agree between, you know, helping the person or helping the company. But one of the things that you said which is very in my mind is that at the end of the day, person that is in the company not because they want to, but because they have to somehow, you know, they don't have another job opportunity or whatever, they are not going to be at their best. If we can help them find a context where they are at their best. And that could ultimately be within the company, like move to another team or take another task or learn another skill. Right. If they come to you, we can help them and we can help them find that new position within or outside the company. We can help them find that new skill or responsibility that they want to take. There's so many things we can do. But as you said, if they don't come to me early, they might come to me only when they are already out the door and so frustrated that they can't take it anymore and then there's nothing we can do. So I think this is a very important aspect of building great teams, which is that ultimately we are working with individuals, certainly in software we are working with individuals and their performance depends on their well being. Right. And if they don't feel that they can be productive, whether it's because of skill or collaboration issues or whatever, then we have to do something about it. Even if that is helping them find another job.

[C]

Yeah, I fully agree. And it's actually really hard to, to identify where you are in this relationship because I even had, I would say friends as colleagues and they still only told me that they're going to leave the company when they already had a new job. And I was looking at them like, why are you just telling me this? I thought you were happy. But then it turned out no, that person wasn't happy for a long time. And there, of course I was a bit disappointed, but I was mostly disappointed about myself for not seeing that and not having established the relationship that I want to have with my Direct reports or like, I actually don't like the name Direct reports. Is there a better one?

[B]

My teammate.

[C]

Yeah, like, but the people that I manage, right. They, they, if, if they cannot tell me that I think I failed as a manager. Yeah. And that, that was driving me a bit mad, I must say, because it really happened with people where I, I thought, oh yeah, we are, we can tell each other everything. But in the end it turned out that we actually couldn't. And I'm hoping that with this expectation sheet and when I, I, I put it explicitly in there. So if you ever feel like something drives you away from work or even if you say like, hey, you have enough of this, you want to actually leave, tell me, I will help you. Solving the problem, solving the situation, and whatever the solution looks like, it doesn't matter if it's, if it means you're changing the word content, if you're changing the team, if you're moving into like a different department or if you're moving out of the company, it doesn't matter. It's about you. And I want to know that and I want to help you. And I put my name behind that statement. And that I think so far was the strongest bond that I could build or the strongest strategy that I can build for creating that bond.

[B]

So another aspect of being a leader, of course, is helping teams make decisions, getting people on the right task. And these are all difficult things to do as a leader, especially when you need to go against what you know is somebody's expectation or desire. So when you work as a leader within engineering teams, how do you approach the alignment question? So how do we keep everybody aligned even if they have to do something that they are perhaps not so happy to do? Keeping people aligned and focused on the teams impact rather than just individual performance? How do you manage this? Because of course, there are individuals who really want to shine anyway. Right. And we can't take that away from them.

[C]

Yeah. And it's also a bit our human nature, I guess. Right. We want to achieve something where we can say, oh, I did this. Right. And so it's like the things that we discussed before, it's always a bit of a balance. And we're also dealing with individuals, right, that have their own desires, that they have their own situations that they're in and that they have their own history also. So if you're talking to a person who, like, who was always the runner up in a team, who always wanted to get something done for themselves, but they always needed help from someone and they feel like, oh, they actually need to show eventually that they can do it as well. That is a very different situation from a person who can do everything already and he just has a team or they just have a team who work up to them. And that person might need very different coaching, very different conversations than the other person that wants to catch up. And so I think it's therefore highly individual. But it also, I would say, is a question of what kind of culture are you building? And the culture, I think, is a combination of how you as a manager communicate your values and what you want from the teams and that you really consider the team as the unit of delivery and not the individual. And how do you bring that into the team as a culture and then how do you, like, address the individual desires of the individual people? And therefore, I think there are definitely cases where you want something sometimes where an individual can say, I did this. Let's say there is like a fairly junior developer who wants to prove themselves. Who wants to show the company I can do it? You want to give them something where they have a little bit of their own time, where they can, where they can identify themselves with that work a little more. But you want to still embed it into a full team. And so you still want to make sure that yeah, you can actually work on this and you can drive this, you can put a lot of design aspects into that, but you can still do it while for instance, pairing with your teammates, they can still contribute to this work that you did. And actually even in higher level of engineering that is even demanded, right? So what we demand in our company, for instance, and I highly stand behind that approach, is that if you are a very high level engineer, your individual contributions are actually not that important. They're more like you have some duty to be a highly skilled developer, but you're actual benefit that you bring to the company as a staff level or senior or maybe even principal is that you, you form tribes in a way. So it does not necessarily mean that you form your own team, but you rather actually pull in multiple people, even from different teams, maybe from different roles in the companies. Let it be like a product ownership or program management, including developers, coaching younger, younger engineers and bring them all together and build them up, right, Build that company. And if you invest that very much into your own vision or into your own like North Star kind of, you communicate that continuously and you, you manage to invest that into or ingest that as a cultural aspect in the team, I think then you attacked it from all sides and I think then you, you also eventually get to the point to like to have that as a goal. So it's no longer the individual having the goal that they want to do this particular thing and they want to like do some epic work and then that's it. And everybody else is like left behind. But their goal is actually to, to not only have something that is really epic, to, to show to the rest of the world, but also that they can tell and these and these and these and these people, they all contributed. And I made sure that this happened, that we all have this common picture and that we all have this solution now in place. And you usually see it also if it worked, because as soon as something goes wrong with a solution, then there is one call and then somebody has to solve it. And if you always have to go back to the same person, to the same high skilled engineer, then you already can see well, it didn't really work that well. And then the engineer themselves also Sees okay, we could have done that maybe differently to avoid all these after effects in the long run. So I would say it's very difficult to establish that.

[B]

What are some of the approaches that you've been able to apply to, to create that exactly that kind of atmosphere where we feel that we are part of that shared direction, because that's the job and the challenge of leadership. Especially in a context where most of our work is driven by individual decisions that need to come together. They need to be aligned. So what are some of the strategies that you think really work to create that alignment?

[C]

There are I think like very, very simple things that are also very known and I think Scrum has been building on them. Like the starting from very simple ideas similar to planning poker, where you try to establish this common understanding in the team. Right. You're working on one particular thing and everybody should understand what has to be done to actually establish it. Maybe not everybody's an expert, but you're always pushing everybody to be become a bit more of an expert with like doses of micro doses of information. Then I think even this on call rotation that we have in our teams and we in every team we have an on call rotation that is always showing you the silos of skills that you might have in the team. Because if you do a rotation and anybody can have, can have any issue at any time, then you very quickly see if anybody can also solve any quick issue at any time. And I'm also nurturing quite a lot like pair programming or software teaming or as it used to be called, mock programming, where you already nurture this, this idea of there is not a single person who is building everything, but it always goes in circles and everybody needs to navigate and drive eventually and they need to contribute and in the end the result will look very different from what one person might have imagined. It's actually something that's very, very similar to being in a band. When you come with a, like a song idea to a band and you usually have a very concrete picture in your head, oh, this is what the song should sound like, what it looks like and this is what it should be. Even then you bring it to the band and then you figure out very quickly, so, okay, well this is now very becoming, very, very different.

[B]

But perhaps also better. Right?

[C]

Exactly. Yeah, exactly. It's, it's definitely going to become very, a lot more versatile. And this is like this, this switch or this like flipping the switch in, in everybody's mind that it's, it's extremely important to bring your ideas to the table and to, to improve on the approaches and the ideas that we have. But if there is somebody else bringing other ideas, still try to be open, consider them and bring them in. And I actually also value that a lot. And I also reward that in my direct conversations with especially high performing engineers or like the higher level engineers. They all perform usually very highly, especially to, to make everybody aware, especially those people that think, hey, like I'm a 10x or maybe 100x, I don't know, like where the usual numbers are now that they like, they detach from their ideas in the sense of that it's just an idea, right? You throw it out there. It's like a ball that you throw to another person and the other person might catch it or the other person might drop it and maybe the other person is throwing you another ball and like keeping this afloat, like not putting your ego so much into the equation, but much more thinking about the product itself or like the solution itself, what do we want to build? And it doesn't really matter who had the idea. And usually we also completely forgot about like who had the idea in the first place.

[B]

So yeah, Jochen, it's been such a wonderful conversation. There's so many other topics that I would love to go deeper and explore with you, but unfortunately we're getting close to the end. Is there a book or a video, any resource that you would recommend for people who would like to take some of these ideas, maybe one of these ideas and explore them further?

[C]

So the first book that I really love, it's by far my favorite, I would say is the Culture Code from Daniel Coyle, where he exactly goes through the process of building high performing teams. What is the structure and how do they work together and what is the role of leadership in them? It's extremely good. I like it because I had a big fight with one of my managers in the past where they said always that you need sometimes micromanage, you need sometimes command and control. And I always said if you need it, you do something wrong. And then he always came with the example. But what about firefighters? And I didn't know enough about firefighter, so I couldn't really respond. Maybe he also didn't know, but he used it as a good example and this book really debunks all of this. And it exactly, I'm super biased because it's exactly saying what I was always thinking and that's why I like it. So Culture Code from Daniel Coyle. I also really like Product Development Flow by Donald G. Reynoldson also like a super classic. It's I think the summary of maybe 100 or 1,000 other books there and it really goes down to, I would say much more like the scientific level behind many of the other books that are out there. I would say it explains everything around all the agile methodologies, what is really behind it and what we are really trying to solve there. So I highly recommend that the third book is the Culture Map, which is also something that I really like as a person to understand and get experiences from very different kind of cultures, from people with very different origins, and to bring everybody together to distill the best aspect of each culture that everybody can bring to the table. So the diversity is something that I also really like in teams. And the fourth that kind of got me started with the whole agile stuff. So you kind of understand also like how long I'm knowledgeable to it. It's coaching agile teams from Melissa Atkinson. And this is maybe one person that you even had like direct conversations with quite a lot. And of course last but not least, Vasco's podcasts. They're extremely good source and I don't just make a joke here. I actually really enjoyed listening to your podcasts in the past and I think they're like very, very valuable. And I never forget when you say sharing is caring was good. This is one of my mental connections with you.

[B]

Absolutely. Sharing is caring everybody. Don't forget to share all of these books. And of course also this episode by Jochen and his own experience informed by his handball player and band player.

[C]

Also.

[B]

His experiences as an engineering leader. Jochen, if people want to connect with you, maybe ask you a few follow up questions, where can they find you?

[C]

Yeah, I think the simplest is to just reach out to me over LinkedIn. So my name is Jochen Ising. I think there are no other Jochen isings yet on LinkedIn, so it should be fairly easy to find me if you have trouble. Still, I'm currently working at Fan Ride, so you might add that to your search if you're curious about it. But yeah, that's usually where you get a hold of me, I think from a professional perspective.

[B]

Johan, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

[C]

Thanks a lot Roscoe and I was super happy to be here.

[A]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details at Scrum Master Toolbox because listening is great, it's important, but doing it together, that's next level. I'll see you in the community Slack.

[B]

We really hope you liked our show, and if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.