6

I've been at my job for a few years and over the past six months have sort of become my office's main go-to for database needs and improving internal processes. It's very much dependent on what projects need within our office (so if there's nothing of that sort to do, I'm put on another task) and meant more as a tide-over until I'm promoted into a different role.

Recently, I've become frustrated with some coworkers, specifically project leads, who seem to gloss over the information I provide them. We're not on bad terms, they just don't seem to retain anything I've been working on related to their projects and I'm constantly needing to repeat myself on work matters I've explained multiple times. A recent example that's stuck out to me is an email chain I've had that went like this:

Me: Going forward, project X will need to process their numbers using method Y. I've attached a document with a step-by-step guide.

1 week later

Lead: How do we process numbers for project X?

Me: Method Y, as outlined in the email I sent a week ago.

Lead: So use Method Z?

Individual verbal explanations and group meetings haven't fared any better. Currently, I've recommended to my manager that we need more documentation for the things I've done, which I previously had no time for because we were focused on rolling out new projects as quickly as possible. I started small with some <2 page documents for a few critical processes and the response I got, a few days after I sent out the announcement to go through them and make sure they're understood, was basically "you sent out an announcement?". I'm not terribly excited about having to release much larger documentation with detailed information on the databases themselves, if those are going to be ignored also.

With all this in mind, is there anything I can really do to fix this apathy I'm seeing? I realize that as the person building and conceptualizing these processes and databases that I can expect to get some questions about how everything works, but it really just feels like I'm doing all the thinking for coworkers who really should have a better sense of self-autonomy.

Improve this question
2
  • 2
    "but it really just feels like I'm doing all the thinking for coworkers who really should have a better sense of self-autonomy" -> what happens if they don't execute the recommended/required method? And what happens if you don't respond to them (ignoring them on purpose to make them think for themselves)? Also, laziness comes to mind.
    – Edwin Lambregts
    May 8 '17 at 8:59
  • I've got a very similar issue. I'm developing a web application, from the requirements presented by the managers, to be used by the entire office. The problem I have is that no one is willing to create any kind of documentation either for themselves or their employees. When I take time away from my work to develop some, in the hopes of saving myself the time in the future, it goes largely ignored. Its just too simple to walk into my office and ask me detailed questions on one function of hundreds of pages.
    – SomeGuy
    May 8 '17 at 20:28
4

It's good to have in place some system of document control with active SOP enforcement.

Ideally, you as the originator would put together a document for your process that anyone with some experience with the system could follow and get to the same endpoint. Then you'd have it reviewed by a direct supervisor, have QC/QA sign off on that and get it filed somewhere accessible.

The other requirement, and most people miss this, is you need to train personnel on SOPs and have them sign off that they understand the document.

Typically, you include a statement of scope: where does the SOP apply and to whom? That way it's understood that work on project X is, in part, governed by the methods outlined in SOP-ABC-xyz. From there on the SOP is enforced by management, and instead of emailing you or searching around to piece together the required know-how, all I have to do is go find the PDF (no questions asked).

The primary issues are poorly written and/or unenforced SOPs, and my favorite: the documents exist but no one knows where. It's not a process to start alone, so I highly recommend getting a manager involved!

Improve this answer
1
  • Ending up sitting out of this for a few days and trying to cool down and another scenario at work ended up prompting me to talk with my manager (also the leads' manager) about some of the communication issues. I like the idea of QC/QA signing off as it'll at the very least tell me they acknowledge the documents exist and that they have a general idea of its contents.
    – RioC
    May 10 '17 at 22:36
5

If your colleagues are anything like the ones I had in my previous work, they are likely to be adverse to read anything that is longer than a paragraph (maybe two) at the time.

I would recommend splitting your documentation in very small parts and to provide it as a wiki or something that could provide an internal search engine.

I see two main advantages to this: you can write up the documentation as they ask you questions and then you can always just provide the link to the subpart they ask about. Hopefully, they would then pick up from there and read the rest of the protocol.

In general, provide the information in a written format - even if it is a powerpoint, as you can always reference it later.

You can then answer any later repetitive request as their question being quite important you did document it previously and they can found it in that powerpoint from the slide XX.

Improve this answer
2
  • 2
    +1 for suggesting a wiki. That way (hopefully!) when Underling #4 asks Lead what to do, the answer will be "oh, it's on the wiki page" instead of "oh, RioC has that doc, email him".
    – user812786
    May 8 '17 at 13:41
  • @whrrgarbl Yes, a wiki would be the best. Though you can't always implement one. One way to overcome this is to have a shared folder (or even a google drive folder) with a main 'menu' file where other documentations can be referenced. Not ideal, but can do the trick.
    – Mitra
    May 10 '17 at 9:40
4

Clean up your communication. In scientific texts people would tell you to cite/reference your sources correctly. It also works in this case.

So a cleaned communication from you example could go like this:

Me: Going forward, project X will need to process their numbers using method Y. I've attached ProjectXNumbers.pdf (the exact filename) with a step-by-step guide.

Lead: How do we process numbers for project X?

Me: Quote (use forwarding from your original mail, it has timestamps and all you need): Going forward, project X will need to process their numbers using method Y. I've attached ProjectXNumbers.pdf (the exact filename) with a step-by-step guide. Do you need me to send you ProjectXNumbers.pdf again, or do you have it available?

Lead: So use Method Z?

Well, this should not have happened at that point. In the worst case, re-send them the full original mail. Or set up a meeting/phonecall to clear things up.

Improve this answer
3
  • 2
    Also make sure there is a way they can get ProjectXNumbers.pdf some other way than emailing you. Eg a wiki. Then your emails can be reduced to a link to the wiki page. Eventually reduce your emails to a link to the wiki front page (which will have a search box on it). Eventually eventually, stop replying.
    – AakashM
    May 8 '17 at 11:04
  • I would say you cannot stop replying. Anything that goes wrong "because Person X didn't answer my questions" can easily be blamed on Person X, even if the question should have long been answered. Stopping to reply can only be a valid course if there is a standard for the communication and probably some kind of warning about it.
    – skymningen
    May 8 '17 at 11:08
  • Sure, it's the last phase of a protracted process, and you wouldn't go straight to not answering. But consider this, what happens when OP is on vacation? For two weeks emails go answered, and yet the world keeps turning. Put the processes in place now, and not-needing-to-answer is definitely reachable.
    – AakashM
    May 8 '17 at 11:11
1

With all this in mind, is there anything I can really do to fix this apathy I'm seeing?

You probably cannot fix apathy. But with your management's permission, you may be able to enforce standards.

Talk to management about the need for standards and ask for permission to be the "gatekeeper". Then inform the project leads that they must pass a review of their code before it can be promoted to production.

Set up trainings and documentation so that they are adequately prepared, then start the new process.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .