Dynamics Corner

Episode 342: In the Dynamics Corner Chair: Building Trust: The Human Factor in Implementations

• Christian Lenz • Season 3 • Episode 342

Share episode

Cutting-edge tech is just one side of successful software implementations. Have you considered what the other is?

 

Join Kristoffer Ruyeras, Brad Prendergast, and Christian Lenz as they explore the often-overlooked human aspect of software implementations in the latest episode of Dynamics Corner! 🚀

 

🔍 Ever wondered how to best manage the people side of an implementation?

🤔 What about the evolving role of developers and project managers in today’s remote work environment?

🚧How should we manage risk while building supportive teams?

đź“žAnd what are the best ways to communicate user needs to the technical team?

 

That's not all! We also discussed:

 

âś…Why purposeful meetings are critical in the decision-making process

âś…How to build a culture of trust between clients and project teams

âś…The benefits of developing functional knowledge in new developers

 

🎧 Don't miss out! Tune in at the link below and get ready to change how you think about software implementations!

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 communication. I'm your co-host, chris.

Speaker 2:

And this is Brad. This episode was recorded on September 18, 2024. And this is Brad. This episode was recorded on September 18th 2024. Chris, chris, chris. Another great episode, but before we jump into it, you have a different background.

Speaker 1:

I'm a different background. I am in the city of Las Vegas at the Power Platform Conference First time and I'm excited.

Speaker 2:

Power Platform Conference 2024 in Las Vegas. Yes, you're very fortunate to be there. I'm a little jealous. I wish I was there, not for the gambling and the food opportunities, that, but to learn knowledge about Power Platform. It's such a powerful tool. But while you're over there in Las Vegas, we still keep the podcast running and today we had the opportunity to continue our discussion about effective management, leadership and also the human factor of an implementation With us. Today we had the opportunity to speak with Christian L. Welcome back.

Speaker 1:

Hi, hey Christian.

Speaker 2:

How are you doing?

Speaker 3:

I'm fine. Thank you, last days of summer here, yeah, and I tried to have some summer vibes back then before the autumn is coming.

Speaker 2:

I'd like the summer vibe shirt. I think it's working Last days of summer. I hear that a lot from the conversations because now it's towards the end of September and I guess it cools off in most places. To me, I think it still feels like summer outside. I think it's 85 and sunny right now.

Speaker 1:

You get summer all year long man.

Speaker 2:

I know that's part of the reason. Well, we get summer when most people have winter and then we just have blazing scorching flames. When people have summer, yeah, you have to hibernate. So it's the opposite. It's the north. You stay indoors for the winter for the most part, and then you venture out for spring, summer and fall when it's nice, because it's too cold, and then down here you just don't go outside from May until September because you'll disintegrate from the heat. So welcome back. Christian Enjoyed the conversation last time when we talked about leadership. We do talk with a lot of members of the community about the technical aspects, the functional aspects of implementations or of Business Central, but, as we talked about last time, what's often overlooked is the management of the individuals working on those implementations, whether it be on the customer user perspective, or from the partner or whomever is helping someone implement the Business Central application.

Speaker 2:

What is the word? Is it customers? Is it user? What do we call somebody who uses Business Central?

Speaker 3:

Who uses Business Central? I think it's the user, but from the partner side we speak of the customer because it's the business term. Lately I thought if we should more aim for users. Lately I thought if we should more aim for users. I like the principle Dave Farley has on his Continuous Delivery podcast. He says that we deliver software faster to the hands of the users. Working software faster to the hands of the users.

Speaker 3:

Since I was during my roles from the beginning I started with Navision and NAV a consultant who trained users. I have the direct experience as how it feels for users to learn a new software and something like that. And I think being a consultant in the first roles shapes your perception throughout the projects for the upcoming years. For that, when you are a developer who gets the requirements, makes some coding and delivers an app and the consultant is the one who has feedback to the users, that's another perspective. Since we are a small company and we started with a very small team back then, most of our developers were also consultants, so you always had the direct contact to the feedback of the users and how they feel and something like that.

Speaker 3:

And I did a lot of training sessions, even standard, in NAV or Business Central and train someone brings me to step into the user's shoes. How does it feel having to train a new system, doing my daily tasks slowly, 10 times slower as it is required, and something like that, and, from this perspective, creating, as a trainer, a safe space for the users to learn something new? So we speak about customers, because that's the business side we want to provide. But when it comes to how do I design my software, how do I bring the software to a real value, I think of the users, of the user role.

Speaker 2:

No users are important.

Speaker 2:

