Dynamics Corner

Episode 332: In the Dynamics Corner Chair: Adapting Leadership Styles for Different Team Modes

• Christian Lenz • Season 3 • Episode 332

Share episode

When using Microsoft Dynamics 365 Business Central, there is a significant focus on the technological and developmental aspects of the team. One crucial but often overlooked concept is the management of a technology team. In this discussion, Christian Lenz joins Brad and Kris to explore the concept of elastic leadership and the different team modes – such as survival mode, learning mode, and self-organizing mode. The conversation also delves into the role of behavior in team dynamics and emphasizes the importance of ongoing expectation management.

Connect with Christian Lenz:
https://www.linkedin.com/in/curate-ideas/

Send us a text

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

Speaker 1:

Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics. Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365, this is your place to gain insights, learn new tricks and how to manage a team. I'm your co-host, chris.

Speaker 2:

This is Brad. This episode was recorded on July 17th 2024. Chris, Chris, Chris. A team, A team Building a team Working with a team A team could just be yourself too.

Speaker 1:

Maybe have a team.

Speaker 2:

I don't know, team of one, a team of one, I guess. I guess you could have a team of one. Today we had a great conversation all about teams, all about the phase the team is in, how to build your team, how do you grow your team and how to work with the team. Today we had the opportunity to speak with Christian Lentz. Christian good morning. How are you doing?

Speaker 3:

Yeah, good morning. I'm doing very well this morning or afternoon here in Germany. Yeah, I'm very happy that you approached me and that you're having me.

Speaker 2:

No, thank you very much for taking the time to speak with us today. I've been looking forward to speaking with you, as we are with every guest, and before we get into it, would you mind telling everyone a little bit about yourself?

Speaker 3:

Yeah, I'm working at a German partner for Microsoft Navision for nearly 28 years now and I'm in the field for Navision LAV BC for nearly 25 years. In the beginning, I was a finance consultant and after doing the first projects, I developed as a developer and worked as a developer many projects Back then. These were one-man shows in the early years, but the projects grew bigger. We need more people and I raised to a project manager where I worked many years, led development teams, consulting teams for for big and small projects, and decided in 2018 to shift in an internal role in our organization to bring this whole new stuff about going to the cloud and shifting to a, a language in development to to my colleagues just to condense it developing learning formats for my colleagues that they can pick up those big piles of information to to be able to maintain our customers, and I'm supporting that. I gave myself the role as development facilitator to make it easier for my colleagues to, yeah, get everything they need to know for the process.

Speaker 1:

That's awesome. Make it easier, make it easy.

Speaker 2:

Excellent, excellent. No, that's nice. It sounds like you've been around doing this for quite a while, as they say. There's a lot of us around here and one of the things that I wanted to talk with you about that I saw that you promote is a sense of team modes and leadership. I know that you talked about that. I seen some of the information that you have posted on that. I have shared with that. I just wanted to talk a little bit more about that and how that fits, you know, obviously with the sounds of your history and with the current role that you have, as well as within a business central type of role.

Speaker 3:

Yeah, I came upon this topic of elastic leadership and the different team modes and to adapt the leadership style. Came upon this topic of elastic leadership and different team modes and to adapt the leadership style. While taking a look outside the Microsoft bubble. I'm going to other conferences and during the pandemic many things got to another mode and virtual conferences, so it was very easy to participate in those as well. And then I learned this elastic leadership model, which was developed by ryan osheroff, and it was very, very good to see that you don't have to be a certain kind of leader.

Speaker 3:

It is often expected from from you as a team lead or a project lead or something like that. Just look at in which phase your team is in and then adapt your leadership style so you don't have one size fits all leadership style, which is really hard to maintain and often not the appropriate mode, just to be able. What should I observe and what can I do to assess the phases my team is in? Are they in survival mode, are they ready to be in the learning phase and are they ready to be in the self-organizing phase? Everyone was expecting in the last years and my experience was that many company managers forced teams to switch to self-organizing mode in an instant, while being in survival mode, just jumping too quick from the survival mode and thinking, yeah, let's all be self-organized as the solution for all our problems, and that didn't work out very well. So you have to assess in which phase you're in and then, when you're not in the right phase, what can you do to go to the next phase?

Speaker 2:

You hit on some points.

Speaker 3:

Yeah.

Speaker 2:

Just with that there, but before we get a little bit deeper, you mentioned elastic leadership and, based on the conversation you just had, I have a good understanding of what elastic leadership is. But can you tell us what elastic leadership is?

Speaker 3:

Yeah, it's this adaptive leadership style. It's, uh, yeah, adapting to the faces your, your team is in, your other people you're in. So the base um assumption is you can grow your team and then think of okay, what is the appropriate leadership style in this phase and the the goal to grow the team to a self-organizing team doesn't mean it stays there, so it can shift back to to another team, to another phase, back to survival mode, and then also be elastic in your leadership style and adapted to the phase the team is in this moment and then perhaps act more like a captain of a ship instead of the facilitator role you have when you are with a self-organizing team. Self-organizing team.

Speaker 2:

With that elastic leadership model, is the leadership group consistent or would you have different leadership based on the phase that the team is in? So I understand it's an adaptive model, but is it adaptive to the sense where a person would change the leadership role or is it? Just the leadership style.

Speaker 3:

It's more the leadership style, regardless of who is the leader in this phase. It could be a designated team lead or it could be a team member who is taking the role of a leader. And then it is more about the behavior. It is more about how do I interact, how do I communicate with, with the team members, and something like that and, adapted to the face, you're currently in the team see Brad behavior.

Speaker 2:

I'm kind of speechless because it's it's. So much comes to my mind, because of the points that you have made, that things are different now in the way that we work as a group, the way that we work as people and, as you mentioned, there's different phases of projects, right? So if you're working on projects, whatever it may be, or even the development of a new team for a new group or a new project, you have different levels and I think there's a lot of times there's an assumption made that everybody works and thinks the same. Therefore, the leadership style is consistent throughout, where, in reality, as you're saying it's, it's almost behavioral based in a sense.

Speaker 3:

yeah, it's about how you, how you communicate with the team and with your communication you shape the conditions for the team.

Speaker 3:

For example, in this mode I think we have to talk about what is the definition of survival mode in this model. In this model, survival mode means that you don't have time to learn, so you're constantly fixing fires, you're constantly busy with acting on starting to build features and finishing them and everything like that, and you're not able to pick up new things. And in this VC space and for us, as old enough dinosaurs, many new things came up and we were very struggling with how can we get the time to soak this up and be able to maintain our customers in the new world and bring them there. So this was kind of a survival mode for us, even if we are not really projects that are forcing us to fix files all the time. But if we have no time to learn at some point in time, we are not able to maintain our customers with this product. So, coming to this, we need to make time and that is something you can do with some methods.

Speaker 1:

I learned and I taught at workshops excellent when you're in survival mode, do you? And some are fast learners and can get to self-managing. Is it more of an individual approach with different modes, versus the entire group, because sometimes you have different levels of skill set? So is that how do you manage that? When you have like, for example, you have younger talents. Someone new may not understand your internal process, so in many cases they're surviving as well. Is that is my understanding? Correct you? These team modes can also be individual team members as well? That you're okay?

Speaker 3:

It could be okay, could be it could be, and the tendency is that those fast learners pick up many tasks because they get features done and this, on the one hand side, relieves the team of some of the stresses they are in in the project, but on the other hand, the team is in very high risk if these fast learners are not available and cannot pick up something else.

Speaker 3:

So one of the aspects is that you look at your best factors in your team, which means how many people need to get hit by a bus to stop the team from working, whereas the bus factor of one is the riskiest. And if you look close into these teams with different skilled people and when you have different talents that are needed, you get in this situation very early. And to remove these best factors is to make free time to learn that others can learn these skills as well. So you distribute the knowledge you need to have in this team for more team members so that you get more free time in the next phases that you get more free time in the next phases.

Speaker 2:

Take it a step back. We talked about survival mode and we talked about the elastic leadership. What are the modes that a team would fall into within these leadership styles? So we talked about I think I heard you mention survival learning. What are the other phases of this process? I think I heard you mention survival learning. What are the other phases of this process, and are they linear or does it vary from project to project, team to team?

Speaker 3:

I would say it's varying, it is not linear and you stay there. So the three modes that are described as survival mode. Then the next phase is the learning phase. The learning mode and then the self-organizing mode, which is the goal mode you want to grow your team into. But there could be some disruptive technology and you are back in the survival mode. So you have to look at is there something my team needs to grow into? So I have to make time for them to be able to teach them these new technologies, for example.

Speaker 3:

So I have to be adaptive in this phase. For example, when a new technology puts the team into survival mode. You have to be very direct with your commitments so you cannot put your commitments as you did when you were in your self organizing mode, because you need very much time to do the things with new technologies or new methods or something like that. So as a team lead, you have to be very strict in this phase with keeping the commitments, making the commitments and making your team members thinking about what they can really commit to, to keep some free time to go through the learning phase. When you're coming back into survival mode, then you take back the strict mode of leadership style and just look around how are they doing? Do they have all what they need? And something like that. Do you need something for me? So you're acting differently in those phases.

Speaker 2:

Excellent, those phases, excellent. Now I still have so many leadership questions with this. It's one of the things even that you talk about. It's the survival mode, because then I think of the survival mode as you talked about, like if you have to learn something new and the benefits of learning something new, but also when someone is in survival mode, I also think of like the crisis and the stress and the anxiety of them as well too, and then the impact on the team and the benefits of learning something new. But also when someone is in survival mode, I also think of like the crisis and the stress and the anxiety of them as well too, and then the impact on the team and the impact on the output. And also you talked about retaining customers, or retaining or maintaining success based upon being in survival mode or not and not having the opportunity. And there has to be a balance, I think right, a balance between someone being in survival mode, where you know, again, survival is like that you know fight or flight, you know aggression uh, typically a little bit more stressful. You're trying to get things done.

Speaker 2:

You talked about the firefights and then also is with that, okay, now we need to take some time to upskill or reskill our team to be able to work with whatever change may come that would drop us into survival mode.

Speaker 2:

How do you assess the value of the learning and then the output and the effect on the team learning and then the output and the effect on the team, because that is also a challenge of if you take a look at. You talked about development. You know al development, this changes to the al language, this changes to the business central application, and this is even more so now and it's like my question that I'll have in perpetuity probably. How do you keep up is the question that I ask everybody, because we have so many rapid changes coming from the application point of view itself, the development environment. On top of that add solutions and technologies that integrate with the introduction of Power Platform, power BI, and you have some of these data-driven events within Azure. How do you assess all that and keep all that contained with the team and the group while still moving forward?

Speaker 3:

I think how we approached this is that we created safe spaces where this daily operational mode is suspended. So what we try to establish is a format I called learning sprints Back in the time when we weren't agile, and sprints nobody knew about, just me and something like that. It was a bet for me to bring in this term, possibly loaded with positive experiences, so that is good to pick up. When we switch to these agile modes, we we tried, after every developer was educated in AL, how can we keep up this knowledge when the first projects with VC and AL will come, which could be for some of our colleagues, three years ahead, depending on the projects they're actually in back then, when they had NAD projects and we conducted small learning phases for four or five days and let the people work on what they ever wanted to work on, as long as they use AR language and the new tools, but not alone. I was in this role who was educated a little bit more and had my ear on the community and was hearing what is needed in this current moment, in this phase we are actually in. So I was one of those two people we also put in those sprints who could give some input and offer some help for the colleagues. And that was a learning opportunity for our colleagues. That was very well accepted. So they could pick their challenge, what they want to work on, and they had at least two people who can help them go in the first steps, but with a real thing they wanted to develop. It wasn't necessary that it was for a customer project, it could be, as long as it was intriguing them to make something new. As it was intriguing them to make something new and in the end, after the four or five days, something new is visible in the product that didn't exist before. So that was the principle we had.

