3 ms·

Personally I'd go for documentation. Having all the knowledge in a persons head is useless. You could say your trying to add value to the company. Even help the

Personally I'd go for documentation. Having all the knowledge in a persons head is useless. You could say your trying to add value to the company. Even help them along by providing an outline document that they have to fill in the blanks, like they're answering a FAQ. You would have to know what questions to ask first at a high level. Then determine what needs more details and issue more FAQ requests as required until you have documented the system. OFC this will take another persons time, but guided documentation as part of a persons 'new' work requirement would be worth it. You could even say its a new way you're running the company and get other employees to say "Ok I'm off to fill in my Friday FAQ".

prawn 3y ago
I'd try the same, but with more emphasis on your last point. Have your effort or that of a consultant focused on someone else within sight/similar of the troublemaker. Have the consultant ask the troublemaker for help in documenting this other staff member's processes so you build rapport and it's not obvious the focus will soon be directed at them. Prioritise the key bits first. Could some 'security testing' also require that consultants have overarching access, and at some point indirectly remind the troublemaker that there would be legal repercussions for an employee misusing access/control?
charlie0 3y ago
Sounds good in theory, but in practice, no one wants to write it, even less actually read it, but boy, do most say they want it.
- yjftsjthsd-h 3y ago
  It depends; I write docs because I forget how to do things, so I write everything I'll need to know next time in the wiki, plus a little bit more to help me hand off to someone else so they can do the work too. And this apparently produces docs that other people find useful, because I get very positive feedback.
  - charlie0 3y ago
    I also write docs because I forget, but I only write them for myself, a kind of rubber ducking. I don't share them because there's a high level of effort requires to make the docs great and I use Obsidian, so my docs are interlinked notes rather than 1 nice doc. That and also the low view counters in most of the Confluence docs are discouraging.

prawn 3y ago

I'd try the same, but with more emphasis on your last point. Have your effort or that of a consultant focused on someone else within sight/similar of the troublemaker. Have the consultant ask the troublemaker for help in documenting this other staff member's processes so you build rapport and it's not obvious the focus will soon be directed at them. Prioritise the key bits first. Could some 'security testing' also require that consultants have overarching access, and at some point indirectly remind the troublemaker that there would be legal repercussions for an employee misusing access/control?

charlie0 3y ago

Sounds good in theory, but in practice, no one wants to write it, even less actually read it, but boy, do most say they want it.

yjftsjthsd-h 3y ago
It depends; I write docs because I forget how to do things, so I write everything I'll need to know next time in the wiki, plus a little bit more to help me hand off to someone else so they can do the work too. And this apparently produces docs that other people find useful, because I get very positive feedback.
- charlie0 3y ago
  I also write docs because I forget, but I only write them for myself, a kind of rubber ducking. I don't share them because there's a high level of effort requires to make the docs great and I use Obsidian, so my docs are interlinked notes rather than 1 nice doc. That and also the low view counters in most of the Confluence docs are discouraging.