DEV Community: Megan Risdal

Now anyone can host a global AI challenge on Kaggle

Megan Risdal — Thu, 19 Mar 2026 15:21:02 +0000

Kaggle's community helps the world discover what actually works in AI, and today we're launching Community Hackathons to build on that mission. Community Hackathons is built to help communities, individuals, schools and businesses and create professional-grade AI competitions using Kaggle's infrastructure, at no cost. These are a great way for builders to solve complex problems with AI and hone their professional portfolios.

As the AI landscape evolves, so too do the ways in which builders showcase their skills — moving beyond traditional predictive models toward building full applications, generating novel data insights and creatively utilizing large language models (LLMs). The gap between builders and the frontier has never been smaller and Community Hackathons are an amazing way to bring people together to discover novel results.

Leading companies and research organizations have already been using Hackathons to tackle unique AI problems by challenging the world to solve them:

The NFL has used Kaggle hackathons to create new statistics, hire talent and even make rule changes to improve player safety.
OpenAI used hackathons to red-team their first open-access model, and to help identify possibly hidden archeological sites.
The Google AI Studio team ran two Hackathons with the release of Gemini models. One challenged users to get creative with Nano Banana, and the other testing developers' vibe coding sprint abilities with the release of Gemini 3 Pro. These hackathons shared nearly $1M in combined prizes.
The Gemma 3n release was accompanied by a challenge to use "AI for global impact" and you’ll want to have tissues on hand when you review the results.

Now, Community Hackathons allows you to tap into the AI community to solve problems you care about.

Community Hackathon Features

Community Hackathons are built to be flexible and self-service, providing a seamless experience for both hosts and participants. By making the platform available to hosts worldwide, Kaggle enables diverse, custom-built challenges that drive skill development and portfolio enhancement. Hosts gain access to all the necessary tools for running a successful event, including:

Integrated tools for data hosting, interactive notebooks and discussion forums.
Support for writeup submissions and a project gallery to showcase results.
Flexibility for multiple competition tracks and judge management. Prize pools permitted up to $10,000 USD.

How to get started today

Whether your goal is to challenge the global AI community to build a world-changing application or to host a private internal skill-building event for your organization, Community Hackathons are ready.

Want to host a Hackathon? Create your own in minutes.

Want to compete? Keep an eye on the Kaggle Competitions page for new Community Hackathons appearing soon.

Have questions? Connect with other competition hosts in the dedicated Competition Hosting forum.

We can’t wait to see what you build and what new skills you hone!

Making public mistakes & code memes: The origin of my famous Titanic notebook

Megan Risdal — Wed, 26 Aug 2020 00:11:10 +0000

Yesterday, it was a great honor to be a guest on Nick Wan's data science livestream on Twitch to talk through bad (and less bad) data viz that I've created.

It was a lot of fun! Talking about the history of my popular Titanic R notebook on Kaggle was a great opportunity for me to reflect on my data science journey. Its explosive success was very unintended. But as a result I've got a couple of cool insights to share about this experience and how I apply them in my role as a product manager at Kaggle today.

The history

If you haven't come across my introductory ML tutorial on the Titanic Getting Started Competition, then I guess I can't count you among the over half million views it's received in the past 4+ years. "Exploring Survival on the Titanic" was my very first public notebook on Kaggle. According to the notebook's history, I created it in March 2016. And the story behind it is perhaps semi-interesting!

Flashback to late 2015, I had recently joined Kaggle as a user. After mastering out of my PhD in linguistics and getting my first job doing data science for market research, I was hoping to tap into and learn from the machine learning community. While I was waiting for Kaggle to launch a good tabular dataset competition to dip my toes into (still waiting ...), I was mostly playing around with their newly launched public datasets.

A few months later, Kaggle's newsletter landed in my inbox. They were hiring a part-time content marketing intern. Yes! This could be perfect for me. As the only data scientist at my job, I was eager to make connections and learn in this field. So an opportunity to create content, get feedback, and interview top data scientists was a dream. I applied and after doing an interview and submitting a writing sample, I was asked to do a short test project creating a tutorial notebook.

This short project ended up becoming the legendary Titanic notebook! In addition to receiving (at time of writing) 542,816 views, it's been upvoted 3,388 times, forked 6,135 times, and has almost 1,000 comments. I never imagined my work test would become one of the top pieces of content on the platform, even 4+ years later.

Lessons learned

Imperfections reborn as blessings

In my interview with Nick, we focused mostly on the bad data viz aspects of my notebook. I explained that the time constraints of the short job test forced me to focus on the aspects which I considered most important:

Delivering an end-to-end tutorial
A technical yet fun narrative that showed off my writing skills

I definitely didn't focus on the quality of the data visualizations in the couple of hours I spent on this notebook. Instead, once I got one part working, I moved on to the next. In some places, I wanted to test what was possible in this new-to-me platform which leads to some unusual choices in retrospect which gave us plenty to talk about (what was I thinking with that mosaic plot?).

In the end, I'm glad I focused on writing over data visualization or even quality of my code (because this is what I was evaluated on and I got the job, after all). Now that the notebook has seen such success with newcomers to machine learning, I think its flaws are actually a good thing in two ways.

First, as you might be able to glean from the comments if you read them, it's very easy to find areas to improve upon my work. This makes this notebook a great launching pad.

Second, if you can improve upon something that's as popular as my Titanic notebook, hopefully that gives you a (well deserved) confidence boost as a learner! These kinds of wins are really motivating early on and to the extent this notebook as enabled that feeling for many people, I'm really proud of it!

In all of this, I experienced how much you stand to learn from the community when you put yourself out there early and often even if it requires knowingly making mistakes in public. Today, as a product manager at Kaggle, this reinforces for me how important it is for Kaggle's community to be open to people from all over the world who are putting themselves out there to ask questions and learn.

Code snippets as memes

Another observation that I shared in my interview with Nick was about how I'd see other people copy distinctive bits of my data visualization code in their notebooks. I'd notice my plots repurposed for different datasets in my Kaggle newsfeed or just browsing others' notebooks. Since I'm not particularly enamored with my own data viz work here, it was kind of embarrassing to see my mistakes proliferate!

Code snippets are kind of like chunks of genetic material. Probably stuff that tends to work pretty well will replicate successfully in an ecosystem. And my notebook had a lot of signals of being a "good idea" in general: lots of views and upvotes, lots of forks, lots of comments, and highish score on the competition.

In general, I'd argue that publicly sharing and reusing reproducible code under an open license has been a good thing for developer productivity. But there are plenty of traps, too, as I witnessed my own flawed code go viral like it was some meme. This is something that I think a lot about now in my capacity as a product manager for Kaggle Notebooks (and as someone who previously worked at Stack Overflow). Questions like:

What signals do you use to know some code you're looking at is high quality and trustworthy?
How can we make it easier to find and effectively reuse useful, high quality code snippets?
How do you safely and easily update code snippets (mine are over four years old and probably still circulating)

Especially if you have thoughts about how to measure quality, I'm interested in chatting more!

Conclusion

Thanks to my willingness to publish what you could call "bad data viz" today, I've come a really long ways in my career. It's been an awesome journey from doing a small work test in a notebook to now managing that very notebook product in a few years. In a fun twist of fate, I suppose now I'm even responsible for how slowly this page loads due to its popularity!

If you want to hear more about my journey and my perspectives on data visualization (including an example of a "good" data viz), check out my interview on Nick Wan's Twitch.

Follow the conversation and discuss on Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1298398384529633280-17'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1298398384529633280&theme=dark" }

How our team improved perceived reliability of Kaggle Notebooks

Megan Risdal — Fri, 14 Aug 2020 01:03:25 +0000

I’ve worked at Kaggle on-and-off since 2016. In this time, THE most consistent source of user feedback is about the reliability of Kaggle Notebooks. Sessions were slow to start and, far worse, sometimes users would lose hours of work. While progress had been made over the years, we’d never systematically addressed the problems.

Over the past half year or so since I’ve rejoined Kaggle, the Notebooks team renewed its focus on reliability. In this post, I'm proud to share how our team used a systemic approach to significantly improve reliability, both in terms of quantitative metrics as well as user perceptions.

Background

Kaggle Notebooks is a no-cost managed Jupyter-based notebook product. Our users use Python and R notebooks to analyze datasets, train models, and submit predictions to machine learning competitions. Today we manage many thousands of VMs handling thousands of concurrent sessions for users all around the globe.

When I joined in 2020, we felt confident that reliability was the number one thing we could work on to improve our users’ experience using Kaggle Notebooks. We knew this from:

A happiness and tracking survey we send to a sample of users each month
The volume of bug reports on our site feedback forums

Improving user experience is a critical priority for Kaggle for a few reasons:

Notebook usage is required for some competitions and we don’t want the user experience to be such a pain that it turns users off participating completely.
Many brand new data science learners use Notebooks and if you’re new to something, sometimes it’s hard to tell if bugs and instability are your fault or not.
We want users to use Kaggle Notebooks enough to create cool, helpful analyses that they want to share with the community.

Our approach

In our approach to the problem, we considered reliability as having two facets: actual and perceived. In the first half of 2020, we prioritized a number of focused improvements to address both facets:

We maintained a dedicated working group to address a backlog of issues and monitor and respond to user feedback.
We implemented a new scalable, highly available backend architecture (read about it from Mod, the technical lead on the project) with multiregion support.
We shipped features to improve perceived reliability like “sessionless editing”, a brand new save workflow, and better session start/stop controls in the UI.

We feel the biggest game-changer was the sessionless editing feature that we delivered in June. Previously, rendering the notebook required a running jupyter server. But, starting the session took over a minute at the 95th percentile and about half a minute at the 50th percentile. This was a huge point of frustration for our users that we hypothesized contributed substantially to perceptions of poor reliability. With sessionless editing, we can now render and initialize the notebook editor within seconds.

The gif below illustrates a side-by-side comparison of the experience before and after launching our sessionless editing feature.

Next, measuring impact was critical. To match actual and perceived reliability, we took a multi-modal approach to quantifying the results of our efforts.

To measure actual reliability, our reliability working group created a dashboard to monitor and set goals against some key metrics like availability and time-to-edit latency.

In part to measure perceived reliability on an ongoing basis, we also started a quarterly one-question survey. It asks recent notebooks users to “Please select any of the issues below that you have experienced on Kaggle Notebooks in the past couple of months”. Users could then select multiple options like “Notebook session was unreliable” and “Insufficient features available”. We fielded the survey twice: once at the end of Q1 and again at the end of Q2.

Results

I’ll focus on the qualitative results in response to the one-question reliability survey. Our quantitative data showed progress, but would require a longer blog post to walk through.

First, you can see the overall results below.

Most users in both quarters reported having no recent issues which is great. But, reliability (i.e., “Notebook session was unreliable”) was the second most common response in both quarters. Reliability concerns definitely still persist among respondents.

When we focus on percentage change between Q1 and Q2, however, it becomes clear that we did successfully make progress in the right direction.

Because most of these items are issues (i.e., pain points), an increase from Q1 to Q2 is generally bad (red) whereas a decrease is generally good (blue). Only some of the changes are actually significant (the solid-filled bars).

We saw statistically significant decreases in users mentioning:

📉 33%: Can't depend on notebooks to do serious work
📉 19%: Session was unreliable
📉 18%: Session was slow

Even though reliability still remains a top concern for our users, we were really pleased with these results. Plus, this is the first time we’ve quantified user perceptions to tell us that we’re making progress.

Takeaways

The biggest takeaway is that we’re not done yet, but we’re trending in the right direction. We remind ourselves regularly that this is a journey and what matters is being on the right track. Based on our results so far, we intend to maintain our dedicated reliability working group, set new goals, and continue to listen to user feedback.

Massive thanks to everyone on the team who contributed to this effort: Aurelio, Jim, Dustin, Cole, Philippe (Mod), Michael, Vincent, Erdal, Einav, Chelsea. It’s an honor and a thrill to be part of such a great team. Special thanks to Jim who co-authored the original internal report that this blog post is based on and to Jessica for fielding the survey. Last but far from least, thank you to our users for your invaluable feedback and your patience!

Kaggle’s 5 remote-first tips for new WFHers

Megan Risdal — Fri, 27 Mar 2020 16:36:22 +0000

Kaggle is a unique team at Google. Unlike the vast majority of Google teams, our team is fully remote-first and distributed in offices (Google and home) across North America and Australia. When the spread of COVID-19 led to mandates to work from home (WFH), my coworker Victor and I saw an opportunity to share insights from our team to help others across Google adapt.

So we recently shared our top five remote-first tips with Cloud AI leadership, our parent organization within Google. Now, we want to share our advice with you! The advice we put together is based on the things that we believe either require the biggest behavior shift or stand the best chance of increasing productivity to address pain points in this time of transition.

Victor and me presenting our WFH tips to WFH Google Cloud AI leaders … while WFH.

Background

First, to establish a bit more context, I’ll share more about Kaggle. Our team is made up of about 50 members in engineering, marketing, product management, data science, design, etc. Kaggle has been remote-first for about a decade.