Speaker 3:

We were very strict on this time. It was not allowed to put any new task during this learning sprint for them, to put any new task during this learning sprint for them. So I as a conductor was very strict on keeping everything from outside, from my colleagues away, and I was very strict on there must be something visible that you can get feedback when something is using it. But everything else they can manage for themselves. I just hold the space for them and so spending the daily business was the key there. We had three to six colleagues in each sprint, which we didn't pick. Why are they on the same team or are they in the project we picked them? Who is in a phase there? He's not assigned to a project or something like that, so we can pick some people together and conduct the sprint, and we made this over three years, I think 10 or 12 times.

Speaker 2:

So three years, 10 or 12 times. So you're doing it about four times a year with your group and then that also does help them become more comfortable, get out of survival mode and also for lack of better terms better service their customers or your customers.

Speaker 3:

And they were allowed to pick any topic they like For your customers. And they were allowed to pick any topic they like. In the first phases it was AL VS Code and having source code management and something like that. We started with the basics and we tried to bring something new for every colleague but, as you mentioned, you have different skill levels but you can react on it. So we didn't put a class there. So you have your pre-configured exercises or something like that, because everybody was allowed to work on their task for his or her own and we, as the facilitators for this format, were able to help everybody.

Speaker 3:

And if someone has a problem, we're sitting in the same room. Somebody can just come up and look at it and help this person who has a problem right at this stage, this person who has a problem right at this stage. So this was very convenient because they were not forced to follow the agenda or the curriculum of something we prepared in advance, like this is in the projects you don't know what you get at your next task or what the customer wants to know the next day or something like that. So we just tried to let them have the experience of helping each other, because it is so easy to ask someone to learn the new stuff, regardless on which skill level you are, and that we try to maintain during the years.

Speaker 3:

And then the next time we had while we were in CAL and NAV, we put the main topic of events inside it, because many of those developers who were in projects with NAV needed to learn how to work with events in the code to have a code that can be converted to AL better in the future and get the modifications out of the base app. So we set a theme for each of those learning sprints, but we could adapt on the skill level of each one. So that was something we we developed and adapted as needed as the whole skill level of our developers grew over the time and even now if we have new things. If someone thinks, okay, automated testing is a topic that we should elaborate on that, okay, we conduct a learning sprint on that so they can learn, but they are not forced inside a real customer project, but they need to have something developed after those I do have a quick comment.

Speaker 1:

It's quite interesting that you're maybe from my perspective here that you're treating training and the learning aspect as if it's a and you mentioned sprint. It's almost as if it's a project base. Is that what you're doing so that you can keep track of, you know specific sprints? To say, hey, this is what we're going to be focusing on for the next two weeks, this is what, in this case, you talked about events. Is that the approach that people should consider when you're working with your team? Say, hey, we're going to be focusing on one thing. This sprint is to learn this.

Speaker 3:

We didn't organize our work in sprints. Back then when we developed this format, the main aspect was to suspend the daily business so make a safe learning space, because they had no other commitment than being in the sprint and developing something and learning something new. That was the main aspect. We had a certain time frame so it was easier for them to know okay, I have to manage in advance. I can do something within this four or five days, within this four or five days. So I have to reduce my commitments or fulfill my commitments before this sprint starts, or remove those commitments after the sprint. And the length of four or five days for a learning phase was a little bit hard to negotiate with our upper management because it is some time where they can work on projects and something like that. But it had a very good outcome of leveraging the skills and reducing the anxiety of am I able to program in AL with all the new tools in the future?

Speaker 1:

It's a long-term investment program in AL with all the new tools in the future.

Speaker 2:

It's a long-term investment. There's a number of ways to look at that and a number of challenges I see with that. You hit the point of you know, sometimes upper management may not see the value in taking that time in a for lack of better terms, controlled environment to raise the skill level, which would also allow you to create better products that you deliver and in a more efficient manner. Because I think we've all been there you know you could work with skilled and you know highly skilled, skilled and less skilled team members and the output is different and that output could put you in a box in the future potentially or create other issues. So having the opportunity to do that it's investing in the future. I guess you could say. I see a couple of challenges with this and I have some questions or your thoughts on this.

Speaker 2:

In this mode that we're in here, one team size has an impact because if you have 10, we're talking development, in this case AL developers 10 AL developers you can afford the opportunity to say, okay, well, two or three can go through this training phase. If you have a hundred, you can still keep that same two or three or go with a larger group. If you are a smaller group. I don't know if you can be afforded to suspend operations for a period of time. So that's one challenge that I wonder how one could combat that, if you have any ideas. And then two, you mentioned a great peer review type or peer. You know serendipitous learning, you know you're learning with everybody in the same room. How does remote work factor into that? Because remote management alone has its challenges, because individuals sometimes feel isolated or they're separated, they're less likely to seek assistance. So with this type of survival mode and leadership and elastic leadership, is it geared more towards in-person management, remote management, hybrid management? How could we handle some of those challenges?

Speaker 3:

