So, we are a relatively new business and are deploying JD SBS before we really do any real work, so we’re structuring our business around this system as much as we’re tweaking it to work for us.
We are currently a team of two owners, but we’ll be adding at least 6 more before year’s end. I’ve been debating how to share access to our SBS folder structure, because it’s our main file system that everyone should have at least some access to.
E.g.:
marketing team needs access to 40-59 creative inputs and outputs
employees need access to 11.51, 11.52 training
Engineers need access to 20-39 customers and suppliers
The way I see it, we have a couple of options
Share the top level folders, e.g. managers get access to the 10-19, marketing gets access to 30-39, etc. I figure this becomes a problem when someone needs to access a folder in the 10s but isn’t a manager. I would like to avoid shares for every little folder because that becomes a mess in a hurry across 120+ folders and 8 people.
Everyone gets access to everything, Valve flat hirearchy style, but this could lead to low-level employees getting important things they shouldn’t.
Everyone gets their own copy of the SBS as a template, but then I have to figure out how to make sure every marketing person gets a copy of 40-49 creative inputs, and if some add a few files to their own, everyone has a slightly different version and it’s a big mess.
Only managers have access to the SBS at all, but I foresee a mountain of requests asking for this and that, that managers have to respond to constantly, which is a big mess.
Any ideas on how to manage a team’s shared resources with the SBS?
Basically what we’ve been doing for 15 years except that we exclude the financial stuff to be financial staff and company owners only. Depending on your operating systems that could be modelled in a multitude of ways. On the other hand despite trying to be “digital only” we still have lots of dead trees getting imposed on us. So data will be in multiple places but that is what 14.22 is about.
I share the point about trust and also try to go “trust and empowerment first”, however I’ve also seen cases where this went horribly wrong. So I guess it is about “speak softly and carry a plus one mace”
Wasn’t expecting this as a response but, of course! How lovely. Trust.
Perhaps @sasquatchnetworks start with the everything-open option and only close things off when you really, really feel it’s required. And then only in the most minimal way. Like, just put a password on that one Excel file.
I love trust, but not from a professional standpoint haha. I am an external financial auditor, so we always advice on more security and a need to know basis.
BUT that’s for larger corporations, so small business are fine
is there a way to share the JDex with everyone, and build the company-wide habit of making all notes in the JDex, and then be more restrictive on who gets access to which actual content folders? Decide that on a case-by-case basis. Maybe for the duration of a project. Maybe local syncs within one team. As long as the existence of those files are noted for everyone in the JDex. That’s the key habit/rule.
Disadvantage: requires really rigorous habit construction. But maybe if there’s a work cycle (fortnight, monthly), all private notes can be transferred to the JDex on a recurring basis with company-blessed time to do it. (Thank God it’s Last Friday of the Month, on the company-wide calendar.)
Advantage: Full transparency about what’s going on in the company, but people aren’t burdened with the responsibility of knowing things they don’t need to.
EDIT: I guess this is almost your number 3, with the difference being that it capitalizes on the dual-track nature of the Johnny Decimal system: the JDex being separate from the content. The key being to emphasize that it stands or falls with the ‘note everything in the wiki’ rule. Might still end up a mess, I guess. I’ve tried to introduce that in teams several times, lacked the authority and/or charisma, and it was a total flop.
On trust and transparency: I’ve had experience both with having access to the sensitive information (proposals and quotes for projects I was employed on), and not having that access. It can be awkard and muddy the relationship either way: sometimes I didn’t want to know what my bosses were billing relative to my hourly rate, other times I resented not being trusted with such information because I felt more ownership of the project than just following orders.
I guess my point is: transparency needs real honest commitment from the people in power, and thinking through all the implications and maybe going over the top to hold discussions about how it is for everyone.
You’re absolutely right about the possibility of things going wrong.
In structural engineering (and I assume, but don’t know, elsewhere) risk is based on (a) the severity of the possible bad outcome and (b) the likelihood of the possible bad outcome. Using option 2, “horribly wrong” is rare but potentially very bad. Using option 4, and probably option 1, there may be a trust issue between employees and the company, which isn’t so horribly bad but is fairly likely. I simply don’t have any way to judge which risk is worse. I do know that if someone misuses data they have access to, I know how to respond: anywhere from disciplinary action within the company to firing, to civil action, to making a criminal complaint. OTOH, if my employees think I’m an ass because of a fixable but unfixed logistics annoyance, I don’t know how to address that.
Also, I’m not a complete idiot. Our digital records have things like Social Security numbers redacted. We have one file drawer labelled “Forever paper” for sensitive stuff like that.
Desaster by mistake is more common than malicious intent in my experience and as already mentioned “the smaller the company the easier it is” (trusting people) is usually right. But back to the question: I’d stick with uncomplicated access to [almost] everything (Option 2) as long as there are no reasons to do otherwise. Also there are sometimes regulations (legal requirements) to be checked against.
On a side note: I always recommend reading “Joy at work” (D.W. Bakke) because he also takes this “open company” angle which you find rarely in the business school world.
We’re just starting on converting our existing system to JDexing. The One True Jdex will live in Obsidian, but most of our people do not want to use obsidian because it doesn’t meet the requirements for a good engineering-field-notes system. (More than anything else, people want to annotate PDFs on site and add photos to them, so we’re mostly using PDF Expert.) But an echo of the Jdex is available to all in the admin folder file structure, which people do have access to.
Fair enough. I definitely agree this is a disadvantage that can swamp this approach immediately. Then again, I would like to qualify my use of the word ‘rigorous’ as indicated by my citing of your bins example. And then on the other hand again, there might be stupid little environmental blockers which make it dead in the water again. For example: if people just want to annotate PDFs, one low-friction way to tie those into the system is to get them to put the SBS ID in the filename – but that might be a non-starter on mobile device with screen keyboard etc. And on and on it goes.
So yeah. Probably works only in certain circumstances.
But back to your earlier comment, if we’re sharing the file-system mirror of the JDex with everyone, doesn’t that serve nearly all the purposes of sharing the Obsidian original? We have a JDexy template for project folders and the admin folders will - real soon now - match the JDex structure.
I guess my suggestion can be rephrased as: splitting the data from the metadata. I was coming from the perspective of the team’s sense of trust and unity. It might be a good middle ground if everything can see what there all is, without seeing the actual sensitive information.
This doesn’t fully solve the problem of what to share with whom, but it does add another control point, giving a bit more flexibility. If following the official recommendations, the JDex becomes quite rich and full of information over time. The people with access to the sensitive files can choose how much about those files they want to share in the JDex. Maybe they’ll share the general budget of a project, but not the actual figures. Maybe they’ll share the final contract, but not the contract negotiation notes. They might choose to record the existence of those negotiation notes, though, and maybe the gist. Putting on my employee cap, I think this would give me a feeling of being trusted and respected commensurate with my role, while protecting me from the liability of access to information I could misuse (on purpose or accidentally).
In your case, where you give everyone access to everything, and use the filesystem not the JDex as the ‘place where it happens’, the point is moot. I think I made things unclear with my references to ‘bins’ and ‘pdfs’ because I wasn’t really using those in relation to my original suggestion. I was trying to convey first that habit building is crucial to my proposal, but second, that habit building might be made easier or unnecessary by clever hacks, like having the PDF’s already be named with the JD ID before they get synced out the fieldwork devices, and finally that systems such as that are fragile, as in the case where you can’t pre-name those files.
Because to expect people to give files complicated names on a mobile device is lunacy. Who’s going to switch over to another app, look up an ID, copy it, switch back, and then have to do the whole rigamarole all over after they accidentally exit the file saving dialogue? Especially when they’re lying on their back in a crawlspace and have five more photos to make before they can get back out…
(I don’t know the details of your work, but I can imagine …)
Your approach makes sense. You’ve run into the same issue our esteemed host has, which is the details of a given business may differ from any ideal, so at some point the general discussion ends and the specific begins. I’ve probably tended too much to the specific in my comments in this forum because I came across this while looking for ways to improve my office’s organization rather than a broader interest. (I admit to being a filing geek, but not necessarily a categorization geek.)
Whatever the JDex is today, it may evolve with a business - far more likely to IMO than with a personal system - and with future as-yet-unknown employees. So my answer to some of your questions is the question: what do you consider the unchangeable skeleton of the system as opposed to the malleable flesh? (That metaphor needs some work.) For my company, the unchangeable part is the numbering of the admin categories and the projects. How and what people store within project folders is up to them and will change in the future. But as long as we’ve all got the index (e.g., J5000.01 is the investigation of the Sentry Bridge; F9210 has the current CAD templates) no information gets lost.
It’s interesting, because as an admitted categorization geek, this:
sounds like it’s bound to cause problems at some point in the future. But I think you have the ‘what’ well-defined within the context of what your business does now. So I thank you for the reminder to be more pragmatic and not try to plan for all possible contingencies up front.
I believe I said I’m not necessarily a categorization geek. %^D
We have a well-defined structure for the project folders. (I set up a first draft long ago that worked well; we improved it by crowdsourcing within the office last year.) But not everything can be foreseen and I have zero patience for policing how people use folders.
Example: Maybe ten out of 5000 projects have point clouds. (Just as well, as they run 10-30GB each.) They’re not drawings, they’re not reports. Where do they go? They’re rare, so they’re not getting their own subfolder. So someone may create a subfolder just for them, or put them in reports, or in drawings…I don’t care.
My experience is that people will use the subfolders without being watched if the folder structure makes sense…which is a pretty JDexy statement, I think.
