Meetup Architecture Principles

Originally posted Mar 13, 2018

Our Goal: Empower Meetup engineers to build coherent, lasting architecture solutions.

This post originally appeared on Making Meetup

Meetup Architecture Principles
Meetup Architecture Principles

Meetup has been around for fifteen years, but today we rolled out the first-ever Meetup Architecture Principles. In my fractional VPE role, I’ve been tasked with helping to develop a new process for architecture reviews. As I got ramped up, Yvette Pasqua (Meetup’s CTO) and I agreed that it’d be beneficial to have some principles listed as a foundation to the work.

This process from zero to Principles took five weeks. I’m excited to share how we got to this list, and what they are!

The Process

I organized and facilitated a five-week Architecture Principles Working Group, inviting a handful of individuals who met the following characteristics:

Each of these working group members were responsible for representing a different part of Meetup Engineering (Data Science, Quality, Web, Mobile, the executive team, etc.). Brian Gruber, Meetup’s Principal Architect, was tasked with representing all of Meetup Engineering.

For each of those five weeks, the working group representatives and I met for up to an hour to collaborate, and afterwards the reps went back to their group to gather feedback using Slack channels and group meetings. There was a lot of Google Doc commenting and suggesting, a lot of great discussion, and a lot of asynchronous movement forward. Here was the arc of those five weeks:

Meetup Architecture Meeting Arc
Five-meeting arc with high level agenda and homework

I’m proud to say that Brian presented the following Architecture Principles doc, which contains lots of context about each and how to use the list, to the Engineering team yesterday:

Meetup Architecture Principles

How do we use these?

These principles are intended to help you evaluate engineering solutions to problems. Therefore, before you can apply them to your project, you have to be able to answer the question “What problem am I trying to solve?”

Once you know that, ask yourself questions like:

Build for Change

Meetup’s engineering team and platform will scale. The demands of our members (we call our users members) will change, and our understanding of the needs of our members will evolve. The systems we build will need to either adapt to change or be replaced.

Systems built for change:

What doesn’t this principle mean?

Build for Understanding

Building a compelling product means integrating with other systems, and doing so effectively means understanding those systems. Do you understand the systems that you’re integrating with? Will engineers who need to integrate with or maintain your new system in the future (including you!) be able to understand how it works, and what the limits of this system are?

Seek to compose systems out of small, easy-to-understand components. Make their presence, intent, and how they fit together, discoverable. This likely means a combination of:

What doesn’t this principle mean?

Build Meetup

The decisions we make in designing our systems should reflect the problem being solved. Some teams solve problems for our members, while others solve problems for other engineers, but all of us should be focused on solving problems pertinent to making Meetup.

What doesn’t this principle mean?

What’s next?

Obviously, this isn’t the end of our work on architecture decision making! Now that we’ve shipped the list, the Architecture Principles Working Group has dissolved. Next, Brian and I will collaborate on building an inclusive and sustainable Architecture Review process for Meetup. More to come!

Lara Hogan

I'm an engineering leadership coach and consultant. Previously VP of Engineering at Kickstarter, Engineering Director at Etsy.

I champion engineering management as a practice, getting comfortable giving presentations, and celebrating career achievements with donuts.