I would say that it is about how you deal with your commitments when it depends on the team size, because we had team members in the sprints who are one or two person size teams. So with two persons they could manage to delegate their issues and for some people who have very specific knowledge and specific tasks, it was very hard to be out of business for five days or something like that. We shifted the mode a little bit five days or something like that. We shifted the mode a little bit so we just conducted it per day from 9 to 3 or 9 to 4, for example, so they could manage to handle the requests before and after the sprint each day. So we adapted this as well. In the beginning we said no interruptions allowed during the sprint and we made it a full day. And some of the colleagues who were in this exact situation said that's too hard for me and we adapted it a little bit. We shortened the time per day so they can manage in the morning or in the afternoons to deal with the urgent cases if they can't reduce their commitments. But it is very important to negotiate isn't something that can wait until after the sprint or if there is really nobody who can pick up the task during the sprints and adapting the commitments freed the space and that was key to that.

Speaker 3:

And the experience with remote work is, I think the elastic leadership model and the team faces are not tied to. Is it remote or is it in person? I think that it can be used for all settings because it is not that tied to it. In my experience in the first phases it's really good, especially in the survival mode phase, to bring the people together or have something if it needs to be remotely, to build some team trust. And if the pandemic hit us, I was in the situation that we got new colleagues and that we had to conduct those learning sprints remotely via Teams. But it worked out well because before the pandemic we had, together with this group of people, one learning sprint in person. So if you do this in person up front, it's very, very easy to do it remotely as well, because the trust was there, they knew how it is done and what happens and something like that.

Speaker 2:

Chris and I think a lot alike, and I'll jump in there, chris. See, I'm talking louder.

Speaker 1:

No, I'm just yeah, no, go ahead, cause it got me thinking a lot of the things that you had, um, uh, you had mentioned about. For me, it's always about that, um, when you bring in a new talent or someone new or you're, you know, building a team, uh, everybody has different learning skills. Everybody has a different behavior, what you mentioned earlier, and sometimes I don't know if it's a cultural thing, maybe it's a different country. Wherever you're at in your case, germany or here in the US it's like, how do you convince others to also teach others? Right it's.

Speaker 1:

It's always like I don't have time for that. I am in the middle of learning, right? So, okay, once you're done learning, can you teach others? It's like, well, now I got to do, maybe they go back to survival mode or they go back to learning something else. It's always kind of a challenge, in least in my career. Sometimes they'll get there, sometimes just takes a little bit longer, but they just some people just don't have that mindset of like, okay, I want to teach others, and it's like I'm just here for myself. I'm like, how do you manage that? Like especially remote too, right it's. That's also difficult at the same time.

Speaker 3:

Yeah, I think it's hard to convince someone with this because you cannot force someone to change his mindset to being able to teach someone something. So you can offer the opportunity, a safe space to hey, let's try this out and invite someone. In parallel to the Elastic Leadership model, I had an education on future leadership and some of the system salary things here in Germany which got me thinking about not jumping too early, seeing someone's personality as a problem. So my point of view is can I build a structure in our organization in our case this learning sprints where someone has the opportunity to try out teaching someone something very easy in a safe space, even if they are together, they have someone like me, like a facilitator who tries to get some commitments on that and explaining what is the benefit of doing it. So the role of a team leader in this phase is see the benefit when you teach the knowledge you have to someone else. What is good for the team and for the company for this.

Speaker 3:

This education or this conversation is easier to have one-on-one and not on dailies or something like that, or stand-up meetings with those people who are not that easy jump into this teaching role, but the possibility could be they can be in those situations and just observing how someone else is doing it, just have the experience. So my main theme was let the members in the sprints have the experience how it feels to jump into these learning ravines where I'm extremely slow at what, I'm very fast about it Because I have to learn it for myself or teach it someone else or something like that. But after this experience then decide can I do it in the future or not? And offering this space, this experience space, is something I think a leader or management can do in this organization.

Speaker 2:

It's see I'm circling back to a couple points here. The learning I like the approach of seeing someone's capability versus making a quick assessment, because as somebody goes through the process they could also get an understanding and also grow and build. Also, what you had mentioned before was the trust, which I go back to a lot of times, even with customer projects and projects or even these remote meetings, that we have, why I'm always and have always been a big advocate for having cameras on, because even in a remote environment you can build some sort of trust, because you can see reactions, you can see manners, you can learn a lot about who you're talking with and their reactions when you can see them, even if you're not in the same room, and you can feel the energy in the room about that. And then it is so true because with the in-person meeting and then going into the remote sessions because over the years I've had projects, situations, meetings, acquaintances, whatever you would like, that I've talked to only remotely Then I met them in person. Then you know one, when we met we were like, you know, great friends, if you could say that right or we felt like we knew each other really well, and then the relationship blossomed even further afterwards because we had that in-person interaction.

Speaker 2:

And to the other point Chris I think you were talking about is I do think there's a point where you have to put individual or talent in a position to where they can be successful, because not every person can do a function, whatever that function may be. In life. Like, I know some amazing developers and I'm like oh, they're amazing developers, they can do great things. Let's make them the development manager, for example. Just because you develop doesn't mean you can teach or manage other developers right. So to your point it's you have to have some sort of assessment process to see is this person, can they fit that role?

Speaker 2:

And if they can't fit the role, it doesn't mean they're not a good fit. If someone else can fit that role, then you have a role for that person, right? Everybody has a role and everybody should be in a role where they can be successful. If an organization doesn't have room for somebody, it's unfortunate that maybe you have to figure you know, figure out how to handle that situation. But I see in so many cases where people are being pushed not out of their comfort zone because there is a good thing with a little bit challenge, but put into a position where you know it's like dropping someone into an ocean that doesn't know how to swim. Right, you know they can walk and run and they're a great athlete, but then you just go drop them in the ocean, assuming that they're going to know how to swim, and they end up becoming or having a problem.

Speaker 1:

Just put them at the pool, then see if they can actually learn how to swim.

Speaker 2:

