5 ms·

I work in a team closely related to another team, and together we're about 30 people in the midst of THOUSANDS of engineers responsible for shipping product. We

I work in a team closely related to another team, and together we're about 30 people in the midst of THOUSANDS of engineers responsible for shipping product. We are dying under the burden of tracking and correlating engineering decisions across product lines and customers through presentations (you can't have a meeting without PowerPoint!) and spreadsheets -- scattered all over internal shared drives -- email, and Skype chats (which the company won't allow history for). Just this week, I'm supposed to start working on a plan to implement a knowledgebase system to capture all of this information. Obviously, I'm very interested in the answers here. The original question was about sharing knowledge amongst a TEAM, but almost all of the responses are about PERSONAL systems. I know most people watching this board are small-company startup types (in general), but I'm hoping that some of the old codgers, like me, working in creaky, legacy firms, have more to say. If we can't find something off-the-shelf here, I'm going to wind up writing some kludgy homegrown tool with Elasticsearch, and, frankly, this just doesn't interest me. I need answers people! The leader for large teams, according to what I see here, seems to be Confluence. Notion LOOKS cool, but putting this data in someone else's hosted service is an absolute non-starter for us.

benhurmarcel 7y ago
I'm in a similar company, but the main issue is that almost all modern solutions store the data in the "cloud", which isn't acceptable in that situation. Either my company has a contract for that tool (not our level of decision), or we have to store the data in-house. Very few tools are made for self-hosting or using mapped shared drives nowadays.
- miomyosky11 7y ago
  Shameless plug here. Exactly why FileCloud does the job in this condition. You expose your shared network drive over the network and then via FileCloud it is just seamless access to those documents etc. no more slow vpn. We run a server internally and all our documents are stored there.
gen220 7y ago
We use confluence. To overcome the issues some other people have mentioned (namely, lack of version control), our confluence docs are generated from version controlled markdown docs. It’s integrated with our build system so it doesn’t require much thought, you get the benefits of having your documentation living with your code, and you generate a doc that’s easily searchable and shareable for non-engineers. The only thing that sucks about this setup is that you can’t fix typos without making a diff :)
Riverheart 7y ago
Wouldn't a self hosted Wiki or Gitlab instance using markdown files be better than a homegrown solution?
- TheRealDunkirk 7y ago
  How could that incorporate the endless PowerPoint files that, unfortunately, contain critical details about design specs? Cut that content out, and put it in MD, after the meetings? An import process that does this for us? I'm not saying it's a good system, but this is the corporate culture. The vast majority of our design history is only codified in PowerPoint. We have a PTC Integrity system, but it's so slow and so bloated, people avoid it at all costs.
  - Riverheart 7y ago
    Well Wiki's support file uploading and you can always source control the ppt files and use MD files where appropriate.
    - TheRealDunkirk 7y ago
      What I'm shooting for is to index the content of Office files. I've now looked, and, apparently, Confluence doesn't do this. Given this requirement, I seem to be looking down the barrel of Elasticsearch with FSCrawler.
      - semiotagonal 7y ago
        You might need to simply create a workplace rule that powerpoints are not to be considered stores of information, and that any specs contained in them will be discarded at the end of the presentation.
