Don't Let People Management Take Up Too Much Of Your Time
Be an Eng Lead/Manager, not a Manager
There are three kinds of work an engineering manager1 must do:
People management.
Technical leadership, like scalability, reliability, data loss prevention, security / privacy, APIs, architecture, engineering processes (design review, code review and launch), making sure decisions that are hard to reverse are made correctly, a bit of project management, doing the final round of interviews to ensure a minimum hiring bar, creating a healthy engineering culture (tech talks, etc)…
Individual contribution: As an engineering manager, I would like to spend one day a week working by myself as an individual contributor, such as coding. This is different from guiding others (see point 2).
People management can expand to take up all your time if left uncontrolled, crowding out the remaining two. To prevent that, we should set limits on how we’re going to manage people:
Coordination: I’ll expect employees to coordinate with their peers, rather than having me do it for them. I can do it once or twice to show them and then say, “This is what you do from now on.” Coordination is part of the work. It’s everyone’s job, not just the manager’s.
Problems: I’ll expect people to bring up problems they’re facing, proactively. I used to go on long walks to put people at ease and ferret out problems like a counsellor would. It took a huge amount of time and I realized I’m not as skilled as a therapist at identifying problems. So in the future, while I’ll make a well-intentioned effort, I’ll expect people to bring up problems they’re facing.
Freedom: I’ll err on the side of giving people more leeway than they’re ready for than less.
Error correction vs prevention: Many managers obsess about preventing mistakes, but most mistakes are easily reversible, so I’ll focus on correcting rather than preventing them.
Teaching to fish, not giving fish: I used to work with an engineer Manish who’d never give updates on his project. So I used to call every week to get an update. Neither of us enjoyed the call. In retrospect, it was a mistake. I was giving him fish every week. Instead, next time this happens, I’ll teach him to fish. I’ll post on #engineering that every engineer should give a weekly update on every project he’s working on. If Manish didn’t give an update after an update, I’d post on the same thread after a week asking, @Manish, did you miss this message? If he still didn’t give an update, I’d call him up and ask why not. If he said he forgot, I’d tell him to make it part of his routine from now on. He can set a reminder in Google Calendar or whatever other app, but he should not tell me that he forgot. This is an example of teaching a person to fish (long-term) instead of giving him a fish (short-term).
1:1s: I’ll set up a few 1:1s2 with each subordinate, and then ask him to set one up whenever he wants, without hesitation, reminding him that it’s my job to help them. I won’t set one up from my side, not weekly, fortnightly or even monthly.
Feedback: I’ll expect people to seek out feedback from others and to give others feedback when they have something to share, rather than only through me.
Managing up: I’ll expect subordinates to be at least make an effort to manage up. Any relationship requires effort from both sides.
Personal connections: I’ll build personal connections with everyone I work with, but I’ll expect people to not gate any work-related conversations on this rapport. Some people won’t share unless they feel they’re friends with their manager. Rather than bending over backwards to accommodate that, I’ll expect people to be professional and initiate work-related conversations regardless of a personal connection.
Initiative: Many managers devote an inordinate amount of time to pushing people. They have daily stand-up meetings. They cajole people into working harder. They micromanage every task and ask if it can be done by Tuesday rather than Wednesday. They sometimes express their displeasure. Many managers spend a lot of their focus on motivating people. I’ll take a different approach. I’ll motivate people: I’ll create psychological safety so that people feel free to take reasonable risks. I’ll create a great engineering culture focused on continuous improvement and knowledge-sharing. I’ll challenge people to do work one level above what they’ve been doing. But I’ll expect people to also take the initiative to work better, and to improve themselves. Both intrinsic (self) and extrinsic motivation (manager) need to be in place. It can’t just be extrinsic and 100% manager-driven. If people try their best and have a problem and call me for help, I’ll always answer. But they should call me. I won’t keep calling people up and pushing every day. They should pull. I’ll push a couple of times. I’ll show them by doing it once or twice and then ask, “Next time, why don’t you try doing this on your own?”
Behavior change: When I observe behavior in a group (like a Slack channel) that’s not helpful, I’ll point out the behavior changes that are required to be made in the same group. Not in private as I used to. For example, I might post “We already discussed this topic last week and decided to do <X>. Now, I expect you to follow the decision made and build on top of it so that we can make progress, not ignore what was said and go back to square one.” on a channel where someone exhibited the wrong behavior3.
These limits will ensure that people management remains contained, leaving plenty of time for the other two categories mentioned at the top of this post, which are engineering leadership and individual contribution.
I’ll share a version of this list with employees written in a way that’s easy for them to understand and follow.
Or VP or CTO — anyone who has people reporting to him.
In this context, a 1:1 means a meeting where we discuss the employee, how he’s feeling, any irritations he’s facing, whether he feels he’s progressing towards his career goals. Not how the project is going or when it will be done.
I tried doing it in private (1:1) for many years, and it didn’t work, for multiple reasons: If there are 20 people in a team, and each person needs to be told thrice before he changes, that’s 60 times, which is too annoying and too much of a time waste for me.
People also take what’s said in public more seriously.
I’ve seen people play tricks by pretending not to know something. When I posted in a group with all the relevant people on it, all these games stopped immediately, because nobody could pretend anymore.
Saying it in a group also serves to unify the team by establishing a common standard of behavior, so that we don’t have different people operating in different ways.
If I say something in a group, it will also force me to be more constructive and less irritated than I otherwise would be.
These are all the benefits of pointing out behavior changes in a group when a problem occurs in the group, rather than pointing out the changes in private.