The need for modernization
There were several asks being made by the business to the IT team: be fully digital, be easy to interact with, enable innovation, ensure scalability, have a fast time to market, and ultimately have a fast time to value.
Like many companies, we had a legacy tech stack that was preventing us from achieving these goals so we decided that our best opportunity to meet the needs of the business today and into the future was to build a new digital ecosystem.
Starting with Principles
To ensure that the project was a success we implemented some core principles within the team.
We followed a greenfield approach so that we wouldn’t be constrained by the current systems. And we were strict on this. No connections to the current systems were allowed, not even the smallest one. We had a separation in the teams as well so that there were different teams managing the existing system and new teams to focus on the new system. You can imagine the amount of pain that this separation caused but it was a core principle.
We would work incrementally and use an agile mindset and methodologies. We clearly had to acknowledge that different people value different things and use this to find the best solutions. Some valued customer needs more, others valued efficiency more and others valued society more. The different values and perspectives contributed to better outcomes.
We had to become active listeners focusing on the people who work with the customers every day; the people that are managing the claims. We had to make sure everyone had a good view of what was really needed.
Bring people along
People that have been doing things for 10, 15, or 20 years ago would need massive re-skilling and upskilling efforts to change to do a different process in the new technology. They needed to learn and we needed to acknowledge that there would be a ramp-up period. Leverage business and technology know-how and maximize under new mindset, methodologies, tools and practices.
We replaced core components that were unimaginable in the past, and we replaced them in a couple of sprints. It was challenging but possible. We just had to have the right architecture and mindset.
The final thing was to be brave and supportive. This was more for managers and senior leaders. We had to be super supportive and we needed to give accountability to teams to make it happen. We didn’t go in blind though. We had a lightweight risk management process which we purposefully ensured was an enabler and not a blocker. When things went wrong we would fix what could be fixed and change what needed to be changed. But we had to delegate because this could not be achieved by an umbrella of a few folks. It was achieved by the whole organization moving to the same place.
There were a few leadership principles that we put in place to help make the transformation successful.
Leadership support. You must have a complete alignment, dedication, and support from the senior leadership team. There's no other way because it is a painful process to modernize a company.
Common Goal and Objective
Regardless of who you talk to, everyone needs to know the goal.
Lead by example
In particular, leadership needs to lead by example.
Transparent, close communication
You need to be super transparent. If there is a problem and you don't know the solution, admit that you don’t know but you will figure it out.
Secure your funding, without constant reassessment of why.
Dedicated critical roles
Critical roles like technical architect and security need to be fully engaged in the transformation.
Strong frameworks to manage quick releases are required. Everyone knows stories of big companies that have done an amazing job releasing things every day, every hour, but it's not easy.
Produce quality deliverables
Quality is non-negotiable.
We rush for everything these days but people need to take a couple of days to forward think. There will always be pressure to jump into execution but if we wanted to fulfill the ask of being innovation ready and being ready for the future we had to imagine what the future would look like. So we needed to find the time to engage with the right people and allow them to think.
We didn't know the outcome. We could guess the outcome, but we didn't know it. We had to put an experiment mindset in place so that we could try small things and course correct as needed.
We involved architects, product managers, designers and developers in our imagining sessions. It’s really important to bring in people from all levels, from all teams. They have the right way of thinking, the way of imagining. So by bringing them in we were able to improve the solutions that we defined.
Avoid following a strict methodology
We stopped running product increments, ceremonies and other tasks just to put another check in the box. We had to figure out what worked best for your team. We practiced real retrospectives and made sure that we brought the actions to improve the next day. If we wanted to get better, we needed to learn from the things that we didn’t do as well as we would like.
Don’t go down the (perceived) easy route by writing a big requirements document and run a big project to put some technology in place that is going to be there for 20 years. There's no such thing anymore. The world will change in two or three years anyway. We need to shift to an up-to-date mentality so we can react as things change.
Large transformations are all about the people; the teams, the engagement, the collaboration, the interacting, and the willingness to leave the business in a better shape than we found it. You can only achieve modernization with people. Take them on the journey and be honest that we don't know all the answers, but we'll figure it out together.