You mentioned a couple points and I wanted to follow up on some of the points that you had made. Back when you first started, developers were consultants. So developers understood the application, in essence to work with the customers, to understand the requirements and then to be able to develop a solution. I like that model because I feel, in order to deliver a better app for a customer and extension, if someone can understand the application and ensure they understand the requirements, it results in a better deliverable. And this is KB.

Speaker 2:

And I did a session at Days of Knowledge America this past weekend or week, I don't know, it seems to be a blur to me these days, but that's what we talked about, is you know? The question was are you an AL developer or are you a business central developer to talk about some of the importance? So that's what it was like, and that's how I was brought into this space as well was when you had to basically fill all roles Project, manage, develop, consult, even do some sales. I guess you could say have you noticed a change now? Has it been a radical shift or a large shift where most developers are more just taking requirements and working with them? Not to deviate too much from what I wanted to talk to you about but as you break up the topic.

Speaker 2:

I have some questions on that.

Speaker 3:

I think the shift began more than a decade ago when the projects grew larger. You have to split up the tasks and the responsibilities because otherwise it's just too big for being a one-man show. On NAV, I know some of the freelancers are still doing that for customers. But when we have the big shifts from a major version to another, or from NAV to BC or from CIL to AL, most of them need the help of a partner with a larger team with specified roles. A partner with a larger team with specified roles.

Speaker 3:

And I think it's also a differentiation between projects and product development. I think for product development it is better to split the responsibilities even more and the roles even more and the tasks even more, because you can more streamline the whole development process and the feedback process and everything. Sometimes I see developers who are not that engaged with customers, but then we focus on get the requirements right and talk about the requirements in that way that the customer feedback is in the requirements, so the developer doesn't need to ping pong with the product owner or something like that. That is what we focus on. We don't focus on every developer has to be in the meetings, because it drains them out and it's cost them time, but we lay more focus on. Are the requirements right that they can do their work independently?

Speaker 1:

yes, but I did have a question for christian.

Speaker 1:

You had mentioned, um, you know, focusing some of your developers, or at least prioritizing their time, not to be in a meeting all the time, or if they're not required a meeting, then they shouldn't show up in a meeting and more focused on the solution.

Speaker 1:

You know we've had several conversations now with Brad and many others where any time that you put together a solution or, you know, putting a product together or extension for a client, you typically have to have a I think you mentioned product manager or a functional consultant along with a developer, so that they can both have a full understanding of what the solution is going to look like, versus just throwing a developer in front of a client and says, listen to what they're saying, and that could be detrimental of putting together a solution, because some developers may not think about all the functionalities and they just want to develop a solution background and or experience as a functional that knows the business process and then develop. Those are awesome resources. Or pairing a developer with a functional consultant. I think it's becoming more and more important, um, you know to to have that in your, in your staff yeah, and what we do at cdm is we also train new developers in functional aspects.

Speaker 3:

So they also learning the the application side up front, not in every detail, but they go through the regular training curriculum also on the functional side and on the development side. As I was, I learned most of my experience during the project. That's right. But they have the background and in the first project they go there with an experienced functional consultant or project manager who does this bird eye view of okay, how does this requirement the customer has fit into standard functions and is it really a need to do a customization or not?

Speaker 2:

That's where it's important, as I had mentioned, to have a business central developer versus just an AL developer, because they can catch, and it's also important when they're developing a solution to put it together.

Speaker 2:

But to take it back to leadership and management for a point, in the last discussion that we had with you a few months ago it seems like a few months ago, or maybe a few weeks ago, I don't even know at this point we talked about the different management phases or processes or steps for managing a team, and I wanted to take that a little bit further. I appreciated the conversation because we were talking more so from the partner point of view, or if you're developing an ISP application or an app-for-app source. What we started talking about earlier in this conversation was customer or user implementations working with a partner, and I have some questions around the management and adoption of that. Is there a way to manage a team that's co-joined between a user base and a partner, and how can you manage a team or lead a team for a successful implementation when you have two groups of people?

Speaker 3:

You need to have another additional level of awareness. I would say for that, because as the external partner you are not in a role that you have a direct influence on how the customer or user is organizing their project. So when you experience that there are they are struggling with that, it helps to see if they are in survival mode or not and can provide some additional workshops or discussions on project manager level or on on leadership level on the customer side to address those topics. In my project manager experience back then I didn't take this step as much as I wanted to because I felt this hidden barrier between us as a partner and the customer organization. So we are just the partner who gets some wishes and some requirements.

Speaker 3:

That is seen as someone who delivers. We are just a truck driver for their solution to bring it to them. Who delivers. We're just a truck driver for their solution to bring it to them. We have not the order to also manage their organization and what is going wrong there and something like that. But it impacts the project so much If the customer is in a survival mode or not and they are not aware of these modes. They are not familiar with building up a team, like we are for every project, so they even don't see it.

Speaker 2:

Yes, every time I hear you say survival mode, I get a slight chuckle, because sometimes I feel like I'm always in survival mode when it comes to it.

Speaker 2:

You did you hit another key point where a user going through an implementation is not always in the space or have the opportunity to develop a team for an implementation. I think with Business Central it targets so many different types of customers because it's that versatile of an application that it can handle small businesses and it can handle the medium-sized businesses and a lot of people don't talk about it, but it can even handle larger-sized businesses. So depending upon the size of the organization is going to be how big of a team that they can have to work with the implementation, which I think is a challenge and, like I think you had mentioned, with them being in survival mode with it, it may be because they also have work to do, as I call it Right. So it's it's. The business must still move forward as they're going through an implementation.

Speaker 3:

And from our experiences also lately, the big projects my colleagues did the best projects were those where the project managers were able to work full-time on the project. That were the best cases. They prepared all the requirements, they prepared the test cases, they did the testing, they were the key users. They knew what other key users they can approach to have good feedback about the solution early on and something like that. But many customers are not in this role. Mainly the guys from the IT departments are nearly in this role.

Speaker 3:

If you have a project manager who is mainly in charge for finance management or purchase or something like that, and because of this they are purchasing a solution from us as a partner, struggle the most with this because they see us as a partner, more like any other vendor who is just delivering goods to their loading dock, who is just delivering goods to the loading dock and when it's there it will be checked and they receive the invoice and they say, okay, we did receive the goods and we will pay them. But that is more like acting in daily business than doing an ERP implementation project and most of the partners don't have the time to send their people on a five-day project management training or something like that. And even if they do, having the experience to really do a project takes much, much more time and there is no repetition right takes much, much more time and there is no repetition right. Most of them are doing an upgrade project or even an implementation project two or three times in their career.

Speaker 2:

Yes, I could see there's a challenge. So, from a partner point of view, how can you lead or manage that project? In those types of situations, is there anything that a partner can do, or someone leading the project from the consulting point of view, even if they're not a partner, to help with that management process of their team?

Speaker 3:

I think the best approach to bring this to the table is doing it in a section we call risk management during the steering meetings. But to be able to do this you have to manage how you can build trust on the customer side that you can talk to those topics. I had some of those situations back in the large projects but it needs, again, very much experience to address it right, not to upset the customer and to open them up to look at those issues. But it comes down to yes, it is about risk management for the company. So you look for how is the correlation to risking them going out of business if we do not address this?

Speaker 2:

And the importance of all of this for a successful implementation. I have conversations and I try not to go off, but we're going down a certain road with the risk. I try not to go off, but we're going down a certain road with the risk, and a lot of the conversations I hear about an implementation sometimes make them sound like they're a daunting task or a big task. I mean they are a big task because, in essence, someone's changing the core of their business. What's the function of the business? To manage all of their business processes to continue to be successful. But it doesn't always have to be complicated, it doesn't always have to be what I call difficult, but with that it also requires some preparation, which sometimes sounds like a lot of work, because we all talk about this and it's not just this conversation we're having.

Speaker 2:

It's I've been having more and more business type conversations versus the technical and the functional conversations, and I'm starting to hear phrasing that if I were a business owner, I may sometimes be afraid to go through an implementation because I hear, as you had mentioned, risk management. I hear project management and my staff will need to learn a new system. My staff will also have to go through and test the new system, but I still need to perform my function. It does sound complicated, but as we go through this process and working with them with leadership, how can we tone that down and also explain to them? Yes, there are risks, but there's risks that, with anything that you're doing and it doesn't have to be so big, in essence I don't know if.

Speaker 2:

I'm phrasing it properly.

Speaker 1:

I think there's always going to be risk. I think, maybe finding ways for people to understand that there'll always be risk but you can do a lot of things in terms of preparation as a leader or if you're leading a project or even managing a team, that if you take the time it will minimize those risks. Not necessarily, you know, sometimes you can't, you just can't remove risk. There's just unknown risk. But you can certainly minimize and even prevent some of those things that would creep up. So I think the conversation still needs to happen, even though it could sound scary. But if you don't have that conversation ahead of time, then it's certainly going to be more difficult and the risk would be more amplified if you're not having this conversation and, of course, investing the time to do it. It sounds tedious, but it's a must.