Well, that's what. That's what Christian was saying as you take them to the pool and you see, you know, see how they handle, you know the shallow end and the deep end and if they can't swim in the deep end, then you don't put them in the ocean. You talk with them and you figure out. Maybe we need to give you swimming lessons or maybe they don't want to swim.

Speaker 1:

Yeah, I do like the safe space of experience because, like I said, sometimes you give it a shot and they may end up liking it or at least they have an understanding. I think to me it's important for them to experience the process and at least they understand. They may not want to do it, they may not be something they'll ever do, but for them to have an understanding. I think it creates that sense of respect, of like what that role really takes at the same time. So I'm learning a lot in this conversation. My mind is still going.

Speaker 2:

So we've talked a little bit about survival mode and how we can survive. You know, many songs are jumping into my head. Another layer or method or stage is the self-organization layer. Right, self-organization to me is almost, you know, I pictured or visualize as you were talking is okay. So now you know, I'm a parent, I have five kids, I've raised them and I just throw them in the backyard and go let's see what you, let's see what everybody can do, right, so you know, and then hopefully they figure out who can be the leader, who can cut the grass, who can do whatever, right, they kind of figure out and self-assess the role of what needs to be done to survive and kind of fall into place. Is that what this means?

Speaker 3:

Yeah, the comparison with raising childs Roy had in some of his talks too, but more in the learning phase. So when you get the first kid you're not prepared and you're not prepared and you're learning to do how to raise a kid and something like that. So I have just one son and those who have more kids are developing their skills. But I think it's more about the space you create there and not putting too much assumptions on the individual and with that you know who can handle something like that. In the original model the self-organization phase is described as can the team members handle unknown situations if they don't know what to do? So can they create a problem-solving condition even if they don't know how they do it? But can they do it? Or do they need someone else to do it outside of the team? So a team lead or something like that. That is the definition of the self-organizing mode. Are they able to solve the problem if they don't know how to solve the problem?

Speaker 2:

I like that. I'm speechless on that one because that is also in doing. What we all do is you are faced with a lot of challenges, you are faced with a lot of problems and it's how, as you had mentioned, how do I solve the problem when I don't know the problem? So you have to figure out how to solve the problem as well as solve the problem, uh, in the case. And then sometimes I I talk with a lot of peers and I say sometimes, if you don't know how to solve the problem, knowing that you don't know how to solve the problem helps you solve the problem, because you can put someone in the case. You talked about customer projects. If a customer comes to you with a problem, if you assess how to solve the problem, you realize you don't know how to solve the problem. Getting them in contact with someone who can solve their problem in essence is solving the problem from your part.

Speaker 3:

And part of developing this skill is during the problem from your part, and part of developing this skill is during the learning phase. As an experienced team lead, for example, teach how to ask the right questions in these situations where you don't know how can I solve the problem, and that is a skill itself you can teach. But what you often cannot teach is the talent that when you know ah, there could be some of my colleagues he has ideas. When it is this recurring topic like inventory valuation or something like that, I go to this colleague and then you describe the problem to this colleague and he gets an idea and that is giving a direction where you can look to solve this problem. But he cannot explain how he does it.

Speaker 3:

He has a certain talent to create a problem-solving situation because you have more options to think of for your solution for a problem or something like that, and you just have to be aware is there some knowledge still exists and is it documented? That is one thing. But if there is no knowledge, then you are good to ask who who has an idea how to solve this problem if this idea doesn't come to yourself. So that is very, very good approach to to do this and I teach this to my colleagues as well, because the old notion is in back and back in the days of an AV and and everybody knows how to do any programming or something like that. Whereas the it's documented Is it in the internet, in the docs or something like that. But now there are so many situations where you don't know something. Then you have just to ask who can help me with that or who has an idea how to solve it. Because asking how is not the right question. Question because the knowledge doesn't exist. So, depending on some talent, who has an idea?

Speaker 1:

You know it's interesting that, you know. I know Brad and I have this conversation outside about. You know, managing team members in working with leading with team members is like. You know, you can teach processes, you can teach the knowledge that they need, but it's very difficult to teach anyone passion and drive and desire. Um, you know, looking for answer, I can, you know, you can give them all the tools you need, but if their behavior or they don't have the desire to even look it, it means nothing, right? So, um, I think that's an important thing to note that a lot of that you know. You. You have to encourage them.

Speaker 3:

When you are in this survival mode. There's a tool that's called the influence forces. So you look on the influence forces on the personal level, on the social level and on the environmental level, which is mainly the organization setup. So is someone personally skilled and motivated to adopt some new thing like automated testing or something like that, and then assess, if it is true, is the social environment his, his team, his peers skilled and motivated to enforce this good behavior? It's always about behavior. It's not about is he or she motivated or not, because I cannot look into the mind of the person and really see if the motivation is there or not. I assume it is.

Speaker 3:

Then you have the level of the organization. Is there some bonus structure or pay structure or team structure or structures in the building and forcing or blocking the behavior we want to see? So this assessment helps on which level you have to change and you have to address every level to be on the right track. I would say it's not guaranteeing that you are successful, but you are very likely to see the desired behavior when you address every level.

Speaker 2:

I love that word behavior, and it does. It goes back to the learning phase, because humans are behavioral people. It's you learn from behaviors, you learn from your experiences. So it's the behavior that you enforce that also drives where somebody will be in the future, right? So it talks about the behavior of asking questions, the behavior of you know. If they ask how and you always give them the answer, then they don't learn. You know they don't learn how to problem solve, for example, or the process of problem solving. It's this person is always going to do it for me, um, and just, yeah, I think of so many behavioral experiences where I'm like you know some, some individuals that I speak to, they create their own problems in the sense because of the behavior they promoted.

Speaker 2:

