About three months back I left a stable and well-paid job at one of Germany’s largest companies. This company, Munich Re, offers its employees a lot of social benefits and security. It is a good place to work with many very nice colleagues. I last worked as an IT Sourcing Manager. Within that function I was the overall project manager for a large global transition project. A position with a lot of responsibility and visibility. Hence, my colleagues and managers were wondering and did not understand why I wanted to leave the company. It took some time to clear my thoughts after I left. Now I can look back at a very important period of my life and outline why it was time for me to leave.
My Start at Munich Re
I started to work for Munich Re in April 2011. I had moved on from msg systems to take over responsibility for the SAP Solution Manager within the infrastructure department. Together with other colleagues from Munich Re and SAP we took the SAP Solution Manager usage to a whole new level. The implementation of ChaRM and the completely new monitoring concept certainly were the highlights. Apart from these architecture activities I also became the technical project manager within the team. In my first project, soon after I joined, we virtualized the entire SAP landscape based on VMware. Out of curiosity and necessity I learned a lot about all infrastructure layers in this project. Operating system, hypervisor, server, storage, backup & restore, network – I got practical knowledge about all these layers.
Designing SAP HANA
In 2011 around the time I joined, SAP announced a new database technology. SAP HANA was the first major completely in-memory database. Fortunately, I had a manager who understood about the impact such a technology would have for us. Therefore, I could involve myself very early with this technology and all its developments. When the time came for the company to invest in SAP HANA, I was ready to design a completely new infrastructure based on the Tailored Datacenter Integration approach. To do that, I worked with experts from SAP, several other vendors and other internal infrastructure teams. It was exciting to build up something new completely from the scratch. The architecture became a SAP reference architecture shortly afterwards.
Implementing SAP HANA
I led the following implementation project as project manager. It was a very challenging project with many different internal and external team members and a tight schedule. Against the odds we were able to complete the project in a comparably short time. The infrastructure was up and running in production and operations was done by the Indian team. This success was possible, because the team consisted of 60+ very good experts from different companies and countries and all collaborated very well. During the course of this project I was sometimes called “Mr. HANA” by several colleagues. That made me think and I knew it was time to change something.
Adjusting the Collaboration Model
Having lived in India, the existing collaboration model with the Indian partner always bothered me. Tasks were mostly defined very explicitly in Germany and detailed cookbooks handed over to India. It was more of a serial approach rather than a joint approach. Thus, when I had the chance to move to the IT sourcing department, I took it. I wanted to bring in my knowledge about Indian work culture and implement my ideas of a more efficient collaboration model. As IT Sourcing Manager I became responsible for a large global service provider. I managed the application maintenance service (AMS) with part of the team onsite, part at a nearshore location and part at an offshore location. The objective of the service was to keep applications running at a cost-effective level.
Understanding Global AMS
In AMS I was able to implement my ideas to a certain degree. There were many challenges with expectation management being only one of them. Working as equal partners with my vendor counterpart we were able to improve the service’ quality over time. When the whole IT organization was about to be restructured towards a more global organization the model AMS became very popular as one important measure on that way. There were several providers engaged at the different locations. We decided to combine all of them and create one global application maintenance service. This meant a lot of work, because everybody in literally every location had a different understanding of AMS. On top of that all locations had different maturity levels in terms of AMS.
Implementing Global AMS
We defined one global AMS model and refined it consistently. In several roadshows the model was explained to most stakeholders. The following global tender was extremely interesting and challenging, but done in a very short time. As project manager I led the global transition project that followed right away. This transition project ran in parallel across several countries. Setting up this project and keeping the team of up to 120 team members together remotely was challenging, but very exciting. The collaboration and communication measures we implemented became standard for other projects, too. This project was definitely the highlight of my time as IT Sourcing Manager. Some people even started to call me “Mr. AMS” and that got me thinking again.
Learning to Fly
So why leave if there are several exciting and international projects with nice colleagues? As one manager told me:
“The grass is not greener on the other side.”
Maybe, maybe not. I simply do not know. Almost my entire professional career I have worked at Munich Re. First as an external and soon as an internal. It was an exciting time, both professionally as described before and personally, because both my kids were born during this period. I learned a lot and I grew as a person. However, I have hardly seen anything else than Munich Re. Now, I feel like a grown teenager – ready to leave the parent’s house. For me it is time to leave the safety of the cozy nest, take a step to the edge and learn to fly on my own.