Published: 2025-09-30

Notes for IT Engineering Teams

Teams do better when information is easy to find, share, and update. Too often, knowledge gets scattered across emails, chat threads, personal notes - or worse, it never gets written down at all. To address this, I created a OneNote template that serves as a single, organized knowledge base for the team, and a simple methodology anyone can follow to take notes as they work.

This template balances technical documentation, meeting notes, troubleshooting guides, and upgrade processes, all within a structure that is intuitive and easy to maintain. The template is intended to be filled in PER technology, meaning that each technology the team manages should have its own dedicated copy.

Why Notes Matter

Notes are the backbone of an efficient engineering team. Good documentation allows each member to focus on their area of expertise without needing to be involved in every project, while still staying aligned with the rest of the team.

Each engineer acts as a Subject Matter Expert (SME) in specific technologies, developing deep knowledge in key areas, yet maintaining enough shared understanding that anyone on the team can step in, contribute, or take over when needed.

This structure also empowers leaders to delegate tasks confidently -- assigning responsibility to the right engineer and allowing that person to take ownership, build confidence, and grow their expertise.

Together with practices such as daily standups and team meetings, well-maintained notes ensure that every engineer can excel in their specialty while the rest of the team remains informed and capable of supporting their work in their absence.

Well-written notes make it possible to:

• Share knowledge quickly and clearly
• Avoid re-learning the same lessons individually
• Speed up problem-solving and onboarding
• Allow each team member to work more independently
• Enable the team to handle a larger workload at once
• Provide a living runbook for troubleshooting and upgrades
• Avoid the "I can't remember what we did..." problem

Mindset Shift

For this process to be effective, it requires a certain discipline: every engineer must consistently record their work -- especially changes to the technology, troubleshooting steps and resolutions, and “how-to” guides.

The best way to approach this is to work from the note itself. In other words, creating the note becomes the central activity, and the task naturally emerges from the act of taking notes. Whatever you do, start with a note -- either a new, empty one or within an appropriate existing section.

Three Simple Concepts

1. Capture What's Needed

• Ask: “What steps would another engineer need to follow to get the same result?, “What do I need to record to explain what happend and how I solved it?” or "What might the team need to remember in the future?"
• Include both overview (awareness, context, background) and details (step-by-step).(This is where AI tools like Copilot can rally help!)
• Don’t forget screenshots where helpful.

2. Organize The Hierarchy

• Start messy if needed, then come back later to reorganize.
• Think table of contents: what will the structure look like once you’re finished?
• Keep a logical flow so notes can actually be followed.

3. Keep It Updated

• If you learn something new or something changes, update.
• Use the date under the page title to keep track of the latest version.

Sample Notes Page

• (2). The table of contents comes later after you've written the raw notes.
• (1). These are the raw notes: the Overview (1B) comes after the details (1A) as they are jotted down while you work.
• (3). Go back and update things as needed.

Imagine jotting down notes while making coffee so you can later share the recipe with a friend. As you go, you record each step of the process. Once you’re finished, you might reorder your notes to make them clearer. At the end, you could write a brief overview of the process and, once everything is organized, add a table of contents to make it easy to follow, especially if the notes are quite long. Building the table of contents might help you realize you need to move things around or fill in some information.

The OneNote Template

How to Use It

Create a OneNote section using the structure below and name it so you can recognize it as a template. Copy this section each time you onboard a new technology, or once for each technology your team already maintains.

• Encourage consistency: everyone places notes in the right section.
• Use subpages for specifics: each incident, upgrade, or meeting gets its own page.
• Archive regularly: move old content to keep the main sections tidy.

Version 1

You can download the (.one) file linked here: z_tmplSuppTechnology

Example

Structure Here’s the high-level layout of the OneNote template, with a description of how each section should be used: Alerts Does this technology need alerting configured? How are the alerts received? (email, SIEM, dashboard, SMS, etc.) How often do they need to be created or reviewed? What levels of alerts do we need? Emergency - critical issues requiring immediate attention. Action - issues that require follow-up but are not urgent. Aware - informational alerts to maintain visibility. Architecture Drawing showing how the technology fits in with others. These do not have to be formal, enterprise-approved diagrams. The purpose is to help the team and new team members learn, and to serve as a reference for discussions. Audit Any documentation, screenshots, evidence for audits like HITRUST, SOC2, etc. Screenshots will need to be updated, but this section can help an engineer find where to take the screenshots, etc. Certificates Does this technology use any certificates? How are they obtained and installed/implemented? Expiration management - how do we get alerted or know when a certificate is nearing expiration? Licensing Capture all licensing information. Keys, renewal dates, vendor instructions. Logging How is logging performed? What information needs to be captured? Does the logging information need to be sent somewhere? (e.g., SIEM, centralized log store, monitoring platform) Meetings Meetings worth keeping and sharing with team members. Use subpages like 202X-04-XX for dated notes. Owner Who owns the technology and who uses it. Great for clarifying responsibility. Recurring Requests / Tasks Good for new people. Step-by-step how-tos for daily/weekly requests. Reporting What needs to be reported on this technology? How does the reporting get implemented? (dashboards, scheduled reports, automated exports, etc.) Scenarios / Changes These are mini projects you work on for that technology. Examples: making a change, enabling a new feature, testing a configuration, or rolling out a small initiative. Great for documenting the steps so they can be reused or referenced in the future. Tech Notes (tn) This is where we keep the “how-to” documentation for using that technology. If the technology is large and has multiple sections or modules, break them out into separate groups: tn – Module Name 01 tn – Module Name 02 Each header page organizes its module, and subpages under it hold the details. Training Capture training materials, summaries, and lessons learned. Notes that will benefit teammates in the future. Troubleshooting / Incidents Anytime something happens, record it here. Excellent for building a learning archive for the whole team. Upgrades Log of upgrades to the technology. Include dates, versions, steps taken, and lessons learned. Vendor Info Vendor contact information and links to official documentation. Useful for support cases and escalation. z-Archives.old Place any old pages here to keep the main notebook clean. Keeps a history without clutter.

