Leaders and managers often have to introduce change—perhaps they see the need, or perhaps their team members come to them with a problem and solution. But it’s important to check reasons for any change, and make sure those reasons are objective, which is to say they withstand thoughtful questioning.
I can think of two situations where teams were using very outdated software technology, and yet it wasn’t right to make a big push to replace that, even though new managers wanted their teams to be working with the best and most productive technology available.
I recently wrote about one example, where the new manager was unhappy that their team didn’t have “a good engineering vibe” and wasn’t interested in updating their very old technology. After a short discussion the defensible concerns were really that the team didn’t have the knowledge to support each other and share the workload—there were too many single points of failure. The most important thing in this case was to help the team have more interchangeable sklls, and allow new people in more easily. Changing the technology was secondary, if that.
Elsewhere I met a newly-installed leadership group whose team was using software that didn’t allow basic practices that are so important to modern digital product delivery—automated testing and continuous integration. In parallel, the team was largely not interested in (or not aware of) such practices.
It would have been easy to issue an edict that the old software stack had to be replaced by a newer one. But the execution would be very difficult (replacing legacy systems almost always leads to trouble). Instead there was a multi-strand approach.
In one strand the leadership group made the working environment much more fun, which involved some physical changes to the space and the introduction of technology talks and training from outside people. This showed the team that the leaders cared about them and it increased engagement in their subject and current practices.
In another strand there was a concerted effort to build a framework for automated testing and continuous integration in the older technology, where none existed previously. There was a sense of showing the so-called modern practitioners that “anything you can do, we can do, too.”
In a third strand they started using a more modern software stack for new-build projects. So new technology was introduced, but not at the expense of existing technology.
In both these examples change did happen, but it wasn’t the change initially envisaged. By subjecting the initial plans to more careful questioning the leaders and managers ensured the change that did happen was more meaningful, better supported, stuck for longer, and was therefore more successful.
niksilver.com 