Rust 2019 (4): More Intention, Less Reaction

Another one of those things that helped us a lot as a young project: we’re good at reacting to what’s happen. For example, we are used to bringing new people on as a reaction to their work or interest. Or even by setting up the community email address and making an effort to answer all questions. A lot of the project is optimized for dealing with random influx and not without pride, I can say: we are good at that.

This has covered for a lot of missing pieces. It’s also a problem. “Reactive mode” has big drawbacks. First of all, it’s never clear who reacts to something and what the appropriate reaction is. Often, the first person to react is the person who chooses the path. This is not a problem while your project is still small: Finding agreements is labor often wasted if the amount of people in a project in charge on a subject is small and know each other well. “Reactive mode” also means that most actions come from external stimulus and not from your own. Finally, “Reactive mode” is hard to communicate as a long-term plan. It’s hard for community members to read up on it and share their experiences on plans.

I would like to get us more intentional about our long-term plans. This means writing down a lot more, around project structure and team plans. It also means informing project members of upcoming announcements ahead of time. It has become a problem to people that announcements have been made that not even all project members knew of, forcing them to react to signals from their own project.

To take an example from the community team again: most of our support action is pretty custom to whoever we are interacting with. We have no playbook. That was great for the last years, but with the number of requests growing, this needs to change. The sentence “we need a policy for this” was not in our vocabulary in 2017, but 2018 has seen a lot of this.

Now, the word “policy” is often scoffed at, but it helps running larger projects! Having a policy for something means you don’t need to train new members on everything, and they can act independently. Having a policy means binding yourself to a halfway coherent set of values. It means that people from the other end of the project can have a half gut feeling about what happens. Good policies are empowering people to work without having to check with or need superiors.

Another example is that the question “who deals with this request?” on the community team mailbox is becoming more and more confusing. The larger the group gets, the larger the group of people potentially handling, the larger the chance that all people think others will do it.

This doesn’t mean we should let go of reacting well to outside happenings. It also doesn’t mean that no one should go and plan announcements without checking with leadership. But it should become good practice to make more of an effort that people that want to know something have an easy way to get to know about it. Policy work is one method, additional communication channels could be another. The project is now large enough to spend most of the time intentionally planning while having a couple of people around for reacting according to a planned set of rules. I would call this “intentionally reactive”.

top