SamuelAdams 7y ago
I've worked at several multi-billion dollar corporations. Here's what was used, to varying degrees of success: Private owned retailer: used Sharepoint and / or word documents on a shared network drive. This didn't work very well, but it ticked the "I did it" / corporate compliance boxes. University: we use OneNote notebooks for each team. It's stored on a file share, and since everyone already uses Windows 10 / O365, it's an easy thing for our security concerns. It's also auto-backed up to the cloud (O365). It's also easy for business users / BA's to view and contribute to. Downsides: it's hard to flag info as out of date, or notify people of changes. Healthcare provider: we used Markdown / Git. This worked because there was a single (mono) git solution for the entire org. Technically there was an SVN thing too, but the org was working to actively remove that / transfer source code to BitBucket. We required each project to have a README.md. This file included what the project did, and all the info a new analyst needs to know to get up and running: how to build the project, what servers it deployed to, what testing / production URL's applied to the project, what tools you installed on your local machine, etc. We had a separate repository for "standards" that applied to all projects or across different global teams (think "internal" - EPIC, Sharepoint, etc teams and "external" product teams). These were just markdown files that contained policy info, best practices, libraries to use, etc. There was a "standards" team made up of a dozen individuals from separate teams that met quarterly to make updates to these standards. Changes were managed in Git and any issues were created there as well. It worked pretty well, since policy / standard changes tend to move slowly in large orgs. It also gave all teams visibility to the policies so they were all on the same page.
nl 7y ago
I've used Confluence with teams of hundreds, and it's ok. It is reliable, flexible and has a pretty good search which works when you have multiple access levels. It's a bit clunky sometimes though.
shantly 7y ago
I'm pretty sure every company I've ever worked at has been in the middle of trying to fix their document management & sharing. It's all sucked. The overall best knowledge-base I've ever used has been... Slack :-( Email is probably second-best but suffers from too much spamminess—"here's a progress report you don't need, for that project you're kind-of on part time, sent once a week, to pollute your search results for same project if you ever actually need anything, oh and there'll be a 20-reply thread here which may or may not contain anything worthwhile to anyone at all, good luck sorting wheat from chaff". Plus if you have both Slack (or similar) and email Slack's more likely to have the Real Stuff, and email may miss out on entire topics.
madhadron 7y ago
> We are dying under the burden of tracking and correlating engineering decisions across product lines and customers through presentations (you can't have a meeting without PowerPoint!) and spreadsheets -- scattered all over internal shared drives -- email, and Skype chats (which the company won't allow history for). Sadly, a tool isn't going to get you out of this. You will end up with all the files uploaded to a wiki or repository. One would hope that seeing all the chaos in one place would make everyone say, "Oh, maybe we need to change how we do this," but that is unlikely. What will probably happen is, "This new knowledge management system is a chaotic mess. Let's abandon it." I would completely ignore tools when you start on your plan. This is going to be a slog about setting expectations for how things will be decided, documented, and referenced, about getting managers and tech leads onboard to discipline their groups, and about having the whole thing not collapse into a bureaucratic nightmare. Since you're shipping software, I might start with articulating the kinds of documents groups are expected to produce and keep up to date such as design documents that include why particular decisions were made, reference docs and docstrings to let users of a system find what they need, and tutorials/introductions to get users up to speed. Then expectations about how things should be recorded (in an expected class of document, not buried in a PowerPoint, and non-trivial examples). Then you need buy in from management that engineers should put cycles towards this, and technical writing support to keep the whole think functioning. But think about behavior, not tools. User stories, if you will, of what kind of information people look for and when, and what kind of information people produce.
thrown_produce 7y ago
Search a job board for an experienced ”Document Controller” with experience from large engineering projects and hire one or more. You need more than a tool, you need processes and a strong owner of those processes.

benhurmarcel 7y ago

I'm in a similar company, but the main issue is that almost all modern solutions store the data in the "cloud", which isn't acceptable in that situation. Either my company has a contract for that tool (not our level of decision), or we have to store the data in-house. Very few tools are made for self-hosting or using mapped shared drives nowadays.

miomyosky11 7y ago
Shameless plug here. Exactly why FileCloud does the job in this condition. You expose your shared network drive over the network and then via FileCloud it is just seamless access to those documents etc. no more slow vpn. We run a server internally and all our documents are stored there.

gen220 7y ago

We use confluence. To overcome the issues some other people have mentioned (namely, lack of version control), our confluence docs are generated from version controlled markdown docs. It’s integrated with our build system so it doesn’t require much thought, you get the benefits of having your documentation living with your code, and you generate a doc that’s easily searchable and shareable for non-engineers. The only thing that sucks about this setup is that you can’t fix typos without making a diff :)

Riverheart 7y ago

Wouldn't a self hosted Wiki or Gitlab instance using markdown files be better than a homegrown solution?

