If you’ve ever written code you’ve probably heard of Stack Overflow.
Most of us have learned from them or shared knowledge on their site. They’ve also got one of the most inclusive and positive engineering cultures out there.
On this week's episode of Dev Interrupted we've brought on Ben Matthews, Director of Engineering at Stack Overflow, to give us the inside scoop on Stack's operations, teams and company culture. Ben also discusses their newest product launch - Collectives - and why he thinks they will be a game changer for dev teams.
Episode Highlights Include:
- Stack Overflow engineering: a developer-first culture
- Leading with empathy and empowering developers
- Hiring the right devs
- Onboarding with purpose
- Team composition and organization
- Enabling work-life balance and maintaining team morale by actually caring: and requiring time off
YouTube Highlights
Set your devs free.
What are Stack Overflow's Collectives?
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Episode Recap and Transcription
Dan Lines: Hey everyone. Welcome to devinterruptedOur. I'm your host Dan lines. And today we are talking about engineering and culture at Stack Overflow. Joining me today is the director of engineering at Stack Overflow, Ben Matthews. Ben, thanks so much for coming on DI today
Ben Matthews: And thanks for having me, happy to be here.
Dan Lines: Awesome to have you. Anyone that's a developer knows what Stack Overflow is. I used it maybe seven years ago and I was developing, I don't know how to do something first place that I go to find out, probably Stack Overflow. We have a bunch of interesting topics today, but I think people will want to learn just a little bit more about Stack Overflow. So we'll start out with some questions here. Most importantly, how much of Stack Overflow is built using copy and paste itself.
Ben Matthews: 99%? Yeah, it's like a self-sustaining website at this point. And then, but yeah, everyone that's at Stack Overflow, even the founders are big users. A lot of the people that came to Stack Overflow over time came because of a love for that community. It sounds cliche, but what we really do is like we're here to help developers and we are a company filled with developers. We're just as passionate as users as we are as creators.
Dan Lines: Yeah, that's awesome. And it must be super fun to work there. How many engineers are on the staff right now? I think we're
Ben Matthews: I think we're around 85 and we're still hiring. We have some more headcount. So we're hoping to get to maybe over a hundred by the end of the year.
Dan Lines: Great. Ending out at about a hundred That's a nice size team.
Ben Matthews: And some people hear Stack Overflow. They think of us as this huge enterprises, big culture, because we're a very visited website. We're very thankful that we have an impact on the developer community, but we are a relatively small company. We keep things focused and then like a small to midsize group.
Dan Lines: That's cool. How do you organize the engineering teams? Like how are people broken up?
Ben Matthews: It’s really run with influence based on what you're trying to do. We have our platform engineering team, which are people that are like our SRE’s and architects that are really focused on making it a lot easier for our other engineering teams to do what they do. On the other side, we have our product engineering groups, which are also split out into other teams, mostly around what the focus of the product is. For instance, I manage the region relevance division at Stack Overflow, which is any way that companies can interact with our users. Then we also have our teams division, which, you know, there's teams for Stack Overflow, a way to have your own private instance of Stack Overflow.
And then of course the most well-known, there's the public platform team, which anyone that interacts with Stack Overflow, you can thank them for all that you've learned and gathered from Stack Overflow.
Dan Lines: Okay. Very cool. And what type of methodology do you use? Are you scrum or Kanban? What are you all doing?
Ben Matthews: Everyone has a little bit of freedom to tackle it the way they see fit, but for the most part, at least in product engineering, where we're very focused on scrum and starting from that, for lack of a better term, the vanilla scrum, and then we could deviate from there based on what the teams need based on what people need, the product, the nature of the product on the platform engineering side, there's a little bit less of a structure. I think they have a lot more freedom to handle those things as they like since they're more service oriented than product oriented.
Dan Lines: Very cool. And is there anything that stands out to you? That's unique about how engineering works at Stack Overflow, maybe compared to other places that you've been at?
Ben Matthews: Compared to the other places I've been at? Just the level of collaboration and freedom of engineers is a step above. Usually I'm coming into an organization and trying to push and, and strive for it. And like, no, we don't have to follow a cookie cutter template or they're really interested in following these other tech paths. Let's give them the freedom to, and, and usually there's some friction there with existing company norms, but at stack it fit in right away. If anything, they were pulling me towards that more than I was pushing. So we really just accommodate our engineers.
We have an empathetic culture of making sure people enjoy what they want to do that gives them the tools that they need and just collaborate with each other there, the cross-talk and our slack channels is higher than any other place I've been at.
Dan Lines: Amazing. Now, in terms of metrics, is there anything that you folks pay attention to more than other data points or?
Ben Matthews): Yeah, and I have a unique asset view on this that I think stack sort of shares in that a lot of the numbers and metrics that people follow are symptoms, indicators, or kind of health metrics. They're not the goal and as uncomfortable as it is to put it this way, sometimes the best thing that you can follow is rather subjective. If product is getting what they need and you're meeting agreed upon expectations, team morale is high. These are things that are hard to put a number to, but that's real success.
And if you're doing that, you start to notice a higher velocity. You'll notice predictability and delivery times. I know, I should think the gentleman you had on last time, Eric from GitLab, was saying that predictability is not the goal. And I completely agree with him. Like it's, if you like the fudge system, you can make a team predictable. But if you're actually producing value and you have a well-run team, predictability is a side effect of that, people will know how fast you go. It's not the goal. It's a symptom of a well-run team.
Dan Lines: Yeah. It was also awesome having him on there. And that's the mantra is if you just go for predictability, is that really hitting the end goal of creating value for your customers at a rapid pace? Probably not. It's more like just, okay, let's make sure we're not wrong. And what we're saying for our estimates, which doesn't usually lead to a good outcome.
Now you're the director of engineering. You've been in a leadership position. We have a lot of listeners that are either really first-time leaders or maybe want to get to that step. What advice would you give engineering leaders out there that are looking to track either some of these team-based metrics or start monitoring, “Is my team doing well?”
Ben Matthews: Another director at Stack Overflow,David Haney, and I had a long talk on this and you shouldn't ignore the numbers,they're important to pay attention to, but use them as introspective, not the goal. For instance, if you had a sprint where you had a really high velocity, that is great, you can celebrate that. But at the same time you should say, that's something that wasn't expected. What did we do to get to this high velocity? What was the behavior that changed sometimes internal or what I got to coach people to say, there's sometimes external factors, especially nowadays with COVID people have a lot of pressure and a lot of changed and they're work-style, and, and that can actually have an effect on the flip side, like delivery size and grooming.
I would say the biggest part when it comes to trying to follow those methodologies is don't get hung up in analysis paralysis. There's people who will be like, is that a three point or a four point? And they'll sit and argue about it for an hour, who cares and make it a four, just keep things moving, keep developers developing and anything that you can take away from them. That should be your job. So servant leadership approach at stack is what we really embrace. Is that it's my job to help you do your job. And if you're not able to do your job, that's more my problem than yours.
Dan Lines: Yeah. Make your people successful. Stick to the essence of value over just being obsessed with planning poker, or is this a two or a five? If we're, if I zoom us out a little bit here, one phrase I've heard you mentioned previously is the idea of building a team around your product and people and not the other way around. Can you dig into that a little bit deeper on what that means?
Ben Matthews: Sure. I'm sure we've all. If you've been around long enough, you've come into organizations where you say, and this is the way that we do things. This is our system. This is our process. This is how we score things. And it takes an assumption that what you're working on and your code base is all the same, that the people on your team are all the same. And, and like the nature that they should work is all the same. And I have found that to not be the case. I have some teams that like to communicate or meet a certain style. And it is our job as managers to make sure that they are successful and accommodate that.
Some people like have worked styles. That kind of, for instance, if you have a product with high turnover, a lot of smaller tickets, perhaps a kanban approach is going to be more successful for you. Don't let the fact that your organization is like, sorry, we're scrum. Stop you from being able to adjust your team in this processes to match your product or the way that your people like to work. It has huge returns after a while, just them being happier, not being forced into something that doesn't fit. And with that just comes a higher value creation from the team.
Dan Lines: When you’re at that director level, maybe a VP level, you probably have team leaders reporting to you. And like you're saying, they're all a little bit different. How do you broker that conversation with each one to find what's suitable for them? How does that look for you?
Ben Matthews: And it's a very open conversation and that, again, it comes a little bit subjective, ”How do you feel like the team is doing?” is a question I ask my tech leads on the team all the time. It's just, how do you feel the team is doing? Not What are the numbers? How many stories did you complete? How many lines of code did you write? All that, again, are just symptoms of how do you feel like the team is doing? And when there are slowdowns or something that we don't think about, that's where we talk about, we dive into it and what are possible solutions or opportunities. We didn't know that they were there.
And then after a while, they just start to learn how to adapt themselves and the team to meet the challenges that are coming, that they're coming across and they learn and grow from there.
Dan Lines: Is there any guidance or suggestions? Let's say, for example, I'm a, I'm on your team and you asked me the question, like, how's the team doing not, well, I know it's not doing well, but I don't know what to do next. Do you do anything to try to work towards what the issue is in that situation? What does that look like?
Ben Matthews: Yeah, I would just ask what makes them feel that way? The common response is that people are just stuck on some story and with that says, okay, let's figure it out. Why nine times out of 10, we just didn't understand the scope of the story or see what was coming well from there, you just got to learn and you're retrospective. What did we miss? What can we learn from that? Or we're just really not good. And this area of code, we didn't have the learnings we thought that we did. And that there's an area for us to improve some knowledge sharing or growth from there.
But it's really, self-diagnosing in a way of just where are we slow? Where's the friction? Then that's where we can tackle. Or where are we going fast and where are we doing? Let's try to replicate it and spread it to other parts of what the team does..
Dan Lines: One thing that could be the case is that we don't necessarily have the right people on the team, which leads me to the next topic of hiring. Hiring is something that's so important you could say, and someone your level and might be one of the most important parts of your job.
Can you talk to me about how you approach hiring at StackOverflow to make sure you're hiring the right developers?
Ben Matthews: Sure. I completely agree. Hiring is the most important thing. Any organization does bar none. And, and by a long shot, whether we're writing mediocre code or not, if we're not bringing in the right people to help us improve and make additions to our company and culture, then we're not going to stay stagnant. We're not going to be successful. So part of what we do in hiring is technical competencies of course, an important part, we've all mused long around, what's the right way to go about that? Do we give them take-home tests?
Do we give them coding challenges and the interview? Do we ignore the coding challenges all together? And we actually shake that up for certain levels and how we go about it. But on top of that, there's a lot of things around how these people view problems that are really going to help us know if they fit in at stack. Even if I give you a coding challenge that you don't do well at, you could still be exactly what I'm looking for. As far as they know, no one is coding like enterprise applications and the code sharing tool and a web browser. That's not a realistic development environment, not a realistic development setting.
And like whether it takes you 10 minutes or 15 minutes to solve something. It's also not like in the real world, I don't care. If you're getting the story done well and accurately, I'm not going to haggle with you over a couple of minutes or a couple hours. So that's why just like the inherent nature of testing, the competency of a developer is somewhat fluid, but you can tell how they approach the problem. We have this idea of momentum in a question like if you're, if once you're given a challenge or a question, are you still thinking it through? And if you get stuck, are you comfortable backtracking?
Okay, I can see where the problem is. Let's just keep going forward. It's the people that kind of get stuck in a method that it's going to be a dead end, but they won't go back. Or they're just gonna pause, and not keep trying to tackle it. That's more of something that we worry about then just them getting it right. If someone's always thinking of new solutions or even calling themselves out saying, I know this may not be optimal. There's probably a faster way to do this, but I know this would work. We love hearing things like that. And that there's more to learn in the real world. You'd all tab over to Stack Overflow and okay, what's the faster way for me, this sort, whatever.
So those are the things that we really want to do. How are you going to work with us? How are you going to tackle those problems? And,that's really what we're looking for. Even more than what your final code submission would be.
Dan Lines: And that makes sense because with developers, you could argue that you could describe the job as like problem solving, problem solving pretty often on a day-to-day basis. And all these different problems are thrown at you. How do you work towards a solution? That's not obvious if I'm a developer and I am applying to Stack Overflow. What does the step-by-step interview process look like?
Ben Matthews:It's long. And this is something that we're trying to improve on. We try to let a lot of people we get from all departments of Stack Overflow. We try to let people have a view into what this candidate will be like and what they're like and who they work with. And the downside of that is it makes the hiring process much longer than it needs to be. Especially in a time when certain areas of the country have negative and unemployment for developers, a long hiring cycle is not going to go well. But what we try to do as fast as we can is like for sure and meet with your hiring manager, just to get an idea, to make sure that this is something that you want.
A lot of people just churn developers through. It's good to test to make sure that they're going to be happy once they come here, because every place is going to be different. They'll tackle different problems. You don't want to just treat them all as cogs. That'll all do the same thing, regardless of where they end up from there, we do have two kinds of coding challenges that they'll have directly with engineers, where they try to work together on how can we solve this problem. So it gives a sense of how they would work together. And then from there you get to meet a product manager and a designer, potentially some other people on a panel interview at the end, and then hopefully make our decision.
Dan Lines: One of the advantages there. There's a little, maybe a little bit longer than probably a recruiter might want to see, but it sounds like they do get to interact with the developers on the team, a product person, a designer, a little bit more, what you're getting into, if you are applying for a position.
Ben Matthews: For sure. Yeah.
Dan Lines: You've probably been through hiring processes throughout your career. Is there anything that you're seeing in the tech industry developer hiring process that you wish would just be completely thrown out and we should not do as a community anymore?
Ben Matthews: Oh man. Completely thrown out? That could be a tough one, but I do think one trend that we can get better at is dividing developers up into what tech they know. So it's going to be a metric to understand where they've worked and what they can do. But for instance, Stack Overflow is a.shop where we're heavily invested in that platform. If I see a very brilliant developer that works in Java, I'm not going to turn them away because they don't have that tech mark on their resume as someone that, especially at a high level, understands proper object-oriented principles and the ways that they can like the pitfalls of working on a product.
That's very valuable. I can teach you dot.net. I can't teach you how to approach some problems that all comes with experience. A lot of people drawing those lines, I think miss out on a lot of positive candidates.
Dan Lines: Yeah. Makes sense. And you're going to throw someone out just because they haven't had language experience that doesn't really make any sense. We can, you can learn a language pretty fast. But solution driven, problem solving teamwork, it's much, much tougher to learn.
Ben Matthews: Yeah. A lot of that learning comes from experience. Like I can teach you kind of syntax and C-sharp teaching you how to interact with people is something that just comes with time. Like you can coach all you want, but until they're actually in there and doing it, they're not going to have that growth that you hope to see,
Dan Lines: Assuming that you're getting the hiring, you're having some good people come into stack overflow. You're going through a growth phase. I want to dive into onboarding. How do you do onboarding at Stack Overflow? And do you have any unique onboarding practices that have been working for you?
Ben Matthews: For what we tried to do right off the bat is as quickly as we can get them to push a ticket to production. And some people misinterpret that as throw them right into the code, get them working right away. But what that really does is give them a basis for everything that they're going to learn after that our platform engineering team has done a wonderful job of setting up some tools that within, I'd say roughly 45 ish minutes from when you get your laptop, you can be up and running the production version of Stack Overflow and your work machine. And everything has been kept up to date.
That was completely unique to me. I think most engineers have had that first two or three days of wait, what is this setting? I don't even know what is this error I’m getting. They've eliminated a lot of that by having a lot of stuff done right out of the box. So we try to have them push a ticket early, just so they can see what our bill processes, what are grooming and, code review processes. But from there, that's when kind of ancillary learning starts. No one on our, on my team, is going to be angry that you don't know what your velocity is or that you haven't completed work for the first like four-ish weeks.
We want you, we're focused on how well you're going to do in a year and not how well you're going to do in four weeks. We want you to meet other people and the team we want you to poke around in the code, break it, put it back together. We want you to learn about those areas. And with it, we'll give you small tasks. That'll maybe move you into areas to learn. But onboarding for us is about making sure that they're enabled and capable of working in like six months, in a year. And so on. Not how quickly can we get them churning out code that they're not sure about.
Dan Lines: Do you do something like, okay, in the first sprint they're taking a small piece of work or do you try to spread them around to different areas of the system? How do you approach what type of work?
Ben Matthews: Yeah, we try to get them into small areas. Everyone that comes on, we'll have what we call a tech mentor. And this is someone that we've carved out a good chunk of their time to work directly with this new person, any question they have and the challenges that person knows that they're there to help them out with lesson that tech mentors work and make sure there's no stress or worry about being able to get to it. So we try to give them first, like a small, we need a copy update on the homepage, very small, but get them through the entire build process, checking and code, review everything, which is a basis for what everyone's going to be referencing when they meet or talk about other problems and stack them.
They'll know what they're referencing to move them into other areas. Though, we try to have maybe one or two, like just database tasks that they can pair programs with that tech. We certainly try to get them to do something around the back end and some of our controllers, depending on what the team is, there's so much tech at stack that you really do have to customize it to what that team is working on. And there's stuff that's hidden and chest buried with bodies that people who have been here like six, seven years ago, don’t even know what it does or how it works.
And so we don't want to expose you to something that might be intimidating, but we do want you to have all the experience and insight into something you'll be using everyday.
Dan Lines: That's awesome. The way that you approach hiring and the way that you approach onboarding are aspects of culture and culture is one of the most important aspects of any business. I think, especially for engineering teams, and while we were doing a little prep and research for this episode, I read a couple of blogs that you've written. And one of them, I think it was from last June or something like that, struck me about how nobody has to lose in work-life balance because effective workers are also more rested workers.
Can you talk more about that? And maybe some strategies you use to make sure your teams stay effective.
Ben Matthews: Yeah. From my experience, a lot of people view a work-life balance as something that a company sacrifices for when I think time and again, it's been shown it's the opposite. Some people only look at hours worked or other kinds of numbers that don't really reflect creating value. They see it as giving someone a mental health day, that's lost productivity. I have never met anyone that works better when they're worried about what's going on in their personal life. I've never seen someone come up with better solutions. I've never seen someone generate less errors.
And if they're able to tackle those things, they're going to be working better, faster. And that's also what they want to do. Give them the option to say, if you need time to take care of yourself, please do that. That's good for us. And it's good for you because in the end, coding really is a creative exercise. You're finding ways to solve problems. And if you're stressed out and learning, you're not a widget on a machine you're finding solutions, you have to think and be able to focus. So when I wrote that blog post, what really came to mind was around how, just how much we focus on taking care of the people that work for us. At Stack, we have unlimited sick days, no questions.
If you need to take a day, we trust you to take a day. If you want to keep working to distract yourself from something we're not going to stop you, that's totally up to you. There's some people that view that as an escape, and that's totally up to you, but by accommodating them so they can work better. That's better for the company too. We're going to generate more value. They're going to be happier and you don't have that guilt of cracking whips and poking people with pointy sticks to get more work done.
Dan Lines: I think burnout is becoming more and more of a problem. The pandemic has made a lot of us work from home. We're still working from home at LinearB. It feels a little bit harder in the sense to take a vacation because you might not even be able to go somewhere on vacation. So you might say, oh, I don't even know if it's worth it. Have a data point here. And new study by the world. Health organization came out, showing that putting in these long hours, these are just crazy numbers, like 745,000 people that are having either a stroke or heart disease related deaths.
And this is going up like 29% since 2000. And just with all of that, and that's really nasty health stuff. How can we as leaders make sure that our people aren't over committing themselves and damaging themselves as humans without even knowing it?
Ben Matthews: It’s a great question. I think in the end, you have to set an example and set the tone for that. For instance, I make it a point to take vacation. I'm showing people it's okay to, you should take your vacation. When I'm on vacation. I do my best to totally disconnect. I admit I'm not great at it, but I'm getting there, but there's no expectations for you to work when you're on vacation. And we wholeheartedly encourage you not to. And, that's actually been tough during COVID, as you said, people don't have places to go.
So they haven't been taking their vacation. And with that comes more burnout. So we're actually nudging people, encouraging people to take more vacation. Stack even increased their vacation rollover. I think we doubled it just to make sure people don't lose that time because they haven't used it. Around the burnout portion, there's three steps that I try to train people on to be an effective leader: 1) set clear expectations on what needs to be done 2) make sure they have all the resources that they need to accomplish it 3) get out of their way.
And the third one is by far the hardest part. So if you set clear expectations from someone that I don't want you to work 40 hours a week, we're going to agree on what you want to do. And if you're working longer than that, if you're getting burned out, that means more likely I'm not doing my job, then you're not doing yours. And I try to be involved as I can just to do those health checks. We start every team meeting with how are you feeling? How are you doing? Any announcements? And if someone brings up anything that they're potentially stressed about, that's something that you need to act on right away. You need to get ahead of it.
And with that, we've been very successful. Burn out at Stack has been at least, and in product engineering relatively low, and people feel enabled. We have our internal surveys that we do. And I think it's gone up by 20 or 30% over the last six months because the initial impact of COVID of course was very heavy, but a lot of the ways that we responded to it and trying to make people feel safe and secure in what they do has really brought that up.
Dan Lines: Let's dive in there. What do you think makes the culture at Stack Overflow so strong?
Ben Matthews: I think it’s at the core of what we do. We constantly ask ourselves when we're building a product, is how does this help developers? Which is a unique thing to ask because when I'm talking to some executives about this new product, like here are the numbers, your revenue, projections, timelines, you'll often be stopped and say, what stops us? How does this help developers? That's the first thing we want to talk about. And that's really refreshing. And just that culture of we're here to help people also comes inward. We want to help you do your job better.
We want you to be happy in your job. And that takes a lot of effort, but it's a really empathetic company. We care about how people feel. We care about what they want to do, and we care about making them feel successful to an extreme. And any way that's not being supported, we address right away.
Dan Lines: I love that because especially as you get further and further along in leadership positions, team leader, director of engineering, VP of engineering CTO, and so on, more numbers are going to come your way. What's our revenue? What's our churn rate? All of these things that are very business KPI focused, and it can be easy to lose that mission. How are we helping developers? Because your developers are the people building the product.
They have to make decisions every single day. And if they have a mantra in their head, when I get stuck, I can just think to myself, like how do I help developers? That seems like it will go a really long way. So I love that point. Are there any other ways or things that you're doing to maintain morale?
Ben Matthews: We all moved to a remote working environment. That was a big shift for a lot of people. We had a New York office where roughly 50% of our workforce was, we also had offices in Austin and London. And, those people had to shift home and that's not easy. Stack Overflow was already a remote first company, like we were all over the world. But what we really tried to focus on for those new people moving into those remote positions was we want to make sure that you are completely comfortable with whatever new work environment you're in. We gave a hefty stipend to them and thousands of dollars to build your home office, get your desk at your chair by a nice monitor, whatever you need, do you feel comfortable?
And I think that really helped people feel back in their own skin. I have been in times where I was working from home, where I felt like I just grabbed the closet and I just worked in there. It's not the same. It's not comfortable, but being able to build out your home office with everything that you need and investing in your work environment really pays dividends.
Dan Lines: I can totally relate to that because when the pandemic hit, a lot of the people know me from the pod, I was actually working out of a closet cause I had nowhere else to go under the stairs. And yeah, now I've been able to upgrade. I have my own office and a nice couch here and some speakers, a flat screen TV. It just makes you feel so much better, more like yourself. As we're wrapping up here, I gotta ask you, what does the future of Stack Overflow look like? Where are you all going?
Ben Matthews: For a long time and in a good way, Stack Overflow was a very idealistic company. Engineers decided what we built, engineers decided how the products were directed. And that was very great at the time. And,it wasn't a bad thing. That's what made Stack Overflow so successful was that it was made by engineers driven by engineers. And we don't want to change that. However, like bringing in other people like some product focused people do help compliment that to see where we fit, where our community is, the heart of everything we do, but how can we help the community grow?
How can we get other people involved? That's the direction of stack now. You have this great repository of information. We have a fantastic community of people that just want to help each other. How can we take that to another level? One of the ways that we're doing this is our team's product and product engineering, and you can have your own private instance of Stack Overflow for some people that have some company specific questions that they don't want out in the wild, or may not be appropriate for a public platform. You can have your own Q and A section for people to come and learn and grow. For me, trying to onboard at a company, I have a billion questions and working in something that's already as familiar as Stack Overflow to try to find them is wonderful.
So it's just things like that. How can we keep taking our core community and the way that people work with each other to another level?
Dan Lines: Fantastic. That's awesome. Ben, we were excited to see that Stack Overflow actually launched a new solution recently called Collectives. Can you give us an overview of what Collectives are and how they'll help empower the community?
Ben Matthews: Yeah. Collectives are a way to conceptualize a new sub-community within Stack Overflow. If you're really passionate about certain technologies or interacting with other people and that technology, or even the company that sponsors that technology, you can do that through Collectives. You'll get to see a curated list of all the questions and tags that are around that technology. You'll be able to see other Stack Overflow users that have been selected to represent that technology. And it's a way for you to see what are kind of the trends, what are some other people doing in a more curated place.
You're able to see all the questions around that technology. For instance, right now we've launched with Go and Google cloud. So Go is a very popular language, Google cloud, a popular hosting platform. So if I am someone who hosts my site on Google cloud, going to the Google cloud Collective, I'm going to see other questions that users have had, see their solutions, even some questions I didn't even think of looking for. On top of that, even places where Google can post some articles and how to guides, trying to be a centralized place for people that want to learn more about this tech, they can go there and just view it in the Collective.
Dan Lines: What’s the kind of response you've gotten from folks who are using the beta solution so far?
Ben Matthews: A lot of people are adapting to it, but the one thing that we're most proud of is that users want to take part in Collectives. They have this new whole part of the site that they can use and learn more, and all these other features for ways that they can experience Stack Overflow. For those that don't want to be a part of it, or haven't found a collective that they're excited about yet, their Stack Overflow experience is not going to change. They're able to use the site just as they always hope to. We're flattered that they worry about losing the Stack Overflow they know and love, but that's always going to be there for them.
For instance, we're not changing accepted answers, whether it comes from Google or not. If people don't vote for that answer, it doesn't get accepted. Same thing for content moderation. Moderators are going to moderate the content from those sponsored users, just like anyone else. I think the most positive thing about it is that people aren't losing the site that they love and that we're really proud of that.
Dan Lines: That’s really cool. It sounds like you're totally prioritizing the user experience and saying, look, you can use this however you want. We'll give you a value add. And if it makes sense for you and how you're using Stack Overflow, great. We want you to use this. We'll give you more opportunities while at the same time, letting users, as you pointed out, hang on to the experience they know and already love.
Ben Matthews: Exactly.
Dan Lines: What are some of the actionable insights that Collectives provide?
Ben Matthews: So a lot of companies want to know about what their technologies are doing and a lot of conversations around that happen on Stack Overflow. So just in the Collective, just even as a normal user, you're able to see how many people are interacting with that technology. Just viewing the questions. You're able to see how many other people are in that Collective’s recommended questions, the number of recommended members. So you're able to get a feel for the technology that you're a part of. On the side of Google, we're actually showing them how their technologies are doing, how people are interacting with them.
How quick are they to respond to some questions that come up. And also sometimes more importantly, how quickly is their own community answering these questions just on their own, because that's really what we want to do at Stack. We build communities and we don't want it to be something that companies use as a direct to user thing, as much as building a community. That's something else that's great for them to do on Collectives. But anything that fosters our user's ability to help each other and to benefit from it, that's always a home run for us.
Dan Lines: So your primary customer is those users, the people who are in Stack Overflow every day, who are using command C command V every day to bring stuff into their code base. It's great that you can have this kind of win-win where you get Google or another company to come in and say, here let's provide value to your users. And here's this reciprocal exchange we get. If our listeners want to know more or start using Collectives, what should they do? Where should they go?
Ben Matthews: Check out https://stackoverflow.com/collectives. We have all the Collectives that we have so far. We're hoping to bring on more over time, hoping to add more companies to that. And you're able to see the new technologies that come and get an overview of all the capabilities Collectives provides.
Dan Lines: This has been such a great conversation. Ben, thank you so much for coming on the show today. Thank you. It's been wonderful. Now I know you're doing a little bit of hiring.
Ben Matthews: Stack Overflow to come work here. You'll see we have openings all across engineering and we're always looking for other talented people who just want to help developers. It's always rewarding to hear how people use stack overflow to help their careers get better. Even though you hear it a billion times. And I'm one of those people that gushed about it too -every time, satisfying. You like being a part of that. There's a lot of ways that you can contribute and help out at Stack. So go check it out. We'd love to meet you.
Dan Lines: Awesome. Everyone definitely check out the hiring opportunities at Stack Overflow. Also be sure to join the Dev Interrupted discord community. That's where we keep the conversation like this going all week long. You can find all the links in the description below and everyone have a great week and, Ben, have a great weekend. Thanks for coming on.
Ben Matthews: Thank you, Dan.