I have been in IT since 1989. Twenty-nine years in the field, twenty-five of them as paid professional engagements. My first computer was a Macintosh SE with dual floppy drives, no hard drive, and 1MB of RAM. I say that not to date myself, but to establish that I have seen a lot of what works and a lot of what does not.
Recently, I took over full responsibility for the IT organization at Virtual Instruments. My background has always been rooted in infrastructure: servers, routers, switches, endpoints. Taking on the application side of the business was a new challenge, and what I found when I got there was instructive in the worst possible way.
From Order to Chaos, and Back Again
I joined Virtual Instruments in 2009. On paper, I am employee number 76, and I am one of a small handful of people who have been with the company from its earliest days to now. During that time, the applications division was always a separate world from infrastructure.
For a while, it was run well. A Director of Applications named Anne was exceptional at her job. She had the skills, the discipline, and the professionalism to run a tight operation. You always knew where things stood. When she left in 2015, that position was not backfilled, and the vacuum it created had consequences that lasted years.
From late 2015 through early 2018, the applications team existed largely in firefighting mode. Too many tasks, not enough oversight, and no consistent framework to work within. A lot changed during that period. Almost none of it was documented.
When I took over in 2018, my first priority was to bring stability and industry best practices to a department that had been operating in the dark. That meant a significant amount of reverse engineering.
We use an ERP system that has no native integration with our CRM or warehouse platform. To bridge that gap, we rely on middleware, specifically Dell Boomi, to move orders between systems. What I found when I started digging into the existing Boomi workflows ranged from straightforward and logical to genuinely difficult to interpret. Some processes had multiple forked paths that seemed to meander without clear purpose. Staring at someone else's undocumented code and asking yourself what they were trying to accomplish is a frustrating and time-consuming way to run an IT operation.
It does not have to be this way.
Documentation Is Not Bureaucracy. It Is Respect for the Next Person.
I have lived by one principle throughout my career: there is no acceptable reason for an IT professional to skip proper documentation. None. Not timeline pressure, not team size, not the assumption that you will always be there to explain it yourself.
The framework I keep coming back to is ITIL. If you are not familiar with it, here is the short version. ITIL 3.0 is an industry standard framework that structures IT service management into five stages:
- Service Strategy
- Service Design
- Service Transition
- Service Operations
- Continual Service Improvement
Service Strategy aligns IT activities with the core needs of the business. Service Design creates and adapts services to support those needs. Service Transition moves systems through change management, testing, and knowledge transfer. Service Operation manages day-to-day events and incidents. Continual Service Improvement identifies opportunities to do things better over time.
Working within a framework like ITIL or COBIT makes undocumented work structurally difficult. The discipline is built in. When my predecessor operated without any framework, critical context was lost the moment a project closed. No notes. No decision rationale. No institutional knowledge. Just systems running on logic nobody could fully explain anymore.
Good documentation paired with sound architectural decisions creates systems that are manageable. The absence of both creates systems that are fragile and expensive to maintain.
The Tools That Made a Difference
Choosing the right framework is only part of the answer. You also need tools that support the work without getting in the way. Here is what we put in place:
Atlassian Confluence became our documentation hub. Of all the wiki-style platforms I have evaluated, Confluence is the most intuitive and flexible. The tool has to disappear into the work. If people are fighting the interface, they are not documenting.
A proper helpdesk and ticketing system is non-negotiable. Every IT team, regardless of size, needs a way to track incidents and requests. Metrics depend on it. Accountability depends on it.
GitHub gave our application team a place to store and version their code. Infrastructure teams may not use it daily, but for any team writing or managing scripts and integrations, it is indispensable.
Monday.com helped bring visibility to complex, multi-phase projects with a lot of moving parts and stakeholders who needed to stay informed without being in every meeting.
Slack improved day-to-day communication and collaboration across the team in ways that email simply cannot match.
Where We Are Now
Today, the applications team is visible, accessible, and effective. We are doing more with a lean, skilled group, supplementing with contractors when we have genuine technical gaps to fill. We are methodically working through systems that were previously black boxes, exposing what is inside, documenting what we find, and building a foundation that the next person can actually work from.
The lesson is simple. No IT team is too small to operate with discipline and documentation. A team of two people benefits from a framework. A team of five people needs one. The investment in doing it right the first time pays back every single time someone has to touch that system after you.
Document your work. Every time. No exceptions.
