The conversation

Lessons learnedExperience excerpt · English

A common mistake that some managers make is pushing the burdens of managing onto those you're …

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.

Original discussionIf you're remote, ramble464 source comments · at import
2

What was this responding to?

Parent context · original excerpt

AU

I understand the point you were making, but from a manager’s perspective this format is something we’ve tried to avoid. Having a place to have people ask questions is great and encouraged, but doing anything that starts gravitating the knowledge toward a person instead of a topic creates problems for discoverability, searchability, and risks creating the impression (for new employees) that certain specific people are at the center of projects they just happen to know a lot about. So while the Q&A format is good to have available, I’d discourage creating separate channels around a person. I would encourage everyone to just go to the appropriate topic channel and discuss it there. I do the same thing when someone starts asking specific technical questions in #random or #general: Redirect to the project specific channel. That’s the place where all of the relevant people will be relevant and…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

PA

> 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?

Full original
TR

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.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.