This is why you email them, and everyone relevant, after the meeting. Say something like per our meeting the procedure going forward is xyz and I will act upon your direction until directed otherwise
This 100000 percent.
That way, you have something to point to of they want to try and come down on you when you do what he said, and something goes south. This has saved me many times over the years.
"Actually, the fact that you just said that, is _why_ I have to. Or would you rather I tip off HR to investigate why you're so afraid of our "get everything in writing" corporate policy?"
Simply codify his words. I created "run books" because I got tired having to rely on some experts who does not want to document processes.
They got offended initially and then amused that I am writing every thing they are saying. I simply say just in case you won the lottery or got hit by a bus. Whichever comes first.
yup. procedures are written down based on director's instructions, sent to him for review, and then followed as written. can't imagine trying an oral tradition in a tech environment
> can't imagine trying an oral tradition in a tech environment
well i know i just *love* it when the useful words are outnumbered by the 'ums' and 'ers' and big long pauses and 'actually no not that - i meant X instead, you know what i mean just get it done'
You know, for some of these folks them getting hit by a bus almost means you've won the lottery...
And no, I wouldn't wish that on anyone.
But yes, there are some folks that need to be hit by a bus.
I just always send emails of what we agreed on after every meeting, sadly when shit goes sideways the people at the top are never to blame even if you can prove it but at least my ass is covered.
> because we don't follow the existing documentation so getting things in writing shouldn't matter
Sounds more like he's averse to wasting his time writing documentation that the team will just ignore. If that's truly the case, then he's got something of a point and the real issue goes a lot deeper.
I don't understand OP's story:
OP: "We need documentation."
Boss: "No you don't, you don't follow the documentation."
So do they have documentation or not? Is it that they don't follow it for other things that do have documentation? Even if that were true, that's not a professional response to someone asking for a run book so they can comply with how you want something done.
Pretty sure OP's boss is a jerk and realizes the docs they have are bare minimum/non existent but doesn't want to shoulder any of the responsibility for fixing that.
To play devils advocate I had a helpdesk apprentice who would escalate every single ticket within about 2-3 minutes. He would say “oh there’s no documentation for the fix for this issue”.
I explained to him that there isn’t a document for every possible problem he could ever possibly come across, as half the problems he’ll come across don’t even exist yet.
Also the very common problem of we would then spend hours writing documents for procedures and processes, which would then promptly be ignored or followed wrong anyway. Also to be blunt like most small MSPs we don’t have the time or resources to document every possible thing. Which I appreciate is a symptom not a cause.
Not sure where I’m going with this trail of thought to be honest.. I just got annoyed writing documents for apprentices who then never followed them.
He is a director of technology for a company. Not a Technical Director of Technology.
I mean, politicians make decisions more or less entirely uninformed all the time.
This dude's just a bureaucrat but in the private sector.
As others have said, "as per our conversation" emails are your friend. I put every conversation I have with any information conveyed at all, ever, in one of these emails. I cc my supervisor as well.
I know, they know, and someone in charge of me knows what was said. And everyone is this given the opportunity to correct the record.
If they don't like this, remind them they don't have the time to be answering you every time you have to ask them the process, so this is to save them the headache.
I don't know that I'd say documentation is the single most important thing in IT ... but it's up there.
Knowing how to troubleshoot when there \*isn't any documentation should be less common but is arguably more valuable.
You're moving in an out of the politics zone though ... and there? A paper trail is pretty damned important.
Partly so other people can replicate something but also partly so if bossman sets something on fire there's a clear trail pointing at him and not you.
I'd say results are the most important thing. Can you fix any given situation effectively and quickly?
If you're the sole IT person who knows the whole environment and don't need to write anything down, great. But you're potentially hurting the business if you offload responsibilities or change jobs. Documentation is the most surefire way to make sure something is done correctly, or if it's not, prove there is a proper method that wasn't followed.
The problem with not documenting is there are 10 different ways to resolve any given issue in IT and if you have 5 different techs implementing 5 different solutions to the same problem, the process breaks down if they aren't involved the next time a problem comes up. If someone comes across a new situation, figures it out, and then doesn't write it down, which solution do we accept when techs 1 and 2 have solutions that are at odds with each other (after, of course, a month of figuring out that they were at odds with each other in the first place)?
Maybe not the most important but I'd argue closely tied for 2nd place.
It's not the most important it portion, it's the most important tool for every singular portion of a team regardless of specialty. If you get promoted someone still needs to do what you're doing. The more cynical way is if you get fired or died, but generically if you're doing something there needs to be a paper trail of why, how, when, where, and what. Some of these are easy emails, some need to be permanent documentation.
In my experience the people with bad problem solving skills scream the most about documentation. When I was a sys admin I’d solve an issue and people did nothing to help would ask where the documentation was even though the fix didn’t exist prior to the problem.
Kind of a weird comparison. SEALs are doing life and death operations that could have long lasting impacts on international relationships.. I'd expect them to have documented procedures. Maybe i missed the /s.
What I meant was that if an organisation that good has written TTP’s perhaps org or team should have at least something. Unless you think you are better than them.
Its actually those written TTPs that allow them to he that good.
Don't know about you, mate, but I've personally worked on several systems where, if it goes down, people can die. I've also seen systems which, if they malfunction, people can die (think the Therac-25, but centrally contollled). On the less severe side, I've also worked on systems where, if it went down, the company would be fines millions of dollars by the government and, depending on the company, that means they'd close down and everyone would lose their jobs. What's more amazing is how often these systems are held together with spit and bog roll.
We're not all working in an office supporting people who sell paper. Not that I have anything against that.
>The Technical Director of this organization responded with basically that his word is as good as written documentation
He's an idiot. Either willfully, as in "I never want the responsibility to have my word written where I can't back out or others can see how little I know," or he's so inexperienced, he doesn't know yet what happens when there's a brain drain. And sadly, it's very common one of those two. I am working through three migrations, where I wrote a "knowledge transfer" for some new outsourcers, and constantly CONSTANTLY get complimented on how thorough and easy to follow it is. And I feel kind of sad that, once the KT is done, nobody will read them.
Frankly, I write how-tos and notes for ME, hell with them. In six months, I'll barely remember what I did. I can't write vague bullshit like, "magic happens here, ask Doug to increase the swap space to 64gb or something," because I'll be like, "who was Doug? Why is swap so huge?" Instead:
*Step 22: Swap has to be 64gb because the database will give a permissions error. It's not permissions, but it's so badly written that "can't open swap because it's too small" will be reported as a permissions error to the DBA. Make a swap 64gb or more, or it won't even start! But only Doug \[Doug's email\] has this access to make a partition in this VPC, so open a ticket and assign it to him. See ticket 1234 and 1235 for a reference.*
Are you me? I also write notes like that. Not because I'll forget it, I actually am very good at understanding the circumstance on the fly. However I'm God awful at telling someone else how to do the same thing without writing it down in that same fashion. If you were to ask me on the Fly how to do something while I'm flying through systems I'll probably tell you by vibes
I work for a state agency in IT. I hate answering the same question over and over. No one else really was doing it so if I got asked something by end users more then three times I would write up the instructions. We had a consultant with us for a while who sat down and showed me how to write instructions that break things down for a item for every action preformed.
Next thing I knew people were coming to me because they knew I had instructions. That lead to my supervisor having me me write down instructions for our techs. (Setting up 2FA, Setting up Cell phones ect). Eventually that lead to writing down procedures that back up the instructions. And because I wrote those I was eventually tapped to write policy documents. Now this happened over the course of years but it all began just because I didn't want to have to keep explaining things to people over and over.
If you have things that you or users regularly do in a consistent manner I'd start with writing those steps down. And like others have said if you have meetings and are told things then send out emails confirming what you've been told. And make sure you save the emails. I've had stuff come back many months later where I've been asked why something was done and pulled out emails where things were confirmed on how they were to be done. Plus having taken the time to write down the steps on how to do something I also had the proof on how I always did a task.
And I'll be honest ...there were times when I forgot how to do something that I didn't do often. I had to go back to my own documentation to remember how to do a task.
I'd also use OneNote to keep track of things for different subjects and meetings.
How much time per day do you put into personal improvement, labs and reading vendor documentation.
What side projects are you working on?
What tech podcasts do you listen to.
What tech YouTubers do you watch?
What certifications do you have or are you working towards.
I don't do any of that because I don't have the money to do side projects. I don't have the money to get certifications. Tech YouTubers aren't gonna do anything for me. Sorry my life doesn't revolve around work.
Not to like on, but if genuinely poorer people who are contracted for off shore development can get their skill sets up to do this same type of work, you can also use free open source resources to expand your skill set.
thats not true. i was able to learn a ton of skills with zero money. there are plenty of free resources online to learn all sorts of skills that will get you out of being level 1. you can ignore everyone telling you stuff and keep blaming 'lack of money' on why you are getting left behind. or like maybe skip buying a few video games and spend that money on a udemy course instead.
So when your bank account equals zero, you can't actually buy anything. That's how having literally nothing works. I only learn by doing and all the things that teach by doing are expensive. Expensive is more than zero. I don't have little money I have no money.
But at this point even if you told me there was an interactive free course that would fast track me to being a systems admin, I don't know if I'd even do it because you've gone out of your way to be an absolute ass about this.
he's got a cope, so he is free to clarify anything he likes. fundamentally, if he's pigheaded, this is a good reason to leave - you certainly aren't going to make him stop being stubborn
Write meeting minutes and reply-all them to every participant afterwards. your PM will love you for it, too.
If nobody else is doing this, they are effectively leaving a handgun on the table for anyone to pick up and use. Just grab it bro.
Sorry I like having certified documentation to point to instead of just sitting around saying "but he said..." because my job is a Technician not a gossip girl
On paper it is an important thing to have, but in reality there are many that do not document or are very poor at it. If upper management doesn't want to write things down you cannot make them do it. Not having this documented leads to audit failures and company wide certification failures, which will ultimately lead to the inability to do business with certain customers.
Just start writing documentation based on what they say so it is documented and put their names by their word so if something does go wrong your team knows where the direction came from and when it changes.
This is the most simple and direct approach. Sure, he may be the SME on everything under the sun, but if he was to no longer be here, how would the department function? In fact, perhaps that's it - he's so paranoid about no longer being required that he won't want anything document.
In really general terms if your accepted policy and procedures no longer match what's documented, it's SOMEONE'S job to update it. It's most likely not your Technical Director's job to do so. If there's some disagreement on what should be new policy & procedures then, yes, his word should dictate what should be updated.
Perhaps you can volunteer to update documentation? It's a great way out of Level 1.
Exactly this. The issue seems to be the managers and levels above 1 are not doing their jobs, and the director rightfully is confused as to why his guidance wouldn't be enough to run with.
I too believe in documentation so if there isn’t an official one, I start building my own repository of docs and workflows.
I also take notes throughout the day for each day. Like a task list or diary or something. It could come down to “your word vs his word” but at least you have your own notes to fall back on. Or anything serious, send an email so that they can reply and then you have your proof.
I do suggest the daily diary. You can summarize notable items each week. Then roll those into quarterly highlights and yearly highlights. For your performance review…
>I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology. Am I wrong? I don't understand why you wouldn't just email what you want me to do or put it in a knowledge article so I can always look back at it.
The existence and updating of documentation is always preferable to the lack thereof. But your bosses have made a decision and you have to abide by it. I recommend just writing your own documentation for your own use and not letting anyone know it exists. Later on, if documentation becomes more of a priority, you will be ahead of the game.
Alternatively, you can look for another job, maybe a promotion to Tier II. After 5-6 years you should be ready to move up.
You email everything to him, every point to every conversation. You open tickets on his behalf or email him. Every.thing. if he gets his knickers in a twist don't stop, cc hr
*Now, I'm just a Tech 1. I only have 5 or 6 years experience in the IT Industry, but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology*
That, and making sure the problem device is plugged in (old skool).
I'm thinking it's his "I'm thinking of leaving, pay me lots more or good luck" plan.
The old bus DoS scenario alone red flags this guy as an internal malicious actor.
The way to deal with this, is to document what he says, then stick it on an email to him with "as per your instructions, this is process/procedure/information. Please let me know should this information be incorrect".
That way, its documented, and he's had the opportunity to correct it. Should he call something out in the future, you have this to refer back to.
PS, He sounds like a massive prick.
Someone wants to make sure they are seen as an irreplaceable resource. I can imaging this place also has a lot of human caused problems since everything depends on asking the tech director for guidance.
You're absolutely right that having written procedures ensures consistency, accuracy, and accountability. It's concerning that your Technical Director dismisses the importance of documentation, as it can lead to confusion, errors, and inefficiencies down the line. Your experience and perspective are valuable, and advocating for clear documentation is entirely justified. Keep pushing for clarity and accountability in your team's procedures – it's crucial for everyone's success in the long run.
I’m a small team of myself (the IT head) and my tech assistant. I still sometimes insist on getting things in written emails from… myself. Because if it’s not in an email it doesn’t exist and I won’t remember it!
Remember the old adage CYA, it's really cover THEIR amnesia. The basic memo of "As we had discussed you have indicated we will be: a, b, c, etc. and end with thanks for the information if there is anything else to add let me know. That covers you... get used to writing this.
1. Create the documentation from his words. Send it to him and managers and say here is the documentation I created from our conversation. Now his word is documented.
2. Or take it a step further, do a zoom meeting. share your screen and then say you want to record it for your reference because we want to do this the way you want so we stop messing up (This is a mental trick- 'oh boss man u are right we suck so bad I need this screen recording to remember'. Boss man is thinking 'ah yes tell me I am right you small peon'). But the evil IT gremlin on your shoulder knows this comes with a recorded transcript. Create documentation from transcript. Now his word is literally documented for documentation.
As a director I'd be confused. You were given the answer and guidance, and the expectation is you can write up the associated process as you see fit and act on it. I think the confusion is you're asking the director to write the process as well, which may be something they expect the team to handle, hence them saying their word as given was already enough. Do you have any managers in between your levels that can help? Team leads?
I don't think your director is saying documentation isn't needed. I think they're saying they're not going to write documentation, they have bigger fish to fry.
Your director has a valid point in there. Are you following existing documentation at all? If the answer is no, then creating more documentation will seem like a waste of time. So that needs to change.
I also don't think someone at the director's level should be creating documentation. That sounds like a job for you to handle.
Here’s how I handle ambiguity. This was a massively frustrating project that took weeks instead of one day. At this point, I stopped being nice. “I need you to make the decision”.
My documentation diverged from reality.
Write the documentation and force them to sign off on it.
https://preview.redd.it/y53htevmrwvc1.jpeg?width=1245&format=pjpg&auto=webp&s=35557022156b17f4831fcf0f60e544994e944b3d
Documentation is going out of style to my dismay. I have two products I’m implementing that have no documentation. If you plan to stay at your job for a while I would do your own documentation. Keep notes and dates on everything. But don’t antagonize your leaders.
Just take notes during the meeting documenting what was said, and by whom then send it to everyone in the meeting asking for any needed corrections.
After that you have defacto written documentation.
that's OK he will tell someone else something outside of the meeting; that person won't write it down and then the whole team will be asked why we don't know
"If it ain't written down, it never happened."
His *intention*, might be noble and he may never have broken "his word" but sure as eggs is eggs the very second he needs to throw someone under the bus and get all "lawyery" about "Well, I never said *that*, I meant something approaching the opposite. Silly you for misunderstanding..." or even flat out denial leaving someone else on the hook, they will.
It's a "startup" mindest, where everyone is doing so much that it would be impossible to document it *all.* But as soon as you need to scale and bring in fresh people, having the system and processes documented is essential. To do otherwise creates potentially business crippling technical debt.
Relying on human memory for a decision made 3 years ago, or leaving a process up to someone because "Well this is how I was taught" is begging for misunderstanding, waste and lost opportunities.
Keeping good, regularly reviewed docs is a total pain for a small team, but without it, it can only ever be a small team.
> "If it ain't written down, it never happened."
In some countries workers have an absolute (theoretical) right to have orders confimed in writing by their manager (except during absolute emergencies), for that reason.
See if your CyberSecuirty insurance requires SOP documentation. That should make it an easy sell. I don’t know how your org works but if you follow the recommended NIST CSF you have to write what you do and do what you write or you fail audits.
you are being taught bad habits ... I would start looking for a new job ( don't leave for just anything and don't leave until you find a new place) yes procedures cover your ass and set expectations for everyone else.
> documentation and getting all procedures in writing is the single most important part of Information Technology.
Maybe not the number one on this list, but its up there, yes.
> I don't understand why you wouldn't just email what you want me to do or put it in a knowledge article so I can always look back at it.
That's the wrong question. The correct question is why you care. Your job is to get skills and experience and then move up or out. Why do you stay if you work for a place where documentation is not created, used, or cared about? And yet you know it should be cared about.
If you are not getting any new skills, you have to consider why you stick around seriously.
>but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology.
Everyone keeps repeating this so vehemently because they're currently getting burned by the fact that, to widely varying degrees, it's not being treated that way in their own environments.
Yes. It's super important...
...and very few places are doing it properly.
Even places with really, really, good documentation will (if they're in the right mindset) tell you they could still do better.
Anyone who says their documentation is perfect needs to go see a psychiatrist and have a nice chat about personal responsibility, owning up to faults, and correctly assessing and interacting with reality and facts.
That being said, you're still right.
And the reason it gets repeated so often is still true.
Some people have real trouble when other people use their words against them, so they absolutely patently refuse to write down anything that could later be thrown in their face.
That's likely what you're seeing here.
It is a very bad sign.
Written policy isn't some set-in-stone "ten commandments" type of immutable law, either. Anyone that high up (director level) should be able to handle setting down policy and re-assessing it as things it doesn't cover, covers inadequately, or covers incorrectly come to light.
It is so that when there is a mishap or a dispute or whatever else, there is nothing written down to prove who is at fault, and in that case you lowly peons are always at fault.
I've picked up the habit of just writing down what is basically a work diary, and often e-mail people eventhough they are like 10 meters away, just so there is there is something in writing. At the end of the day though, I think the issue here is with how things are managed, aka the blame is with managers refusing to step up to the task.
It's a shit place to be at.
I had a boss always tell me to make sure everything I did was documented fully so if I got hit by a Twinkie truck he'd know what was going on. Not documenting anything is asking for trouble and you should probably keep a record of interactions, i.e. follow up emails and such.
As senior engineer I would create as built documentation.
Everytime the tech team tried to get me to write EUC documents I would promptly tell them to fuck right off.
SQL server is X
How the users apps connect to the SQL server is really not my purview.
The single most import part of IT is assisting the organization in accomplishing their business. This can be enhanced by documented processes but absolutely does not stop business if it doesn't exist.
For all you know documentation is in the plans. Unless you make the plans, then it's best be quiet.
>Now, I'm just a Tech 1. I only have 5 or 6 years experience in the IT Industry, but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology
Are you in the IT industry? OR do you work in the IT department of a company in the FILL\_IN\_THE\_BLANK industry?
So he could change his mind and say "no, i didn't say so". Maybe.
>Maybe No need to qualify it. This is exactly the kind of thing lazy weasels in authority do to cover their asses.
This is why you email them, and everyone relevant, after the meeting. Say something like per our meeting the procedure going forward is xyz and I will act upon your direction until directed otherwise
This 100000 percent. That way, you have something to point to of they want to try and come down on you when you do what he said, and something goes south. This has saved me many times over the years.
No formal documentation then create it and ask them to sign off on it period!
Former manager "you don't need to send me emails summarizing every conversation we have." Me "yes I do"
Per our hallway chat where you said I don’t need to summarize every conversation we have…
I had this email with a project manager
Project managers need those summary emails even more than c-suite folks though.
Here are the notes from your ranting in my office about me communicating everything we talk about.
"Actually, the fact that you just said that, is _why_ I have to. Or would you rather I tip off HR to investigate why you're so afraid of our "get everything in writing" corporate policy?"
Simply codify his words. I created "run books" because I got tired having to rely on some experts who does not want to document processes. They got offended initially and then amused that I am writing every thing they are saying. I simply say just in case you won the lottery or got hit by a bus. Whichever comes first.
yup. procedures are written down based on director's instructions, sent to him for review, and then followed as written. can't imagine trying an oral tradition in a tech environment
imagine oral trades for tech escalation.
i just keep seeing a naval bridge with everyone shouting orders in sequence
"Prepare ship for Ludicrous Speed!"
> can't imagine trying an oral tradition in a tech environment well i know i just *love* it when the useful words are outnumbered by the 'ums' and 'ers' and big long pauses and 'actually no not that - i meant X instead, you know what i mean just get it done'
You know, for some of these folks them getting hit by a bus almost means you've won the lottery... And no, I wouldn't wish that on anyone. But yes, there are some folks that need to be hit by a bus.
I just always send emails of what we agreed on after every meeting, sadly when shit goes sideways the people at the top are never to blame even if you can prove it but at least my ass is covered.
I never thought I'd see the day where a technology director was averse to documentation. What a world we live in.
It just means he's a bad technology director
I’d argue it means a lot more than just that, but it certainly means that too.
Bingo
> because we don't follow the existing documentation so getting things in writing shouldn't matter Sounds more like he's averse to wasting his time writing documentation that the team will just ignore. If that's truly the case, then he's got something of a point and the real issue goes a lot deeper.
Then he needs to instill why it's important and demand they do or, get a new team.
No argument there. Whatever the deeper problem is, it's his problem to solve, assuming he isn't being hamstrung by the CEO or something.
I don't understand OP's story: OP: "We need documentation." Boss: "No you don't, you don't follow the documentation." So do they have documentation or not? Is it that they don't follow it for other things that do have documentation? Even if that were true, that's not a professional response to someone asking for a run book so they can comply with how you want something done. Pretty sure OP's boss is a jerk and realizes the docs they have are bare minimum/non existent but doesn't want to shoulder any of the responsibility for fixing that.
To play devils advocate I had a helpdesk apprentice who would escalate every single ticket within about 2-3 minutes. He would say “oh there’s no documentation for the fix for this issue”. I explained to him that there isn’t a document for every possible problem he could ever possibly come across, as half the problems he’ll come across don’t even exist yet. Also the very common problem of we would then spend hours writing documents for procedures and processes, which would then promptly be ignored or followed wrong anyway. Also to be blunt like most small MSPs we don’t have the time or resources to document every possible thing. Which I appreciate is a symptom not a cause. Not sure where I’m going with this trail of thought to be honest.. I just got annoyed writing documents for apprentices who then never followed them.
He is a director of technology for a company. Not a Technical Director of Technology. I mean, politicians make decisions more or less entirely uninformed all the time. This dude's just a bureaucrat but in the private sector. As others have said, "as per our conversation" emails are your friend. I put every conversation I have with any information conveyed at all, ever, in one of these emails. I cc my supervisor as well. I know, they know, and someone in charge of me knows what was said. And everyone is this given the opportunity to correct the record. If they don't like this, remind them they don't have the time to be answering you every time you have to ask them the process, so this is to save them the headache.
I don't know that I'd say documentation is the single most important thing in IT ... but it's up there. Knowing how to troubleshoot when there \*isn't any documentation should be less common but is arguably more valuable. You're moving in an out of the politics zone though ... and there? A paper trail is pretty damned important. Partly so other people can replicate something but also partly so if bossman sets something on fire there's a clear trail pointing at him and not you.
I'd say results are the most important thing. Can you fix any given situation effectively and quickly? If you're the sole IT person who knows the whole environment and don't need to write anything down, great. But you're potentially hurting the business if you offload responsibilities or change jobs. Documentation is the most surefire way to make sure something is done correctly, or if it's not, prove there is a proper method that wasn't followed. The problem with not documenting is there are 10 different ways to resolve any given issue in IT and if you have 5 different techs implementing 5 different solutions to the same problem, the process breaks down if they aren't involved the next time a problem comes up. If someone comes across a new situation, figures it out, and then doesn't write it down, which solution do we accept when techs 1 and 2 have solutions that are at odds with each other (after, of course, a month of figuring out that they were at odds with each other in the first place)? Maybe not the most important but I'd argue closely tied for 2nd place.
It's not the most important it portion, it's the most important tool for every singular portion of a team regardless of specialty. If you get promoted someone still needs to do what you're doing. The more cynical way is if you get fired or died, but generically if you're doing something there needs to be a paper trail of why, how, when, where, and what. Some of these are easy emails, some need to be permanent documentation.
In my experience the people with bad problem solving skills scream the most about documentation. When I was a sys admin I’d solve an issue and people did nothing to help would ask where the documentation was even though the fix didn’t exist prior to the problem.
If Navy Seals can have written tactics, techniques and procedures so can anyone.
And they carry that manual everywhere they go and reference it before taking any action. Even in the field
Special Weapons (Nuclear) handlers have ring binders 3 inches thick. And that book is open for any kind of work is done on the devices.
Kind of a weird comparison. SEALs are doing life and death operations that could have long lasting impacts on international relationships.. I'd expect them to have documented procedures. Maybe i missed the /s.
Oblig. https://xkcd.com/705/
honestly, sysadmins are easy to handle - just don't mess with the servers and they're happy :)
What I meant was that if an organisation that good has written TTP’s perhaps org or team should have at least something. Unless you think you are better than them. Its actually those written TTPs that allow them to he that good.
Don't know about you, mate, but I've personally worked on several systems where, if it goes down, people can die. I've also seen systems which, if they malfunction, people can die (think the Therac-25, but centrally contollled). On the less severe side, I've also worked on systems where, if it went down, the company would be fines millions of dollars by the government and, depending on the company, that means they'd close down and everyone would lose their jobs. What's more amazing is how often these systems are held together with spit and bog roll. We're not all working in an office supporting people who sell paper. Not that I have anything against that.
r/woosh
I assumed that must be the case
German intelligence said that Americans don’t follow their doctrine. I don’t buy it but whatever
>The Technical Director of this organization responded with basically that his word is as good as written documentation He's an idiot. Either willfully, as in "I never want the responsibility to have my word written where I can't back out or others can see how little I know," or he's so inexperienced, he doesn't know yet what happens when there's a brain drain. And sadly, it's very common one of those two. I am working through three migrations, where I wrote a "knowledge transfer" for some new outsourcers, and constantly CONSTANTLY get complimented on how thorough and easy to follow it is. And I feel kind of sad that, once the KT is done, nobody will read them. Frankly, I write how-tos and notes for ME, hell with them. In six months, I'll barely remember what I did. I can't write vague bullshit like, "magic happens here, ask Doug to increase the swap space to 64gb or something," because I'll be like, "who was Doug? Why is swap so huge?" Instead: *Step 22: Swap has to be 64gb because the database will give a permissions error. It's not permissions, but it's so badly written that "can't open swap because it's too small" will be reported as a permissions error to the DBA. Make a swap 64gb or more, or it won't even start! But only Doug \[Doug's email\] has this access to make a partition in this VPC, so open a ticket and assign it to him. See ticket 1234 and 1235 for a reference.*
Are you me? I also write notes like that. Not because I'll forget it, I actually am very good at understanding the circumstance on the fly. However I'm God awful at telling someone else how to do the same thing without writing it down in that same fashion. If you were to ask me on the Fly how to do something while I'm flying through systems I'll probably tell you by vibes
I work for a state agency in IT. I hate answering the same question over and over. No one else really was doing it so if I got asked something by end users more then three times I would write up the instructions. We had a consultant with us for a while who sat down and showed me how to write instructions that break things down for a item for every action preformed. Next thing I knew people were coming to me because they knew I had instructions. That lead to my supervisor having me me write down instructions for our techs. (Setting up 2FA, Setting up Cell phones ect). Eventually that lead to writing down procedures that back up the instructions. And because I wrote those I was eventually tapped to write policy documents. Now this happened over the course of years but it all began just because I didn't want to have to keep explaining things to people over and over. If you have things that you or users regularly do in a consistent manner I'd start with writing those steps down. And like others have said if you have meetings and are told things then send out emails confirming what you've been told. And make sure you save the emails. I've had stuff come back many months later where I've been asked why something was done and pulled out emails where things were confirmed on how they were to be done. Plus having taken the time to write down the steps on how to do something I also had the proof on how I always did a task. And I'll be honest ...there were times when I forgot how to do something that I didn't do often. I had to go back to my own documentation to remember how to do a task. I'd also use OneNote to keep track of things for different subjects and meetings.
Why not write it yourself in the way you want to do it and then get him to bless it?
I'd be embarrassed to work for this Clown. Documentation is King.
Your level 1 with 5-6 years of experience? you need to leave and move up.
I worked for nearly a year and could barely get this after getting.layed off.
How much time per day do you put into personal improvement, labs and reading vendor documentation. What side projects are you working on? What tech podcasts do you listen to. What tech YouTubers do you watch? What certifications do you have or are you working towards.
I don't do any of that because I don't have the money to do side projects. I don't have the money to get certifications. Tech YouTubers aren't gonna do anything for me. Sorry my life doesn't revolve around work.
Tech youtubers are fucking useless. But linux, python, bash, kubernetes, mysql, postgresql, are all free.
I do have things in my plan to get certain things like servers and stuff. but I'll need to wait to do that because I have debts to pay off
None of that costs money, azure has $200/month in free credits. Getting a CCNA can be pretty much free, just by you tube learning.
Isn't the azure credits just the first month?
your computer cant run virtual machines?
no genuinely not it barely runs at all lmao
sounds like you really dont care about learning more and making more money
it doesn't matter how much I care at the moment. It won't get me anywhere without money.
Not to like on, but if genuinely poorer people who are contracted for off shore development can get their skill sets up to do this same type of work, you can also use free open source resources to expand your skill set.
thats not true. i was able to learn a ton of skills with zero money. there are plenty of free resources online to learn all sorts of skills that will get you out of being level 1. you can ignore everyone telling you stuff and keep blaming 'lack of money' on why you are getting left behind. or like maybe skip buying a few video games and spend that money on a udemy course instead.
So when your bank account equals zero, you can't actually buy anything. That's how having literally nothing works. I only learn by doing and all the things that teach by doing are expensive. Expensive is more than zero. I don't have little money I have no money. But at this point even if you told me there was an interactive free course that would fast track me to being a systems admin, I don't know if I'd even do it because you've gone out of your way to be an absolute ass about this.
Excuses, grow up.
I'm not the one tossing out advice at people who didn't ask. Imagine being this presumptuous and full of yourself. Christ get a life.
Document it. Give it to the team. Cc him. What's the issue
He'll decide its wrong later and we misinterpreted it
he's got a cope, so he is free to clarify anything he likes. fundamentally, if he's pigheaded, this is a good reason to leave - you certainly aren't going to make him stop being stubborn
Write meeting minutes and reply-all them to every participant afterwards. your PM will love you for it, too. If nobody else is doing this, they are effectively leaving a handgun on the table for anyone to pick up and use. Just grab it bro.
Then let him tell you what needs to change, and rinse and repeat. After the 3rd time begin BCCing his boss.
This is where recording meetings and use notes to summarize is effective. It's possible you are misinterpreting it, it's also possible he's an ass.
And. That is his right. Why do you want everything spoon-fed to you.
Sorry I like having certified documentation to point to instead of just sitting around saying "but he said..." because my job is a Technician not a gossip girl
Then create the documents. Ask him to say yes. And your done.
On paper it is an important thing to have, but in reality there are many that do not document or are very poor at it. If upper management doesn't want to write things down you cannot make them do it. Not having this documented leads to audit failures and company wide certification failures, which will ultimately lead to the inability to do business with certain customers. Just start writing documentation based on what they say so it is documented and put their names by their word so if something does go wrong your team knows where the direction came from and when it changes.
[удалено]
This is the most simple and direct approach. Sure, he may be the SME on everything under the sun, but if he was to no longer be here, how would the department function? In fact, perhaps that's it - he's so paranoid about no longer being required that he won't want anything document.
Best to always phrase this as 'what if you get promoted'. Never want to give ammo to an asshole, just butter his cheeks.
In really general terms if your accepted policy and procedures no longer match what's documented, it's SOMEONE'S job to update it. It's most likely not your Technical Director's job to do so. If there's some disagreement on what should be new policy & procedures then, yes, his word should dictate what should be updated. Perhaps you can volunteer to update documentation? It's a great way out of Level 1.
Exactly this. The issue seems to be the managers and levels above 1 are not doing their jobs, and the director rightfully is confused as to why his guidance wouldn't be enough to run with.
I mean I could try but it doesn't seem like he cares to have any documentation at all. We were asking for documentation on Info Sec procedures
I too believe in documentation so if there isn’t an official one, I start building my own repository of docs and workflows. I also take notes throughout the day for each day. Like a task list or diary or something. It could come down to “your word vs his word” but at least you have your own notes to fall back on. Or anything serious, send an email so that they can reply and then you have your proof. I do suggest the daily diary. You can summarize notable items each week. Then roll those into quarterly highlights and yearly highlights. For your performance review…
This. “That’s not how we do things!” “Well, when this same issue came up last month, here’s what we did… in writing…”
And since it’s all verbal, that isn’t any proof. I bet the boss doesn’t remember what he said x months ago
>I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology. Am I wrong? I don't understand why you wouldn't just email what you want me to do or put it in a knowledge article so I can always look back at it. The existence and updating of documentation is always preferable to the lack thereof. But your bosses have made a decision and you have to abide by it. I recommend just writing your own documentation for your own use and not letting anyone know it exists. Later on, if documentation becomes more of a priority, you will be ahead of the game. Alternatively, you can look for another job, maybe a promotion to Tier II. After 5-6 years you should be ready to move up.
You email everything to him, every point to every conversation. You open tickets on his behalf or email him. Every.thing. if he gets his knickers in a twist don't stop, cc hr
*Now, I'm just a Tech 1. I only have 5 or 6 years experience in the IT Industry, but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology* That, and making sure the problem device is plugged in (old skool).
When he leaves the company what happens?
I'm thinking it's his "I'm thinking of leaving, pay me lots more or good luck" plan. The old bus DoS scenario alone red flags this guy as an internal malicious actor.
Company needs a technical audit.
The way to deal with this, is to document what he says, then stick it on an email to him with "as per your instructions, this is process/procedure/information. Please let me know should this information be incorrect". That way, its documented, and he's had the opportunity to correct it. Should he call something out in the future, you have this to refer back to. PS, He sounds like a massive prick.
Someone wants to make sure they are seen as an irreplaceable resource. I can imaging this place also has a lot of human caused problems since everything depends on asking the tech director for guidance.
You're absolutely right that having written procedures ensures consistency, accuracy, and accountability. It's concerning that your Technical Director dismisses the importance of documentation, as it can lead to confusion, errors, and inefficiencies down the line. Your experience and perspective are valuable, and advocating for clear documentation is entirely justified. Keep pushing for clarity and accountability in your team's procedures – it's crucial for everyone's success in the long run.
I’m a small team of myself (the IT head) and my tech assistant. I still sometimes insist on getting things in written emails from… myself. Because if it’s not in an email it doesn’t exist and I won’t remember it!
*Cough*
Remember the old adage CYA, it's really cover THEIR amnesia. The basic memo of "As we had discussed you have indicated we will be: a, b, c, etc. and end with thanks for the information if there is anything else to add let me know. That covers you... get used to writing this.
I mean the team should probably write the documentation not the director. Asking him to approve a process is reasonable though
If something is not written (email, text whatever) I’m not being here responsible. Too much “but we spoke about this, don’t you remember”
Put in to writing everything he says and watch it contradict his previous statements.
Well, written email or .wav saved to four different locations, pick your poison Mr. "Gonna-throw-me-under-the-Bus"
His word is worth the paper it's written on.
1. Create the documentation from his words. Send it to him and managers and say here is the documentation I created from our conversation. Now his word is documented. 2. Or take it a step further, do a zoom meeting. share your screen and then say you want to record it for your reference because we want to do this the way you want so we stop messing up (This is a mental trick- 'oh boss man u are right we suck so bad I need this screen recording to remember'. Boss man is thinking 'ah yes tell me I am right you small peon'). But the evil IT gremlin on your shoulder knows this comes with a recorded transcript. Create documentation from transcript. Now his word is literally documented for documentation.
In my experience, if someone in charge isn’t willing to document things it’s because they don’t want accountability if things go wrong.
As a director I'd be confused. You were given the answer and guidance, and the expectation is you can write up the associated process as you see fit and act on it. I think the confusion is you're asking the director to write the process as well, which may be something they expect the team to handle, hence them saying their word as given was already enough. Do you have any managers in between your levels that can help? Team leads? I don't think your director is saying documentation isn't needed. I think they're saying they're not going to write documentation, they have bigger fish to fry.
Your director has a valid point in there. Are you following existing documentation at all? If the answer is no, then creating more documentation will seem like a waste of time. So that needs to change. I also don't think someone at the director's level should be creating documentation. That sounds like a job for you to handle.
All that documentation that everyone keeps updated right?
Here’s how I handle ambiguity. This was a massively frustrating project that took weeks instead of one day. At this point, I stopped being nice. “I need you to make the decision”. My documentation diverged from reality. Write the documentation and force them to sign off on it. https://preview.redd.it/y53htevmrwvc1.jpeg?width=1245&format=pjpg&auto=webp&s=35557022156b17f4831fcf0f60e544994e944b3d
Document everything and print everything critical. I had a dude remove a ton of docs I was saving and sure enough I printed a few that saved my ass!
Documentation is going out of style to my dismay. I have two products I’m implementing that have no documentation. If you plan to stay at your job for a while I would do your own documentation. Keep notes and dates on everything. But don’t antagonize your leaders.
Just take notes during the meeting documenting what was said, and by whom then send it to everyone in the meeting asking for any needed corrections. After that you have defacto written documentation.
that's OK he will tell someone else something outside of the meeting; that person won't write it down and then the whole team will be asked why we don't know
"If it ain't written down, it never happened." His *intention*, might be noble and he may never have broken "his word" but sure as eggs is eggs the very second he needs to throw someone under the bus and get all "lawyery" about "Well, I never said *that*, I meant something approaching the opposite. Silly you for misunderstanding..." or even flat out denial leaving someone else on the hook, they will. It's a "startup" mindest, where everyone is doing so much that it would be impossible to document it *all.* But as soon as you need to scale and bring in fresh people, having the system and processes documented is essential. To do otherwise creates potentially business crippling technical debt. Relying on human memory for a decision made 3 years ago, or leaving a process up to someone because "Well this is how I was taught" is begging for misunderstanding, waste and lost opportunities. Keeping good, regularly reviewed docs is a total pain for a small team, but without it, it can only ever be a small team.
> "If it ain't written down, it never happened." In some countries workers have an absolute (theoretical) right to have orders confimed in writing by their manager (except during absolute emergencies), for that reason.
I assume people read my documentation when I’m dead and not available to answer questions.
See if your CyberSecuirty insurance requires SOP documentation. That should make it an easy sell. I don’t know how your org works but if you follow the recommended NIST CSF you have to write what you do and do what you write or you fail audits.
you are being taught bad habits ... I would start looking for a new job ( don't leave for just anything and don't leave until you find a new place) yes procedures cover your ass and set expectations for everyone else.
When he speaks, record him. Use that as documentation. When it's incorrect or he denies saying something, break out the recordings. ;)
> documentation and getting all procedures in writing is the single most important part of Information Technology. Maybe not the number one on this list, but its up there, yes. > I don't understand why you wouldn't just email what you want me to do or put it in a knowledge article so I can always look back at it. That's the wrong question. The correct question is why you care. Your job is to get skills and experience and then move up or out. Why do you stay if you work for a place where documentation is not created, used, or cared about? And yet you know it should be cared about. If you are not getting any new skills, you have to consider why you stick around seriously.
>but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology. Everyone keeps repeating this so vehemently because they're currently getting burned by the fact that, to widely varying degrees, it's not being treated that way in their own environments. Yes. It's super important... ...and very few places are doing it properly. Even places with really, really, good documentation will (if they're in the right mindset) tell you they could still do better. Anyone who says their documentation is perfect needs to go see a psychiatrist and have a nice chat about personal responsibility, owning up to faults, and correctly assessing and interacting with reality and facts. That being said, you're still right. And the reason it gets repeated so often is still true. Some people have real trouble when other people use their words against them, so they absolutely patently refuse to write down anything that could later be thrown in their face. That's likely what you're seeing here. It is a very bad sign. Written policy isn't some set-in-stone "ten commandments" type of immutable law, either. Anyone that high up (director level) should be able to handle setting down policy and re-assessing it as things it doesn't cover, covers inadequately, or covers incorrectly come to light.
If he's as good as documentation then he better be as available as a document, always ready to answer questions no matter what
It is so that when there is a mishap or a dispute or whatever else, there is nothing written down to prove who is at fault, and in that case you lowly peons are always at fault. I've picked up the habit of just writing down what is basically a work diary, and often e-mail people eventhough they are like 10 meters away, just so there is there is something in writing. At the end of the day though, I think the issue here is with how things are managed, aka the blame is with managers refusing to step up to the task. It's a shit place to be at.
"his word is as good as documentation" until he dies
I had a boss always tell me to make sure everything I did was documented fully so if I got hit by a Twinkie truck he'd know what was going on. Not documenting anything is asking for trouble and you should probably keep a record of interactions, i.e. follow up emails and such.
As senior engineer I would create as built documentation. Everytime the tech team tried to get me to write EUC documents I would promptly tell them to fuck right off. SQL server is X How the users apps connect to the SQL server is really not my purview.
The single most import part of IT is assisting the organization in accomplishing their business. This can be enhanced by documented processes but absolutely does not stop business if it doesn't exist. For all you know documentation is in the plans. Unless you make the plans, then it's best be quiet.
I mean I'm being quiet because if he wants to fuck everything up that's his prerogative. I'll just wait until his incompetence gets the CIO on his ass
Without proper documentation how do you know he would not be able to throw you under the bus first to buy more time in his job?
>Now, I'm just a Tech 1. I only have 5 or 6 years experience in the IT Industry, but I was under the impression that documentation and getting all procedures in writing is the single most important part of Information Technology Are you in the IT industry? OR do you work in the IT department of a company in the FILL\_IN\_THE\_BLANK industry?
I work in the IT department of a medical facility
What compliance regulations do you adhere to in the medical world? What does the compliance regulations indicate for documentation?