Change is inevitable

In today’s world, in my opinion, standing still in your job is the same as committing career suicide–this applies to individuals as well as the teams they work in. The world is moving at a tremendous pace, technologies and their respective ideas are becoming quickly antiquated. The evolving workplace continually challenges people’s roles and responsibilities to the point that they induce, relatively speaking, identity crises. How shall we move forward? What do we change? How can we improve? How do we satisfy our customers? These questions are posed by our colleagues every day. Are you and your teams working the same way as you have in the previous year? If you answer yes, I assume then that you are satisfied with the value your customer has reaped from your team’s services and works. In my experience, this is often not the case. In my coaching experience, I often get the feeling that teams are unhappy with their progression, and the goals they have (or have not) yet achieved–therein lies the crux.

New roles, new responsibilities, and new leadership paradigms quickly challenge the assumption we’ve held at our workplace—nowhere is that most strongly felt than in the IT industry. The trend towards “agile” ways of working have been eagerly followed, adopted (in some ways incorrectly) in a hasty attempt to survive and keep up with the customer’s needs. Agile methods have begun to seep into various departments in your organisation, even in departments that aren’t directly IT related. This puts us in a roughly challenging position, keenly felt by long-time employees (and teams), who have traditionally over a period of time, cut themselves a little niche market of know how that gives them a sense of identity and value. They have the impression that they have power over the company because they see themselves as essential and non-replaceable and this is neither beneficial to the company nor the team.

In my opinion, nothing could be further from the truth. During my years on the field in organisations developing their know-how, expertise and capabilities, I’ve always maintained an attitude of sharing knowledge and making knowledge accessible to everyone in the organisation. Knowledge belongs to the whole organisation, and so I’ve actively coached teams and delegated responsibility to them, regardless of their age or experience.

Some time ago, I was asked to transform a team from a static, silo based, waterfall, low performance team (with a ridiculously bad reputation within the IT department) into an ever improving team applying scrum. There were many employees who believed this within the department. I had two of them in my team. One was an external contractor who had become part of the furniture because she had been there so long, and the other was an employee who had been the only person working in his field (at this company) over the last 10 years. Both of these employees were absolutely certain that without them the company would grind to a halt.

Unfortunately, not everybody wants to use scrum or to be agile. And so it was in this team, the members just did not want to do scrum because of what it meant for them. If I had a dollar for every time somebody in this team said “but it just works, let’s not change it” I would be rich. The single biggest problem was the fact that it was required for the team to change to way it communicated and worked. It meant that they would need to interact with other people at eye level (within the team and throughout the company), and this was categorically rejected. Secondly it meant they would need to share their knowledge, and help other people, and as I found out, this was a “no-go” to these more experienced employees, who were scared of the consequences. After beating my head against the team wall for many sprints (yes, we were sprinting) I still could not get my team to grasp the benefits of sharing and growing and moving forward. They refused to budge from their standpoint, and I wasn’t able to remove their fears that were being driven by these two employees mentioned above.

Eventually something had to give. And true to form it was the external consult who was the first to be removed from the team. I still remember her parting comments at her farewell dinner. “Mark my words, without me, you will get nothing done. You will come begging me for help within weeks” . I suppose I always loved a challenge, but I feared the team might not be up to this one, as at least half the team shared her view, and my trust in the team had begun to wan. I knew that we would need to implement a few little changes (small steps) and the team would be required to leave their comfort zone and move on. Losing somebody with this much know how always impacts negatively on the team and we were hard pressed to fill the gaps. The steps the team did implement, although we were taking more time than before, did start to take root, and with good retrospectives being held every sprint, the team got to grips with the loss. We continued to implement small steps every sprint and we did move forward. In particular, I noticed a massive increase in team members know how during this time. I´m pleased to report that 6 months down the line, the team had not contacted the consultant at all, and the team was producing code faster and with less bugs than before.

As to the second employee, this was a different kettle of fish. Not liking the new direction the team was moving forward and after we hired a junior developer to help in his area of expertise, he felt compelled to resign and move on. He was not enjoying his work, he didn’t want to work with anybody, and certainly was not prepared to share his knowledge. To be honest, this made me sad for him, but what made me angry was his comment when handing in his resignation to me: “When I leave, you can close the company doors. Without me you cannot continue to do business because I am the only one who knows how this area works” . My blood was boiling and so to ensure that he was able to leave immediately and not impact the team negatively, I waived the period of resignation and cut it down to the bear minimum for a handover of their daily tasks. The team decided that we wouldn’t even have know how transfer sessions with him.

Again, the team sat down together and we were forced to implement some small changes (even one or two radical ones) to take up the slack. Our comfort zone was gone again. It was clear that we had to move a bit more. The team accepted the challenge and we moved, using small steps while sharing the knowledge gained and helping our new young team member to get his feet. After the person in question had left, it took just 6 weeks before the affected department came to me to offer feedback. The feedback I got was staggering. They thanked me for the smooth transition from the old to the new employee without any down time or interruption in service; and secondly, they praised the new employee for his adaptability, his initiative and independence, for his incredible ability to do what they wanted, in a friendly and uncomplicated way, while delivering their requests faster and with a higher level of quality than they had ever seen before. Additionally they stressed on me that they had felt an increased team awareness of this area, and that the team seemed to be sharing a great deal of responsibility and know how for this department. They blatantly asked me why I had not implemented this change before.

In both situations, it was clear that the employee’s opinion of their abilities and area of impact within the company was completely incorrect and cemented that age-old adage that “no one is irreplaceable“. Although I eventually stepped down as scrum master, I was always impressed by the way the team had mastered these challenges. They did this not by standing still, but by continuously inspecting and adapting to meet the new situation while assuming more and more of the responsibility for the product themselves. Yes, as scrum master, I was the catalyst for this by enforcing that we stuck to the agile values and principles while implementing scrum correctly, but even after I left the team, it continued to grow as they implemented small steps to bring them closer to that goal of goals, a high performing agile team. To me this is what it is all about. Yes, you can stand still but then the world will pass you by. You will get left behind even if you do have a high repository of information. And your belief that you are essentially and irreplaceable will disappear like mist on a warm day. Slowly at first, but faster and faster once it warms up. This applies to teams and to individuals. But if you keep moving and keep sharing, if you inspect and adapt then your team (and you yourself) will continue to grow and hopefully you will be happier doing it.