Back to resources

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

Different Skillsets
Internal Communication
Collaboration
Convincing
Cross-Functional Collaboration

11 May, 2020

Peter Maddison
Peter Maddison

Founder at Xodiac Inc.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty