[fallous]

A common mistake that some managers make is pushing the burdens of managing onto those you're managing. Any of us who have been managers can look back and see things that we tried to push down to those we've managed because it made it easier for us while later realizing that wasn't the best solution.

If there's a catch-all channel that employees are using to share knowledge that's not a bug, it's a feature. If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together. Trying to push that burden down the chain often results in that institutional knowledge being shared verbally or via private emails/DMs in order to avoid the burden of documentation, which is a net negative.

Such information is a force multiplier for teams as well as a great asset for onboarding new hires. Both of those are direct benefits for the manager and the company, so take the advantage of that kind of spontaneous documentation rather than insisting on passing on the cognitive burden.

[tracker1]

IMO, the greatest force multiplier in onboarding is automation... How many user interactive steps does a dev need to walk through to get up and running?

I've often gotten this down to a single directory and a primary script you need to run 3-4 times... mostly because of required reboots, such as after WSL setup, also, a few options to set in Docker Desktop. I've done similar with mac/homebrew.

From there, you have docker-compose and shell scripts to run against the projects... these scripts and the compose file(s) are the entry points into a project, actually documenting where things are, and how they connect (to an extent).

Effectively, getting a working solution running sooner than later. This is just my own opinion, but automating a dev environment for onboarding, especially if you're a larger org, is a great tactical decision.

[xp84]

Heavily seconding the “setup script” method for anything that can be scripted in lieu of documentation and handholding. I’ve done this at multiple companies and it proved valuable. Even if it eventually breaks it’s easy to fix, and it’s usually pretty self-documenting, so anyone who’s even a little curious what’s going on, they have access to all the “secrets” of how it’s being done (and can also improve it).

[pammf]

> If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together

Isn’t the GP describing exactly that?