Second, our core values are important to framing how we approach remote-first.

Low ego because it facilitates trust and open communication
User first because it drives focus on important problems to solve
Agility because it helps us make decisions quickly in ambiguity

You may want to consider how you can leverage aspects of your team’s culture to reinforce WFH productivity.

Tip #1: Default open

🙅‍♀️ Problem

Your team may be feeling isolated, out of the loop, and siloed. Team members may be communicating one on one but missing the sense of team and community. This can cause anything from miscommunications or dropped balls to serious tensions and degrading trust on your team.

✅ Remote-first solution

Default to communicating as openly and transparently as possible with your team. Make extensive use of public (to your team), readily accessible communication channels.

🛠 Tactics for your teams

Deliberately communicate more frequently than you think you need to

Communicate more frequently. Also make sure you’re not simply shouting into a void, but ensure that your team hears and understands, as well. Make sure your calendar events and Google Docs are visible by all by default.

Share meeting summaries / action items in a public (to your team) venue

Take good meeting notes and share out summaries or action items in a public venue. GitLab has more great remote meeting tips in their handbook.

If you repeat something verbally in 1:1s, write it down in a Google Doc and share

Don’t succumb to games of telephone. If something seems to be remotely important write it down. If your team doesn’t already formally document everything, this may make certain things feel more “official” than they might really be. The next tactic is one way to help make this adjustment.

Make WIP docs available for input from more people earlier

Get feedback earlier on things in progress. Normally you would get feedback about ideas or projects in progress during “watercooler chat”. This is a way to replicate that and you might find that you even get more diverse and creative input.

Making important documents easily accessible to anyone on the team.

Tip #2: Practice async communication

🙅‍♀️ Problem

Feedback loops are slow. Team members are AFK and unresponsive during typical working hours. This can slow projects down and leave people feeling frustrated.

✅ Remote-first solution

Move more communication to async, setting norms and expectations so work still gets done efficiently. Kaggle’s team is distributed across many time zones so this is really important for us. Your teams may not be so distributed as ours, but at a time when so many team members’ schedules are becoming unpredictable or shifted, async can be critical.

🛠 Tactics for your teams

Agree on team-wide expectations around hours of communication and availability

Agreeing on team-wide expectations around hours of communication and availability. If you haven’t already done this, this is absolutely step 1! For inspiration, checkout GitLab’s handbook on communication guidelines.

Know when to move from async to sync

Next, to the extent possible, be willing to quickly jump into a call if something doesn’t seem resolvable via chat. This means keeping a headset handy. This is especially useful in cases where you might feel things are tense or something is getting lost in translation.

Create a venue like chat for async daily standup

Finally, if you’re worried about making sure you know what everyone on the team is working on, create a venue for this. We have a chat channel called #nikodaily where people share 1. What they did today. 2. What they’re doing tomorrow. 3. Any blockers. 4. Any FYIs. Create something that works for you.

Our internal Niko Daily tool which records our async standup statuses and notes.

Tip #3: Embrace a non-linear workflow

🙅‍♀️ Problem

Without the ability to just walk over to someone and ask a question, team members are blocked and not making progress on a task, frustrated they can’t get immediate help.

✅ Remote-first solution

This tip applies especially to engineering teams. For engineers who bristle at lots of meetings and context switches, productivity is normally associated with finding flow on a single task. That’s not always possible in a remote, distributed context. Similarly to async communication, a remote workflow expects non-linear progress and optimizes for it.

🛠 Tactics for your teams

Have multiple tasks that you can switch between to always ensure progress

Due to the asynchronous nature of remote work and especially with current unpredictable circumstances, try to have more than one task on the go, that you can switch between if you get blocked on your current task. At the same time, avoid having so many ongoing tasks at once that context switching prevents making any progress.

Document and make team knowledge searchable to minimize pings

Since you and your teammates may be focused on different things or available at different times, before pinging someone and potentially interrupting their workflow, check if your question has been answered in one of your public channels. One of the benefits of defaulting to open is that all your team knowledge is written down and searchable!

Provide lots of context

When you’re blocked and waiting for someone’s response, give plenty of context on what you’ve tried and what you understand so far so they can unblock you while you’re working on something else. Likewise, when responding to others, be deliberate about unblocking them. For example when making decisions or reviewing code, if possible give approval with conditions so they can progress without another round trip to you.

Tip #4: Foster team bonding

🙅‍♀️ Problem

Morale is low and team members feel lonely and disconnected from each other. Tensions might emerge as trust weakens. People may feel less willing to take risks.

✅ Remote-first solution

For many years, a Kaggler on our team, Jeff Moser, has evangelized Steve McConnell’s concept of the “half life of trust”. The longer you’re removed from aspects of your colleagues’ lives that make you realize who they are outside of work, the lower your trust is with them.

In a study on Google team effectiveness, psychological safety was the number one factor contributing to team success. Psychological safety requires trust, so for remote teams for whom this is harder to build, you have to be very deliberate about cultivating it. Put effort into unique ways to maintain and strengthen personal bonds. And have fun. :)

🛠 Tactics for your teams

Celebrate wins (even more) often!

First, celebrate wins more often. We use chat to regularly share wins in our largest team channel. If your company has a peer recognition system, encourage your team to use it.

Set up socialization spaces for “watercooler” chat

Second, set up spaces to replace watercooler chat. These can be a combination of async (e.g., chat) and sync (e.g., recurring optional team meetings).

Use emojis gratuitously (seriously!) 🤪

Finally, it might sound like a joke (okay, it’s a little tongue-in-cheek), but don’t forget to use emojis! By this, I really mean make sure you find ways to insert phatic expressions that are often missing from text-based communication.

A sampling of posts from our some of our many interest-based chat channels like #pets, #random, and #booksandmovies

Tip #5: Take care of yourself

Our last bit of advice is to take care of yourself and encourage your teams to do the same.

As we all know this is not a normal work from home situation. Even for our team, one that’s been remote for almost a decade, some of us are feeling the impact on our well being and productivity. In fact, we know from experience that some folks may respond to a situation like this by working even harder than usual. We have to give ourselves and each other a break.

There’s a LOT of good advice already out there for well being and work-life balance. But here are some tips from our team. You should strive to do them to the extent possible, but it may be harder for some given circumstances.

This is not normal.

🛠 Tactics for your teams

Establish clear work boundaries

Have a routine of “going to the office” like get showered and dressed, maybe exercise to start the day. Also have a wind down routine for “going home” for example go for a walk. Try to have a dedicated space for work only.

Disconnect by creating a predictable schedule

Disconnecting requires finding or creating predictability. For example, try to work the same regular hours. Snooze or disable notifications when you’re done working. And make sure your working hours are visible to others.

Assume good intent

Finally, assume good intent from those you’re working with. This is an extremely taxing time for many and patience can more easily wear thin and mistakes will be made. Be understanding and compassionate (including with yourself!).

Wrapping up

We hope that you find these tips helpful. Even for us, a seasoned remote-first team, improving our productivity, efficiency, and happiness is a perpetual process. We’re constantly redefining our own best practices, habits, and workflows.

Our most important tip for how to apply these recommendations is to be introspective and flexible. At the end of the day, we can’t give any one-size-fits-all advice because it doesn’t exist. Take the time as a team to listen to your own needs and pain points and adapt solutions accordingly. You’ll quickly find that you’ll develop norms that work for your style, culture, and situation.

We’d love to hear in the comments what things work for you and your team!

Productive transparency in online communities: Inspiration from trains and IKEA

Megan Risdal — Thu, 23 Jan 2020 05:44:57 +0000

The Japanese train system is famously fast, clean, friendly, and efficient. On the drive home from my first day back at Google I was reminded of why as I listened to the 99% Invisible podcast episode “Wait wait ... tell me!”. I’ll give you the tl;dr summary of the story and explain some connections I made to product development for online communities that got me so in my head I missed my exit for the 405.

One of the secrets to Japan’s impressive system of bullet trains, called Shinkansen, is simple. It’s the kind of elegant solution I dream of and representative of the values I hold as a product and community person. In order to improve rider satisfaction with wait times while trains were cleaned, the new CEO of Shinkansen didn't sacrifice quality. Instead he introduced transparency between workers who cleaned trains and waiting customers. He did this by literally making workers more visible (e.g., bright red uniforms) instead of intentionally invisible (pale blue uniforms that blend in with their environs). Beyond physical appearances alone, he also encouraged workers to actually speak with passengers.

Making their work more visible in these ways had profound effects on behaviors in the system between workers and waiting passengers. Namely, passengers:

Were less frustrated by wait times because they could better see and understand the purpose of waiting
Empathized with workers to the point of being more conscientious by proactively cleaning up their own messes

With this transparency, passengers were empowered with insight into the common interests between themselves and workers. They not only tolerated the extra wait as workers cleaned trains, they embraced it. And no one had to tell them “because it’s good for you.” Additionally, Shinkansen was able to maintain high standards of cleanliness.

In a conversation with a friend about the Shinkansen train system story, he brought up IKEA’s cafeterias. The ones with the amazing Swedish meatballs and lingonberry sauce. Where you bus your own table. Not only is a DIY approach appropriate here (it’s IKEA!), they make it consistently transparent throughout the diner’s “user journey” so there’s no room for unmet expectations for Michelin-grade experiences. And it goes beyond signs everywhere. The carts where you stash your emptied trays are an unmissable centerpiece of the cafe. In most places they are hidden out of sight.

Photo by Oleg Laptev

In my blog post reflecting on my time leading product for Stack Overflow’s public Q&A, I alluded to tensions among different types of users. Curators and moderators and question-askers and question-answerers. One of the things that I think is well appreciated by moderators and curators (and probably many question-answerers, too) is the importance of the quality of content that gets created and maintained over time. Interestingly, question-askers (mostly new users) are the driving force behind content creation on Stack Overflow, yet often their local and immediate needs may not make the quality of the entire repository present in mind. The tension, in part, in my opinion is a lack of transparency between integral parts of the system (people!) that could be communicating.

If the flow a question enters when it's closed was more transparent, would that help people understand why it happens? If people saw how content reviews help keep up a healthy ecosystem of question and answer pairs, would they more eagerly contribute to review themselves? What if the average user knew that without a small number of volunteer moderators handling flagged content toxicity would be double what it is?

I’ve long thought that much of Kaggle’s relative welcomingness as an online technical community stems from its inherent temporal transparency between power users and newcomers. This started with Competitions. Each Competition which runs for a couple of months is a new shared objective for new and old users alike to collaborate and share ideas. Each competition generates a cohort that’s basically a community of practice with a deadline. Once it’s over, users often write-up their approaches (example), sharing what they learned with the community. And then they start all over again with the next competition. Over time, each user is on a cycling trajectory from novice to expert and there’s always some new technique or framework to learn as the state of the art in machine learning evolves. I really believe it's visibility and participation in constantly cycling cohorts with shared goals that make it easier for users of all levels to better empathize.

In an online community, you need to find ways to foster and incentivize ways to encourage different types of users to interact positively and contribute to your mission. I believe that transparency, especially by making shared goals and opportunities to empathize apparent in the product itself, can be an important way to achieve this.

Thank you once again to Josh Heyer (AKA Shog9) for his feedback on this post (and for talking to me about delicious lingonberry sauce). Thanks also to my fellow Kaggle Noobs moderators (Aakash, Yifan, Mikel, Jorge) for their discussion on this topic.

Follow the conversation and discuss on Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1220193165535170560-599'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1220193165535170560&theme=dark" }

Reflections on Stack Overflow: Building Successful Communities

Megan Risdal — Sat, 07 Dec 2019 03:03:41 +0000

Today is my last day at Stack Overflow. For most of this year, I was the lead product manager for their flagship product, public Q&A. In my last couple of weeks there, I spent some time reflecting on what I have learned and how my perspectives as a product leader matured. As someone deeply invested in building open developer communities, I continue to refine my opinions about how to approach building community-facing products.

Based on these reflections, the following is my own personal perspective on what a product leader at a place like Stack Overflow can do to be successful (and hence make community products successful). Although they are pretty specific to Stack Overflow, I am taking what I’ve learned with me to my next endeavor and you may find them applicable to your world, too.

Make Stack Overflow work for everyone.
Be ambitious and a driver of positive change in the face of inertia.
The community is an asset. Experiment, iterate, and listen.
Create simple defaults and tear down configuration and customization.
Keep the mission and impact in perspective always.

Building a successful community

Make Stack Overflow work for everyone. Do not indulge “us versus them” dynamics.

There are many types of people who use Stack Overflow. The main segments for Public Q&A are: Askers (including people who just look up answers to existing questions), Answerers, Curators, and Moderators. The interesting thing about Stack Overflow’s user base though is that all of these segments (of real people!) interact with each other in feedback loops:

People ask questions and other people answer those questions
Curators identify quality issues and other people receive that feedback
People flag content that doesn’t belong on the site and moderators handle those flags

