I'm the CTO of Meetup and I lead the engineering team with a focus on continuous learning, iteration, and using data to launch software that brings people together to do what matters to them. Our team enables 32+ million members in over 180 countries to organize and meetup in real life around the world.
I think a great deal about engineering empowerment, culture, organization, speed, and tackling technical debt. My AMA will start at 1PM ET today, September 28, so please feel free to Ask Me Anything!
Top comments (62)
What's the workflow between engineering and product like?
Great question! We work in cross-functional product teams, with an engineering lead working closely with product from the onset of feature ideation and creation. We find that the product we ship is best when the engineers are on the same teams and share the same goals as the product team designing the features.
Meetup is a community platform that has global value - what are some of the technology development and the user adoption challenges you face because of this? Were there any surprises or insights gained (post-rollout) that required rethinking?
There are so, so many global considerations to take into account when rolling out internationally. We have an international team dedicated to this that we always wish we can invest more and more resources into because it's so important.
Whether it's translation and localization of content and layout (for languages that are up and down or right to left), making sure our mapping software works in other countries (a huge thing we run into), making sure we support local organizers in creating good local meetup content in their native languages, SEO, or supporting payment types in every country (there are so many!).
But even fundamental things to our platform we've had to re-think as we've grown internationally. For example, the fundamental unit of our platform, the RSVP, isn't even a word or concept in most countries outside the US. So, we have to re-think important things all the time and take them into account as we're designing new features.
Great answer
I loved your appearance on SE Daily
You talked about using both Amazon Web Services and Google Compute Platform. At the time you were in the middle of migrating to the cloud.
How did that migration turn out and is your multi-vendor approach still something you're happy about?
Thank you very much! Oh, a really good question. We are still in both AWS and GCP. I could write a lot more (and maybe I will if I have time) but I'll summarize here. Our migration turned out AWESOME! Getting out of our bare metal data centers was so important for us. Our total cost of ownership to operate and maintain our systems has gone down and even more importantly for us, our engineers have been able to use native cloud technologies and auto-scaling to build and operate new features and software so much faster than we would if we were still in our data centers.
We're still in both AWS and GCP but have found AWS much stronger overall in terms of breadth of quality managed services we can utilize. For example, their Lambda product is way ahead of Google's serverless (functions I think it's called) so we are using Lambda a lot. Google still has a lot of data services we love. We're going to remain in both for now and leverage their strengths. For example, when we're trying to determine which technology is right to solve a particular problem, we get to choose between both GCP and AWS options, which is great. There is some overhead in that but it has been a lot less than we imagined it could be.
What new technology should we keep an eye on?
Oh, if I were able to answer this well, I'd probably be able to retire as a hard working CTO and instead rely on my awesome abilities to predict the future of tech! :)
Alas, I can't say for sure, but the technologies that we've really be impressed with using in our production systems that need to really scale (we have 32+ million members on our platform) include:
Kubernetes -- especially since we can not run K8s on both AWS and GCP -- it really reduces the complexity of running our Docker container ops and makes is much simpler to empower cross-functional teams of engineers to own and operate their own domains in production.
Serverless -- we're using both AWS Lambda and GCP functions to build business logic in a lightweight way and love it.
Fastly -- using Fastly and VCL as our CDN layer has been a huge game changer for us. It's really powerful and we can do a lot of things at the CDN layer that we used to have to do at the application layer. Doing it at the CDN layer helps us reduce the amount of complexity and technical debt in our application layer.
Frameworks/languages we've been using a lot more the last 2 years that we love (nothing is very revolutionary on this list but we've battle tested these and they've withstood very well): React/Redux/Node, Swift, Kotlin (just started playing around but love it)
Big +1 on Fastly
How does fastly stack up against CloudFlare? I've been really happy with themç, but haven't looked much into other CDN providers.
What kinds of things do you recommend for CTO’s and VP’s of Engineering to create a tech environment that attracts and retains women in tech roles? How can we help to reverse the concerning trends we have seen in the world of tech and gender discrimination?
"Identity" is a huge issue to most people. Meetup has to walk the line between accommodating various facets of identity (gender, race, ...) but also preserving user privacy (anonymity, ability to use aliases etc.).
To organizers however - the lack of clarity on things like gender, email or "name validity" have been challenges given the emphasis on real-world engagements.
On what basis are these decisions made? How do you balance organizer needs with user requests? (Who is your primary customer?)
Great question and that's something we obviously have to struggle to walk the right balance of every day that we're making decisions. We have clear community guidelines, a privacy policy, and terms of service that we literally spent many years drafting and refining. Those things are what we use to make decisions and we're constantly iterating on them to make them better. For example, earlier in the year when we saw the potential for hate groups to enter our platform, we updated our community guidelines to make sure that it was even more clear what was allowed and what was not allowed on our platform to make sure it was a clear decision for anyone to understand that hate groups of any kind aren't allowed.
We take all our member and organizers privacy very seriously, and while we want to be able to connect members with organizers in an easy way, we would always do that while making sure we were clear to both sides what information was going to be used for what. That's why we spend so much time on our policies and make very thoughtful decisions when we make changes.
As far as a primary customer, we have both organizers and members as our two important customer groups. We haven't had to pick just one and there's no reason to force the issue. At the heart of Meetup, everyone is a member and we're member-centric. But, we have whole teams dedicated to our organizer experience and making sure we're investing in organizer features and experiences as well.
What's the engineering culture there like? Are you agile or scrum? You mentioned you work in cross-functional product teams? Is every team responsible of one feature? How are decisions made for what has priority and what doesn't? Where does management(non-tech) fit into decisions? Whats you process for going from staging to production?
Our engineering culture is centered around the idea that we're all here first and foremost to make Meetup and have maximum impact on lives through our mission of helping people get together in real life, to do things together, and talk with one another.
We are not dogmatic about process -- we believe that process should be used by the team in a way that helps them hit their goals best. For example, some of our teams use kanban and others use scrum.
As far as how cross-functional teams work, our teams have a product domain that they own and they each come up with their own objectives and key results that they are going to go after each quarter.
High level priorities are decided by our leadership team -- things like what product areas and teams do we want to focus our resources on. But, we believe in giving the teams themselves autonomy to decide how they are going to have the biggest impact in their area, and create their own objectives and key results. At the team level, our product managers and engineering leads make decisions together with the team, and if needed they step in and are the final decision makers in their respective areas (product or engineering).
We're actually trying to entirely cut out our staging environment soon. As we finalize being able to run all automated tests in production, launch everything behind feature flags, and finalize our canary deployment processes, we will no longer need a staging environment. We like the idea of getting rid of staging because that's one less environment that we need to spend time operating and maintaining.
I'd like to hear more about your specific concerns, Steven. A lot of our members love our new apps and we get a lot of useful specific feedback around areas our members want us to improve as well. I can't really address your question without knowing more about your issues.
As far as our business model -- we haven't changed the model at all for many years now. We charge organizers a monthly subscription fee to run meetup groups.
What would be your advice to a startup, from technology point of view, which is just starting out (ideation or MVP phase)?
Assume everything you build you're going to throw away and that's ok. In fact, you'll probably throw it away at least twice before you're ready (from a product market fit perspective) and need to (from a scale perspective) build something that needs to scale and you know you don't want to throw away. So, in those early stages, don't worry at all about being perfect, just be good enough to move fast and have a high quality user experience and plan that you're going to throw everything away, probably multiple times.
What's the meetup stack and how has it evolved over the last 15 years?
Wow, it's evolved SO SO much! I don't have time to write all about it, but wrote a little about that in this blog post that I hope you find helpful:
medium.com/making-meetup/moving-me...