Erik van Hurck was our special guest.
His YouTube channel: The Project Corner Vlog.
His Twitter: @erikvanhurck
His LinkedIn.
You may find this interesting and relevant: https://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work https://www.ted.com/talks/alan_iny_reigniting_creativity_in_business.
Transcript
Yegor: Hello everybody. This is our next episode of Shift-M podcast number 30. We have a special guest. His name is Erik van Hurck. He is from the Netherlands. Right? Yeah. Let me give the microphone to him and ask him to introduce himself now.
Erik: Thank you very much, Yegor, for inviting me on the chat and I’ve listened to a number of your podcasts and I’m impressed what you’re doing. So I’m very happy to be a part of it. So a bit about myself. I’m a senior project consultant for the company Projectum, and we are a Microsoft Partner and have been for about 15 years, and as such I help companies get into use to Project Online, Microsoft Project and tools like that.
Yegor: That’s great, thanks for the information. I would like to talk today about change management. That’s the subject which we were not able to cover in the previous episodes and that is really interesting and important I think. And by changes I mean not only changes in the scope of the project but in general the changes which happen to projects and how projects react to that. So I think you have some experience about that and I will have questions about that.
Erik: Yeah, well exactly. Change management is a very interesting field of the business because every time when we enter a new customer or a new client there’s always some project management system already there. And it might be different than any other tool. It still helps, holds projects and it still is used for project management but it’s different than for instance Excel which everyone uses for project, right? And so change management… You mention the scope management as well. Scope management for me is within a project and change management is what happens during but also after a project has finished. So it’s a field that hasn’t matured as much as project management, in my opinion. So I was wondering, you mentioned in a couple of your podcasts, you’re a developer, right? How do you deal with scope management or change management?
Yegor: Oh, as developers, we’re trying to avoid them, because, that was my question actually, because we as technical people, we hate that changes, we don’t want them, we stay you know as stable as we can. So that’s why there’s like a permanent conflict between our technical people, business people and requirements people and product owners. So that’s my question so do you think changes are harmful and b caused troubles or we need to welcome changes and expect them to happen?
Erik: Well I think that change is a natural thing in the order of life and nearly everything, right? Because otherwise we might still be monkeys. For the world to change because 20 years from now we didn’t have the iPad, we didn’t have the service, we didn’t have cloud computing as much as we do now and the world is constantly changing. And if there is one that O’Toole’s we should adopt that better tools, but it’s difficult because we still have our monkey brain, right, because we still think the old way and it’s hard to change people’s minds. So I like the developers’ point of view where you don’t want to have change. I would love that. As long as people stick with project.. and of course because that’s my life. But. Yeah we need change to get cheaper, to get better quality, to get faster time to market. But as a developer you do change your code based on security issues. You might change them right. More upfront to the end users who might change the front end of an application as well, right. And how would those people react to that? And there’s a difference between change management layers right where the first layer is just a simple extra button or a background code that is changed, that doesn’t affect the end user that much but it makes the code more fluent. But then there is a whole new application as well. And if you have a new application, well, how will the end user react to that? For instance, if you all of a sudden should use Google Spreadsheets instead of Excel you might first think “Ok, well, that’s just another spreadsheet program and one plus one is also two in every one of the applications.” But how do you work with that? How would you work with it? Change management is interesting in that aspect where it helps you get a better grip on that change. Yegor: Well let me give you a practical example. I was in one team a few years ago and we wanted to… we had a bunch of servers in the organization and the project and that servers were hosted on site in the office. We wanted as technical people to migrate them to cloud, so just sell off the servers, get rid of the equipment, and just rend that stuff from the cloud from Amazon or Google somewhere and we tried to convince our upper management that this is the way to go, that this is better, this is more effective, this is more efficient and their answer was “This is not how we used to work. That transition would potentially maybe cause some trouble for us, may cause some potential issues and that’s why let’s not do that because what’s wrong with the service we have right now, they work, everything’s fine, it’s stable. So it’s better to keep it the way it is for a few more years. Don’t touch it. I mean if it works don’t touch it.” And we didn’t touch it. We left the servers in the office, so we failed this game with the management, because the management didn’t want to change. So my question is how would you recommend us, technical people, to resolve that in order to actually have changes to happen? It sounds like you didn’t stress them “Why” good enough Where are upper management. Well they might know that the cloud is the future and they might know that “Yeah, maybe we’ll eventually need to go there” But we currently have the same situation with a client of ours where they are running project server 2010 and that product is end of life. It doesn’t exist anymore with Microsoft and you won’t be able to purchase it and support will be canceled pretty soon. So we had a discussion with management, our client and the project manager, had a discussion with management, and he said “Well, if you don’t mind, right now security will be an issue.” And this is a big issue for management obviously, because you had all that data and it’s a high profile customer and you need data, and the data is secure. And they will never change a winning team. That’s a good saying right now. We know that as well. And so maybe that wasn’t the opinion of manager. And you can have a situation where you as a developer know exactly why you should change that, but you need to change your point of view. Think money, think security, think GDPR. So that’s might be a good one.
Yegor: So you’re suggesting to threaten them with a bigger trouble that may have, if they don’t follow our advice right now?
Erik: Well, threatening always works. But I’d also say that’s a return on investment, and if management says “This is not how we used to work”, well that’s not a very positive mindset as well, right? Because like I said earlier the world is changing. You need to change with it.
Yegor: Ok let me give you another example. I wrote a number I wrote that article just about a week ago about the way software according to my experience has to be developed and the quality control, and I sent the article to one of the magazines like online. And they announced that they don’t want to publish it because, I quote, my recommendations go against the well-known best practices on the market. So they basically told me that what I’m suggesting is not what the entire market is doing right now and that’s why it’s not interesting to give it to make it public, to give that information to readers. You see, that’s the overall attitude to new information, to the changes, basically.
Erik: Yeah, how would Steve Jobs react to such a comment if he was promoting the iPhone for a first time, right? You are a frontrunner, and you are in the market, you know what people need. And if you have a new innovative way of thinking and article doesn’t get hit the first publishing company just try try and try again. Most of the people that publish the article might break walls the first few times. After a while you will get it.
Yegor: So what do you think is the right way for a programmer to try and hit the wall multiple times and try to convince them actually to make the changes happen or just go with the flow and you know stay quiet and just, you know, have a good time in the office.
Erik: Having a good time in the office might sound good in the short run, but if you keep stressing yourself out because you know that you’re doing the wrong thing, that wouldn’t be healthy for you in the long run, right? Now, as a developer, hope you’re never alone in there, and never to do anything in a project, right? If you are in a project and as a developer I’m assuming that you’re doing things Agile, right?
Yegor: Yeah.
Erik: …that’s the whole new world where short runs, short sprints, things in the backlog, user stories. But there’s still someone managing that. And there’s Scrum master, or someone like that, and there’s a team effort. And if you can’t convince your team, you might be wrong of course, but if your code is good and your argumentation is good and there’s the solid return on investment. And I heard “The team is bad or a scrum master is bad, or you might even have a different team.” I am not quite sure how that will relate to change management rather than if you do get that change out. How would the people react to it. How would you want to have them respond to it. And that’s maybe something like sitting there why do you want this upfront, so making sure that the people know why they want this change happened. Either faster servers, better return on investment, front runner in the market. They need to know that it’s something they need, and then they need to be training, they need to be followed up, they need to have the risk management as well. It’s very important to keep them in the loop of why you want that change to happen.
Yegor: You know I agree with that. But when I’m listening to that I kind of feel that is quite close to politics because in most cases people just don’t need the software to work, they need something else. They need to stay at their positions. They need to keep their power somehow. They need to stay with their friends. They have many other needs which are not technical at all.
Erik: Absolutely. Yeah, absolutely. And I like the title of your podcast being Shift-M, and its management that needs to shift here, right? Because the people as long as they are employees they need to follow leadership, right? And leadership means that the people in leadership need to be able to address certain issues, certain changes in the organization that needs to happen. An example of one client where I was we had this project server in implementation and all the projects were in there and all the documentation was in there and everything was in there and it was digital. And I came to the guys there and I came to the management office, and it was talking into one of the guys and I said “Well can you show me your project and how it’s progressing?” And he said “Well let me get my papers.” And he came back with a small library of documents and he had printed out everything that was digitally already available in the system. He started working through all these documents and if he lost half of his documents and he needed to go back to his office again. So that person, he has the right tool available to him, and he just was not able to make that change for himself. So change management for that person, is very expensive for the company because he’s working in the old way. He didn’t adopt to the new way and that’s maybe also a bit a fault of management as well. Because management didn’t train that person good enough or didn’t stress enough that the need for computer use or digital use of all the documents that he had, he wasn’t stressed enough. So change management is very political. If a person doesn’t want to use a system he will not use that system and that will end up with him being fired or him overthrowing the government, right? And this person was so settled in the organization that he even made sure that his boss fired in the end and his boss that replaced the other boss was also fired. So that person was very good at political play and change management is really political.
Yegor: But you know how many technical people, very technical developers, you know, skilled programmers complain about this politics in their organizations. They hate that, they don’t like to be, you know.. they’re not politicians, they don’t know how to manage this political question. They don’t know how to manage people, they know how to write software code. And when they want to move the server from the office to the cloud they’re quite obvious political at quite obvious technical reasons, they don’t know why it would happen and when they start talking to people they realize that they are there toothless. They have no they have no power against them because there are political games and that people are way more skilled in these games. So what would you recommend to them? Do they need to learn, do they need to become politicians or just I don’t know what to do.
Erik: Well I would assume that they are the best at what they do, right? They’re technical. They know how to code. It’s like having two people in a room and one talks Chinese and the other one talks Dutch. For instance, you won’t understand me if I talked Dutch.
Yegor: Exactly. Yeah exactly.
Erik: And that’s what happens with the technical guys have problem where they know the exact need to change the environment, change the servers to go to the cloud.
Yegor: Yes.
Erik: There needs to be a translator between them and management I guess. And if you have a good team, a good Scrum master, it could be that person because that guy needs to know the business, that guy needs to know politics, that guy need to know how to steer the right priorities for the right common work. Well it’s going to happen once, and he needs to prioritise that politics. I would assume that any technical would love to go into politics, right? Yegor: Yeah, that’s what I see as well, they don’t like that because there different kinds of people, you know.
Erik: Yeah, but you do know how to write technical documentation, right? And you do know how to stress why you need it. So maybe you use the fear factor there because there’s nothing as scary as saying “Ok, well, technically speaking there’s a leak in our servers if we don’t go to cloud.” And you need to oversimplify it because management won’t understand any code. Right? And I guess that was something that you said in a one of your earlier podcasts, where you said “Well it doesn’t matter if a manager walks into the room of the developers and he look at the bunch of code, and he thinks “Ok, well, those people are hard at work”, and then they return to [inaudible voice] or something like that. Basically there’s a gap between what the technical guys know and what the management needs to know to make that change happen because who is going to use that server and how are they going to use that server. And what needs to change for them to be able to use that server. There’s training that’s needed as well and documentation, communication.
Yegor: So it sounds like it would be useful to have some sort of a change advocate or change manager who is responsible for translating the language of people who need changes to language of people who are in power to make that changes happen, right?
Erik: I couldn’t say better. Yeah, exactly. You need to have that advocate. So with manager and someone that is just about to know that it’s something to do with code and it’s not Jason. So there needs to be someone that’s been around in the field of that organization, that has certain power because he’s on top of management or something like that, or because he just knows how to talk. He’s a talker, he’s political, but he’s also some kind of leader.
Yegor: Have you seen those people ever, those roles?
Erik: Well they are [inaudible voice]. Absolutely. And that’s something… we at Projectum had a change management guru and he held the office, and he told us that the field of change management is pretty new or pretty immature where project management is very mature currently. And then there’s portfolio management, program management, risk management, all that stuff that’s around there, and change management really is something that people haven’t put enough attention to. So yeah, it’s maybe just like a project manager, you don’t become a project manager because you studied for it, you were good at running your projects and you get that label: “You are a project manager”, right? So yeah, I think that a good change manager could grow out of a good project manager. Yegor: Uh-huh. Do you think we should include staffing decisions into this change management umbrella term. I mean finding new people and letting all people go or is something outside of change management?
Erik: You mean if a new product will lay off people, or…
Yegor: For example. For example, I have… let’s use the same example, we have servers in the office and we obviously have a few people who take care of them and then we want to go to the cloud so we don’t need these two people anymore because the servers are over there. And that’s why Amazon will take care of them somehow. I’m just making this up. So when somebody starts the change, let’s say I’m a programmer and I come up with the idea that we don’t need this service anymore, then I obviously mean that we also don’t need these two people, Jeff and Mary, they will be laid off. So that’s kind of also changes, right. So I what suggest that as a programmer, or i should avoid that?
Erik: Well for upper management that’s a return on investment. So it is obviously a result of your change, and depending on who you talk to you might want to include or exclude it, don’t talk to Mary and then tell her that her job is gone, right? So the management might have a new role for Mary or the other guy. So there is a thin line to who you talk to, to the changes that you are going to have. You might want to focus in change management, on the pros, rather that the cons and focus on how would we work in your situation, how we work in your environment, work from everywhere can be something that you can put as a pro if you go into the cloud.
Yegor: Well in my case well when I have that situation with the server I remember that a few people who were in charge of the computers, they immediately became enemies in the office, they wanted to get rid of the servers and there was a conflict which was so difficult to resolve because it was not just a technical conflict but money conflict as well because it meant you know cash flow for those people. So that’s why it was understandable that those people are making up all the kinds of arguments against the cloud computing because they don’t want to lose their paychecks.
Erik: Yeah, yeah, you should not stop them from speaking out of course because they do have a valid point that they have a job and they want to keep their job because they’re happy where you are at, right? And if management is good they will talk to these people and say “Ok, well, life is changing, we are changing our servers to the cloud. Is there anything that you want to learn about computing, you might be useful in our organization still. Because we are going to the cloud. It is very cost efficient. It is super cheap, it’s super fast. We do need that. Our customers need it, our backend needs it. We will go to the cloud.” And if management is powerful enough and that’s going back to politics again and the whining should be enough for management to go with that.
Yegor: You know what I learned from that situation? I learned that the less changes you suggest, the more likable you are in the team, so the more changes you try to initiate, the more aggression, potential enemies you earn for yourself around yourself in your team, so that’s why the less you move, the less you try new things, the more stable your position is in the company which is counter-intuitive because like when you start those changes you think that you want to contribute to the team, you want to make it better, you want to improve something, but in the end, in the worst case you will be ejected by the team, because you shake it too much, you shake the ball up too much and nobody likes you anymore.
Erik: Yes. So you have a slow moving department because we have grey mice everywhere and you are moving because if you don’t move you will die out as well. But at some point you will be disrupted and you’ll be disrupted if you never speak out, your company will slowly appreciate it, right? So change is needed and I can understand that if you speak out and say about everything “Okay, this is bad, and it’s bad. This is bad and everything is bad.” And yes sure you would get kicked out of my team as well, but change management is probably more broader understanding of change when it’s not changing. Do we need to change? No, change is needed. And how we manage that change as best as we could.
Yegor: Yeah I also remember that there was like a thin line between suggesting changes and whining about everything else, like about everything. So when you say too much about changes and say that everything is so wrong that they will just call you a negative person and they will not listen to your ideas constructively, they will just expect you to say something bad every day and that’s why they say “Okay let’s stop listening to this dude.”
Erik: Yeah, yeah, exactly. It’s needed for everyone to be at least a little political person, right? You need to say okay well… have a compliment sandwich there, right? This is good. That is bad and this is good. But let’s focus on the thing that’s bad. Yegor: And do you… Have you seen or do you do that in your team like official tracking of changes that are suggested that they are implemented? Erik: Well, as a consultant I’m only working in projects where a heavy change is required for the organization. So as a consultant for ProjectOnline I come into an organization where there is a certain system used for project management. So for instance they have a Primavera or a NewEra, well any other tool, and maybe they even use Excel for management. As soon as I come in there, depending on the size of the project or the size of the organization, there’s always a bit of change management going on there. And one of the important things is that there’s ample stakeholder management. There’s ample training, there’s ample communication because as soon as I come into an organization, the change will happen. There’s no way back, platform is burning we are stepping off and we are going to ProjectOnline. So I always see that need for change management in our organization. And the successful implementation of project management hangs very much on that good working with change management.
Yegor: But do you get practice with change idea of a request or how they call them or they just happen verbally informally and just by meetings, discussions and all that. Or you have some log for example some track racker saying that today Michael’s suggested to do this and that, the change request is number 17.
Erik: Also we are adopting a more agile way of working so we do track a backlog of what is needed and we do set up a user story upfront where Person X wants to be able to view his projects from anywhere in the world, for instance. Program manager Y wants to have his dashboard in Power BI, wants to be able to see that on his mobile phone. So we do track all those changes and most of the time we have a project manager onboard from our new organization or we work closely with a project manager for the organization you’re implementing for. And we always suggest “Okay guys, listen up, we need to communicate changes and we need to communicate stakeholder management.” So there will come changes and that’s more into the field of scope management, right. Our scope changes and how to adopt with them. And most of the time we have a fixed scope or a fixed budget or time and material. And yet if change happens too often we need get back to the board and we need to say “Okay well. Our project is going to be more expensive because you have these new features that you want to do that” and then yeah, we work with that.
Yegor: And what do you do with people who suggested changes and because of those changes failures happened? Erik: Failures happen within the project itself. So… Yegor: Let’s say I’m that person and I suggested to move those servers, I’m just using the same example. So I suggest that to get rid of the servers and move to the cloud. And we did that, and then after a few months we realized that because of that we have bills and those problems for the person who suggested that
Erik: We hang them. [laughing] What we need to do is don’t make it personal, right? It isn’t bad that there’s a lot of issues but maybe we didn’t plan that change good enough, right? It is not best practice to move servers to the cloud from one day to another. You need to have a good plan there. You need to have tests, you need to have testing environment, you need to have an acceptance environment, protection environment. It can never be that one person does something wrong. It’s a team effort, right? Yegor: Well that’s true, but you know every time in every single team I’ve been at, it’s always the reaction like “You suggested that, remember?” And everybody looks at that person, and that person doesn’t want to suggest anything else.
Erik: So you make making grey mouse of that person and that person will never contribute anything very useful again.
Yegor: That’s true, yeah.
Erik: And that is just killing for change or killing for that person he just dies out of it.
Yegor: Yeah that’s true but would you expect the team to do that? You would expect everybody to say it doesn’t matter who suggested that, it’s our fault?
Erik: Yeah, because this is something as big as this. I expect everyone on the team to search for issues that might have happened upfront. For instance if you say “Ok well the servers are in the staircase now and we turn them off and we go to the cloud and all the sudden half of all sales force disappears, right?
Yegor: Yeah.
Erik: Well you can’t pin that on one person. That’s the team effort. That moved to the cloud. You might have suggested “Ok well we should test our skills before we move to the cloud.” And if the Scrum master doesn’t have testing or scheduling or planning in his team effort, then it might be the team manager’s fault, not that team member which suggested it.
Yegor: That’s what I wanted to hear actually that’s this is fault of the manager, right? Not the person who suggested. Erik: So, Shift-M? [laughing]
Yegor: Yeah exactly. You just said what I wanted to suggest that maybe it’s a fault of the project manager who led the changes to change request to just go to implementation or without like you said, without proper planning or testing or risk management.
Erik: Exactly. You need to think of the risks before you take your change, right? If something is as affecting the organization as moving to the cloud or adopting a new antivirus program or adopting a new system that needs to be thoroughly tested and the people that need to work with that new system need to be trained, then you have a change management program on your hands, right? People need to be aware of the change that’s going to happen and they need to be aware of why and they need to be aware of risks as well.
Yegor: That’s absolutely true but it never happened to me in my life, I’ve always seen project managers blaming people for bringing bad ideas, maybe because they are weak managers and they just… they are not ready to accept the responsibility for the entire team. It’s easier for them to say like “Hey, Jeffrey was the troublemaker.” They’re not saying like “Let’s not listen to Jeffrey”, but they’re just saying “Hey, remember everybody that was Jeffrey’s idea?”
Erik: Okay, and does Jeffrey still remain on the team after he was blamed for something as crucial as this? Yegor: To be honest Jeffrey becomes more manageable after that. Because Jeffrey’s scared now, Jeffrey will be way more careful with the new ideas. Jeffrey will listen. Am I wrong? Erik: Yeah, but no good ideas will come from Jeffrey as well. Oh that’s for sure. That’s a shame.
Yegor: It’s like we started on the podcast the majority but the majority of managers don’t need changes. They are fine with the situation they have, they’re fine with the status quo, the way now is perfect, so let’s shut let’s shut up those Jeffreys, we don’t need them to bring too many change requests here. But maybe it’s better to point fingers and say “Okay, Jeffrey, it was your idea.”
Erik: Yeah, but the world needs changing, right?
Yegor: I’m just showing you what’s happening in reality.
Erik: That’s true and you are very much true.
Yegor: So how to fix that.
Erik: How to fix that…
Yegor: If you are always Jeffrey, if you are the Jeffrey, and you want the changes to happen that you want to bring to the team. But you know that when they fail for some reason, you will be blamed. Erik: Yeah, yeah. At some point that might happen to me twice or three times before. I would start my own company and I would disrupt that company I came from. That will happen because I am a super Jeffrey, and I know what I’m doing, and I have all the power in the world currently, because I can start a company with Kickstarter. I have a good idea and I know how to develop and that is a very useful skill, so the company, you just lost one Jeffrey. Good people need to talk out. People want to speak out. So if you don’t want to have good people in your team, then you will be left with all the grey mice, and that’s just sad because then there will be this Jeffrey Inc. startup company that will go to the Stockholm Inc. and then run into every other company that has grey mice. Change will happen, you want it or not. And if a manager is a project manager that blames his team and he is indeed bad project manager it’s not good to play the blame game because you hire that team, you put that team together, so you are out of blame if anyone should be blamed, right?
Yegor: Ok let me ask that question. Speaking about change management and project management, what do you think people, this Jeffrey for example, has to be blamed or punished for? In what situation, for what? If not for failures. We just agreed that not for failures, but for what?
Erik: Not communicating enough. I think if you are a developer and you write the code, you’re good at writing code, you should also document, and you should also communicate with your team members like you do to code. I think communicating and the lack of communication is something that is holding change management as well, where you didn’t communicate more and that’s that’s difficult in a time of Twitter and that coaches that you can use to communicate. But people need to find each other. People need to do stand up meetings and talk to chatter about risks that they see happening. So for instance let’s go back to that server issue where we went to the cloud. If you are Jeffrey and you see this huge risk coming up. For instance you didn’t buy enough Azure subscription plan or big enough subscription plan. And you see that happening. We see that wall of issue coming up here. But you know you don’t talk about that, and then that should be punished. If you know something is going wrong, you don’t speak out?Wow.
Yegor: Well that’s interesting. I like it. So you’re saying that we should be the people… we should be punished not for greeting ideas, but for not saying what we think is happening, for not disclosing the information that you have.
Erik: Exactly. Yeah. You are a professional. You are the person that knows best and if you see a risk or if you see an issue and then talk about it, for instance, if you are in a room together with other developers and you see a developer next you write bag code, you don’t shy away from that person. You might be misheard or you might not. If you see that code, talk about it, right? Because if you don’t talk about it, that code might land on your plate later, he might have forgot about it and you drew the whole program at least. So communication is something very important in change management, at any kind of management thing.
Yegor: So it’s all like we have to be punished for not communicating enough. And we should be rewarded for communicating properly?
Erik: And communicating correctly, that is something that needs to be awarded, not communicating per se where you just stop working and start chatting at the work for all day, but you need to be rewarded by putting issues on the plate or putting risks on roadmap because that way we can ensure that the change that we’re working on because we are on the program, or we are on a project, we are making change happen. And we don’t communicate it correctly, that project will not per se fail but it will be less successful or less quality will be.
Yegor: You know, in my company, in Zerocracy, in all the projects we manage, we encourage people to report bugs about the software they work with and we give them like some mandatory, some tangible rewards for each bug they report. So what do you think about that? Because so many people criticized that approach, it seems like you would agree with that.
Erik: I would love that. I would love that. And just to take it out of the company environment. Why not use gamification? And by gamification I mean a new way of rewarding people. So for instance if Jeffrey… or Jeff? Well what do we call that guy? Jeffrey?
Yegor: Jeffrey.
Erik: Jeffrey. So if that guy reports 10 bugs this month, we might give them an experience point for him. And if he solves these bugs, we might give him 20 experience points. And if his team communicates correctly and writes is very best technical document that everyone has, even upper management, we might give them a 100 experience points. And if that organization or the person runs to 200 experienced points, we take everyone out to dinner, for instance. That is something that people can relate to because probably the average gamer is 30 years old, 40 years old, maybe. So we all know about experienced ones and getting a level up or something like that. And that’s this little adrenalin shot and we need that. And if we could get people to report bugs because they want to report bugs, because they want to get to dinner with your wife, or husband, or your friend, that will take the negative sentence out of it because you’re reporting that Bob to become better, right? Not because you think “Okay, well I’m going to report this bug that Dave did.”
Yegor: Which also may happen, you know.
Erik: If you’re in small teams, most of the time you know Dave is right or who this bug guy is. And the team is obvious fast, where there’s the slowest program right? And if you keep that programer a great mouse or a slow person, then the team won’t perform better if you run twice as much quality code as that slow guy. Right? So it’s a need to work together. You need to make a change as efficient as possible. And that happens with communication documentation progress reporting and generally approving people speaking out.
Yegor: That’s interesting because everything you’re saying makes sense for me, but the reality is different. So who do you think is more responsible for actually making the reality better, the management layer or the programmers, the technical people who just start improving the situation? Erik: Well I think the management has the power but they developers have the skills and you say well the reality is different, I think there is more and more startup companies that do like it when their team members speak out. Google changes. Apple changed. Microsoft changed. We currently have a “Thank god it’s Friday” session at our office where we speak out of things that we ran into, issues that we solved, issues that we are running into and that need solving. We are a very open community at Projectum where if we have an issue, we can talk about it and that’s why we’re one of the best. And that’s not being critistic or something but if you don’t speak out then there’s a big issue and management needs to know this, management needs to know that if no one interrupts you or no one corrects you and you’re doing something wrong. Basically, right? If you’re all right, then you’re wrong. So management has the power and the developers have the skills.
Yegor: So you know one more thing which I’ve seen quite often in companies is that the management would say we’re so interested in your technical ideas, just tell us where the code doesn’t work. Tell us what to do with the server. Tell us what to do with the with this algorithm. But don’t tell us anything about organizational questions like for example don’t bring up the idea of low salaries for example, or some work conditions, or some competition or our marketing position, because those subjects are quite toxic and we don’t want them to hear in the office. So please sort of know the line, know where to stop. So we are so interested in your technical opinions and technical concerns, but keep your financial and organizational concerns and marketing concerns to yourself.
Erik: As a developer, do you think is that a bad thing or a good thing? Yegor: Well as a developer it seems to me like some sort of hypocrisy, it’s that you’re my manager and then I’m a developer, I would feel that you are not being honest to me saying that you’re interested in my ideas and my concerns, you know you’re just saying that you need my concerns. But in reality you still keep me in the dark and want me just to write code and never and never come to you with a really you know important changes and ideas. And I would quit the company, I would try to get away, because I feel that the management is not with me. We are not the same team, where like separate parts, you’re working for yourself and keeping us working for you.
Erik: And I think that is the only healthy response where you will move away from that company. You will not work for another company because you as a person aren’t appreciated. And change will happen again. So if that person is not appreciated as a person but just as a tool or just as a programmer, well yeah, management will die out because people will not want to work for that kind of organization in the future. The millennials are now well on the way and the next generation even more so, where people need to be outspoken and want to talk. They want to know that people know their opinions. So if you are a manager and you don’t want to hear about your opinions of your people, so be afraid. Yegor: So you’re saying that all concerns, all questions, all ideas should be welcome in the office, in the team.
Erik: Absolutely. Yeah, yeah. And if you’re scared for your management and if you’re scared from management and.. how do I say it in English, in an anonymous, anonymous ideabox, if you can’t do that if you can’t still do that. Just yet sit in a workbox somewhere where there aren’t any cameras. Let people just drop their concerns there and maybe send out a thank god it’s Friday meeting where everyone can speak out regardless of their role. If you don’t do that then you’re losing all that intellectual property that you have in your own company.
Yegor: One of my last questions. Have you seen any lectures, or trainings, or courses for employees to help them understand how change management works and how they should be improved to start working on this better change welcoming environment or it just happens in short talks or the kitchen talks.
Erik: Well, there are a lot of TED talks about change management. I could look one up and connect to the show notes, right? And then there is this change manager that wrote a book that I would like to have linked too, if that’s okay with you. She was Danish change manager and she wrote a couple of books and did a couple of lectures and she really taught us that change management is very important in any project. So she might be something to look out for and look into.
Yegor: Uh-huh. Ok. And you think it’s in general is a good idea to train people for for change management?
Erik: Yeah, train them to communicate better train them to assess risk. Train them to you assess the line we’re doing something and let them communicate when you’re in the organisation while you’re doing it. No one wants to wake up one morning and go to the office, and hear “We move to the cloud, big surprise!” They want to know that upfront in a newsletter or something like that.
Yegor: Well sounds good to me. I have no more questions. It was an interesting discussion.
Erik: Yeah, I liked it.
Yegor: Saying something to our listeners, we encourage them I think to be more open, to be more open, to be more brave and to quit the company if they’re not appreciated.
Erik: Yeah, be a startup, don’t be a grey mouse. Exactly, and I don’t hope that half of the people quit their job tomorrow. Well basically yeah, talk about it. Talk about it, discuss it. And if people start being negative all the time, and leave, yeah. It’s a free world.
Yegor: Ok. All right thanks, Erik. Thanks for joining us.
Erik: Yeah, thank you very much for having me here.
Yegor: Absolutely.
Erik: Bye-bye.
Yegor: Bye.
