antipaucity

Along the difficulties of initially building a good group/community, comes the hassles of managing said [virtual] community – especially on the book of the face.

I am a coadmin on the Ontario & Western Railways Historical Society Inc Facebook group. My friend Peter is a coadmin of the Linux Mint group.

Something both of us have noticed is the ridiculous spam problem Facebook groups have developed over the past 1-2 years. It’s not a new problem, of course – Stack Overflow has had problems since very early on, too: they printed A Theory of Moderation to outline the issues they were seeing, and how they planned to handle it.

The real problem at the root of all the spam lies, though, not in technology, but in people.

Even with active community self-regulation, moderators occasionally need to intervene. Moderators are human exception handlers, there to deal with those (hopefully rare) exceptional conditions that should not normally happen, but when they do, they can bring your entire community to a screaming halt - if you don’t have human exception handling in place.

Spam doesn’t arise on its own – it’s all developed by people. Until the people problem of spam can be addressed, it will continue. Sadly, technology, in and of itself, cannot deal with the people problem.

So instead we have human admins and moderators whose [typically volunteer] job is to ensure that the communit[y|ies] keeps to a general standard, as defined by the community itself. By assuming technology could be made that would fix the problem, we’re asking the wrong question: human behavior needs to be addressed and improved; while technology is wonderful and can aid in the process, it is no panacea.

Encouragements for moderation teams can come in the form of gamification (the SO model), community accolade, or just the individual admin’s personal satisfaction.

The drawback is that this task can become so overwhelming at times and in places that it those tasked with caring for the community, when the community itself won’t do anything about the problem(s), give up because they adopt the view that it’s everyone’s problem, and presume that since it is everyone’s problem, it’s not “theirs”.

What are the solutions to these issues? I can think of a few – but many remain yet unanswered:

1. the community must encourage the admins
   • if the community isn’t doing something to make their admins feel appreciated, the admins will, eventually, leave
2. better tech
   • it’s not possible to solve all problems with technology, but there are certainly many areas that can be improved in this regard
3. community engagement and education
   • seasoned community members and admins alike need to take the time to “mentor” new community members to make sure they stick to the guidelines of that community
   • community members need to be proactive in assisting the moderators when inappropriate items are posted, or conversation degrades below the stands of the group
4. a willingness to say “no”
   • admins and the general community needs to be willing to tell some people they are not welcome
   • this should [almost] never be in a hateful, grudge-bearing manner, but it must be done to ensure the integrity of the community in the long-term
5. a willingness to morph
   • the flip side of (4) is that the community needs to be willing on a regular basis:
     • review its own guidelines
     • change / modify rules
     • find new admins
     • welcome new members who aren’t yet versed in the ways of the group ( related to (3) above)

I am sure there are many many more items that can be added to this list. But this is the starting point for every successfully-maintained community I’ve ever seen.

What others would you add, or what would you change?

I recently found The Seven Stages of Expertise in Software Engineering.

• Stage 1: Innocent
  • barely knowledgeable if at all
• Stage 2: Exposed
  • seeking knowledge
• Stage 3: Apprentice
  • has read case studies and tries to apply those techniques
• Stage 4: Practitioner
  • can actually apply concepts learned in one context to a not-identical context
• Stage 5: Journeyman
  • professional understanding and application of the field; can mentor
• Stage 6: Master
  • moved from “whats” and “hows” to “whys”; can mentor very effectively
• Stage 7: Researcher
  • the teacher, presenter, mentor, speaker, evangelist, writer, authority

Presented firstly in the humorous guise of The Seven Stages of Expertise in Bear Hunting, Meilir Page-Jones makes a highly-compelling case for progressive advancement in [nearly] any field.

Some of the ideas seem similar to what Malcolm Gladwell brings in Outliers (review) or Robert Greene does in Mastery (review). Which seems to only lend more credence to those other works, given that this article is © 1998.

Back in 2009, Joel Spolsky wrote an article called The Duct Tape Programmer. Of everything he has written, I think this is the very pinnacle, and it is summed in one simple sentence in the middle: “Shipping is a feature.”

I’ve referenced this article twice before (in Feb and Sep of ’11).

Why is this so important in my mind?

I went back to school in 2003 to complete my bachelor’s degree in CIS. I had graduated in 2001 with an AAS in CIS from HVCC, and after finding nothing in 2 years of searching better than the job I had at Hertz, I decided a 4 year degree might help. I graduated from Elon University in Dec 2006 with my newly-minted BA in CIS. During my tenure at school I discovered that I didn’t really like the development end of Computer Science, and I instead preferred the analytical and integrational aspects of systems work – tying disparate tools together, improving internal workflow, etc – to help make individuals’ lives better and easier. In other words, I enjoyed finding ways to automate time-consuming and repetitive tasks to allow myself (and others) to focus on more interesting work – like figuring out how to automate more tasks to move up the chain.