Realize that working and managing with a team is sometimes you may support or enforce behaviors that are not favorable behaviors and then you pay for that in the long term a number of different ways. So it's, um, it's important, uh, and we're talking about that learning phase as well, which is the other phase that I wanted to of the three phases that we talked about with the survival phase, learning phase and the self-organization phase, which I still picture a bunch of people just sitting out in the backyard figuring out who's the leader, who's the digger, who's the lawnmower who's the planter, who's the harvester?

Speaker 3:

And when you just put a team into, now you are self-organized, you can decide everything on yourself. That's not putting them in self-organizing mode, that's putting them in survival mode, getting every building they have and putting them on a lawn and there's nothing that can shield them from the weather or something. So you have to think are they ready to be put on self-organizing mode? Yes, we want to grow you into self-organizing mode, but it's not something we can just decide. And now you can pick and rip every structure off, because the structures you gave them in advance and you have they have a purpose and they are for good reasons there. But are they blocking growing or are they enforcing growing? That is what you have to look at on the organizational level and on the management level it's so important to think of a team when you're in an organization.

Speaker 2:

Again we talk about with business central. Again a business central implementation be a number of different ways. You can be a an isv that has a solution that gets implemented. You have a project to develop an extension or an application. You have a team to develop that extension. You have a partner bar whatever that they're called these days. It's like everything else. I think their names change over the course of time.

Speaker 3:

We have both in our organization. We are as well VAR and ISV.

Speaker 2:

In that group you have the VAR that manages customer projects and then, depending upon which I'm going to touch on that in a moment and then you also may have the customer side, which is a user of the business central application, and you'll have teams to uh. You know your daily functions, whatever those functions may be, whether they're operational uh departments using the business center application or maybe an internal team for managing the business central application, whether it's self-development, implementation, training or the like. But go back to the VAR type scenario. So in the VAR type scenario you have customers.

Speaker 2:

Unless you're a really specialized VAR, you may have different customers come to you, different size projects come to you, and in those projects you may not have the need for the same team, and what I mean by that is you may have a project come in excuse me, that's just some small implementation, training type. You know, no modifications required. You can handle it with one or two people. There may be some larger implementations where you come in and you may need you know need four developers, two functional consultants and a project manager. So they're all varying sizes. How does that work in this scenario where you have teams that in essence divided and shifted based upon requirements or need for the project, so that team that you had is no longer a team. Now you have a variable team and if I'm in a VAR, I could work on project A, project B and project C as all part of different teams.

Speaker 3:

Yeah, we have this situation for decades in our company situation for decades in our company, shifting and often more than one project at the same time for a project manager and with different team members, and something like that. What is, I think, independent is that you have to look are the skills to do this project covered by those people? And often it's not, because we need some help from some VARs as well or from some ISVs to manage the project. So many projects consist of a mixture of employees of our company and other companies as well and you have to assess as a project lead, are the skills here, are the information clear? Is the goal clear and is on the customer side and on the project manager on the customer side, everything set up?

Speaker 3:

And are they in survival mode as well, or are they in a self-organizing mode where we can act together as a team, or not? So the principles I would say are applicable to this scenario as well Assessing in which phase is this team and then adapting to it. And if you are in survival mode, the first thing is think about your commitments and mainly you got into survival mode because what reason it could be, you are overcommitted and then talk about the commitments and reducing the commitments, so you can lower the stress and manage the expectations between what this project team wants to deliver and what the customer expects to receive.

Speaker 2:

Stress. I'm longing for the day when there isn't stress. I don't even think I know what that is. I think if I didn't have any stress, I would be stressed for not having stress because I wouldn't know how to handle not having stress because it's a behavior that I learned.

Speaker 1:

You'd wonder why there's no stress. Is something wrong then? You'd wonder why there's no stress. Is something wrong then?

Speaker 2:

Exactly Because you're so used to it. Yes, if I had a day go by where I didn't have any stress, I do I think there would be something wrong.

Speaker 1:

You'd stress out that maybe something's wrong.

Speaker 3:

I would, I would. The main thing is mainly when you get into the survival mode. It's because some people jump too early on commitments they should not give or didn't think of. Do they have everything in control to give those commitments?

Speaker 2:

You just opened up a whole new can of worms with overcommitting. And you know it's.

Speaker 3:

In this model. It's a whole topic and that is a section I taught the participants of the workshop at EasyTech Days. It's about commitment language. That is one of the first things you teach your team.

Speaker 3:

To get out of survival mode and being able to shift into learning mode is to think about how you make commitments and how you communicate them. And that is a small phrase you can put. It's I will be doing something by a certain date and then you can fill something like that so this I will states that would be a real state in the future, and this phrase by adds the time frame. But this allows to do it earlier, but at least at some point in the time. And when you speak like that, it feels awkward if you're not coming up to this commitment. And that is something you can teach your team in the first phases, because cutting these commitments is very important to have more slack time to learn more, and often it is what commitments did we give and we cannot live up? To Look at the timeframe in the next 30 days, reduce the commitments and hold the commitments until this time frame and after that have free time to learn something new, to distribute the knowledge in the group, or something like that.

Speaker 2:

That is a great approach, chris. Listen, it sounds familiar, doesn't it? Because I am an advocate for that type of process. Because if you give a commitment to a customer telling you'll have something done by a certain date, if you get that done early and give it to them, they're happy, you can give it to them. You could have 10 tasks that you have commitment dates for, and and on nine of them come in early because everything worked well right. You always give yourself some slack that I'll talk about in a moment too. And then the 10th one, you deliver on the day that you said you would. They'd be like oh you know, you usually come in early. I was kind of expecting to come in early. You can still say we at least met the date that we said we would meet which goes with commitments is.

Speaker 2:

I'm an advocate for realistic expectations and commitments because if you tell a customer or a person something will be done by or on a date, if you meet that date, they're happy, even if that date's sometimes months in the future again, depending upon what it is and in which type of crisis they're in. You know state of emergency. But most people, if you communicate when something will be done and you meet that date, they're fine. It's when you may not give them a date. Or you give them an unreasonable date like, oh, I'll do this tomorrow and you never make it because you may have another crisis come in that has a different priority, or somebody gets sick or something like that, and that's something else we need to work on teaching right it's under promise so we deliver

Speaker 2:

well it's. You also have to leave some room. Depending upon what you have in your team. You do have to give yourself some room, and people forget to do that at times. If you you're in a bar, you may have multiple projects. You may have emergencies come in that somebody may need to focus on, or even on a project team. You could have things such as illness. You have to account for some of those things and no one ever said that you can't deliver early. You just have to deliver by a date. But you still need to have some room in there for unforeseen circumstances.

Speaker 3:

And it doesn't mean that you are not pushing commitments away or something like that, so you cannot keep up to every commitment you make, because you said there can be some circumstances that you cannot influence but also teach the team to raise a red flag on the moment they see that they cannot live up to this commitment and speak about the why can I not commit to that anymore? Or why can I not commit to this initially and talk about this? Why and this reason is something you try to foster Do you have this conversation about that?

Speaker 1:

Yes, you have to encourage that because sometimes, when you know maybe it's embedded to many where you're not, if you're not going to meet it, you're afraid to say it. So you have to create that culture within your organization that it is okay to tell us like hey, we're five days to the deadline and I don't think I'm going to make it. Can I get some help? A lot of times people have a hard time saying that it's like I got five days, I still got to do it, versus raising the red flag ahead of time.

Speaker 2:

No, it's a behavior that needs to be. You should just post this stuff all over, because in doing what we do, everyone thinks of the technical side, everyone thinks of the application side. They forget about what I call the human side. Right, the human side is the accomplishment of the work.

Speaker 2:

Yes, you can use some tools to do the stuff, but, as Chris had mentioned, most people for some reason are intimidated or fearful from some learned behavior. That saying I have a problem early on is hurtful, where sometimes it's beneficial because you can get the right help, or you can get another talent to come in and help you, or you could get it some additional training, you know, to kind of steer you so that you can complete your task on time, reducing the stress. You know having the satisfaction that you completed a task on time or, if it's something that was misassigned, that maybe after further review, that the talent that's working on it isn't the right, you know the right role for that task. Taking it off their plate reduces the stress as well, too, so that they can be productive and complete other tasks.

Speaker 1:

Yeah, and you also have to think about it kind of beyond that too, right, and that's just kind of an internal conversation. You foster that, you encourage that, you encourage that and you allow them to do that. But also it goes to the client side you mentioned. We mentioned about communication Brad and I always talk about. You know, effective communication that if you raise a red flag ahead of time and you tell the customer and say, hey, I know we have this deadline, we do have to push for it and you can give whatever necessary information you need to give From a customer's perspective I've been on that side too.

Speaker 1:

I will respect that more to let me know like hey, yes, we're still a week, you're letting me in though, ahead of time. I feel better as a customer to know that it's no different when I ever like for example, I just got a retaining wall done and they're very communicative throughout the process where you know the project manager told me, it's like hey, we're, you know we're about two days off. Is that okay For me? I'm like thanks for letting me know ahead of time. Yes, I'm okay with that. But for some reason we've created this unnecessary fear to communicate that with a client Like it doesn't make sense to me, just communicate it. You know, and in many cases they understand.

Speaker 3:

Yeah, because you manage the expectations. And when you manage the expectations regularly throughout the project phase, it's very more likely that the customer gets what he expected. And this experience is building the trust. The trust comes when I get what I expected and not because someone told me I have to trust, because it's about the experience and we we have um an exercise in in this workshop and I did it as well when when I was on the master class at voyager Oshirov two years ago Speaking about this whole morning and then before the lunch break being a small team forced into survival mode and see how I can apply what I learned in the morning.

Speaker 3:

This exercise is about being in survival mode and getting the team out of survival mode. That is one task and the other task is does what you build meet the expectations of the customer, so that the customer who is giving a certain task to the team and then you have to manage this, and it's very, very grounding to have this experience in this exercise, that you struggle to do this, and that is an experience for workshop participants. Okay, I learned this the whole day. It's a total different thing when I return to my project on Monday next week, next week. So what I took away is this whole topic of expectation management, ongoing expectation management and when you train your team in this or yourself in this, it's not that great scary thing to talk with customers that you cannot hold your commitments or something like that because you want to have a managed expectation. And that is the whole view shift I had for my project management abilities as well and about the keeping the commitments.

Speaker 3:

I also had a personal experience for my workshops, because one day with our son, I had an argument why he is not holding his commitments. He said to me yes, I will do it tomorrow. And the other day I come and I'm talking as a dad. And the other day I come and I'm talking as a dad. And one day he said to me I say I will do it because you're not allowing me to say no, because when I say no, you don't stop talking. So I'm just saying yes because I want you to stop talking. And that was very, very grounding. It's like the universe is pressing the pause button and saying he's totally right. And then we shifted this mode and we came to okay, you can say no and let's talk about why, but I accept it. I don't try to convince you just with talking on and on and on. That is a personal experience I have with this commitment topic it.

Speaker 1:

It's. It's so funny because it's a lot of the things that we do at work here. You know, just professional career can bleed into, you know, family as well. It's very similar approaches.

Speaker 2:

It does.

Speaker 1:

Yeah.

Speaker 2:

But you hit the key point too. It's okay to say no in a sense and discuss why it can't be no, because that can educate whomever asked the question. I'm just trying to generalize it. Right, because you talked about something with your son, but this could be the same thing at work, right? Just because somebody says no doesn't mean that they don't have a valid reason for saying no, or it doesn't mean that they just want to say no, I don't feel like doing it. There could be a valid reason why they can't do it, and then being able to discuss it, then you can make the determination. Is the reason really valid? Meaning I'm saying no because I have another commitment, right? Or I'm foregoing because I have another commitment. So maybe then you can discuss which commitment has the higher priority, or maybe it's okay, you can't do that. Let's work with the scheduling. And then also, even in doing that case and it goes with what I say with like arguments, right, I don't believe in arguing any more in my life, right? Or arguing because it doesn't get anywhere.

Speaker 2:

Sometimes, a lot of times, people have these discussions. They just want it to be understood or heard. So if you have these types of conversations, I may not to use it loosely, loosely get something that I wanted, but at least if I feel that somebody understood what I said, I feel a lot better. Right and I may not, you know, you know that whole saying like some. You know people argue to be right, right, but in reality they argue to be understood. So that understanding and having a conversation versus you just do what I say, you have better acceptance on the other end as well.

Speaker 3:

And when you have these discussions it's really helpful to also see it from the perspective from which role? Does this not committing come or does this? No come, not putting too early personal psychological things into the reasoning. I had the strong argument when I invited our management team into one of those learning sprints because in the early phases I said to them even if you are not not a developer, I will conduct a learning sprint for you, I will guide you through it, just to let you have the experience what my colleagues go through here, how we do it and what what it makes with them during those days. So after two years they said, okay, let's do it, but we got to have it in two days and I said, no, at least three days, even four would be better.

Speaker 3:

And then we got a strong argument and I reacted more heavy than I would now because I didn't see that my manager was acting from his negotiator role. He's a trader, so what he does is trading and I was very upset because I had the experience and something like that. So it helped me a lot afterwards to look upon okay, he's acting from his management role, it's trading, what his job is and it's my job to say, in two days I cannot do it. Do it in three days or leave it. And we conducted this sprint in three days and afterwards it was it could be one day more, I think.

Speaker 2:

No, that's good perspective Perspective plays an important part in understanding of other people's perspectives. It plays an important part, I think, everywhere in life.

Speaker 3:

So context and personas is also very, very important and that is why I like this influence forces tool in this model very much, because you can see on which level personal, social or environmental are blockers, Something like that. Do the value quality over time, for example, is delivering on time more important than delivering high quality standards, or something like that. Management can decide on that and can act on what they want to see.

Speaker 1:

This whole topic, we can talk all day.

Speaker 2:

It's a never-ending topic because now you went into the whole. We need to have another separate conversation just on that.

Speaker 3:

But you come back to those things as well. But you come back to those things as well, and when it goes into the rabbit hole, I pull my attendees of the workshops out of it and bring it to the point Okay, think about your commitments and think about how you make decisions. That is very helpful in this phase because it comes back to setting priorities and deciding on something like that. There are some things they didn't know before how to decide and how a group can come to a decision. So I add something about this as well, and that is a thing that is helpful. So you don't get too much into philosophical questions or something like that, just having some practical things you can add to your communication inside the team and inside the organization.

Speaker 2:

That is, that is my approach when I teach other people things that that is a great approach and I like the approach and I like the topic. Well, christian, thank you very much for taking the time to speak with us. I could talk with you on this topic and the offshoots of this topic for days.

Speaker 1:

Yeah, we'll have to have you back and maybe more focused on some of the scenarios. Yes, sure you know.

Speaker 2:

Yes, yes, We'll talk afterwards to get some more time with you to talk about, as Chris had stated, some of these specific scenarios and some tips and tricks and how to pull through it. Even as you just talked about was, you know, you know focusing on your commitments and your priorities and how you make decisions and and the like. But if someone would like to contact you to learn more or hear more from you on this, the topic of leadership roles and management and anything else that we spoke about, how would someone best get in contact with?

Speaker 3:

you? Yeah, I think about my linkedin and my twitter handle, which is curate ideas. When you search curate ideas, it's very unique there and and I like to know how ideas come up, or something like that you can find me on Twitter and LinkedIn. You can contact me and we can have a call and see in which phase you're in and what is a pragmatic approach to come out of this phase.

Speaker 1:

It's like TED Talk Curate ideas. It's great.

Speaker 2:

Chris, you should give Christian a call and help you out with whatever stage you're in Survival every day Everything I heard with Christian.

Speaker 2:

You can use a lot of help. You can use a lot of help from Christian at this point. But again, christian, thank you very much for taking the time to speak with us. We really do appreciate it. Time is truly the currency of life and once you spend it, you can't get it back. And anybody who spends time talking with us or doing anything with us we greatly appreciate because, frankly, you're not doing something else, you're giving us your time, so we do appreciate that.

Speaker 3:

Thanks for inviting me. Thank you again. So we do appreciate that. Thanks for inviting me, thank you again and giving the chance to talk about this topic, which, on other conferences, has a whole track of sessions, and that's the reason I thought it would be good to add it to a developer conference as well. That's awesome. I think it's a great idea and I think we should have more of these.

Speaker 2:

You know, I think it would take a little bit to get maybe some momentum, but there is such value in this. So much For people to think it's the technical stuff everyone focuses on, but you have to have the personal side of it too, which is important. Thank you again, Christian. We'll talk with you soon.

Speaker 1:

Thank you, Christian.

Speaker 2:

Ciao, ciao. Thank you, chris, for your time for another episode of In the Dynamics Corner Chair and thank you to our guests for participating.

Speaker 1:

Thank you, Brad, for your time. It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. You can find Brad at developerlifecom tuning in as well. You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-Ecom, and you can interact with them via Twitter D-V-L-P-R-L-I-N-O dot I-O and my Twitter handle is Mattalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.

People on this episode

Head Shot

Kris

Host
Contributor

Brad

Co-host