Ask HN: Non-obvious product/engineering processes to set up when scaling team?

I don't know if this is non-obvious, but only one other team I've worked at or with has done this.

Creating a team playbook. This would document processes and responsibilities that were otherwise institutional knowledge.

One person on the team knows how to grant access to a particular tool? Add it to the playbook.

One QA is in charge of the test automation jenkins- add it to the playbook.

Everyone on the team knows how to build the app - doesn't matter, add it to the playbook.

The idea being that if

* there's some action that people in the team do over and over again, or

* if colleagues outside your team repeatedly ask your team to take care of something,

writing it down helps spread the knowledge on how to deal with that issue AND it helps establish a centralized, consistent set of actions to address the issue.

fwiw, in my current team, I use it to document processes that folks rely on my team for (access requests, data pull requests, common customer support problems).