Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Simplifying the Architecture

Dev Processes
Coaching / Training / Mentorship
Team Processes

30 September, 2020

Justin Potts
Justin Potts

EVP of Engineering at Bank Novo

Justin Potts, VP of Engineering at MoneyLion, tackles the ever-intriguing problem of simplifying the architecture and thus reducing the overall complexity of the systems.

Problem

As companies build out products, oftentimes teams build various systems that over time start to interact in complex ways. Furthermore, as time passes, those interactions become more and more complex. Eventually, you will have to take a look at all of your systems and reassess what belongs where and what should be talking to what. Then, you should simplify some of the complications and reduce the complexity of the systems.

Actions taken

We addressed this problem by implementing domain-driven design (DDD) -- an approach that emphasizes that the structure and language of code should match the business domain. We trained our engineers on the facets of domain-driven design and have them examine the system with fresh eyes, fresh tools, and fresh concepts like bounded context, aggregates, domain events and ubiquitous language.

We also started an architecture team that helped people learn and implement these concepts, and moreover, make key suggestions for the design or redesign of the systems.

The reason we chose this approach was that there are only a couple of approaches when you are trying to teach people architecture. There are paid-for platforms like Pluralsight or O’Reilly Media or we could help with mentoring relationships. However, we already had a team of people who were quite good engineers and we wanted to leverage the in-house knowledge we had since we knew our systems quite well. We chose an architecture team over those other options because it was the quickest to implement, we had the credibility and knowledge and we knew how to make the proper connections with people to make sure that it wasn’t an approval by the committee but information sharing with colleagues about how to better design systems.

The training for engineers went exceptionally well. We implemented it in two ways -- we had workshops where we would give presentations to the company and we also introduced a company-wide process called the request for comments (RFC), where people would draft design proposals. We would discuss the architectural principles inside the RFC with a lot of repetition and soon enough people were able to understand what is, for example, a bounded context and why we care about it. We used the RFC to effectively spread the knowledge about the architecture.

Also, we had one-on-ones with people when there was a need to clarify some concepts without them encountering any problem. There were not part of regular one-on-ones that are driven by employees, those were one-off discussions on challenges they were facing -- if we would notice that someone is struggling with a particular problem, we would reach out to them or more frequently after we built our reputation they would reach out to us, as the goal is always to be pulled not pushed.

Lessons learned

  • The solution, in this case, is never final because you are fighting complexity and entropy and these things are omnipresent and constantly recurring, but we were able to eliminate tech debt at a faster rate than we were before and the systems were becoming easier to reason about which means the meantime to resolution was also going down -- these are the key progress indicators that we are interested in.
  • Don’t do architecture as an approval committee -- that is an anti-path you want to avoid.
  • Make sure you take a gentle approach when teaching people architecture. Rather than saying this is the right way, make sure that you are approaching the conversations in terms of facts, impact and then, feelings. It is important not to dictate these things, otherwise, people become resistant to the change.
  • The key thing about architecture is not that architecture itself is complex, but that you have to be very considerate of the work people are already doing because this is an addition to their current work.

Discover Plato

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


Related stories

Preparing Your Team for the Remote Workplace

29 November

Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.

Alignment
Remote
Internal Communication
Coaching / Training / Mentorship
Data Team
Cross-Functional Collaboration
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

How to Strengthen Your Team Pitch

29 November

Vadim Antonov, Engineering Manager at Meta, details his journey to improve his personal hiring process and team pitch.

Alignment
Personal Growth
Hiring
Coaching / Training / Mentorship
Changing Company
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

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.