Speaker 3:

Yeah, it's more like something you can train on a project management or leadership course. That is more some skills that you can follow, and it's easier to get up the skills. The hard part is how will you address it? Who will you address it? Who will you address it to? Sometimes the complex part is not that you have to have a risk management list. The complex part is who in the organization of the customer will be best to be addressed. This and this could be a person who's not in leadership, who is not even in the project management role. But it could make sense because you feel that the person there's someone maybe in the purchase department who has a connection to the project manager that the project manager will listen to what he is saying and it's more likely that you can bring your points to the table when you first talk to this guy in purchase. That is the complex thing and you have to try out. You don't know in advance if this goes well or if this fires back.

Speaker 3:

And that is a really complex part. You don't know how they react. You have to test a little bit who is the best I can approach, and for this I take some thinking tools from my future leadership training, together with Elastic Leadership and traditional project management. And that is do I have a problem of knowledge when knowledge is there but not for the person? Okay, how can we do it? How can we show them the documentation or book some training or something like that? Or is there no knowledge? Nobody knows how to address this in this company. So then the question is who can I ask? Who has an idea about how to approach this? And that is the point where I now can shift a little bit more. Then I can decide okay, this problem I can address with training and it's got a high possibility that this problem is solved.

Speaker 3:

But there are other problems, even larger, for customers in such projects where nobody knows how to do it in their organization, and then me, as a partner project manager, knowing of these things, can guide the customer organization a little bit in this direction. So when you have this kind of problem, do you have someone who you are talking to? Because you know, when you talk to this guy. He has some idea sparking. It's a starting point where it opens up or something like that. Okay, go to him or her, or something like that.

Speaker 3:

We had that in a big project Many departments. I trained with a new NAV version back then and during the lunch break they're all sitting in the same bistro and eating and one of the guys in a particular sales department talks about how he is configuring with the personalization mode, his role center and his pages and something like that, so that this is a good fit for his work, and he has ten colleagues in his department who are nearly doing the same. So after the lunch break I approached the project manager, the customer side, and said did you listen to him? Maybe he is a good key user, Maybe you should talk to him. Building up the role center for the profile for this department and having this feeling who is good for approaching him a certain problem?

Speaker 1:

is a big part of project management, that that's a leadership skills, skill that you must have, um, because you do have to gauge the audience and figure out you know who who knows something and you sometimes you have to get it out of them. Sometimes you have per person in the room. That's the most quiet person, but in many cases they're probably the most knowledgeable and they're just taking it all in. So you have to get that person involved. You know to speak up and share, because, yeah, you're right, you know there's going to be somebody within that group that knows something. Maybe they're just afraid to speak up and and so you have to get it out of them. And, like you said, you know, you listen and you heard someone. That's like you know what that person has, some ideas, um, you know just from listening to what they're saying.

Speaker 3:

And how to approach this, because often if you encourage a person like this in an official meeting to speak up, they stay quiet Because the culture in this organization is shaped in a way. We cannot say this in an official meeting, so you can try to approach them informally in the coffee kitchen or somewhere else and try to leverage this knowledge that is there so you can in some way, as a partner project, shape this environment for those people to speak up, but diving into. Okay, we have a workshop here or a training class or something like this. You offer to me a good solution, please present.

Speaker 3:

It is sometimes very risky. Very risky because nobody can directly influence the culture of any organization. We, as a partner project manager, are even less able to do that. So you have to find to play the way and open spaces on the backstage of the project to do this. You have also to play the front stage in the official meetings, steering meetings and something like that, and you have to play on the backstage because if you are not getting these people to speak up, you don't get on the project early, on these problems early, and the risk that you get all the bunch of problems in the go-live is very high.

Speaker 1:

Yeah, you made a good point. Yeah, sorry, brad, you made a good point that as a partner, it is very difficult as a partner to help encourage that right. You have to have a really good partnership with their internal project manager or even their executives or sponsor the project where they also have to encourage that right. That's their culture they'll have to live with every day Because once you're done with the project you may slowly go away, come in and go for other future projects. But it's really their responsibility as an organization to encourage that. And if you start a project and that's not encouraged, where someone speaks up and puts them down right away, then they clamp up and don't want to share anymore because now they were put in a spot, you know, and I don't want to share now, so that that could be detrimental. That's risky. You're right, christian, you can't just put someone out there and said, hey, calling them out, it's, it's a big risk as well yeah, when you, when you are not aware how is the culture at this organization.

Speaker 3:

So my advice would be try to get a picture. How is the culture here in this organization at the customer side. You have to play in swing with this culture. That is a very better approach than just saying, okay, we are open here, just speak up. It won't have any negative consequences when you're not knowing what is the culture playing here.

Speaker 2:

It is important to identify who in the room, as we're calling it, which I'm going to talk about in a moment knows the true process, the true requirement or what needs to be done in a project right from a leadership point of view. Requirement or what needs to be done in a project right from a leadership point of view, and we're talking about being able to talk to this individual or group of individuals, or however you do it, in an unofficial manner to try to organize or bring to service the team. But now we're in 2024, and I know how we talked about just how the roles have changed through a project over the years, where a developer early on in the conversation would be responsible for also doing some consulting. Now, in 2024, a lot of things are done remotely. So how do we impact leadership?

Speaker 2:

And I loved the conversation on elastic leadership that we had and I encourage everyone to go back and listen to it and learn about it, and we can continue that conversation forever. But now, from a leadership point of view, let's take into consideration even going back to that elastic leadership model, where you no longer have everybody in an office together, where you no longer have everybody in an office together, even for implementation. Sometimes you can do them fully remote. I've had conversations and discussions with many on should you ever go on site? Do you need to go on site and meet the customer in person or the user in person? But now, from the management point of view, all of these things that we're talking about, all the modes and the elastic leadership management or even the layers that we have through an implementation how does working remotely impact that and how can you address the differences between in-person management versus remote management or even hybrid management?

Speaker 3:

I think you can do it full remotely, but you have to set up more meetings just for those topics. You cannot just cramp it in the regular status meetings or something like that, or just doing a remote kickoff workshop or something like that and hoping that these problems can also be solved there. In my perception, experienced project managers are also doing good project management work remotely, because most of our project management work is remotely, even if we have very local customers here in northern Germany. What we try is to be before the kickoff workshop or after the kickoff workshop with our team at least a day on site just to get to know each other. But I think it's done in a third of the projects. Most kickoffs are held remotely or something like that.

Speaker 3:

What helps is having a good project structure, but it doesn't put the risk completely down. So what you can do is being aware of this and offer some of these meetings just to talk about how are we doing in communication? Are there some blockers in the communication or something like that. And when you approach these topics, not play it to the personal level of the people, because every organization has a cultural behavior or something like that to personalize right away Like, okay, I know this guy. He doesn't want to talk to anybody or he's so upset and so angry and something like that, and then you are doing kitchen psychology and not addressing it right. So what you can do is to carve out from what function is this person, this persona in this organization acting and behaving, and talk about this and how this affects the communication for the project.

Speaker 2:

Chris, you're taking notes over here.

Speaker 1:

Yeah, yeah, so you know, I am.

Speaker 2:

That sounds familiar, doesn't it?

Speaker 1:

Of course it sounds very, very familiar. I mean, a lot of us are remote and Brad and I always, you know, we have conversations about this daily. It is difficult when you have remote team members because it's different. When you're on site, you're with them shoulder to shoulder in a conference room. It's easy to read the body language, it's easy to read the room. But when you're remote, when you start the remote meeting and you end the remote meeting, that's it.

Speaker 1:

It's not like if you're on site with them, there's always that small chatter leading up to the meeting and then there's some additional chatter after the meeting. In remote, it's a little bit more time to maybe do a little bit more one-on-ones, you know, maybe additional chat via Teams or some kind like that. But I think it's important, right? So it's not extra's, you're not, it's not extra work, because you would have done that already, even if you're on site. So I do love that approach. Christian, you know, certainly learning something from you that you know you should take the time to maybe reach out before or after and not just have a set scheduled meeting because, yeah, you're not going to get a lot if you just box yourself in within those meetings.

Speaker 3:

So, as a leader, you have to expand, expand that communication plan yeah, and that is just making the safe space to talk about this. And then you have the point how can you address it? And I learned a kind of communicating this or being an opener thinking that it has a good reason for the other person to behave this way, which seems blocking communication or blocking the project. So I take the mindset that no one wants to block a project, but they behave in a way that it blocks the project. So what is the good reason for them to behave, to block the project, and ask this, and often that leads to a function they in parallel try to accomplish. They are in and then you can see okay, that's a good reason to to behave this way.

Speaker 3:

How can we integrate this in this project? Because you also have a function in this project. So how can we leverage this so that you can do better communication or better work, more time for the project? For example, what are the factors from your peers, from your manager or from your organization that need to be changed in order that you can just be free from? I have to manage it all and I don't know how at the moment? That is the kind of conversation you can do, and the opener I would suggest is hey, I see there's some behavior that is not in shape or in sync with the communication for the project. I think you have a good reason for that. Let me know.

Speaker 2:

I think it all breaks down to communication, proper communication, and this is where I think with the management, with the remote, is being able to get that connection as well with it, because of some offices may be far away or they may have remote offices. Because it also does help with the talent pool to be able to complete some functions within an organization. Not all functions can be remote, depending upon the type of business, but I think the whole leadership style is important to incorporate or at least be aware of how to also manage remote talent.

Speaker 3:

So it's both. You have to set up your communication room a little bit different for remote, doing more meetings or doing a check-in in the beginning of every meeting or something like that to make a better connection. But there is something that is applicable to remote as well as on-site or personal when you have very experienced coaches, you can see that they can build their trust for coaching initially, even if it's remote. I had this. I came to know a coach from Berlin who is doing online coaching for years now and had to shift his whole business model to remote because of COVID crisis to remote because of COVID crisis. So here's an offer that you can have a 15-minute meeting about a real problem you have and there's no chit-shatter in the beginning or something like that. Just go directly to this problem and he tries to make a step into a solution for me and I had this via a Zoom call. I didn't know him and I left this meeting after 20 minutes with a new way I can address my problem.

Speaker 2:

You hit on some points there and I'm glad you went there because you had mentioned with remote you can have more meetings, and the first thing that I think of is having more meetings versus having productive meetings. I am involved in a lot of meetings and I can honestly say a lot of them are useless. And what I mean by useless and I'm sorry to use such a strong word but I feel like I waste my time Because I show up to a meeting, people talk, I have other things that I need to finish and sometimes people have meetings, in my opinion, to have meetings. Now I understand the importance of the meeting to bring the team together, to group the team together, of the meeting, to bring the team together, to group the team together. But also sometimes I have a meeting for somebody to explain to me something, to just say I need to look at it, to have a meeting instead of giving information ahead of time to prepare for the meeting.

Speaker 2:

So with that whole conversation comes with what you had talked about and I think you alluded to with this individual from Berlin that you met within 15 minutes. It's how to have an effective meeting. There's a difference between having meetings and having effective meetings and having meetings all the time also to me I find very disruptive, because if I go from meeting to meeting to meeting, for example, by the time I get to the third meeting I already forgot about the first meeting because just the nature of the handling I could go down this road of effective meetings for days too, and, as you mentioned this, I think what made this meeting so effective was that he has trained a very good kind of questioning or asking questions to come to my problem or the core of my problem very quick and from there, when you are clear about the problem, you can come up with better solution ideas for this.

Speaker 3:

And coaching is mainly about asking questions to the coachee. I would not consider myself as a coach. I pull out ideas or offer ideas as they come up in my body, so I'm not that question guy, but I know the principle and that is very helpful how to ask questions to come to the core problems very quickly. And I think coming to the root causes of problems or the description of problems very quick makes it easier to okay, is there some knowledge or not, and who is the best to make a decision on this? So, having in mind that when you have a problem, you look if there are some ideas and also, in the same moment, think about how will the decision be made, who makes this decision for this problem, in this project, and how do they make them? What I often see in meetings is that the form of making decisions is consensus. We're talking until everybody agrees and we all know what this leads to yes.

Speaker 2:

the more opinions you have, the less you get accomplished. And you do need to have some decisions. You've been sitting in on my meetings, haven't you?

Speaker 3:

And this gets even worse if you introduce self-organizing teams. It doesn't address what kinds of decision-making do we have here? Because when you have self-organized teams and they are used to that they have some hierarchy guy on the top who is making the decision and that isn't present anymore. Then they fall back to. Okay, we try to belong to this group so we are not raising important topics or critical topics or something like that and then we talk and make no decision and this means another meeting or something like that.

Speaker 3:

So an approach I learned was are there different kinds of coming to a decision? Approach I learned was are there different kinds of coming to a decision? And that means sometimes in preparation you need some time to think about and speak about how do we decide here. That seems a little bit overdoing, but in the end it leads to a more effective decision preparation. So I had this when shifting from consensus talking until everybody agrees to consent, and that is a form where you present a possible solution and ask if someone has a strong objection or a strong veto, because this solution can put the organization at risk.

Speaker 2:

So it has to be a really strong objection. That's very important.

Speaker 3:

