Taking Ownership of a Legacy System
7 January, 2022

Sr Director of Engineering at FanDuel
Problem
My team's most recent project involved taking over a massive system and codebase where we had little experience. There was a more extensive reorganization within my company where senior engineers were moved to new products, and my team acquired the legacy business. I struggled to manage this system, in which I had to take control of support and ownership while setting my team up for success. Our new platform consisted of code and systems that were unknown to my team. We had to identify all the moving parts and unknowns and set ourselves in a position to maintain this system long-term.
Actions taken
The first step my team executed was an audit of the existing system. During the audit, we identified the current services and processes in place. We connected our findings with information from experts from the last team to try and understand the architecture, documentation, tech debt, and known problems within the system. Unfortunately, many senior engineers who previously worked on this platform were moved to complex, fast-moving projects. Because of this, my team tried to be as efficient as possible when interacting with the experts and expanding their understanding. When we could connect with a critical subject matter expert, I tried to specifically get a level of commitment to be a resource for my team. Afterward, they were present in ad hoc meetings to consult on future projects.
After creating a foundation of knowledge, we reviewed the existing architecture with the business, product, and engineering teams. We tried to adhere to Conway's Law, where the org structure and architecture align. To do so, we mapped out the function we knew the system was supposed to do and how this related to products and features. This information was organized in a logical way in which we wanted to deliver value in the future. From there, we worked to find well-reasoned team groupings that would best support our outcomes. Lastly, my team assigned clear ownership of those areas and used it for the organization moving forward.
Establish what it means to own a portion of the system with your teams. Even if it is ambiguous, understanding who is responsible for something moving forward will bridge the distance between knowledge gaps. The outcome was a clear map of all the functionalities and products that our team was responsible for. These functionalities are aligned with business and product and separate from the audit of the existing software systems. From there, we clearly understood what logical grouping owned each of these areas and who was in leadership roles.
Lessons learned
- Don't be stuck on the current structure you are in right now. Align with business and product on how you want to deliver value in the future.
- When taking over any legacy systems, associating with the existing subject matter experts, plan on creating clear commitments on what level of support your team can expect.
- Clarify what it means to be responsible for a portion of a system with your team. By doing so, your team will understand the requirements to act like an owner.
- Establish explicit dependencies between the teams. Especially as teams take over areas they do not understand, they will be less knowledgeable about all the potential hidden dependencies. Examples of this can be stakeholders or other departments a team needs to interact with to achieve an outcome.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
22 June
Łukasz Biedrycki, VP of Engineering at BlockFi, talks about the importance of building on your strengths and finding your passions to maximize your impact. He dives into the tactics that managers can use to support their teammates in this pursuit.

Łukasz Biedrycki
VP of Engineering at BlockFi
13 June
Deekshita Amaravadi, Engineering Manager at Justworks, talks about the intricacies of making the decision to switch from an IC role to a management one.

Deekshita Amaravadi
Engineering Manager at Justworks
11 June
Tarek Mehrez, Engineering Manager at Klarna, explains what team health entails and shares his advice to managers who want to assess and better their teams.

Tarek Mehrez
Engineering Manager at Klarna
6 June
Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Ivo Minjauw
Global Product Director at OTA Insight
3 June
Otavio Santana, Distinguished Software Engineer at Zup Innovation, points out that becoming a manager is not the only way to progress in your career, and details the path toward being a highly influential IC.

Otavio Santana
Java champion, software engineer, architect, and open-source Contributor at Independent Technical Advisor
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.
