Numbers for managing teams
Sometimes you come across an article that makes you think. The article, Numbers To Know For Managing Software Teams, made me do that.
My daytime role involves managing helping a team of developers to deliver a great product. The article lays out a number of guidelines for how often something should happen. I don't necessarily agree with all of them but it is an excellent thought exercise to look at what you do and come up with your own set of guidelines.
For example,
7 - the number of days before a new hire should have merged a pull request
We try and achieve this within 2-3 days.
5 - the number of comments on a document before you should ask to talk about the issue
I thought this was an interesting rule of thumb. So much time and effort could potentially be saved by doing this.
Links