I approached this when I was a project manager at a big company, at the customer, and we had steering meetings every month and before we had consensus and they couldn't agree on what to work on in the next sprint or something like that. And then I talked to the project manager can we shift the mode a little bit? And then I talk to the project manager Can we shift the mode a little bit? Let's do for every department make a list of features we try to accomplish in this sprint. I prepare this, I send it to you to get some feedback and we present it to all the department managers in the steering meeting.

Speaker 3:

With the rule, everybody is asked one by one, so everybody has the chance to speak up and if someone has a strong objection or a veto, he must raise it in this meeting or it's over. So nobody is allowed to raise a veto or do chit-chat or gossip when the meeting is over in the coffee kitchen or something like that. Can we try this? And he said, yes, okay, we go for it. And this changed the effectiveness of steering meetings at this customer immensely. We cut the length of the meeting by one third and we always finished early.

Speaker 2:

I like that strategy and I think many can learn from that, because that's one thing.

Speaker 2:

I say some things in jest and some things with seriousness, but it is important to have those effective meetings and, thinking back to some of the meetings that I've been in, everything you're saying stands true. With the self-leadership or the self-directed teams, you do need to have decision-making, you do need to have some sort of hierarchy in a decision or, as you had mentioned, you often have everybody having an opinion and you get nowhere. It's almost. You know another one of Chris's favorite terms. I throw that with analysis. Paralysis is you can spend so much time talking about it or coming up with something and you never do anything at the end of it.

Speaker 3:

That was a mode we were in before we shifted this mode at this customer.

Speaker 2:

No, it's a pleasure to hear. I feel like I'm in that mode all day long sometimes.

Speaker 3:

Yeah but when you have an offer for an alternative decision making method that could shift the room, because you can choose now you don't have to bring everybody on your side. And the other thing is you don't have to play politics, because when someone raises a veto that is taken seriously, he has to explain why he's doing this veto and why it is a risk for the organization and not a personal feeling or something like that.

Speaker 3:

So we had this in this first meeting at the customer. Someone raised a veto because the logistics project was at risk because of the proposal I made. I said, okay, let's discuss this and when this veto is there, my proposal is disregarded. We cannot do this this way. Even the general manager cannot say we do this. So we talked about it and we found a little shift in the solution and we asked again has anybody a veto? One by one, no, and then we have the solution. We had much more buy in from all the department managers.

Speaker 1:

Yeah, that's really important. I love the fact that you know, I know Brad and I talk about this all the time. It's like we have just meetings upon meetings and you know, even from the other end, where I'm asked to make a decision, at the end of the meeting it's like what were the options? Which options so much should I be choosing? Like I will, I will give you my decision, but I never got what was the option. So I, in the other side of that flip side of that, you know, when you are the one that is coordinating this meeting and you're asking for people's opinion and decision, you you as a leader or leading that meeting you have to prepare and bring, you know, options. You can't just leave it open and like what you guys were saying everybody has an opinion of what a solution should look like versus. Here's the three things that I'm bringing to you. Which one do you think fits, you know, for the solution?

Speaker 2:

I have so much I want to say because you were correct and it goes with what I said, with meetings upon meetings. It's preparedness, let's be prepared of what we're going to say in the meeting. Let's make sure also, if somebody has an opinion, let's validate that opinion. Or, as you had mentioned, the veto is extremely important. I agree with that because it's important to bring a group together.

Speaker 2:

Everybody has again in the information technology field, if you're going from implementation or running a business or anything, everybody has different viewpoints or different pieces of knowledge that someone may make a decision. They're not aware of something as you had mentioned I'm kind of phrasing it differently they're not aware of something in a different area. Therefore, they raise a video for you to make or raise awareness to something and have facts behind it, and then the group could make a decision, maybe change the decision, because the information that was presented in the veto and it's important to understand that those who may have an objection in the case that you're talking about, or a suggestion rather than an objection, to validate that objection, to validate that and just also understand that sometimes a decision has to be made that not everybody in the room is going to be happy with, because sometimes there's also external forces driving the decision that somebody may not understand again because of the different perspectives it is. It's all about preparedness, awareness, and I can't even say anything anymore because I have so much to say.

Speaker 2:

Do you ever have so much you want to say about something that you have nothing to say?

Speaker 3:

You have to keep in mind that you sometimes have to play front stage and backstage. So at this customer in this example I had, I honestly didn't know what was going on backstage because that is hard to grasp as a partner. It shifted the mode for the meetings and for the role of us as partners. We were happy with this because we could think through what we would find the best solution for the customer is and for our team and propose that and if there is no veto, this solution is good enough to execute. Good enough to execute. So you're shifting from finding the best solution ever to the good enough solution that doesn't put the customer on risk. So that is the key point here. So that is what frees up the whole discussion.