Any initiatives that only serve one segment put the community and product into imbalance. In reality you’re making changes in a complex, dynamical system of real people in a community. Emphasizing one type of user also makes things unnecessarily personal. By “personal” I mean about people, not about the system/software. I observed that this triggers an “us versus them” backlash which is not necessary and causes users to suffer. Instead, focus on the system itself and how all different kinds of users participate in it to interact with each other. I believe that this is an approach that will inherently make Stack Overflow more welcoming.

Here are some things I kept in mind when thinking about how to make Stack Overflow work for everyone:

Always ask “How does this impact users?”. In specs/briefs I write, I always explicitly consider all participants in the relevant feedback loop. Going through this motion can uncover unanswered questions, highlights your thought process for readers, develops a muscle for user-focus.
Treat everyone as a valuable person as part of the system. Even if I’m working on something mainly designed to help one type of user, it can go a LONG ways both internally and externally to demonstrate care for everyone. Other people will pick sides or favorites, but you as the chief advocate for your users cannot succumb to this.
Think holistically. I tend to like to think of user journeys in product work. For a given feature, how did users arrive there? What’s the next step? Considering all participants at each touchpoint in a user journey is a natural extension of this thinking.

Be ambitious and a driver of positive change in the face of inertia. Exude optimism.

The team focused on public Q&A is shockingly small: four IC developers. And the surface area of responsibility is enormous: all of Stack Overflow and the Stack Exchange network serving millions of people every month. Stack Overflow is a top 50 site in Alexa rankings. Having the impact the user base needs and deserves requires efficient use of resources paired with a healthy openness to risk. Otherwise it’s too easy to slip into conservative bug-fixing mode to just keep the status quo afloat.

The good news is that the team is super capable when pushed to dream big. When I joined in early 2019, we made 7 internal commitments of which only 28% were hit. In October, we made 31 internal commitments and hit an 84% completion. This was possible despite receiving no additional developer resources during this timeframe.

Here are some tips for keeping functional teams productive and engaged:

Constantly clarify ambiguities. The biggest thing a product manager can do to help team productivity is clarify ambiguities. In the face of chaos or shifting priorities, the best thing you can do is make sure to shield the team as much as possible so they can stay focused on productive project work. In the day to day, stay engaged with what they’re working on and answer their questions.
Accentuate the positive. This team has historically been subjected to a lot of strife. Be empathetic, but do your best to sincerely highlight successes and positive motivators.
Connect the team with end users. Making the team clearly see how their work has impact is a morale boost and motivator. Some ways to do this include inviting developers to join user interviews, reviewing and discussing research with a broad group of people, and holding project retrospectives that include preliminary data on feature performance. In a small example, I always included a user quote in the team’s weekly company-wide report.

The community is an asset. Experiment, iterate, and listen to your users the whole time.

Rapid experimentation, incremental releases, and iteration is an opportunity to keep a dialogue with your users open. It’s a venue for you to not only involve them in the conversation, but to shape it by sharing and aligning on goals. Like I once told a coworker, “We’re both on different vectors. I share mine with you and you share yours with me and we both get a little closer and amplify our efforts.”

A number of examples of this approach took place as part of our bigger efforts to improve experiences related to question closing. In one recent project, we worked to ship the new post notices feature early and we were responsive to feedback from users. This led to making lots of small improvements before rolling the change out more broadly. In another example, we engaged the community closely in testing different thresholds for voting to close and reopen questions, including transparently sharing the results of our experiments.

Stack Overflow is a website with a huge user base. Not taking advantage of the ability to run tests and get feedback from enthusiastic community members is a missed opportunity. Do it in complement with other research methods. At the same time, these feedback loops threaten to slow things down and can be emotionally draining. Your mileage may vary (and a lot seems to depend on individual tastes), but here are some quick tips:

Don’t take things personally. You’ll get a lot of critique, positive and negative. As a product manager you have to emotionally separate yourself from the features you work on as much as possible. Instead, invest your energy into focusing on the objectives you share with end users and other stakeholders.
Delegate communication. It can be exhausting and extremely time consuming to interact deeply with a critical audience. Lean on people who are experts at this. For example, you can try strategies like ghostwriting blog posts or asking others to synthesize feedback for you in a report.
Take a principled stance. Decision-making is easier when you already have clear objectives and guiding product principles to use as heuristics. So form these early and lean on them aggressively to quickly resolve feedback rather than debating minutiae at length.

Where appropriate, experimenting and iterating on ideas in public is also a great way to battle harden new features before introducing them to Teams customers, Stack Overflow’s Private Q&A product. If something is successful at Stack Overflow’s scale, it may work for a company’s internal knowledge management, too.

Create simple defaults and tear down configuration and customization. Do not try to please everyone.

Stack Overflow is too complex. It’s hard to use for people who are not power users, it’s difficult to maintain for engineers, and it’s a challenge to design and build changes that work around tons of variants. This is not sustainable for such a small team with a huge mandate. For example, take user profiles. They’re a mess of information overload, they’re bogged down with tons of settings and togglable preferences (some only used by a tiny number of people), and users can maintain unique profiles for each and every network site that they’re a member of. Then there’s the overall network profile. And chat profiles. Then profiles for Teams (private Q&A), too. Oh, and they’re not mobile responsive. Yuck.

Taking things away by simplifying them will be hard, but it’s necessary for the future of Stack Overflow. When I first joined Stack Overflow in March, the team launched the new Ask Question Wizard. This created a whole new default question-asking flow for users with less than 111 reputation while other users had the old (10 years old) form intact.

The UX of the wizard was clunky. We heard this in feedback from a random sample of people who responded to our new monthly site satisfaction survey. And maintaining it AND the existing form was an immediate timesuck as we battled bugs and strange edge cases arising from technical workarounds required to support this complex feature. It wouldn’t surprise me if its measurable benefits actually stemmed from how hard it was to use. Therefore, we went back to the drawing board, taking what we learned from the wizard plus additional research, and launched a redesign of the question-asking form for everyone. The data (quantitative and qualitative) and increased simplicity led us to consider it a huge improvement. Plus, it’s now way easier to iterate on (since of course it’s still not perfect!).

Do more to reduce forking paths and little used customizations. It’s not realistic to continue supporting these given extremely constrained resources and minimal benefit to users.

“This web of time – the strands of which approach one another, bifurcate, intersect or ignore each other through the centuries – embraces every possibility. We do not exist in most of them. In some you exist and not I, while in others I do, and you do not.”

― Jorge Luis Borges, The Garden of Forking Paths

Here are some tips for approaching this:

Make data-driven decisions. Use data (quantitative and qualitative) at every level to inform how you solve this problem. Use data to prioritize which things to tackle first and then use data to decide what configurations are most important, for instance.
Involve all stakeholders in decision-making. You really, really have to know who is dependent on something and how when you’re planning to take it away. Make sure to involve the right people in the conversation and, as much as possible, share the same data you have access to (and invite them to ask new questions, too).
Have empathy. Loss aversion is a very real thing. Even if simplifying something is the best thing for users by all other accounts, taking something away still hurts. And this impacts not just end users, but the people who originally worked on a feature. You can have empathy by understanding how they use the feature and asking about the historical context around its original creation.

Keep the mission and impact in perspective always.

With respect to mission, a lot of people are passionate about Stack Overflow and its community. There are a lot of loud voices and strong opinions pulling in many directions. Do what you can to keep focus on the bigger picture, both inside the team and externally. In this period of transition for the company, the mission is still being honed, but here are some things I personally believe to be important:

Stack Overflow is a source of high quality question and answer pairs. Do things that continue to grow this content, enrich it, and make it easier to access and use for all developers. But, Stack Overflow is not equivalent to Wikipedia. It’s not made up of facts frozen in time. More than a traditional encyclopedia, relevant information and practices in Stack Overflow’s community change as the developer landscape evolves. Make Stack Overflow a living, evolving library. It will never be “done”.
Make Stack Overflow for all developers. It started as a place to serve programming enthusiasts and this was a successful way to catalyze the creation of a community and corpus of technical knowledge. Over time, it has clearly shown potential to make lives better for anyone who writes code. Figure out how to make Stack Overflow a place where anyone in the world who codes has a place to participate and learn.

With respect to impact, this is where it’s all too easy to fall into a trap of listening only to a small minority of people who enthusiastically offer their voices. These voices are super important to be sure, but they need to be balanced. In my time at Stack Overflow, we put a lot of effort into filling gaps in who we listened to. The vast majority of people who use Stack Overflow don’t have accounts (or aren’t logged-in) yet we had virtually no way to hear from them until we launched a satisfaction tracking survey last summer. At the same time, we also strengthened ties between Community Management and product as a way to more scalably incorporate feedback from highly engaged users into the work we prioritized. They need to have a seat at the table in all of major feature work in order to continue to have a big impact on the solutions the team designs. They are experts on different types of user segments as well as the system and are critical to building Stack Overflow to better serve everyone.

Continue keeping impact in perspective and strive to better serve the needs of all types of users. It’s difficult, painful work because limited resources means important people may feel ignored. But I have confidence that progress will continue to be made on this front.

In conclusion

These beliefs are a reflection of my own personal values as a growing product leader who’s passionate about building great experiences for global developer communities, and as someone who has a great deal of optimism about the future of Stack Overflow. If I had to sum them up, I’d say I believe in unrelenting user focus and optimizing for global, rather than local, minima. I’m excited to take these values, along with everything I learned at Stack Overflow, with me in my next adventure: rejoining the Kaggle team at Google.

Thank you to Shog9, Donna Choi, and Julia Silge for their feedback on drafts of this post.

–

Follow the conversation and discuss on Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1203000660817367041-549'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1203000660817367041&theme=dark" }

Experiment results: Testing close/reopen thresholds on Stack Overflow

Megan Risdal — Mon, 07 Oct 2019 18:46:52 +0000

At Stack Overflow, one of the main things we're working on is improving the ways our Q&A system facilitates feedback among users. Our user base plays an important role in not only answering questions asked by thousands of people per day, but also in helping to ensure that Stack Overflow is valuable as a resource which helps our future selves, too. This means that in many ways there are real people behind the keyboard using our software interacting with each other and influencing experiences people have (good and bad). Stack Overflow users deserve a system that sets everyone on all sides up for success.

Today, an essential part of how feedback is relayed among users on our site is our system for closing (and reopening) questions. While it was originally designed to help facilitate the creation and preservation of high quality question and answer artifacts, it's also a source of a lot of friction for our users. You ask a question on Stack Overflow because you think you can get an answer there. Getting your question closed today can be confusing, frustrating, and sometimes even unjustified.

So, what are we doing about it? We're taking a three-pronged approach:

Small changes to make the current experience feel less opaque or frustrating (e.g., redesigning our post notices including those for closed questions to be more helpful)
Experiments to understand the effects and emergent behavior of the system when we make changes
In the longer term, performing an audit of the current system and user research to inform a holistic overhaul

In the rest of this post, I'll describe a recent observational experiment we ran as an example of approach #2 including what we observed and our thoughts on next steps (which I'd love your feedback on!). Shog, a Community Manager at Stack Overflow, and I published a longform version of this write-up on meta. This is mostly Shog's write-up; I contributed the charts.

Close/reopen vote threshold experiment

In August, we ran an observational experiment on Stack Overflow in which we reduced the number of close/reopen votes required to close/reopen a question. Our main hypothesis was that this would make the system more efficient. We operationalized "efficiency" to mean, if a first close vote is cast, that question is more likely to ultimately get closed (same for reopening).

Why do we care about efficiency? For users whose questions are closed in the current system as it works today, we'd prefer that their questions get closed sooner before attracting downvotes/discouraging comments. And for users who volunteer to review questions ("curators"), if their vote does not result in closing or reopening, it should be because other members of the site reviewed it and decided that outcome was unwarranted; the vote should not be ignored.

As with all experiments (observational or experimental) and product changes we make on Stack Overflow, we also monitor other metrics. Some of the other factors we looked at:

Qualitative perceptions shared on meta (where we announced that we were doing the experiment) and in our site satisfaction survey
Volume of things like closed/reopened questions and participation in the respective review queues
"Close wars" (a close war is when a question is closed, reopened, then closed again)
Consensus (there are multiple reasons a close voter can choose from and reducing votes from 5 to 3 could impact consensus rates)

We ran the experiment for thirty days and compared the experimental period to pre- and post-periods.

The experiment results

Efficiency

Our hypothesis was confirmed. The close/reopen system was more efficient across the board.

Very importantly, the total quantity of questions nominated for closure stayed about the same, even as efficacy -- questions actually getting closed -- went up. This means that the experiment didn't trigger a wave of close voting.

Qualitative perceptions

We heard the most from our active, engaged users on meta who represent the curator side of this equation. From them we heard optimism and motivation to participate in the site plus a lot of thoughts on how the experimental threshold would impact the close system including users implicated in it.

We supplemented this feedback by looking at responses to our site satisfaction tracking survey which we recently started as a way to get more diverse feedback from Stack Overflow users. On the survey, we regularly see people mentioning closing as one of the most frustrating things about using Stack Overflow. During the experiment, we saw a slight uptick, but it wasn't anything significant. This is something we'll continue to monitor.

