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!
Oldest 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.
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...
Hey Yvette, Meetup is great! Thanks for making it so.
What are some of your favorite technical solutions so far at Meetup?
Any exciting prospects coming up you'd like to share, technical or otherwise?
I'm not sure what you mean by prospects? But I'll assume you mean technical projects or product features?
We're excited to write more and more of our Android app in Kotlin -- we love using it to build our app so far.
We're really looking forward to getting on Swift 4 -- we really want to be able to take advantage of faster compile times and other improvements that we need to be able to iterate more quickly when doing iOS feature development.
We're pretty excited about using Airbnb's Storybook to better manage our web component library, since consistent web components is a problem we've been working on solving and we really like how Storybook has done that in many ways.
We also have been iterating on our variant testing framework and systems for segmenting and testing things like emails and mobile notifications. We're really excited about being able to experiment with those things and iterate on them faster than we ever have been before, and make our product better in that way for our members. We built our own in-house variant testing framework, but use Appboy extensively for creating and segmenting new emails and notifs (without the need for engineers to build them).
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.
How long did it take for you to become a CTO? What was it like?
My first job in tech was a part time job my sophomore year in college when I was a networking support specialist and helped end-users get connected and stay connected to 'the internet' in 1995. My first CTO job was at Meetup in 2015. So, it took me 20 years.
Before Meetup, I ran several engineering departments and teams and was also the General Manager of a 75 person team in Costa Rica. That job was most similar to a CTO, since I was ultimately accountable for everything the office produced -- not only the quality and delivery of software but also was responsible for the business operations like profit and revenue. I learned so much at that job specifically because I was working with people all around the world for the first time ever, and was combining my technical leadership skills with learning business leadership skills.
At different stages in my career I learned some really important, key things. When I first became an engineering manager, I worked at a company where we grew from 1 to 20 engineers in about a year. I learned so much about hiring, managing, and building engineering and company culture during that time.
While working for agencies, I learned so much about solving business problems via software and technology. I also learned an insane amount about how to communicate ideas (often complicated technical ones) in a clear and simple way and how to present an engaging story in front of an audience for the first time. I'm still learning that, and it takes so much practice.
How do you measure technical debt and how do decide that too much is too much?
We had (and have) a lot of technical debt when I started 2 yrs ago at Meetup -- the product and platform has been around for 15 years! One key for us is not spending too much time measuring technical debt. Most technical debt is complicated and you could spend a lot of time measuring it and not even be that accurate. Instead, our approach has been to identify the technical debt that is holding us back the most, and go all in to pay that debt down so that our efforts to pay down technical debt are going against the areas of maximum impact.
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.
How do you handle hiring? Would you say your hiring process is unique to Meetup?
We concentrate so much on the candidate experience at Meetup. Our recruiting team is so strong and great at working with engineering to create a great candidate experience where we really listen to our candidates and partner with them from the very beginning. I've interviewed at a lot of places myself and was always so frustrated that (especially at bigger companies), no one ever seemed to listen very much or care about what I wanted from a career and growth perspective. I think that's so huge in attracting but even more importantly retaining great engineers and people. So, we spend a lot of time getting to know our candidates, really listening to them, trying to be as unbiased and inclusive as possible, and changing our process all the time to make it better and customized for the individual we're interviewing.
We have a whole team of Community Experience specialists who are constantly reviewing groups to ensure they aren't going against our community guidelines and terms of service. We also have technology systems in place that help us identify these things.
I'm not sure specifically what your question is, but paid events are allowed on Meetup and we're all for our organizers making money on the Meetup platform as long as they follow our guidelines and terms. Spamming members is not allowed, and as soon as we identify actual spammers, we remove them from the platform.
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 is the key lesson that you have learned?
Wow, THE key lesson. I've learned so, so many lessons that it's hard to pick just one. In fact, I think the only way companies are successful is if they are constantly learning lessons from their failures. I think that's so important that the below is how I look at everything we do at Meetup and especially within the engineering team:
Build -> Fail -> Learn (repeat)
I think it's really important to build and fail fast, learn quickly from your failures, and directly apply it to your next iteration. That can apply to software development, organizational development, management techniques, whatever. But the key is to focus on failures as your most precious times of learning new things and applying them. Conversely, if you think of failures as times to point the finger or blame, you'll never move quickly and innovate as a company.
That all said, the key lesson...well, how about this -- speak up! Especially as an engineer, speak up about what you see, your ideas to improve things, your thoughts around how to simplify things, reduce technical debt, design a feature a better way, whatever. I've seen 1000 times now that engineers who speak up (within the right company cultures, of course) have 1000 times the impact than engineers who don't. Trust your experience, your instincts, you teammates and speak up!
Thanks a lot for all the answers!
Any intention on better integration with calendar platforms? It's the biggest barrier of entry for many people into Meetup.
What are the biggest hurdles?
We allow members to add meetup events to their calendar across all the major platforms. It's even easier to do in our apps than our web product. I love that feature myself because my calendar is so full that it's essential for me to block off times for meetups!
But if you mean integrate people's personal calendars and free/busy time that is a bigger technical and product challenge. We are very dedicated to respecting people's privacy and data security and we would also need to build those features in a way that are truly useful. We'll keep working on it!
Wow, trying it from in-app is so much easier than I remember. It must have been my web-experience that was frustrating!
Thanks for taking the time to reply, can't wait to dive back in.
Hello!
What are you proud of within the organization that perhaps has gone unnoticed?
In a similar vein, what processes (technical or in terms of philosophy) do you think make for frictionless collaboration between teams and encourage teams to work both productively and strive for growth?
Great questions! I am proud of so many things that the team does. I would say the thing I'm most proud of right now is how hard everyone has worked to reduce technical debt and build new frameworks that enable us to develop and launch software faster. It isn't easy to work on long term and hard projects like that, but so many people on so many teams have been working for years on this, and we're really starting to see the positive results of our work and be able to ship product so much faster than we were before.
I think the best way to help collaboration are alignment/shared goals and communication. For example, we create company key results that all teams ladder up to, and that's specifically so teams at the individual level, with their own autonomous goals, still are laddering up to a shared goal that helps them work towards the same things.
Also, nothing is a substitute for communication across teams. The more you can get teams to actually talk with one another, the more they'll understand each other's needs and goals and potentially 2x each other's success.
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.