Speaker 3:

But, sometimes you have to play this business theater on the front stage so that you are pleasing the bosses or the formal people or something like that, and play politics on the backstage to get your idea through.

Speaker 2:

I appreciate the phrasing of the words that you use Business theater aka politics. No, I understand, and it's also important to prevent those from shutting down as well too, because I've seen ineffective meetings where you, in essence, can shut people down from wanting to talk and express opinion as well too. So it is a delicate balance, uh, with all of that, yeah, and you and you put yourself on risk and you put yourself on risk when you try to change something in this operating mode.

Speaker 3:

I had this in an internal meeting with some fellow project managers and our general management where we try to speak about what we can improve here, and it went very fuzzy. So at some point in time I felt back to okay, I have to bring more structure to this meeting. I don't have a talking stick, but I can bring a talking stone, but I can bring a talking stone.

Speaker 2:

I like the talking stick. I say that in meetings.

Speaker 3:

I brought a big stone we collected at the shore in Denmark where we are on holidays, and I said, okay, only the one who has the stone is allowed to speak, and I will take care who is next and that everyone who wants to speak gets a word. And at some point in time the old behavior kicks in and our general manager interrupts. And that is a very tough point where you have to shut down your CEO and say it's not your turn, it's her turn, and when you're in the order, then it's your turn and that's why you have a stone, because you can throw it at them if they talk or no.

Speaker 3:

No, it was just just the symbol symbol I had, oh okay I didn't know if it you know I agree with the talking stick, whoever has the talking stick.

Speaker 3:

And then, if it's just a symbol for I have no stick, but I have something that can handle someone. It has to be a physical object and that is sometimes very difficult, remote. I heard of some concepts to have a virtual talking stick or something like that and some tools. You can put something on the screen of someone that you know who has the talking stick at that moment. But it's difficult to make this and it's risky Because it could fire back and that is why it's leadership.

Speaker 2:

You put yourself at risk. You need to have someone who can control the mute. Yeah, you have to mute everybody first, like they did with one of the presidential debates here. They had everybody muted when it wasn't their turn to speak, and I think it brings some effectiveness to it, and then people would have to signal that if they wanted to speak, and I think it's a good way to manage it.

Speaker 3:

And when you think of humans, you know that nobody wants to interrupt the other. Everybody is polite from the heart, but when you look at the behavior it's different. So you have to adapt and sometimes you have to put some structure in those meetings, something like that oh, it's excellent.

Speaker 2:

Well, christian, thank you for talking with us again. I could talk about this for hours and hours and hours because, as I had mentioned, we often, with the implementation process and cycles, focus more on the technical aspect or more of the functional aspect of the application, and now I'm seeing a need and a shift to have to talk about the people. People are a big part of an implementation of anything, so I'm happy to talk about this and continue talking about this with members of the community.

Speaker 3:

Thank you so much for opening the space again, because in the conferences in our space, I miss this whole track of the human factor. So it's even more important that you open up this space with podcasts like this, that we have a space to talk about this. I even got someone new that approached me on LinkedIn because they heard the former podcast episode where we were talking about elastic leadership. So I think that sparks a little bit talking about the human factor and how to tackle it, because every project has it, but everybody's focusing on this functional and technical side. I agree with you.

Speaker 1:

I agree. I have a session, christian. That's not technical. It's all about the preparedness before you even start and, of course, planning and what to do during implementation and even after. So those are very important components. Technical is good, good for sure, it gets us going, but at the same time you need the backbone, which is the people that does all this stuff, people will make it successful.

Speaker 2:

The application will do things, but it's not going to do anything on its own, and we're thankful to hear that there's visibility in the space for it. I'm seeing it more and more and that's why I'm enjoying and trying to coordinate conversations like this, and we appreciate you sharing your experience with us, because we couldn't get the message out without speaking with members of the community such as yourself. So thank you again for the time that you spent speaking with us and sharing this message, and we'll do our best to help raise awareness to the human, or the people factor of implementations, along with the functional and the technical aspect, because all of that is important for successful implementation. We will have to reach out to you again to have another follow-up discussion from a different set of management, but thank you again for your time. We look forward to speaking with you soon.

Speaker 3:

Yeah, it was a pleasure. Thanks for having me again and see you in the future.

Speaker 2:

All right, thank you, ciao, ciao.

Speaker 3:

Bye.

Speaker 2:

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

Speaker 4:

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, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E. You can also find me at Mattalinoio, m-a-t-a-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