Managing Reports

Engineers, whether or not individual contributors do have to manage people at some point in their careers. Ideally, you or your organization should hire people no one has to manage. Most companies are far from that.

Enabling is the best word to manage reports. Instead of managing them enable them. Enable them to do their best job and be resourceful enough to make that happen. Give your reports all they need to do their job well. It includes access to necessary accounts, access to yourself, access to each other, access to code, and infra. Give them your trust, responsibility, and overarching guidelines. Set expectations, and set them free. Some will take that opportunity and make the best out of it. Some will fall flat on their faces. Those who don't get it, help them understand in detail what is expected of them and how they could manage themselves. Some people are very good followers and would wait for directions from their managers to act or think. Help them understand that they can think and act regardless they have a manager or not.

For small companies and startups, keep people in your team that you don't have to manage. Hire managers of one. Big companies? We shouldn't have any. I suppose, a bit optimistically, that the time is near when we won't have big corps. There is no humane advice I can render for managers of big companies and especially big teams. One cannot do justice to all reports if you have more than 10 people on a team. 10 is already too many. Keep it at 5 to 8. A manager should have equal skin in the game as the people whom he/she manages. If the reports are coding, a manager should code. A manager who doesn't code won't be able to manage effectively. You have to understand the day-to-day, hour-to-hour challenges your reports deal with. A manager who is just a people manager is the worst case in a tech company. That idea comes from industrial-era floor managers/foremen. Don't be that manager. Such a company/team becomes slow, bureaucratic, and goes downhill fast.

Here is an excerpt from an essay by the legendary Paul G

Companies know groups that large wouldn't work, so they divide themselves into units small enough to work together. But to coordinate these they have to introduce something new: bosses.

These smaller groups are always arranged in a tree structure. Your boss is the point where your group attaches to the tree. But when you use this trick for dividing a large group into smaller ones, something strange happens that I've never heard anyone mention explicitly. In the group one level up from yours, your boss represents your entire group. A group of 10 managers is not merely a group of 10 people working together in the usual way. It's really a group of groups. Which means for a group of 10 managers to work together as if they were simply a group of 10 individuals, the group working for each manager would have to work as if they were a single person—the workers and manager would each share only one person's worth of freedom between them.

In practice a group of people are never able to act as if they were one person. But in a large organization divided into groups in this way, the pressure is always in that direction. Each group tries its best to work as if it were the small group of individuals that humans were designed to work in. That was the point of creating it. And when you propagate that constraint, the result is that each person gets freedom of action in inverse proportion to the size of the entire tree.

Trust people to do their best work. If the trust is breached tell them with 100% clarity what you think happened. Do not sugarcoat negative feedback. But hear them out too. Encourage them to speak their mind. If the trust is breached without a plausible explanation multiple times, let them go. Give a few chances to people but not at the expense of the rest of the team and culture.

People do a disservice by not firing bad performers. It is a disservice to the bad performer and to the rest of the company. We indirectly signal that it’s okay to not do your job as you are supposed to. It’s okay to not put in the work. We also signal to the good performers that we don’t value their work as much. Fire people, so they understand the gravity and work on themselves. More about hiring and firing here.

Shield your reports from the ill culture of your organization if you inherit any. Especially in communication. If you had your ass handed to you by your boss, do not let that feedback seep through you into your team. Be the shock absorber.

Hold 1-1 every week. Create a bond that they feel comfortable opening up to you about their problems. Feedback cannot be delayed for more than a week. I think it should be relayed quicker than that. I have seen managers hold all the feedback until the performance review. That sucks. No one who is interested in building a good company of people would like to do that. Interestingly very few people are interested in building a good company of people. They are interested in improving the KPIs that will make them look good to their managers.

Review your reports' code even unsolicited and give direct feedback. Observe how they communicate in different channels and give feedback privately. Keep a close eye but don't micromanage.

Sometimes your reports could be better engineers/professionals than you, understand that and give them space to shine. Give them all the credit and take the blame. Give them space to make mistakes and learn from them.

If someone on your team joined recently from a different organization or team, they would be super observant about issues in the team and recognize them faster than other people. Listen to them and improve.

Do not ask for estimates. Do not set unnecessary deadlines. More on estimations later.

Communicate asynchronously. Programming needs focus. Do not kill your reports' productivity by constantly pinging them. More about communication here.