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

Numbers To Know For Managing Software Teams

Random Posts

Abolish performance reviews

  • July 13, 2018

I have never been a fan of performance reviews. It may have been down to the way they were implemented at the places I worked however they never seemed to achieve what they were set out to do. The review would usually consist of going over the “achievements” for the past period and then setting a bunch of artificial goals for the next period. The only time these new goals were actually consulted was in the run up to the next review.


Read More

Questions to ask yourself before you buy

  • November 4, 2020

Sometimes it is very easy to buy things just for the sake of it. We get that rush when either we bring the item home or it is delivered. It is easy to form an addiction to that feeling.


Read More

In a distributed system ... there is no now

  • May 29, 2018

This paper is a discussion around the issues faced by distributed systems when dealing with time, ordering and failures. This is particularly relevant with the work I am doing at the moment designing a very large distributed system that will need to scale massively.


Read More