This is the fifth post in our ongoing series: The First 90 Days. When you're coming into a company as the first-ever IT manager, you have to hit the ground running. The work you do in the first 90 days is what sets you up for success for the rest of your career, but it's also a huge challenge. To help, we put together this advice on the process and mindset culled from our team's extensive experience running IT for top Silicon Valley companies.
In the last article in this series, we talked a bit about IT project management and strategies for successfully juggling short-term and long-term work as new tickets pile in everyday. This is super important because there are many things that really matter that are also easy to forget about as you spend your day smacking down emergencies like Bruce Lee working his way through a crowd of kung fu henchmen.
Today we’re going to talk about one of the best examples of that: process documentation. Documentation is easy to overlook, and the dangers of inadequate documentation are insidious and wide-reaching. Many companies don’t realize they have a documentation problem, even as policies aren’t followed, teams miscommunicate, new hires stew in confusion, and things explode whenever anyone goes on vacation.
This isn’t an IT specific-problem, but IT is uniquely susceptible to it. It’s just not likely to feel as urgent as everything else you’re working on, especially if you’re the only person in IT—the most likely scenario for a new IT manager. If the only person paying attention to something is you, and you know what you’re doing, why write it down?
Long-term success in IT is about fireproofing, however—doing the things you can now to keep minor issues from turning into emergencies in the future. And documenting responsibilities, processes, escalation paths, and common response patterns is one of the most important forms of fireproofing you can have.
Document early & often
The time to start documenting things is now, when you’re just getting started. This is because a large part of what you’re doing when you come in as a new IT manager is centralization. You’re taking things that were being done informally by lots of different people across the org and bringing them together in one place. In theory, this is more efficient. But it can also create bottlenecks and single points of failure.
The difference between good centralization and bad centralization is whether you’re centralizing things in a person, or in a process.
If you don’t write anything down, you’re centralizing things in a person: you. If you don’t have time for something, it won’t get done. If you’re sick or on vacation, it won’t get done. If something comes up when you’re unavailable, it will go unaddressed. Since problems in IT tend to snowball, that means more small issues becoming big headaches.
Worst of all, it will be really hard to dig yourself out of this hole. When you do finally get more people in your department to support you, you won’t be able to get them up to speed quickly. You’ll have to split your time between teaching them your idiosyncratic systems for everything and actually doing those things yourself. Extra manpower won’t be the force multiplier it really should be because the lack of documentation will be sitting like an anchor on your collective backs.
But when a task is well thought out, well-documented, and accessible across the org, everything gets better. The rest of the org knows what’s expected of them, so they’re easier support. Minor tasks you used to drop everything to do become things you can delegate, or even things people can do on their own. Since documentation is often a first step toward deep understanding of a problem, it can even help you automate away work entirely!
Best practices for documentation
Hopefully I’ve sold you on the importance of this work. Good! I hope you’re really excited to start documenting things now.
You will need that enthusiasm. Remember it. Hold onto it.
Because no lie: this process is tedious.
The only real answer to becoming a documentation-rich IT department is consistent, steady work of the sort some people call “the slow boring of hard boards.” The main rule is:
Anytime you do a thing, spend at least 15 minutes writing down how you did it.
You probably won’t have 15 minutes to document each thing as it happens. That’s fine! Jot down a quick note to yourself and come back to it later when you do. Schedule a longer period, maybe an hour at the end of each week or a few hours at the end of the month to revisit this quick, ad-hoc documentation.
For each thing, ask yourself: is this something I or someone like me might have to do again? If so, clean up your documentation and make it publically available somewhere. Documentation should be stored in a format that’s easily shared. Ideally, it should be searchable and referenceable without going through you, i.e. stored in a wiki, Dropbox Paper document, Google docs “How to do everything” folder, confluence page, etc.
While you’re documenting a process or procedure, here are some important points to consider:
- What permissions do you need to do this thing? Where are the credentials stored? Who do you need to talk to to get them?
- What are the steps to do the thing?
- Who else needs to be involved?
- How do you communicate what’s happening to the rest of the organization?
- Are there any danger areas/quirks/things that often come up that need to be noted?
- Who else is trained to do this?
- If something goes wrong while you’re doing this, who do you talk to?
How you actually write the documentation is up to you, but you’ll probably find that it’s most useful when it focuses on specific tasks and workflows rather than broad descriptions of different functions. You don’t need to give very much context around each topic—focus on what someone who’s competent but also completely unfamiliar with your systems would need to know to accomplish a task without supervision.
Each company is unique, but at the bare minimum you’ll need to document:
- Your complete vendor lists with contacts for each
- Every app and service your company uses, and how to get credentials for each
- Your company’s procurement process
- The escalation path for common issues
- What to do when you need to patch something
- How to onboard a new employee
- How to offboard a departing employee
- What to do when someone’s laptop breaks
- What to do when the WiFi is down.
Keep your documentation up to date, too! As more processes get documented and there is less new stuff to write down, use the longer documentation periods to instead revisit previous documentation. What has changed?
You’re never really done with documentation, but you’ll know you’re in good shape when you can take a vacation and be reasonably sure that people can handle the foreseen problems without you.
In fact, this is an excellent way to determine what you need to document. Ask yourself: if I were to disappear into the woods for three days with no cell phone reception, what kind of mess would I find when I emerged? What would break, and what wouldn’t get done? What would people be most angry with me about? Start there.
You do want to take a vacation eventually, right? Then start documenting things now, in your first 90 days.
In the next article in this series, we’ll talk about strategies for building visibility for IT in your first months on the job, and why this matters, even for a department that unused to the limelight.