login


Google Sign inLinkedIn Sign in

Don't have an account? 

Cloud Migration: A Journey In Visibility, Communication, & Regulation

Convincing
Collaboration
Internal Communication
Different Skillsets
Cross-functional collaboration

11 May, 2020

Peter Maddison, founder at Xodiac, shares his story about how he dealt with a cloud transformation that was causing some substantial issues that, if ignored, would compound into some bigger issues. He learned more about the value of including everyone in the solution while increasing visibility across the company. His approach highlighted the benefits of keeping the business and operational sides better connected.

Problem

I had to help an organization with a cloud transformation because of some problems and difficulties I had realized. There were some prior architectural decisions that were paralyzing the IT delivery organization and cloud was a part of the solution. In a previous role within the same organization, I had been tasked with moving one of their data centers. During this, I discovered an architectural decision had been made to create independent “stacks” of systems for each development feature. This had resulted in hundreds of systems that needed to be managed, draining infrastructure resources. To make matters worse, lack of good data management meant product and development didn’t stay within their stacks causing errors and conflicts. Overall, this was just an absolute mess. it was slow to create new capabilities for customers and the quality was low.
 

Unfortunately, this problem was not very well known by everyone. I thought we should look at the underlying reasons behind this so that we can start to put the right piece into place. Once I established this, I had to convince everyone of the importance of making the necessary changes.
 

Actions taken

I proposed a three-step plan of things we needed to introduce to fix it.
 

The first step was to present this largely unknown problem to a few hundred people. It consisted of our leaders, managers, and other technical leaders. This presentation was a key spark that got them talking. I had to explain it clearly and straightforward because they needed to understand the pain points. They needed to see what is slowing us down and why we need to fix this problem. This helped us get some initial momentum, but, of course, this created many questions, and there was some pushback.
 

The second step was to deal with the concerns. The pushback came primarily from the development teams. Our infrastructure teams did not express the same concerns because they were the ones swamped with work, and they were paralyzed to the point that they could not get any exciting work done. This meant morale was low and I needed a spark to engage infrastructure in the change. I proposed a series of small changes to the platforms we were engaging with to introduce some new technologies to ease the tedious work of managing the chaos. This freed up time to focus on the more exciting work that would create capabilities for the delivery teams. By solving the original problem, we could help the team see the light at the end of the tunnel. We could show our teams the problems and have them engage and propose some solutions to help us solve the problem.
 

The third step was to introduce cloud capabilities into the organization to enable them to more effectively manage the environment sprawl. This was only a part of the solution as the majority of systems were not suitable for cloud migration. Instead, we built out a staging platform internally and began to work with the teams on refactoring the critical parts of the applications. This involved creating alignment across the project, development, security, architecture, and infrastructure teams as to what the target solution should be.
 

Lessons learned

  • I learned about the importance of involving the teams in helping find the solution. Of course, I identified the problem and had an idea of how to solve it, but I wanted to know how the teams would deal with the problems. By giving the teams the capacity and the time to come up with different ways of addressing the issue would help us continue down the path to a solution.
  • The human element here was simply involving our teams and adopting similar approaches to the problems we needed to solve. I knew we needed to create a spark that helped us have a sense of urgency to adopt a different change model for organizational change. This experience has now made me a subject matter expert on topics and issues like these, but at that moment, I knew that things would only get worse if we did not act quickly.
  • If we did not act quickly, we were going to end up in a situation where we were going to start losing business. If our systems started consistently failing, and we could not keep up, the complexity surrounding those issues would only get worse. The infrastructure side would not be able to do their jobs, which meant development would grind to a halt.
  • In this experience, I later learned that not only were infrastructure and development affected, but also our IT team was also heavily impacted. They were continually dealing with irrelevant requests that did not generate business value, and we had no traceability. Too many requests with a limited capacity to handle them showed no alignment between what the customer needed and what we created.
  • Overall, one of the key learnings was that when you are dealing with that level and amount of complexity, you cannot manage that from the top. You have to empower your teams to be able to solve these problems. My role had to be taking that over and helping ensure that I was giving my teams enough air cover and finding ways to free up time to implement some of the needed changes.
  • I had to go out, develop relationships, and make friends with many of the leaders on the development side of the technology organization and beyond. I brought them to the table and started conversations that, quite frankly, had not been happening up to that point. We needed to get those communication channels going so that we were not operating in those silos.

Related stories

How to Effectively Communicate on Slack
6 July

Shridharan Muthu, VP of Engineering at Zoosk, discusses effective communication using Slack including a recommended framework that entails three simple tips to make the most of the tool.

Internal Communication
Remote
Productivity
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Improving Collaboration Between Engineering and Product Across Time Zones
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how to make communication effective between PMs and engineers when they are located in different time zones and have very little overlap.

Collaboration
Internal Communication
Reorganization
Remote
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Handling a Mistake - Adopting a New Workflow
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how he quickly agreed to adopt new workflows, a mistake he later regretted, and how he handled the situation by spending the time to course correct and taking a stab at making things easier for his team.

Team processes
Agile / Scrum
Collaboration
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

An Acquisition Across Time Zones
6 July

Shridharan Muthu, VP of Engineering at Zoosk, speaks of the time his company was acquired by another org in a time zone half a world away, listing issues and providing solutions to how he overcame the time disparity while transferring product knowledge.

Reorganization
Internal Communication
Motivation
Remote
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Cultivating a Relationship Between Collocated and Remote Teams
3 July

Arjun Rao, Director of Engineering at Place Exchange, highlights three ways that induce a genial, positive, and flourishing atmosphere between collocated teams and their remote, contracted, or outsourced counterparts.

Remote
Collaboration
Company Culture
Arjun Rao

Arjun Rao

Director of Engineering at Place Exchange

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.