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...
For further actions, you may consider blocking this person and/or reporting abuse
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
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.
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.
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 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!
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.
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.
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...
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.
Are you guys using Kotlin in production? If so, what parts of the app have been done with it?
We are but a very small amount of our app is written using Kotlin so far. We're experimenting by adding some new code in Kotlin as we have to add new features. We love it so far.
Would you hire me?
I don't know -- send us over your resume! :)
meetup.com/jobs/
lol that is too easy, just hire me :(
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.
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.
What do you think has more value: unit tests or telemetry?
I'm not sure exactly what you mean by telemetry, but unit tests are so, so valuable! They're the foundation for software quality, being able to ship software quickly, and they're fundamental to software product development in my perspective.
sorry, by telemetry I mean metrics/dashboards/distributed logging/etc. Statsd/datadog/signalfx/etc.
Some would argue that with rolling updates, canary deploys and autoscaling unit tests are only useful for limited applications. The old days of > 70% coverage aren't required.
Thoughts?
Do you still code? If yes, for what purpose?
I don't have time to code day to day anymore but I still read a lot of code and code comments on PRs!
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.
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.
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 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.
As an organizer of a local non-profit tech meetup (we don't charge member dues), it's really tough to shell out $160/year for our meetup.com membership (or find time to find sponsors just to pay that cost). How can meetup.com reduce this financial burden for folks who just want to create a great free community of tech-minded folks?
How do you collect feedback?
Tell us about how you use data science to make the app better? Do you have any ideas in the pipeline like predicting if user gonna attend a meetup or no, using access to the calendar to suggest some meetup to the user? BTW, UX has become better than last year congrats on that!
This is the smallest of questions, but why is the only way to take attendance for a meetup in the mobile web interface? (At least the last time I tried several months ago)
With an increased focus on mobile across the industry, and many mobile carriers deploying IPv6 to improve their customer experience, what is Meetup's strategy for enabling IPv6 on its services?
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.
What's your typical day at work?
(how much of your day is taken by strictly technical things)
What are your best pisces of advice you would give to young developers?
What are some of technologies and inventions can change the world in coming future?
What advices would you give fresh graduate who started working in a very young startup (he is one of the first 5) as a lead R&D Engineer?
How much time do you get to learn new things?