If you have thoughts, I'd love to hear them in the comments here!

Closing/reopening and participation

Right now, a very small group of people participate in closing/reopening and reviewing questions that have been voted to be closed/reopened. As long as we have the same system in place, we would prefer greater diversity among the people participating.

During the experiment, we saw more participation in reviewing questions. This was driven by an increase in reopen reviewers.

During the experiment, we saw an increase in the number of questions closed. Recall this was NOT the result of an increase in the number of questions voted to be closed, but rather an improvement in the efficiency of the system.

During the experiment, we saw an even larger relative increase in the total number of questions reopened.

Close wars

A "close war" is when a question is closed, reopened, then closed again. Did lowering the threshold required to close/reopen a question result in an increase in their occurrence?

In the 30 days prior to the experiment, 100 questions were closed at least twice.
During the 30-day experiment period, 188 questions were closed at least twice.

We did see an increase, but close wars are actually already relatively rare on Stack Overflow. We aren't too worried about this.

Consensus

During the experiment, it was much easier to close a question without consensus among close reasons.

In the 30 days prior to the experiment, 49 questions were closed without a consensus reason.
During the 30-day experiment period, 560 questions were closed without a consensus reason.

This is more concerning to us. It's an emergent behavior of the lower close threshold which we're not as happy to see.

Conclusion and call for feedback

