Over the weekend, one of our most respected users and moderator extraordinaire, Monica Cellio, wrote a post that shook me up. Please read it if you haven't. Come back, if you like, but please read that post first.

I'm not going to detail what happened or why; that story belongs to others. I'm going to venture a guess from knowing Monica for years that her words reflect a sense Stack Overflow, my employer, betrayed her. As operators of the Stack Exchange network, it was our responsibility to protect the volunteers who make it run from outside threats and we failed to do that job. It doesn't much matter that the action we took was minor in the grand scheme of things or that our intentions were to protect the community from a different sort of harm. We broke trust and our relationship will never be the same.

In ten years of involvement with the network and five years of employment as a community manager, I've seen my fair share of chaos. For instance, I rage quit without the rage.1 I announced the shutdown of a project I believe in. In 2017, good friends and valuable colleagues were laid off.2 For all that the company has done to enable its volunteer users to build a store of knowledge, I wonder if it's worth all the pain we suffered and, frankly, inflicted.

It's only right that you and I should take the time to grieve. As King Solomon wrote:

Everything has an appointed season,
and there is a time for every matter under the heaven.
A time to give birth and a time to die;
a time to plant and a time to uproot that which is planted.
A time to kill and a time to heal;
a time to break and a time to build.
A time to weep and a time to laugh;
a time of wailing and a time of dancing.
—Ecclesiastes 3:1-4

For my part, I've sensed an erosion of community capital for several years and it's no longer a resource we can reliably draw from. At one point during the Documentation project I had a conversation with our Product Manager about how users didn't seem to have any confidence in us. She calmly explained that most companies don't have that luxury at all. In order to obtain the trust of users, most projects need to show them something they can believe in by first meeting their needs. It's the quality of the product that matters in almost every case. Our collaboration with users in developing the Q&A engine was very nearly unique. It's tragic that we are in the process of losing that unusual relationship if the damage hasn't been done entirely.

My analysis is that we as an organization have taken on an unhealthy role with the developer community and our users. I won't go into detail here, but the company pursued its goals with the assumption that our users would be eager to participate. And it turns out that's only really true when our goals directly help users reach their goal to build a library of answers to questions on whatever topic inspires them.

This is the part of the post where I turn optimistic. If you aren't ready to follow me down this path, that's no problem. Here's an earnest song by that band that did a music video with treadmills:

Are you are ready for the optimistic message? Whatever chaos surrounds us, we can know that it's only temporary.3 I'm not sure we can ever get back to the exciting formative years of the network, but we don't need to despair that we'll be stuck in this particular dysfunction either.

What's more, the idealized state of users and developers working hand-in-hand to build the sites was more smoke-and-mirrors than reality. When I was first hired most of the development team was assigned to "core", which is to say, there was a bag of developers for managers to draw from. It wasn't quite the same situation as Valve's no-management structure but it was a lot closer to that than a typical organization. As a semi-outsider, I observed two ways that changes got made:

  1. As a result of major initiatives originated by management.
  2. As the result of an employee rallying support for their idea (and often doing the bulk of the work themselves).

I don't think this is airing dirty laundry because that's the impression I got from observing the company even before I was hired. Also, it's a normal part of a maturing development team, in my experience. To the extent that initiatives and developer-selected projects line up with user's feature requests, this can look like a partnership.

And indeed, when the goals of the project align to some degree with the community's goals and when the project is carried to completion (including evaluating the end result and fixing issues) this arrangement can be very successful. For instance, by working with other people in the company and getting feedback from meta, I was able to create a set of badges for asking questions. It was thrilling to see through to the end and I'm incredibly pleased with the results. But the process was very dependent on personalities in a way that's not very efficient.

Fortunately, there's a solution to this problem: hire a project manager. I don't think I'm alone in feeling a sense of relief when our development process became more predictable and understandable. I can now say with confidence what we are working on and usually explain our goals too. There are still vestiges of the old ways4 that surprise us, but generally PMs have taken responsibility to drive the development process.

The downside of top-down development is there's a lot less room for independent projects and ad hoc feature development. As more developers have been assigned to larger projects and as more gates are erected, fewer of the second type of development has been possible. So if you depend on that work to get your pet project done, more disciplined development is bad news. For better or worse, the features established users most appreciate tended to come from developers pounding them out in their unallocated time.

However there's good reason to expect projects managed by a PM will result in more polished features that get testing, validation and incremental improvements. Take, for instance, the improved review queue indicator. With the previous indicator, it was difficult to explain how it worked without combing through the code. It was a one-size-fits-all-sites algorithm. It had one giant annoyance that couldn't be easily fixed.

Contrast that with the current indicator which was initially created in response to feedback on the new top bar (another PM-managed project5). We went through several rounds of testing before settling on the design. As recently as this week I've handled requests to tweak the logic for individual sites. Perhaps most importantly, I can fiddle with plenty of site settings specifically designed to accommodate the changes I'm making. Lastly, I'm confident that we'll be able to improve on the system in the future if we find a better way. Given we've documented the algorithm, it's even possible users will have the information necessary to productively suggest improvements.

There's one more effect that I think will be incredibly healthy, but will probably scare some users. Project priority is now controlled by our PMs. They might ask for input yet the ultimate decision of what to work on resides with them. Really that's the only logical way to get work done. Only the person who controls the schedule can make rational priorities.

I think the recent incident highlights the potential danger of people with the loudest voices driving our development schedule. While it's new that the voices are coming from outside our community, it wasn't a good situation when development reacted to voices on meta either. Plus, as I said before, a lot of that was an illusion. And so, I have hope. Not hope that we'll return to the old way of doing things. Rather I have hope that we'll find an even better path.

  1. Rage quitting without the quitting is the normal pattern, of course. ↩

  2. 2017 was a fairly crappy year in my book. ↩

  3. "Everything has an appointed season . . ." ↩

  4. Including the events that led to the problems Monica describes. ↩

  5. AKA: PM-MP. Palindrome! ↩