Balancing Open and Productivity

The adage “knowledge is power” is usually a very good one. After all, the more you know about what’s going on, the more you can usually make a better decision about the things you need to get done.

In an open, collaborative environment, methods such as more transparent processes can lead to more efficient knowledge sharing. which in turn can lead to more effective decisions and outcomes.

But such systems also have people involved, and when that happens, sometimes the most ideal open framework can be thwarted from its intended goals.

Open As A Bug

In most situations, an open decision framework enables any participant willing to be involved in the decision-making process do so, adding their creativity and skills to getting a large project completed.

This needs to be carefully managed, though, as sometimes people misconstrue an open decision framework as “everyone’s opinion will be heard and acted upon.” This is very often not the case, and unless you set expectations right up front, a project can quickly be bogged down by an abundance of bikeshedding.

Bikeshedding, if you are not familiar with the term, is the software industry’s version of Parkinson’s law of triviality, where “members of an organization give disproportionate weight to trivial issues.” Put any bunch of talented and intelligent people in a room together to accomplish a task and arguments about the tiniest of details can stretch minutes into hours into days.

The best way to counter this problem is non-passive management of the project and its goals. It’s not so much that a person has to be in charge in the traditional sense, but at the very least there needs to be someone keeping their eye on the goal(s) and keeping the group focused on those goals. This is easier said than done, since even with the best of intentions, someone may be carrying an agenda of what they think needs to get done and will try their hardest to implement that agenda.

When managing open decision projects, keep the goals of the project finite and narrow in focus. Spend a little time briefing participants when they are gathered together (face-to-face or online) about what specifically needs to be accomplished in that gathering. This bit of extra energy spent up front may save a lot of explored rabbit holes later on.

Knowledge As Power

Another potential pitfall in a collaborative environment is ensuring that knowledge is shared for the right reasons.

Occasionally there will be people in the project who will want to know what’s going on in every aspect of the project, even it is not their responsibility. Typically this is done with the rationale of ensuring that the project as a whole succeeds.

It is a fine line to balance, because on the one hand, people looking out for the health of the project as a whole is not a bad idea. But when people are inserting themselves in parts of the project where they don’t need to be, the implication can be that the other people in the project don’t know what they are doing. This is clearly demoralizing and detrimental to the project as a whole.

The problem is, sometimes this happens even with the best of intentions. Care must be taken, though, that people understand that their responsibilities should be taken care of first, and input to other aspects of the project should be made judiciously and diplomatically. Especially when you are not the person or persons directing the project as whole.

Getting open done right isn’t easy, and I can point to a number of times in my own experience when I’ve just wanted to grab a task and finish it rather than discuss it. But the payoff for real collaboration has always been better than anything I could have accomplished on my own.

No Comments / Read more

About Brian Proffitt

Brian is a Senior Principal Community Architect for Open Source and Standards team at Red Hat, responsible for community content, onboarding, and open source consulting. Brian also serves on the governing board for Project CHAOSS, a metrics-oriented approach to ascertaining community health. A former technology journalist, Brian is also a graduate lecturer at the University of Notre Dame. Follow him on Twitter @TheTechScribe.

Leave a Reply

Your email address will not be published. Required fields are marked *