Continuous Change
“Corporate leaders may not be able to change the world, but they can certainly change their world.”
Harvard Business Review
As a leader, I feel accountable to bring change. Daily. My change, in all aspects of my management role: people, processes, practices, technology, quality of services.
Constant seeking of opportunities to improve, evolve, innovate, gaps to be filled, risks to be mitigated, they all participate in building my continuous change pipeline.
It’s a mental habit, or, as an IT guy, I can say it’s perpetual job running in my background, fostered through a lot of practice, active learning, mentors support, and above all facing the consequences of wrong decisions, under-evaluated risks and unattended improvement actions. As simple as that.
Of course, this is nothing new: Kaizen, through PDCA, to ITIL® CSI (now slightly changed into Continual Improvement in ITIL®4).
But in my opinion, execution matters: my point here is not about bringing a new process approach, but sharing practices and lessons learned.
Let’s dig a bit, ok?
Do You Have a Continuous Change Monitoring System in Place?
My experience taught me that a working approach to Continuous Change is like a well-configured IT monitoring system: it gets you all relevant alerts, which you can manage, reactively, and more proactively as you get better.
IT systems evolution makes some alerts obsolete and determines the introduction of new ones: the same happens in your “Continuous Change Monitoring System”: practices, approach, and processes evolution can help you to keep your alerts relevant.
I think that leadership experience brings the skills and the seniority to build and maintain your Continuous Change Monitoring System, but my experience taught me this is not always true. Inevitably, I tend to work better with those leaders who implement this approach and capabilities, especially peers and bosses.
The reason is simple: such leaders truly aim to constant improvement, no matter what. And these are the ones making a difference in the whole organization.
Making a retrospective, I think my motivation, humble approach, continuous learning, and the strong mentorship I was lucky to receive, all shaped my approach to continuous change, and I try to coach my teams in order to master it.
Continuous Change Monitoring System - Which Change Alerts?
Photo by Hugo Jehanne on Unsplash
Change alerts are potentially endless and can lead to optimization or even transformation initiatives.
Let’s see some relevant, non-exhaustive examples:
- a production incident, leading not only to fix the issue but also reviewing how incidents and preventive actions management are handled;
- a rushing contract signature to stick to a deadline or an unforeseen issue which arises afterward, showing insufficient focus and the need for a more structured review and approval process, especially for large contracts;
- a project deliverable not meeting quality and/or scope targets, causing impacts on project timing, and potentially to service quality;
- insufficiently prepared meetings, showing lack of agenda preparation and management processes, and insufficient agenda planning;
- an unexpected lifecycle management need for IT assets, leading to unplanned, often complex and risky upgrade or replacement projects;
- manual or inefficient practices, which can be accelerated by automation and stronger processes;
- an underperforming or unhappy team member, hiding organizational issues;
- risks analysis, leading to a review of mitigation actions planning priorities;
- new cybersecurity vulnerabilities, which brings the need to prioritize fixing when critical;
- assets, processes or services which need more organizational focus, leading to a change in the organizational or service model in order to gain more velocity and quality;
- strategic, often and business-driven change management initiatives, which can imply strong changes to the operative and organizational model, practices and priorities.
Change Alerts Clusters
Let’s cluster the above examples by category:
- people, perhaps the most important cluster for potential scaling magnitude and impact;
- process and service optimization on IT processes and services (for instance service windows adjustments, communication improvements, meeting managements, production-related issues fixing);
- IT Assets, mainly coming from project initiatives (a new technology, upgrades on hw/sw, new capabilities);
- service model, for instance from internal to third party management of certain services (i.e. Outsourcing) or vice-versa;
- organizational model, acting on teams scope and responsibilities.
All the above-discussed alerts can also be clustered by impact and complexity:
- optimization, usually determining improvement actions;
- evolution, usually generating evolution or projects actions;
- transformation, generally bringing more complex project initiatives.
Clustering alerts brings more clarity on how to handle them, and help to better prioritize your consequent actions.
How to Build your Continuous Change Monitoring System
Photo by Tobias Tullius on Unsplash
In my experience, these are key factors to build an effective and efficient “Continuous Change Monitoring System”:
- observe, stimulate issues sharing with your team, learn how you could do things better (practices, technologies);
- don’t feel overwhelmed by too many inputs: keep a prioritization approach and get supported by a solid Actions Management System;
- discuss alerts and their ranking with your team, sharing a common understanding about the need to act and building a common culture for continuous change;
- share your vision about how your team will benefit from the changes;
- work to delegate alerts management, from “detection” to “execution” phase, in order to scale your system.
I also suggest to read the classical Kotter’s 8-Step Process for Leading Change.
What I did well…and wrong
It is undoubtedly due to the above approach that I could implement thousands on optimization actions, which led significant quality of service, spending and team engagement improvements for instance; in parallel I could also conduct several transformation initiatives: from insourcing/outsourcing services to establishing new practices, as SRE ), re-engineering, technologies, processes and organizational models.
What did I do wrong? Mostly, leaving change alerts unattended, letting potential risks turn into real issues or being hit by unexpected troubles.
This can be exponential if your team is not focused enough, leading not only to issues but to a lot of unplanned work too, with a disruptive impact on your timelines.
While I know I’m not as good as I’d like to be yet, I realize I’m constantly improving: my “success KPIs” (frustration, feeling in control, team motivation, planning fulfillment, and early detection) are all improving.
Conclusion
Summarizing, my suggestions in order to successfully embrace a Continuous Change approach as a leader, and thus as a CTO, are:
- accept that continuous change is the reason you’re in charge, managing the inner resistance on taking on too much, or fear to fail
- build a solid monitoring system, getting help, both outside and from your team
- adopt a structured management approach on change alerts and related actions, in order to effectively manage priorities.
Ready to succeed in Continuous Change?
(Photo on top by Nicolai Berntsen on Unsplash)