> I'd love to experiment with hiring someone whose primary accountability is answering everyone else's questions, not generating output It's an interesting ide

> I'd love to experiment with hiring someone whose primary accountability is answering everyone else's questions, not generating output It's an interesting idea, but I think the problem is that someone who can do this role (the intersection of technical competence and desire) is going to be exceedingly difficult to find or may not exist at all. Someone that's going to be capable of providing useful answers to developer questions is likely to be a developer themselves, and almost certainly they're not going to stick around in that position for long. Part of being an effective "librarian" in this way is going to be knowing where to go to get a specific answer -- the existence of specific documentation, which group/team/person is responsible for which component, the levels of expertise of people on teams so you can immediately contact the lowest level person capable of answering, and eventually just knowing answers yourself. All of that comes with time, and if you have high turnover this isn't going to happen. Also, someone that does the role poorly is going to be worse than nothing: unnecessarily bothering others for (maybe the wrong) information, providing incorrect answers, and/or making incomprehensible documentation. My guess is it's probably hard to judge someone's performance at this until they've been doing it for at least a couple weeks. If you also have high turnover, you will end up with people not suited for this role.