TheRealDunkirk 7y ago
How could that incorporate the endless PowerPoint files that, unfortunately, contain critical details about design specs? Cut that content out, and put it in MD, after the meetings? An import process that does this for us? I'm not saying it's a good system, but this is the corporate culture. The vast majority of our design history is only codified in PowerPoint. We have a PTC Integrity system, but it's so slow and so bloated, people avoid it at all costs.
- Riverheart 7y ago
  Well Wiki's support file uploading and you can always source control the ppt files and use MD files where appropriate.
  - TheRealDunkirk 7y ago
    What I'm shooting for is to index the content of Office files. I've now looked, and, apparently, Confluence doesn't do this. Given this requirement, I seem to be looking down the barrel of Elasticsearch with FSCrawler.
    - semiotagonal 7y ago
      You might need to simply create a workplace rule that powerpoints are not to be considered stores of information, and that any specs contained in them will be discarded at the end of the presentation.

SamuelAdams 7y ago

I've worked at several multi-billion dollar corporations. Here's what was used, to varying degrees of success: Private owned retailer: used Sharepoint and / or word documents on a shared network drive. This didn't work very well, but it ticked the "I did it" / corporate compliance boxes. University: we use OneNote notebooks for each team. It's stored on a file share, and since everyone already uses Windows 10 / O365, it's an easy thing for our security concerns. It's also auto-backed up to the cloud (O365). It's also easy for business users / BA's to view and contribute to. Downsides: it's hard to flag info as out of date, or notify people of changes. Healthcare provider: we used Markdown / Git. This worked because there was a single (mono) git solution for the entire org. Technically there was an SVN thing too, but the org was working to actively remove that / transfer source code to BitBucket. We required each project to have a README.md. This file included what the project did, and all the info a new analyst needs to know to get up and running: how to build the project, what servers it deployed to, what testing / production URL's applied to the project, what tools you installed on your local machine, etc. We had a separate repository for "standards" that applied to all projects or across different global teams (think "internal" - EPIC, Sharepoint, etc teams and "external" product teams). These were just markdown files that contained policy info, best practices, libraries to use, etc. There was a "standards" team made up of a dozen individuals from separate teams that met quarterly to make updates to these standards. Changes were managed in Git and any issues were created there as well. It worked pretty well, since policy / standard changes tend to move slowly in large orgs. It also gave all teams visibility to the policies so they were all on the same page.

nl 7y ago

I've used Confluence with teams of hundreds, and it's ok. It is reliable, flexible and has a pretty good search which works when you have multiple access levels. It's a bit clunky sometimes though.

shantly 7y ago

I'm pretty sure every company I've ever worked at has been in the middle of trying to fix their document management & sharing. It's all sucked. The overall best knowledge-base I've ever used has been... Slack :-( Email is probably second-best but suffers from too much spamminess—"here's a progress report you don't need, for that project you're kind-of on part time, sent once a week, to pollute your search results for same project if you ever actually need anything, oh and there'll be a 20-reply thread here which may or may not contain anything worthwhile to anyone at all, good luck sorting wheat from chaff". Plus if you have both Slack (or similar) and email Slack's more likely to have the Real Stuff, and email may miss out on entire topics.

madhadron 7y ago

> We are dying under the burden of tracking and correlating engineering decisions across product lines and customers through presentations (you can't have a meeting without PowerPoint!) and spreadsheets -- scattered all over internal shared drives -- email, and Skype chats (which the company won't allow history for). Sadly, a tool isn't going to get you out of this. You will end up with all the files uploaded to a wiki or repository. One would hope that seeing all the chaos in one place would make everyone say, "Oh, maybe we need to change how we do this," but that is unlikely. What will probably happen is, "This new knowledge management system is a chaotic mess. Let's abandon it." I would completely ignore tools when you start on your plan. This is going to be a slog about setting expectations for how things will be decided, documented, and referenced, about getting managers and tech leads onboard to discipline their groups, and about having the whole thing not collapse into a bureaucratic nightmare. Since you're shipping software, I might start with articulating the kinds of documents groups are expected to produce and keep up to date such as design documents that include why particular decisions were made, reference docs and docstrings to let users of a system find what they need, and tutorials/introductions to get users up to speed. Then expectations about how things should be recorded (in an expected class of document, not buried in a PowerPoint, and non-trivial examples). Then you need buy in from management that engineers should put cycles towards this, and technical writing support to keep the whole think functioning. But think about behavior, not tools. User stories, if you will, of what kind of information people look for and when, and what kind of information people produce.

thrown_produce 7y ago

Search a job board for an experienced ”Document Controller” with experience from large engineering projects and hire one or more. You need more than a tool, you need processes and a strong owner of those processes.