Live data from Hacker News

Ask HN: Organizing company knowledge?

news.ycombinator.com

81–90 of 110 posts

Re: Ask HN: Organizing company knowledge?

#81

We use a gnarly WordPress install with a user permissions plugin. I hate it, but it is the only thing we've found that meets all of our needs, isn't $500/mo+, and gives our mid level managers control. We use it for everything from on-boarding, to training, to system documentation, to competitive intelligence documentation. Sure we could build something custom, but overall it works and it's given the team leaders cont…

Just curious: why WordPress and not a Wiki of some sort?

We had robust training/quizes setup on WordPress using gravity forms.

Also we found that making people specifically responsible for documenting their job/building training for others before they "moved up" into a higher role was really effective. Wikis didn't allow for the granular control we wanted over who got to see training/documentation.

Re: Ask HN: Organizing company knowledge?

#82

I've found that the tool doesn't matter as much as the company culture. You need to foster a culture of documentation for EVERYTHING. It doesn't matter if you have the best tools in the world if nobody uses them. Too often this falls by the wayside because documentation of processes and preserving institutional knowledge, while extremely important, isn't the type of work that gets recognized or rewarded. If anyone ca…

Well, maybe documenting everything is good, but what's more important is to make sure that the documentation is properly organized, which is exactly what OP is asking about. I've seen many wikis/confluences with multiple documents per topic, i.e. the author of the second document didn't know that the first one existed at all. In such cases, company wikis get cumbersome as they are polluted with knowledge. I would say…

Only for the sake of emphasizing your point, I have seen companies go out of business only because they did not follow proper documentation procedures.

Re: Ask HN: Organizing company knowledge?

#83
post #50

At Airbnb we built and open sourced our own solution for this called KnowledgeRepo. You can find it here: https://github.com/airbnb/knowledge-repo it is used throughout the data org and has been extremely popular and useful. there is a blog post here with more information: https://medium.com/airbnb-engineering/scaling-knowledge-at-a...

Airbnb has been an incredibly good member of the open source community. Airflow is a great tool, and this tool looks really good as well. I was just digging around looking at superset a while back, and that looks awesome as well along with Flask App Builder.

I just wanted to give a shout out to all of you and say thanks for giving so much back to the community.

Re: Ask HN: Organizing company knowledge?

#85

I've found that the tool doesn't matter as much as the company culture. You need to foster a culture of documentation for EVERYTHING. It doesn't matter if you have the best tools in the world if nobody uses them. Too often this falls by the wayside because documentation of processes and preserving institutional knowledge, while extremely important, isn't the type of work that gets recognized or rewarded. If anyone ca…

I've seen MediaWikia and Confluence used successfully. It does require culture . . . but I've noticed that more people use the friendlier tool and that we have a lot more documentation with Confluence. The MediaWiki stuff was okay, but clumsy.

Other tools I've seen used with success generally have the characteristics of being lightweight, not too complicated, and having a relatively frictionless interface for making small changes (e.g., "press an Edit button and start typing").

I've been in a culture that desperately wanted to do documentation, but the tool that management forced people to use was SharePoint, and it was horrible (search functionality that never worked, very bad response time, very difficult to link or move documents, and worst of all a policy to delete "unused" SharePoint sites after a while . . . the result being that important engineering documentation was irretrievably destroyed). PMs loved the busywork that SharePoint created for them. I wound up putting all of our documentation into source control and snapshotting it to SharePoint periodically. This made me unpopular with the PMs, but I'm pretty sure the documents are still there, a decade later.

So tooling doesn't matter, unless the tooling stinks badly enough.

Re: Ask HN: Organizing company knowledge?

#86
Use a Digital Asset Management (DAM) system. You get binary version control, automatic extraction of text for searching, automatic document type conversion, tagging, thumbnails, custom fields, etc. Everything can be sorted into a category hierarchy, with many-to-many relationships. You can control who can access what and when, and users can use native or web-based clients.

As others have said, your company culture has to support it, lest you use the resources to set it all up and no one uses it.

Re: Ask HN: Organizing company knowledge?

#87

Ours is here: about.gitlab.com/handbook - it's open source: gitlab.com/gitlab-com/www-gitlab-com/ My tips: 1. Maintain a clear single source of truth 2. Make sure everyone can contribute to it. We do this by requiring at least to edits to the handbook during onboarding 3. Embrace it as an organisation: if not everyone is committed to it, it's hard to maintain it as truth 4. Constantly iterate and improve it. Structur…

Curious whether you really mean _everyone_ -- including non-technical roles like Sales? I notice that for instance Sales seems reasonably well document [1] so, maybe so?

[1]: https://about.gitlab.com/handbook/resellers/

Re: Ask HN: Organizing company knowledge?

#88
I feel qualified to provide input here. Hopefully it helps. Ironically, it is quite verbose.

I position myself as

- Virtual Chief Knowledge Officer aas

- Virtual Chief Quality Officer aas

- Virtual Chief Information Officer aas

-----

Issue 1: "Knowledge and process is seen as a dichotomy, but shouldn't be".

All businesses that I have worked with, and all discussions I have seen or been a part of, draw a distinction between actual operations, and the workflow & guides that govern them.

The problem manifests as such:

- The business doesn't update info, as it is buried away (out of sight, out of mind)

- This fundamentally undermines the information immediately, making it even less likely to be used

- The information is therefore less likely to be updated, compounding the issue further.

Instead, these should be tightly integrated. For example - If a ticket/job is generated, the relevant guide should be proactively attached by the system as part of that ticket. When a human comes to that job, the information is there waiting for them. People aren't going to go out of their way to bring up information.

-----

Issue 2: "The Business Manual is verbose, not effective or up to date, and people don't like it"

Most business manual's aren't encouraging use anyway, in that they aren't relevant, are too constricting in areas, and are verbose.

1. Simplify (streamline the process, break the process down into procedures, break procedures down into atomic steps. Everyone in the organisation should know exactly what your processes are)

2. Automate (any steps that can be automated, should be)

3. Steer (Any steps that cannot be automated, should have a guide attached - But only to the extent that you need).

The last point is critical, as I often see strict, long instruction documents that stifle creativity, have a negative impact on job satisfaction, and don't cater for everything possible anyway.

Instead, guides should be curated to the extent required only, using the following attributes:

- Budget hours (if you exceed this let's regroup and decide whether to re-plan)

- Instructions (only where specific and accurate steps need to be followed)

- Considerations list (exhaust this before escalating, but allow creativity)

- Notes (general hints and tips / knowledge base that should be added to over time)

- Team (a section which shows who can train and undertake the task, and who is on the 'to-train' list)

- Reference (reference information or items)

- Tools (any potentially relevant tools)

This strikes a balance between paternalism and laissez-faire, and uses each where it is most effective. It solves a problem in that business manuals tend to be 'ineffectually authoritarian', so people resent them anyway.

-----

Issue 3: Information gets stuck

The following should be standard practice (knowledge transfer is king):

1. An entity is generated in the system

2. Template auto attaches

3. The template has a list of people authorised to undertake that entity, and a list of people to induct to that procedure/task

4. One of those authorised people undertakes the task, along with someone on the 'to train' list

5. Repeat 1-5 until trainer can 'pass' trainee. Trainee's name added to the top of the authorised list

6. Trainer moves down the list of members as people are inducted and added to top of the list, therefore gets used less and less for that task and is freed up to move 'up the process chain'

This creates a moving machine within the organisation, where people are proactively provided information to complete their job, and proactively are able to pass that knowledge on and faciliate personal development within the company.

-----

Issue 4: Reactive thinking, lack of proactive thinking

The following should be deeply ingrained into the culture:

1. The business becomes aware of 'the system' no longer comprehensively and accurately reflecting reality

2. The interface node (user / system) that discovers this difference should log it immediately in or as a system entity (service ticket, general client, technical documentation update, client information change, new client user, data breach, potential sale, etc.)

3. All relevant information should be auto-attached

4. Whenever any entity is being closed off, the team member considers whether there are any potential follow ups that they can derive (including improvements to the template/guide), and triggers them

-----

"3 clicks away" is not good enough. "2 clicks away" [was never] good enough. Information needs to be a) in the user's immediate view along with their work, or b) a single click away (to hide peripheral information, so as not to overload the primary view).

Documentation is unfortunately often an afterthought, or at best is a follow-up task for a system that is not at the forefront of people's vision and mind.

As a final thought, here are two contributions to the suggested software so far (no affiliation):

- IT Glue (if you are in the IT industry) (www.itglue.com)

- Process Street (www.process.st)

Re: Ask HN: Organizing company knowledge?

#89

Earlier quoted context omitted.

At a glance, it looks like a product that's stored on the company's servers. Why would any company, startup or dinosaur, want to put their knowledge base and documentation in the hand of a new pretty and fancy product that might fold next month? There's no Linux download, no github, and especially, no server - I stay away from products like that, sorry.

You can export it as a HTML document, PDF or Markdown and do what ever you want with it.

So I would have to edit my documentation in this app, export to HTML and rsync the files to a web host on our intranet to share it? I'll stick with Mediawiki.

Re: Ask HN: Organizing company knowledge?

#90

Earlier quoted context omitted.

Well, maybe documenting everything is good, but what's more important is to make sure that the documentation is properly organized, which is exactly what OP is asking about. I've seen many wikis/confluences with multiple documents per topic, i.e. the author of the second document didn't know that the first one existed at all. In such cases, company wikis get cumbersome as they are polluted with knowledge. I would say…

Only for the sake of emphasizing your point, I have seen companies go out of business only because they did not follow proper documentation procedures.

Whats funny, is you must also be careful what you document as it becomes discoverable. Even procedures, especially when they are safety sensitive, involve the public, or anything sorbanes.
Post reply on HN