From this experiment, we've concluded that a lower close/reopen vote threshold successfully increases the efficiency of the system. This has positive effects on our curators who volunteer to review questions and we hypothesize that it's a better experience for users who ask questions (though we'd love to hear more feedback from you!). It was especially encouraging that there was NOT an increase in the number of questions that were voted to be closed even while participation in the process increased.

Based on these results, we have learned that we would like to implement a consensus rule before lowering the close/reopen threshold to 3. That is, a question must receive n close votes have to agree before a question gets closed.

Our thinking is that a consensus provides more confidence that question should be indeed closed AND gives the question author more concrete feedback which they can learn from or act on.

What are your thoughts? What feedback do you want when you ask a question on Stack Overflow and how do you want to receive it? Do you think we should enforce consensus close reasons? What aspects about asking a question on Stack Overflow today frustrate you?

Can you help unblock dark mode on Stack Overflow? 🌒

Megan Risdal — Thu, 03 Oct 2019 04:49:03 +0000

Oct 2 '19 Comments: 6 Answers: 3

In our design system at Stack Overflow, we use Less to compile CSS color values.

We have global Less variables like @orange-500 that are frequently modified for hover states, building border styling, background colors, etc.

In Less, this is written as darken(@orange-500, 5%). I'm trying to achieve something similar…

Open Full Question

SELECT Post FROM Stack Overflow Questions WHERE Topic = "git" ORDER BY Votes DESC;

Megan Risdal — Fri, 30 Aug 2019 15:39:36 +0000

Recently, one of my friends, Jamie Hall, wrote a really great, practical tutorial titled "Get good at git". In it, he introduces the basic workflows you need to know to use the version control system everyone "loves to be hated by" (his joke, not mine). Not only is it a lovely introduction to git, this paragraph really resonated with me:

In practice, everyone [screws] up constantly. I’m talking about professional software engineers, with many years’ experience, totally [screwing] up their work through unforced errors and dumb mistakes.

Problems with git are so common that Katie Sylor-Miller created a website explaining how to get out of a specific git mess in plain English.

Knowing that the best place to find reassuring company with other developers totally screwing things up is Stack Overflow, I decided to have a look at the all-time top questions by votes to see how common git problems are. And it turns out that 5 of the top 10 most voted questions are about getting help with git.

If you've come across one of these questions (I know I have), you are very far from alone! I used DEV's new Stack Overflow liquid tag to embed the top git questions of all-time on Stack Overflow. Plus, on Stack Overflow you can now also click "share" and select "DEV" on any post.

#2 most upvoted question

May 29 '09 Comments: 12 Answers: 105

27198

I accidentally committed the wrong files to Git but haven't pushed the commit to the server yet.

How do I undo those commits from the local repository?

Open Full Question

#3 most upvoted question

Jan 5 '10 Comments: 3 Answers: 41

20360

Failed Attempts to Delete a Remote Branch:

$ git branch -d remotes/origin/bugfix
error: branch 'remotes/origin/bugfix' not found
$ git branch -d origin/bugfix
error: branch 'origin/bugfix' not found.

$ git branch -rd origin/bugfix
Deleted remote branch origin/bugfix (was 2a14ef7).

$ git push
Everything up-to-date

$ git pull
From github.com:gituser/gitproject

* [new

…

Open Full Question

#4 most upvoted question

Nov 15 '08 Comments: 8 Answers: 37

14043

What are the differences between git pull and git fetch?

Open Full Question

#8 most upvoted question

Dec 7 '08 Comments: 13 Answers: 39

11608

I mistakenly added files to Git using the command:

git add myfile.txt

I have not yet run git commit. How do I undo this so that these changes will not be included in the commit?

Open Full Question

#9 most upvoted question

Jul 6 '11 Comments: 1 Answers: 41

12018

How can I rename a local branch which has not yet been pushed to a remote repository?

Open Full Question

What about you?

Are there Stack Overflow questions about git you constantly reference? What are your biggest git hangups? Have you ever had any "oh crap" moments with git?

What’s in the Works at Stack Overflow: Improving Feedback for All Users

Megan Risdal — Tue, 27 Aug 2019 02:06:19 +0000

Hi, I'm the product manager leading the development of Stack Overflow's flagship product, public Q&A. Last week, I shared an update on our blog about what we're working on and why.

Building Stack Overflow in a way that better meets the needs of more and more developers is important to me and my team. I'm cross-posting an abbreviated version here because I want to hear your feedback for us.

Where we're at today

Last year, we kicked off an initiative to make Stack Overflow more welcoming. After launching a new Code of Conduct, an improved question asking experience, and several other changes, we spoke to many Stack Overflow users to hear more about their personal experiences using the site. Through these conversations, we heard that the limitations of the Q&A system continue to create the very environment we set out to discourage. People who need help with coding problems feel attacked when their questions are closed or downvoted, while those curating site content feel blamed for doing what the system has asked them to do.

It’s simply not enough for us to ask people to be nice or change their behavior when the software that underlies everyone’s interactions doesn’t facilitate this. That’s why we’re looking at ways to revitalize the way the core Q&A system works.

What we're working on now

Today, my team's focus is on these initiatives:

How feedback is delivered by the system
Addressing issues with our commenting system
Making a single question asking experience work for everyone

Improving feedback

As Sara, our Director of Public Q&A, noted in her recent blog post, it’s hard not to take feedback personally when it’s piled on, no matter how constructive it is. Unfortunately, this overwhelming pile-on is exactly what users who ask an imperfect question are confronted with.

The first way we're improving the feedback loop among our users is through a redesign of post notices. If you’ve come across a duplicate question or closed question, you’ve probably seen a post notice. These are the pale yellow informational banners that sometimes appear on questions. For people who ask questions today, if your question is closed, feedback that is directed toward you privately is shared publicly with anyone who views your question.

Here’s what our holistic redesign of all post notices will prioritize:

Delivering improved, private feedback to post authors
Not putting users who curate content on the spot
Giving actionable, understandable information for the vast majority of public viewers

While working on building our refresh of post notices, we’re also doing discovery on ways to make our question close workflows and review queues better facilitate feedback and content curation for seasoned moderators, technology experts, and new question-askers alike.

“They told me not to read the comments…”

It probably comes as a surprise to no one that the comments section on Stack Overflow doesn’t always serve its original purpose (facilitating clarifying questions to improve question quality). Comments can be distracting, outright harmful, pure spam, and everything in between.

We encourage people to flag content that doesn’t belong, and our moderators do incredible work to review everything. But there’s a lot of opportunity to reduce the burden for moderators and users who flag inappropriate content in ways that make using Stack Overflow more pleasant for everyone.

For example, some of the things we’re exploring right now:

Better distinguishing the “Answer” and “Comment” actions (due to a high volume of helpful “Not an answer” flags indicating problems with the interface).
Ways to reduce the number of unhelpful comments that are likely to get removed in the first place.

Improved question-asking guidance for everyone

Several months ago, we launched the Ask Question Wizard on Stack Overflow. The new experience defaults users with low reputation to use a guided mode to formulate their questions. So far, we’re pleased with how it’s helping users ask better questions and as a result have a better experience on the site. In fact, we’re so pleased that our next iteration is focused on incorporating aspects of the guided mode into the question-asking form for everyone.

We’re still in early stages, but some of the changes we’re working on so far include:

Upfront guidance for first-time question-askers
Setting expectations for what happens after asking a question
Improved “how-to-ask” guidance while drafting a question
Making it easier to improve question quality by consolidating many dozens of validation messages into a single “review” interface

We’re excited to begin working on these changes because it gives us an opportunity to create a better user experience for everyone. More and more, we hope to look for ways to simplify our platform to seamlessly and intuitively meet the needs of all users who come to Stack Overflow to find and share knowledge.

What do you think?

Millions and millions of users come to Stack Overflow each month and rely on and contribute to the site and community in so many unique ways. Stack Overflow wouldn’t be what it is without contributions from developers like you.

What do you think of this direction? What would make it easier for you to use and participate on Stack Overflow? What are your biggest frustrations today?

How to know nothing

Megan Risdal — Wed, 14 Aug 2019 06:16:50 +0000

I wrote this post a few months ago on my personal blog. Today I'm six months in as a new product manager at Stack Overflow, so I'm cross-posting here. 🎉

A couple of months ago I started a new job as a product manager at Stack Overflow. This blog post is about how to know nothing in a new job. It's about that whiplash-like experience of going from confidently knowing everything there is to know about your work to coming to a grinding to halt so you can start all over again from scratch.

Okay, maybe it's not so dramatic as that, but the insecure feelings I was having inspired me to ask for advice from my Twitter followers:

// Detect dark theme var iframe = document.getElementById('tweet-1120880418562002945-119'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1120880418562002945&theme=dark" }

To give some more background, I was feeling especially daunted by my own lack of knowledge for a couple of reasons, I think:

First, at Kaggle (my previous job) I worked through a really exciting high growth period. When I started in 2016, they were focused mainly on competitions and towards the end of my time there we had massively expanded the community, the product, and the team. We even lived through a successful acquisition by Google. I was present as a participant, either as a "witness" or "creator", in all of this change. I felt that I could competently answer just about any question someone (internal or external) could ask me about Kaggle.

Second, the company I've joined (Stack Overflow) is quite a bit like Kaggle in that it has a large, technical userbase with a rich history of cultural norms and past product decisions. That rich history has made Stack Overflow the household brand it is today, but it can feel intimidating as someone who wasn't an active participant in it over the years. It's a lot of tribal knowledge to catch up on!

Anyway, for this blog post I wanted to summarize some of the great advice I got from folks on Twitter.

1. It's normal and okay to feel insecure

This is worth mentioning up front! I got a number of replies from people either expressing solidarity or assuring me it's a normal feeling for anyone starting a new job.

// Detect dark theme var iframe = document.getElementById('tweet-1121099345535864842-781'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1121099345535864842&theme=dark" }

2. Remind yourself you were competent and you will be again

This is for those of us that laugh at the idea of ever succumbing to the Dunning–Kruger effect when it comes to evaluating our own competence. I'll admit that I requested my personnel file when leaving Google so I have my performance reviews to remind me that I can kick ass at my job in some objective-ish sense.

I like this reply from someone else who recently changed teams:

// Detect dark theme var iframe = document.getElementById('tweet-1121188776250888192-749'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1121188776250888192&theme=dark" }

3. Lean into your newbie perspective as superpower

This was probably my favorite reply (from a former colleague at Google):

// Detect dark theme var iframe = document.getElementById('tweet-1120881183552757760-86'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1120881183552757760&theme=dark" }

It was also stated nicely by another person who replied with this quote:

In the beginner's mind there are many possibilities,
but in the expert's there are few
Shunryu Suzuki

Because I know I have a lot to learn in my new role, I've had an amazing opportunity to ask "Why?" so many times. I'm definitely going to keep wearing this hat for as long as I can as I talk to both coworkers as well as users.

As someone else replied, by challenging assumptions you're "both learning about the environment and moving it forward."

4. Be vulnerable

People can only help you if they know what you're struggling with or how you want to improve. Maybe it wasn't comfortable for me to tweet the world about not knowing everything, but it got me some amazing replies that can hopefully help even more people than just myself. Plus, as someone replied, "If you don't feel uncomfortable you're not learning."

// Detect dark theme var iframe = document.getElementById('tweet-1120915698350321664-825'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1120915698350321664&theme=dark" }

This also ties in well with some other advice I got to request feedback early and often as a newcomer to a team.

...

I've distilled the advice I got into the several different themes I wrote about above, but at the end of the day my two biggest takeaways are:

Be patient with yourself
Be inquisitive

And eventually you will know something again.