There is no organization that can escape the transforming IT landscape we see today. Change from static Virtual Machines to Containers to serverless infrastructure. Transform the traditional data-center-oriented organization and adopt a “cloud first” approach. And last but not least, everything is code: from infrastructure scripts to security guidelines and policies to business-driven dashboards that constantly flash to spit out new metrics. Changes are everywhere and all departments constantly pinpoint their focus. All of these changes might lead to (strong) resistance across different departments, especially in case they have different interests. Although these departments share the same end result, forces push and pull people in different directions. You need a solid change management strategy to make a success out of every organizational change. There are several books to guide you during this journey. Sometimes, simple things are very effective. Three powerful questions to drive your IT changes.
Context and scope
This article is not a summary of a completely winning change management strategy. Every company is different and not all strategies work in every situation. However, every change comes with a lot of things that are common for everyone. It’s wise to decompose the entire change into manageable chunks. By doing so, they become easier to digest and it’s more likely that people are actually able to react to them. Hopefully, in a positive way, and if not, you have a clear indicator of the resistance. In addition to that, it will give you valuable information on how to overcome problems.
Three questions
The following three questions act as a starting point for several projects/activities that are affected by the change. Besides this, they also form the base for any business case that should follow after you have identified these and when you have an agreement to steer in the given direction.
- Question 1: which new things should we do (as an organization)?
- Question 2: which things should we do better (than before)?
- Question 3: what should we stop doing (from now on)?
Together they form the theoretical benefits of the proposed IT change. Providing as specific (or explicit) answers as possible makes them powerful to seek the best solutions. It might lead to discussions and raised eyebrows: things become concrete. But this is needed to actually change, otherwise, things keep floating in space and nothing actually changes.
Question 1: which new things should we do?
Starting new things does not always imply you need to abandon the old things immediately. Although this is a strong statement for everyone that leans toward the “old way of working”, it might lead to a lot of friction. New things can start small and grow bigger over time. Small things tend to gain traction once they become more popular within the organization. This happens when it’s relatively easy to spot the success factor. Every stakeholder, not just the skeptical asks themselves the question “what’s in it for me” before they support your idea. Consider the following topics as inspiration for the “future things” you want to do.
Log streams
Switch from a centralized logging facility that is based on (raw) file storage towards a solution that enables applications to stream their logs continuously. Build a sample app that uses this feature from A – Z, for example through pure open source-based solutions. This way you can kick off pretty fast and people see the results. Highlight problems from the past (full disks, slow indexes, manually accessing sensitive log files, no real-time information, etc) and be sure to express the benefits of the new solution. Suppose you link this to another project that is all about Business KPIs, you can extract some sample data and show how the new solution helps to make an informed decision about a future situation. The more this aligns with the business goals, the better. For example: provide an accurate figure on the expected recurring customers that spend at least 1000US$ on your product.
This example is incredibly powerful since it’s very specific. Everyone can identify him/herself with the results. Even better, this approach boosts other people in the organization to think in the same direction and seek solutions for their problems as well. Collect those ideas in a list and share it with the relevant stakeholders that benefit most from it. Within no time you have a decent list of which you can pick the most beneficial changes which are already supported from the beginning by a large audience.
Hopefully, this approach reduces the resistance and overcomes other organizational obstacles a bit.
Question 2: which things should we do better?
Improving things is all about doing existing things in a better way. First, you need to identify crucial things that go wrong but for which you can implement a solution in a rather timely manner. Some examples of where you can start:
- Start using dynamic secrets as opposed to “static secrets” which tend to lead to various problems: key management is time-consuming, the governance of those secrets lacks clarity, and every now and then secrets are lost and need to be revoked. All of these aspects should lead to “we can do better”.
- Start transforming the most simple application from containers to serverless. Just to get the (hands-on) experience for developers and system operators. A simple pilot project quickly reveals practical and organizational problems you would otherwise get from endless discussions and other bureaucratic processes. This is not to say you don’t need to prepare this up-front, but “the proof is in the pudding” might reveal much more detailed aspects you haven’t thought of yet.
A central knowledge database
- Another example is from the customer service perspective: construct a knowledge base (KB) from previous incidents and collect the root causes that led to the original problem. Use that to build an internal FAQ to support developers in their struggle to solve problems quicker over time. The better structured the FAQ, the better. Imagine a fixed structure for every Question <> Answer pair. The question stems from a business perspective (f.e. how can I make sure the end user faces as few latencies as possible) with the potential answer (f.e. use cache mechanisms, index services, up- and downscaling, etc). All solutions should be linked to actual examples with a “before and after” situation. This way, developers understand what to do and business owners also have a hook to understand the problem. They will understand it and thus create the right priority for it on the backlog once they see the benefits.
All of this help to improve over time. It brings a positive spirit, since the majority of the attention shifts from “problem-solving” to “solution mode”. Both the business as well as the IT department are aligned since both worlds will be connected in every aspect of the resolution. Furthermore, this improves communication between different departments since they work on the same tactical or operational goals.
Question 3: what should we stop doing?
Perhaps the most challenging aspect of change is to “stop doing things you’ve always done”. This is especially true if you execute tasks year after year in the same way. The software application industry is constantly moving, but sometimes that leads to a massive shift in how you should do things to achieve new goals. Consider the following examples as a starting point to improve the things (over time) that you want to achieve. Suppose you want to reduce the time to market for new features or acquire more paying customers as a frame of reference.
- Stop requesting new Virtual Machines, on-prem as well as in the public cloud. Don’t accept exceptions, even for critical workloads. This would really cause friction within teams as well as the management of the responsible departments, but it’s a clear statement. VMs are over, containers are the new infrastructure component of choice. It also removes the “false sense of speed” of the popular “lift and shift” strategy which often turns out to be a very expensive deployment model in the long run if people are not transforming their applications. Refer to the article about cloud cost reduction to find out more about this. It is also a very tangible example of how much you can save on your (on-prem) bill (given setup, provisioning, and maintenance-related aspects).
Prioritization pays off
- Another powerful example from the business domain. Make a prioritized list of all (security) issues every day (or week) and only spend time on the issues that are part of an application that generates X amount of revenue. Stop spending time on other aspects which do not contribute to the profit so much. This shifts the focus towards the things that really matter and also puts the spotlight on those who are working on projects/activities which are less beneficial for the organization. Hopefully, it triggers a positive movement toward more innovative projects as a spin-off from the original example.
Avoid pointless discussions
- In some corporate companies, there is a trend to have a lot of lengthy discussions nearly about everything. Sometimes people instantly “let’s have a meeting” about anything that pops up. Important topics like conducting application portfolio assessments to determine which software system with a lot of dependencies should be refactored and migrated to the cloud first. But also smaller things like “assess CVE-X for an application that only has 2 active users”. It makes sense to stop having meetings with 10+ attendees about the smaller issues. Having a proper User Story on a board that is visible to everyone helps to keep the focus. Every ticket should have a clear Business (problem) Owner and the desired outcome. It should clearly show the business benefits when the User Story is successfully implemented or applied (in the case of a non-tangible deliverable). So stop having too many meetings without a solid focus.
Stopping doing things is hard, but beneficial if there are too many projects/activities that do not actively contribute to the greater organizational goals.
Wrap up
To change an organization, you need a solid vision and practical mission statements to guide people in the right direction. To make things more practical for the people that operate on the tactical and operational levels, it’s useful to formulate three simple questions: which new things should we do, which things should we do better and what should we stop doing? Explicit answers make the actions that come out of these questions very powerful. It might lead to resistance and discussions at first but the end result should be a solid change that persists.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
