Every August, the same thing happens in districts of 1,000 to 10,000 students. New teachers arrive on a Monday. They have two days of district orientation, one building day, and then students walk in. Somewhere in that window, a five-person technology team is supposed to hand each of them a login, a device, a learning management system account, a gradebook, a data-privacy briefing, and a working understanding of how to get help. The packet that gets handed out is usually a 40-page PDF assembled in July by someone who is also imaging 600 Chromebooks.
It does not survive. Not because it is wrong, but because it is the wrong kind of document. A packet that survives August is a map, not a manual. It tells a new teacher where to go on which day and who to ask, and it deliberately leaves out anything that will be stale by October.
The binding constraint is maintenance, not content
Most onboarding packets fail on the back end. A five-person team can write almost anything in June. What it cannot do is keep a 40-page document accurate through a fall LMS update, a device refresh, a new gradebook module, and a mid-year change in the help-desk vendor. Every page that names a product feature is a page that will be wrong.
So the design constraint comes first: before writing a single page, decide who owns the packet, when it gets revised, and how it gets distributed. One owner. One revision window, ideally the third week of September, after new teachers have actually used it. One distribution channel, so there is no question about which version is current. If those three things are not settled, the packet will be a one-time artifact, and next August someone will rebuild it from scratch.
The tradeoff is real: a leaner packet means the team gives up the satisfaction of a comprehensive reference. It also means the team stops maintaining a document nobody reads in October.
Component 1: the one-page first-30-days tech map
The first page is a calendar, not a curriculum. It answers one question: what do I need to have working, and by when? For a typical new teacher, that is a short list of days, not a list of tools.
- Day 1: network and email credentials, badge or device pickup location, and the name of the building tech contact.
- Day 2: learning management system login and the one course shell they will actually use in week one.
- Day 3: gradebook access and the first roster check.
- Day 5: the help-desk address and the triage card (below).
- Day 10: a 20-minute check-in with the instructional coach or building tech contact, whichever the district has.
Consider a hypothetical new fourth-grade teacher in week one. She needs a login, a device, a gradebook entry, and a person to ask about a student data question. Those are four different destinations, often in four different buildings or systems. The map’s job is to make all four obvious on one page, in the order she will need them.
What this page costs: it forces the team to commit to dates. If device pickup is not actually ready on Day 1, the map exposes that. That is a feature, not a bug, but it means the map has to be written by someone who has confirmed the dates with the people who own them.
Component 2: the who-to-ask triage card
This is the highest-leverage page in the packet. Most new-teacher technology questions are not hard. They are misrouted. A question about a student’s data export goes to the help desk, sits for two days, and comes back as “ask the data-privacy contact.” A question about a projector goes to the instructional coach, who does not fix projectors.
The triage card lists four destinations and what each one handles:
- Building tech contact: devices, projectors, printers, classroom network, password resets.
- District help desk: account access, software installation requests, LMS problems that are not building-specific.
- Data-privacy contact: questions about whether a tool can be used with student data, parent requests about records, and anything involving exporting student information.
- Instructional coach: how to use a tool for teaching, not whether it works.
State response-time expectations plainly, and only promise what the team can meet. A card that says “building tech contact responds within one school day; district help desk within two” sets an expectation the team can actually keep. A card that promises same-hour response will be wrong by the second week of September, and new teachers will stop trusting the card.
The tradeoff: publishing response times creates accountability. If the help desk cannot meet two days in September, the card becomes a source of frustration. The fix is to set the expectation conservatively and revisit it in the September revision, not to leave it vague.
Component 3: three tool-agnostic habits, not a product walkthrough
The habits section is where most packets bloat. A tool-by-tool walkthrough of the LMS, the gradebook, the assessment platform, and the interactive display is obsolete the moment any one of them updates. Instead, anchor the habits to roles rather than products, using the ISTE Standards for Educators as the organizing frame.
The ISTE Standards for Educators are organized around seven roles: Learner, Leader, Citizen, Collaborator, Designer, Facilitator, and Analyst (ISTE). Three of those map cleanly onto what a new teacher needs in the first month.
Learner
The Learner standard describes educators setting professional learning goals to apply technology-enabled teaching practices and reflect on their effectiveness (ISTE). In the packet, this becomes one sentence and one action: pick one thing you want to get better at with technology this year, write it down, and bring it to your first check-in. That is a five-minute task, not a training module.
Citizen, with a focus on data
The Citizen standard includes managing and protecting student data (ISTE). The packet should not attempt to recite FERPA. It should give new teachers one rule they can apply before they use any new tool with students: if the tool requires a student login or collects student work, check with the data-privacy contact before using it. That single rule prevents most of the problems a small district actually encounters, and it does not require the tech team to write a legal primer.
Collaborator
The Collaborator standard describes educators dedicating planning time to work with colleagues on technology-leveraged learning, and collaborating and co-learning with students to troubleshoot technology issues (ISTE). In practice, this is the habit of asking a colleague before filing a ticket, and of treating a broken tool in front of students as a teachable moment rather than a crisis. The packet can say that in two sentences.
What this section costs: it is less satisfying than a product walkthrough, and some new teachers will want the walkthrough. The answer is to point them to the vendor’s own training materials and to the building tech contact, not to reproduce those materials in a district document that will be wrong in six weeks.
What to leave out on purpose
The packet gets stronger as it gets shorter. Three categories should be cut deliberately:
- Full app inventories. A list of every approved tool is a maintenance liability. Point to the current approved-tool list wherever it lives, and note that it changes.
- Policy recitations. The acceptable-use policy and the data-privacy policy are board-approved documents. The packet should link to them and summarize the one or two rules a new teacher needs in week one, not reproduce them.
- Anything that will be wrong by October. Product features, menu paths, and screenshots are the first casualties of any update. If a page cannot survive a routine software update, it does not belong in the packet.
The tradeoff is that the packet will feel incomplete to someone who wants a single reference. That is the point. The packet’s job is orientation, not documentation. Documentation lives in the knowledge base, where it can be updated without reprinting anything.
The September revision loop
The packet is not finished in August. It is finished in late September, after new teachers have used it. Build the revision into the plan from the start: during the third week of September, collect the three questions new teachers actually asked most often, and fold the answers into the packet. Then retire anything nobody used.
This is a small amount of work, maybe two hours, and it does two things. It makes the packet better for next year’s cohort, and it gives the tech team a concrete answer when the school board asks whether the onboarding investment is paying off. The answer is not a satisfaction survey. It is a shorter, more accurate packet and a list of the questions that actually came up.
The tradeoff: the September revision competes with the start-of-year ticket backlog. Put it on the calendar in June, assign it to the packet owner, and treat it as a fixed commitment rather than something to do when things slow down. Things do not slow down.
Surviving the board meeting and the school calendar
A packet that gets described as a “compliance document” will be routed to legal review, and it will miss August. Scope it narrowly in board-facing language: this is an orientation aid, not policy. It summarizes where to go and who to ask. It does not create new obligations, and it does not replace the board-approved acceptable-use or data-privacy policies.
That framing matters for two reasons. First, it keeps the packet on the technology team’s timeline rather than the board’s. Second, it keeps the packet honest. A document that claims to be policy has to be maintained like policy, with review cycles and legal sign-off. A document that claims to be a map can be revised in September by the person who owns it.
There is a broader point here about how small district technology teams describe their work. The NIST Cybersecurity Framework, for example, is described on its own page as helping organizations better understand and improve their management of cybersecurity risk, and as intended for industry, government, and organizations to reduce cybersecurity risks (NIST). That is a useful frame for a district’s security posture, but it is not a requirement for a new-teacher packet, and the packet should not borrow its language. The packet’s authority comes from being accurate and short, not from sounding official.
What good looks like on August 15
A packet that survives the August rush has four pages, one owner, and a revision date on the calendar. It has a one-page map of the first 30 days, a triage card with response times the team can meet, and three habits tied to roles rather than products. It links to policy instead of reproducing it. It is handed out in one channel, and it is revised in September by the person who owns it.
That is a smaller deliverable than most districts attempt. It is also the version that is still accurate in October, which is the only test that matters.
FAQ
How long should the packet be?
Four pages is a reasonable target for a district of this size: one page for the 30-day map, one for the triage card, one for the habits, and one for links to policy and the approved-tool list. Length is less important than whether every page can survive a routine software update.
Who should own the packet?
One person on the technology team, named in the document itself. Shared ownership is the most common reason packets go stale, because no single person is accountable for the September revision.
Should the packet include screenshots?
Generally no. Screenshots are the first thing to go stale after an update, and they add pages without adding much for a teacher who is already in the system. Point to the vendor’s own training materials instead.
How does the packet relate to the acceptable-use policy?
The packet links to the board-approved policy and summarizes the one or two rules a new teacher needs in week one. It does not reproduce the policy, and it should be described to the board as an orientation aid rather than a policy document.
What if the district does not have an instructional coach?
Substitute the building tech contact or a designated mentor teacher for the coaching destination on the triage card. The card’s value is in routing questions to a named person, not in the title of the role.