Meetup + WeWork, a Retrospective One Year Later

7 min readJan 10, 2019

In November 2017, WeWork acquired Meetup. Among the many exciting opportunities that the acquisition affords is the possibility of utilizing WeWork space for hosting Meetups. My team at WeWork was charged with architecting and building a user flow to allow Meetup organizers to book WeWork space for their Meetups, within the existing organizer flow on the Meetup website. Here I’ll be discussing some of the interesting challenges around joining together two technology teams and creating an integration that allows for a seamless user experience across multiple applications.

Challenges

Different orgs

The first and most obvious detail to note is that WeWork and Meetup are independent organizations each maintaining their own data, applications, and systems. Each team owned numerous applications and legacy systems involved in the necessary data flow. It was clear that we needed a structured way to control the data flow across the two organizations when Meetup organizers book WeWork spaces.

Reconciling data models

The WeWork application responsible for booking member space did not have a “Meetup” concept. It only understood WeWork employees and members reserving space. Additionally, it utilizes a credit system which needed to be bypassed for this flow. Similarly, the Meetup event scheduling flow for group organizers had no awareness of “bookable space.” Until this project, Meetup organizers were responsible for coordinating and reserving a space, outside of the online flow, then inputting the location into the UI, which would simply trust that the space had actually been reserved

Technical Considerations

The core API functionality needed from both organizations’ sides — scheduling a Meetup event and booking WeWork space — live in mission critical systems, so tampering with any existing functionality, or causing downtime was out of the question. Performance of these systems also had to be kept in mind.

Infrastructure disparities

Each organization had developed its own set of practices and preferred tooling around topics such as infrastructure, code organization and style, testing, and deployment processes. For short-term ease of operations and long-term maintainability, we’d have to find a balance that adhered to both organizations’ needs.

As always, a rapidly-approaching deadline

Unsurprisingly, time was also a big factor. This project came with big goals and a lot of stakeholder attention. In order for it to succeed, good process and an agile approach would be critical.

The Approach

Selecting the tooling

We started by walking through the wireframes and listing out all the necessary pieces of data required for each step to function properly, as well as the source-of-truth application for that data. That list gradually turned into an architecture diagram. For the most part, all the WeWork and Meetup systems involved each handled their own data smoothly enough within their respective ecosystems. That revealed the possibility of creating a single hinge point to control the flow of API requests and responses between Meetup and WeWork applications. This system would effectively serve as a thin API gateway.

We debated between several options for how to handle the gateway:

After some discussion, we settled on using AWS Lambdas. The lightweight nature of setup and deployment, as well as the benefits of easily adding AWS tooling like load balancing, flexible databases, and logging made it a great choice. Additionally, opting for an isolated environment outside of existing codebases ensured that work could be divided up more effectively and done in parallel across the various systems. Each system worked off of mocked payloads until everything was ready to be hooked up.

Divide and conquer

Choosing the right tools early on set us up for success, but there remained the matter of actually completing a sizable amount of work in a disproportionately short timeframe. To borrow the recent catchphrase of the long-maligned Philadelphia 76ers, it was time to Trust The Process. No, not deliberately tanking our organization for the sake of future wins; we needed to implement strong, agile process. All of our teams across the organizations already follow Agile practices, so it was familiar territory. With this newly formed team, we implemented those same strong processes. All team members working on this project joined a daily standup and participated in sprint planning and bi-weekly retrospectives.

Narrow the gap

Sometimes the simple, practical details can make a big difference. In this case, Meetup’s HQ is approximately a mile downtown from WeWork’s HQ. It’s a trivial distance, but it’s distance nonetheless. As any sufficiently-jaded New Yorker can attest, traveling a mile in Manhattan can be an ordeal. To reduce friction around collaboration, we set up space in both offices for each team to work out of the other company’s office.

Iterative design

Iteration often results in better, more honed products, but in this case it also introduced some added complication. The UI portion of the project would live in a Meetup app, but consume WeWork data regarding building locations and conference room availability. We quickly recognized that the best way to empower the design team was to equip them with knowledge of that available data. That way, if any questions were to arise, such as “do we know how many spaces are available at this step in the user flow?,” we could quickly answer them and move on with feature design. To facilitate the process, a WeWork engineer (yours truly) joined forces with the Meetup team for a few sprints. During that time, I worked out of their office alongside their engineers, designers, and product managers. Sitting with them allowed for much quicker iteration, with the added benefit of two-way knowledge sharing (Meetup has some really well-configured pre-commit hooks!). Since the amount of UI work was fairly substantial, I switched over to working in their codebase and building out some of the front-end components. Having domain knowledge embedded directly on that team was a major help.

Maintain deliberate separation

I realize the whole crux of this post is about getting people and ideas closer, but bear with me. At the onset of this integration, there were many potential ways to go about it. Instead, we chose this single, specific entry point where two systems would meet, and even then, we did it through an intermediary service. In our case, combining systems and teams just didn’t make sense, so shoehorning it would’ve caused more trouble than it was worth. While multiple entry points and integrations provide for greater flexibility and potential extensibility, it also adds to the complexity and increases scope. A single entry point provided a clean, isolated place to write feature code and tests.

So, how’d we do?

Pretty well! We launched on time, with confidence in our product due to ongoing, automated testing, carefully configured alerting and monitoring, and a triage process. In addition, we rolled out the new feature as a soft launch, limited to a smaller subset of users via LaunchDarkly. In case user testing revealed that the new feature adversely affected the Meetup organizer workflow, LaunchDarkly provided an easy way to disable the entire feature with the click of a button (versus a rollback or additional merge/deploy). Testing and a kill-switch covered our failure plans, while a webhook posting to a Slack channel allowed us to celebrate the successful Meetup creation events as they rolled in.

Some features were left out of the initial launch and relegated to “nice-to-have” status, to be implemented for v2 slightly later on. However since we set expectations early, and reevaluated them constantly as progress continued, there were no surprises about what would ultimately be launched on release day.

tl;dr for success:

This is among the less weird Google image results for “success”

Plan early and often — planning is not just step 1; it’s part of all the steps.
Acknowledge your limitations and work with them in mind instead of trying to fight them.
Bridge gaps when reasonable to do so — in our case, sitting next to each other for a few weeks was critical for a successful outcome.
Make testing a first-class citizen of the process.
Have easy escape plans like a feature flag to disable the launch without a deploy.
Celebrate your successes! It’s all too easy to finish something and immediately get back into bug fixes and v2 features. Take a minute, bring the team together, maybe order an unreasonable amount of cake, and appreciate what you’ve collectively accomplished. Do a proper retro, and only then, get back into it.