Version 2

Here is a second version of the template, where the pages from version 1 are broken into sections. Each technology would get it's own "Section Group".

You can downlod the (.onepkg) file linked here: z_tmplTechnology_v2

Example	Structure
	Audit Any documentation, screenshots, evidence for audits like HITRUST, SOC2, etc. Screenshots will need to be updated, but this section can help an engineer find where to take the screenshots, etc. Licensing Capture all licensing information. Keys, renewal dates, vendor instructions. Owner Who owns the technology and who uses it. Great for clarifying responsibility. Training Capture training materials, summaries, and lessons learned. Notes that will benefit teammates in the future. Vendor Info Vendor contact information and links to official documentation. Useful for support cases and escalation.
	Recurring Requests / Tasks Good for new people. Step-by-step how-tos for daily/weekly requests.
	Breaking the meetings down into their own section allows for more meetings notes and more flexibility. Meetings Meetings worth keeping and sharing with team members. Use subpages like 202X-04-XX for dated notes.
	Alerts Does this technology need alerting configured? How are the alerts received? (email, SIEM, dashboard, SMS, etc.) How often do they need to be created or reviewed? What levels of alerts do we need? Emergency - critical issues requiring immediate attention. Action - issues that require follow-up but are not urgent. Aware - informational alerts to maintain visibility. Logging How is logging performed? What information needs to be captured? Does the logging information need to be sent somewhere? (e.g., SIEM, centralized log store, monitoring platform) Reporting What needs to be reported on this technology? How does the reporting get implemented? (dashboards, scheduled reports, automated exports, etc.)
	Architecture Drawing showing how the technology fits in with others. These do not have to be formal, enterprise-approved diagrams. The purpose is to help the team and new team members learn, and to serve as a reference for discussions. Certificates Does this technology use any certificates? How are they obtained and installed/implemented? Expiration management - how do we get alerted or know when a certificate is nearing expiration? Tech Notes (tn) This is where we keep the “how-to” documentation for using that technology. If the technology is large and has multiple sections or modules, break them out into separate groups: tn – Module Name 01 tn – Module Name 02 Each header page organizes its module, and subpages under it hold the details. Upgrades Log of upgrades to the technology. Include dates, versions, steps taken, and lessons learned.
	Troubleshooting / Incidents Anytime something happens, record it here. Excellent for building a learning archive for the whole team.
	z-Archives.old Place any old pages here to keep the main notebook clean. Keeps a history without clutter.

How to Roll It Out

ADKAR

ADKAR is a change-management model from Prosci that focuses on individual behavior change, which is exactly what note-taking habits are. ADKAR breaks change into five stages, each of which maps cleanly to improving documentation and knowledge sharing.

Awareness

Why change? - Goal: Help the team understand why better note-taking matters.

For note-taking, Awareness means clearly communicating:

• Knowledge loss when people move on, forget, or leave
• Repeated work caused by undocumented fixes
• Slow onboarding and increased dependency on “that one person”
• Risk during incidents when context isn’t written down

Key message:

“We’re not bad at our jobs. We’re losing value because our work disappears.”

If people don’t believe there’s a problem, they won’t change how they work.

Desire

Why should I care? - Goal: Create personal motivation, not forced compliance.

Desire grows when people see:

• Fewer interruptions because answers live in notes
• Less pressure to remember everything
• Recognition for creating reusable knowledge
• Easier handoffs and vacations without guilt

Important: You cannot mandate desire. You enable it by showing that:

• Notes protect their time
• Notes reduce their stress
• Notes make their work visible and valued

Knowledge

How do I do this correctly? - Goal: Remove uncertainty and friction.

Teams often fail here by saying “document more” without explaining:

• What should be documented
• Where notes should live
• How much detail is “enough”
• What a “good note” looks like

For note-taking, Knowledge includes:

• Simple templates (problem, context, steps, outcome)
• Examples of good real notes from the team
• Clear expectations (notes during work, not after)
• Naming conventions and structure

Key principle:

If people aren’t documenting, it’s often because they don’t know how, not because they don’t want to.

Ability

Can I realistically do this? - Goal: Make the new behavior achievable under real conditions.

Ability is where change often breaks down.

To enable Ability:

• Reduce friction (fast note tools, screenshots, copy/paste)
• Allow imperfect notes (not everything must be polished)
• Encourage documenting while working, not at the end
• Make notes part of the workflow, not extra work

Critical insight:

If note-taking feels like “extra work,” it will always lose to urgent tasks.

Reinforcement

How do we make it stick? - Goal: Prevent regression to old habits.

Reinforcement should be:

• Positive (recognition, reuse, appreciation)
• Visible (linking notes in tickets, incidents, reviews)
• Consistent (leaders modeling the behavior)

Effective reinforcement examples:

• “This incident was resolved faster because of X’s notes”
• Sharing useful notes in team channels
• Referencing notes during meetings instead of re-explaining
• Treating notes as the source of truth

What not to do:

• Punish people for missing notes early on
• Turn documentation into a checkbox exercise