Improvement requires context

In chapter 3 of Program Management for Open Source Projects, I talk about getting started as a new program manager in a community. I explain how to ease your way in and establish relationships and credibility. What I do not talk about is how to approach making sweeping changes.

You, my dear reader, are a smart person. You have lots of experience and many good ideas. What you don’t have is a license to swoop in and immediately tell a project how to make itself better. Even when you’re right, that sort of behavior is anti-social. It not only harms your ability to make long-term changes, but it can prove harmful or even fatal to the community as you drive people away.

No matter how they may look from the outside, most practices and policies made sense in the context that they were created in. Sometimes the context changes and the current structure is no longer appropriate, but you can’t know that unless you understand both the current and historical context. If you swoop in uninformed, you might make some correct decisions, but you’ll probably make more wrong ones.

When you’re new to a project, you have to take the time to learn what the project does and why. Only then can you figure out what “improvement” looks like for the project. If you think this also applies to a billionaire man-child and his cronies who are wrecking their way through the U.S. government, you are correct.

This post’s featured photo by Jungwoo Hong on Unsplash.