I'm the CTO of Meetup, ask me anything!

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.

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.

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.

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.

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!

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.

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.

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...

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.

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.

I don't know -- send us over your resume! :)

meetup.com/jobs/

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.

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!

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.

I don't have time to code day to day anymore but I still read a lot of code and code comments on PRs!