Post History

There's no quick or complete fix, but the following things have worked for me.

## Plant the seeds early

First, involve those new hires.  When everything is new to them, you are in a better position to plant "culture" seeds.  Maybe your old-timers have gotten used to not documenting anything, but they are no longer the only people on the team.

As part of onboarding, we point newcomers to our existing documentation (wiki), and we *tell* them there are probably some omissions and things that aren't as clear as they could be and maybe even some things that are no longer true.  (We went through three corporate acquisitions in five years; our IT-infrastructure pages were kind of a mess.)  We ask them to update things that need it as part of their onboarding process.  We also show them where to get help if they're not sure what it should say (this is wrong/missing but don't know what's right).  **Editing is easier than creating new documentation, so start there.**

## Use the wiki for more things

You're using a wiki for process documentation, it sounds like.  That's good.  Are you also using it for functional specs, roadmaps (what are we doing over the next few releases?), meeting agendas and notes, team-specific information?  Do people have personal pages?

In my experience, people will use the tools that people are using in the ways they see people using them.  Our chat integration is *probably* not the best way to manage automated tests, but it's where people are so we send reports there.  The wiki might not be the best place for meeting agendas, but since it *is* a good place for *notes* from those meetings, it's natural to keep them together.  And by all means, include the fun stuff too; in the pre-pandemic times we had occasional team outings and we posted pictures there.

A goal of all this is to **make the wiki a natural stopping place**, something that people will tend to keep open in a tab or several.  Once people are there, people are more likely to fix stuff.

## Ask for specific help, not general appeals

Don't ask people to write unspecified stuff.  For some people, even asking them to document a specific process might be too much at the start, without managerial support and more of a team expectation.  I try to draw people in by asking them to *review* or *update* stuff -- hey $busy-senior-colleague, I think this description is mostly accurate but I'm not sure about a couple points; could you make a pass over it?  Even if you can only get them to review and not update, and you have to make the changes yourself, you've at least gotten someone else involved in the information content.  It's a start.