Numbers To Know For Managing (Software Teams)
Learning how to manage is a long race - it takes many years and each lap offers new learnings. Along the way, anchors emerge that can help orient you when a number of other variables are in flux.
Learning how to manage is a long race - it takes many years and each lap offers new learnings. Along the way, anchors emerge that can help orient a manager when a number of other variables are in flux.
Below we offer a number of these anchors. They are based on philosophy, experience, and analysis; we hope they’ll be of some use.
0 - the number of times you should lie
Being a manager often means having privileged information. However, some may think that means they must occasionally lie. That is a mistake.
Management is a skill that requires always telling the truth, but not every truth you know. One easy way to avoid lying is to be clear that you can’t answer a question, whether it’s the answer someone wants or not.
“Are we having layoffs next week?”
“Listen, you know I wouldn’t be able to answer that question even if it was the case. Let’s talk about your concerns though.”
0 - the number of pages your team should get off hours
Pages during the workday are somewhat unavoidable - high speed teams will make mistakes that need to be reverted. However, outside business hours, your team should not be making changes to production. Therefore, issues should be rare. Aim for an average of 0 off-hours pages a week to know your team is prioritizing fixing causes of pages. And remember - stop writing great runbooks.
1 - the number of times you should try to reverse a sincere resignation
Retaining high performers is critical. If a high performer gives notice: stop, listen, and try to retain. Retention might mean a role change, a compensation change, a promotion, growth path alignment, or more.
However, if they sincerely resign a second time, you should let them leave. At that point, you risk retaining them when it’s no longer healthy for them. Worse, you risk showing that that behavior is how to get rewards.
2 - minimum number of direct reports anyone should ever have
It’s easer to manage four people than one person - managing one person creates a very problematic dynamic. Ideally people should have 4 or more reports.
3 - the minimum number of candidates you should interview before making a decision
Even if you think you have a great candidate out of the gate, you should commit to seeing at least 3 people before making a decision.
4 - the number of minutes to spend on chit chat in the beginning of a meeting
At the start of a meeting, take about 4 minutes to ask how everyone is doing - less is curt; more is wasting time.
5 - the number of comments on a document before you should ask to talk about the issue
Megathreads in documents are a waste of time and a breeding ground for conflict. If you’re at 5 comments, find time to chat.
6 - the number people tell you when they’re very unhappy
If you ask people how satisfied they are with their job, on a scale of 1-10, people will answer 8, 9, or 10 when they’re happy, 7 when their neutral, and 6 when they’re quite unhappy. Few people will tell you below a 6 unless they’re walking out the door.
7 - the number of days before a new hire should have merged a pull request
Getting a PR merged in the first week is critical to set pace and get early reps on the SDLC.
This also scales to other roles - in general, look for the first week to be a place where a first, small item is concretely delivered.
8 - the % of people that should be rated as underperforming in a growth company during a bull market
There are exceptions if you happen to be managing the navy seals or if you have known pockets of major performance issues, but for average teams you’re likely going to have about 8% of your team fall on the very bottom of the bell curve for any given cycle.
8% is roughly 1 in 12 people. For longtime managers in growth companies, if you count your reports, I’d hazard that’ll seem about right. Some out there use human psychology and performance studies to back similar numbers - this is just what I’ve seen, and roughly squares with much of that literature.
10 - the max % you should be looking to negotiate an offer
When hiring, you should be looking to negotiate about 10%, no more, no less. Expecting no negotiation is a recipe for failure. Going over 10% in negotiation means you either banded the role wrong or you are getting your arm twisted.
30 - the number of days before a small support issue becomes a large support issue
One of the classic unforced errors. in business is letting a support issue linger and linger. They’re often deprioritized to back burnered exactly because they’re low priority. However, if issues remain open for long enough, no matter the priority, they become the perfect spark to create customer frustration. Low priority issues + time = relationship killer.
50 - the number of Pull Requests a solid engineer should merge per 6 months
Many may contest this, but in my experience, no matter the seniority or amount of other things on their plate, a solid software engineer that is working on a live-in-production piece of software ships, on average, at least a couple PRs a week.
70 - the target % close rate for recruiting in a “regular” market
In a not-crazy market, 70% is a good target for close rate in recruiting for companies with over 100 people.
Unless your brand is crazy elite, higher than 70% might mean your bar is too low or your pay is too high. Lower than 70% often means you’re not closing effectively enough, wasting the team’s time on recruiting cycles.
90 - the number of days a role should stay open
90 days is the industry standard time-to-hire metric.
100 - the way you should keep it
You’re keeping it 100 reading this far. Thank you.
200 - the maximum size of “small data”
With data sets under 200 rows, you can usually run an analysis by hand - it’s small data. This is useful for managers, because for most managers your team will be under this number, your recruiting activity will be under this number, and most of your people-related trends can be done without any fancy tooling.
500 - the number of employees before your CEO becomes a political figure
After 1000 people, your CEO becomes essentially the equivalent to the coolest kid in high school, or a small town mayor. If you grew with the company, you might not realize why adding someone onto a banal thread with the CEO could induce severe panic, but then you realize the CEO has become a political figure.
1000 - the size of company when you’re at risk of losing accountability
At around 1000 people, your company is large enough for people to claim with some validity that it’d be very difficult for them to deliver end to end business value. However, lack of accountability is one of the biggest culture viruses there is. Keep pressing to reward business value, and avoid anything that looks like “even though it failed, I did my piece and should get rewarded.”
3905 - the average number of days from initial funding to IPO, for companies that make it
Durability is one of the most important qualities of leaders in growth companies. For long tenured leaders in growth companies, you’ll lead, on average, through multiple election cycles, at least a handful of “once in a lifetime” events, a number of personal life changes, and potentially even a major, unprecedented culture shift. Change is the only constant and you must be ready to embrace it.
There's definitely something wrong with your hire or onboarding if a new dev hasn't merged a PR within the first week.