I worked for a few places while I was at school (two different departments at the school itself, a pair of non-profits, and some freelance side work doing web site development). When I graduated, therefore, it was only natural that I ended-up with a pair of offers to work with automation tools – one from a company called Opsware, and one from a place called Network General. For a variety of reasons, I chose Opsware.

It wasn’t long after I started in Support for Opsware’s Server Automation [System] product that I became more and more sold on the product, and grew bored doing support – troubleshooting is fun, but with the paucity of good support tickets^*, large similarity of cases coming from customers, etc .. it just wasn’t “me”. Shortly after HP purchased Opsware I put in to move from Support to Professional Services – to, hopefully, get a chance to work with harder integrational problems than I would ever see helping people over the phone and via email.

Beginning March of 2008^{^} I moved from Support to ProServe, and did start to get a taste for the bigger systemic problems that could be solved with the Opsware HP BTO suite. While with HP, I had the opportunity to do the global delivery of HPSA 7.5 for HSBC – performing both installation and onsite mentoring/training in Chicago, NYC, London, and Hong Kong. I also did the replacement install of HPSA 7.0 (a non-upgrade-to release) for Home Depot in Atlanta to manage their 2200 stores. There were some other customers I worked with, too – but those were the two biggest.

One of the issues that has arisen with [nearly] every customer I have ever worked with is that they want what they’ve agreed to pay for in the Statement of Work (SOW) signed, sealed, and delivered by the end of the project – and if it’s not, they want good reasons to sign a CO (change order) to modify the SOW.

And it’s no surprise. When you cost someone nearly 7 cents per second to work for them, they want to see results!

One of the constraints, therefore, that needs to be constantly watched is scope creep – the insidious tendency for all projects to go beyond their intended purpose (violating law 47 of the 48 laws), exceed budget, and never deliver what is really needed.

My primary goal when I work with a customer is not, perhaps paradoxically, to “make them happy”. One thing I learned when working in support is that the customer is never right^!. You may have to pretend that they’re kinda right – but they’re always wrong. They do not know what they want. They do not know what they need. And they certainly do not know what is wrong if you ask them.

My primary goal when I work with a customer is to deliver what they have paid for. When possible, I will change course slightly (following proper CO processes) – but I want them to get what they have agreed to pay for. Ideally, especially now that I am in the architecture end of the world much more than ‘just’ delivery, I can work with them in the pre-sales process to get the SOW to something that approximates what they need. But I always aim to give them what they have paid for. Everything else is window dressing.

At the end of a project – whether as outside consultants, students, internal employees, at home, for work, etc – what needs to be seen is what was paid for.

Ship. Deliver.

Without those two, nothing gets done.

^{* _{I have grown so frustrated with support processes that I spent time a couple years ago writing a small eBook that includes a section on how to make good tickets. I’ve also written on ways to improve your support organization before.}
^ _{Just realized that means I’ve been doing ProServe or PS-like work for 5 years running, and have been with the automation suite for more than 6 now.}
! _{Before you become too concerned – I do realize there are a few good customers out there. But they are just that – few, and VERY far between.}}

One of the biggest issues facing Western societies is that they are all consumption-oriented.

Not enough time is spent creating – all [most] people want to do is consume: entertainment, food, money, fun…

We all want shortcuts. We all want to be at the level where we don’t have to think to accomplish work. We all want to have fun instead of working. Some of us have fun while working, but most people just want the day off.

One of the biggest drawbacks to a consumption-based economy (like most western economies – and certainly how the United States’ economy is currently structured), is that consumers feel compelled to consume ever more. We have to have the next best thing out there. Keeping up with the Joneses.

I think far too few people create in our society, because it is so much easier to consume.

I know I don’t create nearly as much as I consume – I wish I did, but I don’t … yet. One of my personal goals is to move that balance in my life more towards the creating end from the consuming one – little things along the way certainly help: mentoring, teaching, volunteering, growing a garden, etc.

What ways do you see that folks can create more and consume either less in gestalt, or at least less from others because they’re contributing themselves?

Knowledge capture, retention, and dissemination has been an interest of mine for a long time. I have written about various aspects of it before.

The most vital commodity any organization has is the knowledge of its members – it does not matter if it is a historical society, company, church, or school: the organizational knowledge base is vital to ongoing health of the organization.

I love the picture of the “Tree of Wisdom“: at the ground there is a meadow of data, from this data information roots are gathered, the roots grow into knowledge branches, and at the end is the application of that knowledge in wisdom leaves.

Data is easy to come by.

Information similarly so.

Knowledge, taking information and transforming it into a more-usable form, is important.

When to apply that knowledge – aka using wisdom – is the topic for another post.

Capturing Knowledge

There are a host of available tools for capturing knowledge – text files, brown bags, PowerPoint, SharePoint, blogs, Plone, wikis, etc. The “best” one to use is the one you use.

Culture

Getting team members to contribute to organizational knowledge pools can be difficult – unless it is an organizational priority .. a part of the organization’s culture.

Incorporating this culture switch (if it’s not already innate to the organization) needs to be done not merely as a top-down directive, but encouraged via bottom-up interest.

Retaining (Managing) Knowledge

Now that you’ve captured (or started capturing) the organization’s data, managing it becomes the next task of import.

For example, should the KB article written 5 years ago be updated, replaced, or left alone?

Who is responsible for managing all of the information that has been collected? Will it be self-managed and -directed, will there be a curation team, will it be a combination?

Who determines the process for taking “internal” knowledge and “promoting” it to “outside” knowledge?

How are these roles going to be managed as the team changes memberships through people leaving, entering, and shifting in the organization?

For extremely small organizations, formal curation may be unnecessary. Perhaps since everyone knows everyone else, or the knowledge domain is so small, everyone’s individual contributions will remain fairly static and the “promotion” path will merely be proofreading (eg a historical society’s archives – the archives may be extensive, but the material doesn’t ‘change’ all that much (excepting being added-to, of course)).

For very big organizations (like the MSDN documentation available on microsoft.com), many layers of curation are likely going to be needed – proofreading, formatting, verifying, etc.

Finding the right balance of self-direction and organizational management can be tricky.

Disseminating Knowledge – Getting The Word Out

All of the captured knowledge in the world is useless if you can’t find it – and knowing where to look is vital. A close second to knowing where to look is how to find it.

Where is it?

There needs to be a solid document, landing page, directory, table of contents, etc so that new members (or folks who forget) can find the tribal knowledge that exists in the organization.

As a part of the new-hire\introduction\etc process\period, be sure to tell new members where information can be found, and who to talk to about certain major topics.

Finding it once you know where to look

“Search is a hard problem.” Google’s own Udi Manber said that. Anna Paterson at Stanford wrote, “Writing Your Own Search Engine Is Hard.”

Search in general may be hard, but many tools handle at least basic (and some fuzzy) searching well – OSQA, WordPress, Plone, Drupal, and many others. If, in addition to categorization, a tag taxonomy is employed, quickly finding content relevant to the searcher’s wants\needs can become easier.

“A tag is a keyword or label that categorizes your question with other, similar questions. Using the right tags makes it easier for others to find and answer your question.” {SO description}

Knowledge contributors should be the primary agents of tagging. However, consumers should be able to suggest additional tags. Administrators\curators should be able (under unusual, but well-defined, circumstances) to remove tags.

The human factor

For any given topic / knowledge region in the organization’s realm, there need to be established “experts” and “mentors” who will help guide new individuals through the fog to locate the buoys to be able to navigate themselves into a clearer understanding of the new world they have been made a part of.

Apprenticing upcoming experts into the organization is the single most vital aspect of the knowledge capture process – if it is not disseminated, it doesn’t matter if it is captured.

The ubiquitous protocol that enables the internet as we know it, http, is stateless.

Stateless merely means that any given request has nothing to do with the previous, or the next request. This enables the world wide web, as web servers do not need to keep track of who is receiving data, nor how much they have: they get a request, and ship data to the requestor.

It is up to the requestor (often a web browser) to handle the incoming data.

If not every part of a web page, for example, is sent, the browser will display what it can.

This is analogous to a creditor sending you a bill (request), and you sending a check back to them – once the bill has been sent, the creditor knows nothing about the state of the bill until he receives a payment. Likewise, once the check is dropped in the mail, the payor knows nothing about his bill until the check clears his bank.

Why is this important? Because of an oft-repeated “request for enhancement” to the product I use on a daily basis. When the implementors of Opsware SAS were picking how a user should communicate with the system, they picked to run everything over http(s). They chose to utilize http because it’s commonplace, well-understood, and easy to work with.

One of the things about statelessness is that you cannot know how many people are using a given web page at the same time. Google cannot tell anyone how many people are actually looking at www.google.com at this moment. They can tell you how many loaded it,and how many just pressed “Search”, but they can’t know what percentage of the loaders promptly went elsewhere – either to a different page, or a different room in their home.

One [partial] way around the statelessness of http is to utilize cookies or session data – but that merely adds a check layer to the interaction, it does not provide true “statefulness”.

Several times during my time in Support at Opsware (and after HP’s acquistion), I would have a customer who was looking for the ability to determine who was logged-in at any given time (in similar fashion to running `w` or `who` or `finger` on a Linux/Unix system). This could be important to know whether a user is “doing something” before doing an application restart.

However, since communication is all done via http, there can be no state known in the tool. Once you load a web page, it is being viewed/rendered on your local machine in your web browser – the server could be shut off, your network connection removed, or any of a host of other simulations of restarting the application. And your browser would be none-the-wiser, nor should it be: it has the data it requested/received, and you’re doing something with it.

This carries over to the product I work with. Jobs might be scheduled by a user to run every day at 0200 – but he doesn’t need to be actively logged-in to have them run. Likewise, someone may have logged-in, but is not “doing” anything currently (maybe they’re at lunch).

Another case of why technical intricacies matter 🙂